Los usuarios que han migrado desde Windows encuentran en esto un paso atrás: una cosa es el sistema operativo y otro las aplicaciones; se pueden ir añadiendo y actualizando aplicaciones sin cambiar de sistema. Para el uso empresarial esto también es importante: los programas se certifican para una versión y es un riesgo demasiado elevado que para actualizar otra aplicación no crítica haya que migrar de versión absolutamente todo y cambien un montón de programas; habría que hacer de nuevo un montón de pruebas.
Sí, existe la opción de instalar un programa por tu cuenta; hoy en día posiblemente no haga falta andar compilando las fuentes para ello ni enfrentarse a un infierno de dependencias y haya un repositorio no oficial que lo hace todo por tí, mucho más fácil que en Windows. El precio es que esos programas no tienen las mismas garantías de actualizaciones automáticas de seguridad que los de la distribución, ni la certeza que no se rompan dependencias y los vayamos a conservar el día que ahora sí migremos a otra versión.
Tenemos que espabilar y ofrecer un modelo más evolutivo en las distribuciones, frente al "revolutivo" actual de cambiar todo a la vez. Y más cuando Microsoft anunció planes de que las futuras versiones de Windows serán más modulares, que no habrá nuevas versiones completas sino que se irán actualizando por partes. No vale tampoco el modelo de instalar paquetes de "unstable" de Debian: para tener la última versión de un programa se cambia de la versión de otros muchos que afectan al resto de aplicaciones y no hay garantías de seguridad ni de estabilidad.
Un posible cambio al modelo actual para hacerlo "evolutivo" sería acuñar un nuevo término "certificada" para la actual distribución "estable" basada en que sólo hay actualizaciones críticas y de seguridad, reutilizando el término "estable" para paquetes que sí pueden migrar de versión, pero con tal que sigan siendo estables y muy importante, que no supongan cambiar otros paquetes. Por ejemplo que no haya que cambiar de versión de glibc.
Así, el paquete de la versión "certificada" de Ubuntu Dapper continuaría siendo la 1.5, mientras que la estable sería ahora la 2.0, pero eso sí, dependiendo de las mismas librerías que la 1.5. Tanto una como otra serían totalmente oficiales, soportadas por el equipo de seguridad, con actualizaciones durante la vida de la distribución y garantía de ser reconocidas al actualizar la distribución a la siguiente versión.
Vale muy bien, pero esto sería una carga para los desarrolladores, al tener que mantener más versiones de paquetes. Además, ¿no favorece el modelo "revolutivo" actual la innovación? el forzar a la gente a cambiar de versión, hace que todos los programas aprovechen lo último que hay, que no se pierda el tiempo con código viejo y se corra más rápido.
Respecto a la carga para los desarrolladores, hay varios elementos a tener en cuenta:
- sólo se mantienen dos versiones del paquete, no múltiples. La idea es que quien quiera quedarse en una versión y ya sólo tener actualizaciones críticas deberá quedarse en la certificada. Por ejemplo quien opte por la versión "estable" de Firefox, la 2.0, deberá contar con que cuando salga la 3.0 y sea estable deberá actualizarse a tal versión. Quien opte por plantarse en una versión, deberá quedarse en la 1.5.
- no es para todos los paquetes, sino para paquetes que se pueden cambiar de versión sin que afecten a otros muchos; por ejemplo no sería para glibc. Además en sistemas mantenidos por voluntarios como Debian puede ser una opción a decidir por cada mantenedor si va a ofrecer certificada y estable o sólo certificada, en qué momento lanza una versión estable y cuándo cambia de una versión estable a otra o decide plantarse en ella porque la nueva introduce demasiados cambios que pueden afectar a otros.
- esta idea no es para distribuciones como Fedora o para las Ubuntu normales, sino para las versiones LTS (Long Term Support: 3 años de actualizaciones para escritorio, 5 para servidor, frente al año y medio de las versiones normales). Esto también responde a la objeción de la menor innovación respecto a las distribuciones "revolutivas". Muy bien, conservemos esta característica en las distribuciones "no LTS", que seguirán siendo el terreno de pruebas y el paraíso de los que quieren siempre lo último.
- Puede extenderse (o no) a metapaquetes que incluyan librerías que sólo afectan a paquetes dentro de ese metapaquete y que conservan la compatibilidad hacia atrás. Por ejemplo puede decidirse que exista una versión de certificación y otra estable de todo Gnome, de tal modo que se podría optar a tener todo el sistema congelado excepto el escritorio, porque las aplicaciones que tenemos certificadas no dependen de GTK+ ni Gnome o sí lo hacen, pero resulta asumible confiar en la compatibilidad binaria hacia atrás.
P.D.: "revolutiva" es por supuesto una palabra inventada ;-)
P.D.2: por supuesto hay más alternativas para lograr una distribución evolutiva que el par "certificada/estable". Más sobre ello mañana y esta vez sí, porque ya la tengo escrita y guardada como borrador, para evitar como otras veces prometer una segunda entrada que no llega :-) Tweet
No hay comentarios:
Publicar un comentario