martes, agosto 28, 2007

Internet como servicio básico

Diversas organizaciones como Hispalinux, Internautas, AI2, ATI, AUGCYL..han propuesto a nuestros parlamentarios unas enmiendas a la Ley del Impulso de la Sociedad de la Información. En España la penetración de Internet se mantiene por debajo de la de otros países con similar desarrollo económico, por lo que es evidente que algo hay que mejorar. La cuestión a analizar es si estas propuestas son un paso adelante.

Una de las propuestas es que para dar acceso a Internet por parte de una Administración (por ejemplo un Ayuntamiento) o una organización que actúe sin ánimo de lucro, como una ONG o una asociación cultural, no tengan que pedir permiso a la CMT (Comisión Mercado de Telecomunicaciones). Estos dos casos se sumarían al ya previsto en la ley de redes gestionadas en régimen de autoprestación. Por ejemplo que los industriales de un polígono industrial o los vecinos de una urbanización no tengan trabas para montar su infraestructura de red.

Esta propuesta no quiere decir que un Ayuntamiento o una ONG pueda montar una red al margen de cualquier regulación: las regulaciones técnicas serán las mismas que las que debe cumplir una "teleco" (con el Wifi es relativamente fácil de cumplir, al usarse equipos ya homologados que transmiten a poca potencia). De lo que se habla es que se eliminen trabas burocráticas por parte de la CMT, comisión que no trata de aspectos técnicos sino como indica su nombre de "mercado".

Creo que la propuesta de Hispalinux es muy acertada y que las posibles redes Wifi de Ayuntamientos y ONGs no son una amenaza contra la libre competencia por la que deba actuar preventivamente la CMT. Algunas razones para pensar así:

  • La red Wifi que pueda ofrecer un Ayuntamiento o una ONG sin recurrir a una "teleco" no son competencia frente a una infraestructura cableada como el ADSL o la red de ONO. Empresas, profesionales y usuarios que hagan uso intensivo de Internet usarán una red de pago si está disponible. Una red Wifi gratuita de hecho beneficiará en corto plazo a las operadoras, al popularizar Internet y descubrir nuevos usuarios que demandarán más. Habrá usuarios que tengan bastante con la red Wifi gratuita, pero en su mayoría a falta de esta no contratarían un servicio más caro. Las "telecos" evolucionan a prestarias de comunicación global (Internet, llamadas móviles, pago por visión) que nunca ofertará una ONG o Ayuntamiento. Así las cosas y con la escasa oferta existente, obligar a las "telecos" a espabilar y ofrecer algo por lo que la gente esté dispuesta a pagar favorece la libre competencia.
  • Para cualquier infraestructura compleja las entidades recurrirán igualmente a empresas, sacando a concurso quién presta el servicio. Así pues, lo que se deberá vigilar es que en los concursos se garantice el acceso en igualdades de condiciones a cualquier empresa y no se cierre a una empresa pública. Sobre empresas públicas los que ya tenemos una edad podemos recordar lo "bien" que funcionaba Telefónica cuando era una empresa pública.
  • La parte del león en la economía de las telecomunicaciones está en los servicios que se presten sobre ellas. Las telecomunicaciones son las infraestructuras, como las carreteras y estructura ferroviaria y aeroportuaria en las comunicaciones "físicas". El que las infraestructuras de telecomunicaciones se crearan a la vez que las aceras, calzadas e iluminación con su misma titularidad (Ayuntamiento o en caso de urbanización privada, vecinos) sería un modelo más entre otros posibles, que admite variaciones, de igual modo que el estado crea carreteras y autovías y concede concesiones de autopistas. Por ejemplo el Ayuntamiento puede sacar a concurso la explotación de su infraestructura regulando las condiciones por la que otros proveedores de servicios pueden utilizarla pagando por ella.

viernes, agosto 03, 2007

Distribuciones evolutivas (y 2)

Decía ayer que hay más fórmulas para tener una distribución evolutiva que la propuesta de tener tanto paquetes "certificados" como "estables". Una de ellas es la de Red Hat, lanzar revisiones de su distribución enterprise en las que hay cambios pero el sistema base es el mismo, con lo que se garantiza la compatibilidad binaria. Algo parecido ocurría en los viejos tiempos de la Red Hat 7.0, 7.1, 7.2 y 7.3. Aunque este sistema sí implica actualizar la distribución, se supone que es un cambio controlado para que no deje de funcionar nada. Al fin y al cabo en Windows los famosos Service Pack también son una actualización masiva de sistema operativo ;-). Las distribuciones tipo RHEL así mismo suelen mantener la versión del kernel, pero portando a lo largo de su ciclo de vida drivers y a veces nueva funcionalidad de versiones del núcleo posteriores.

La otra idea interesante son los "backports" de Debian, también existentes en Ubuntu. Un "backport" es un paquete que se ha portado a una distribución estable, desde otra versión de la distribución lanzada posteriormente, pero muy importante, con las dependencias de la distribución vieja. Sólo hay "backports" de paquetes que no rompen compatibilidad binaria ni afectan a otros paquetes. Es una idea muy interesante, porque permite disfrutar de aplicaciones nuevas, pero ya probadas en otra distribución, sin tener que cambiar de versión toda la distribución. Además el mantenimiento no se dispara: en general es menos costoso mantener una misma versión del paquete para dos versiones de la distribución, que dos versiones distintas de una misma aplicación.

Lamentablemente es una buena idea poco llevada a la práctica. Los backports no están soportados oficialmente, no hay garantía de actualizaciones de seguridad o críticas, ni que se mantengan los paquetes mientras dura la distribución, ni que se tengan en cuenta el día que se migra el sistema a otra versión.

Para el caso concreto de Ubuntu, creo que sería buena idea una mezcla de la idea de los backports con la que comenté de la diferenciación entre "certificada" y "estable". El paquete "backport" portado de una distribución posterior, sería el paquete "estable", mientras que el paquete original sería el paquete "certificado". Aquí va la propuesta:
  1. Los backports sólo serían para migrar aplicaciones a las versiones LTS (Long Term Support), utilizando paquetes presentes en las nuevas versiones de ciclo ordinario que surjan posteriormente; por tanto no habrá nuevas versiones de los paquetes como mínimo hasta que surja una nueva distribución (6 meses después), ni volverá a cambiarse salvo para actualizaciones críticas y de seguridad hasta que vuelva a surgir otra distribución al cabo de otros 6 meses. En realidad estos plazos serán más largos, pues hay que dar un plazo para comprobar que el paquete realmente es estable y puede portarse sin problemas.
  2. Mientras dure la versión LTS estará garantizado que sigue actualizándose el "backport" con actualizaciones críticas y de seguridad. Una ventaja de los "backports" es que como esas actualizaciones críticas hay que hacerlas de todos modos para la versión nueva de la distribución, el mantenimiento es mucho más sencillo. Ahora bien, dado que la distribución LTS tiene más tiempo de vida que las versiones normales, podría darse el caso que un paquete procedente de un backport ya no se actualiza en la distribución de la que se portó. Afortunadamente, con aplicaciones de escritorio esto ocurrirá rara vez y durante poco tiempo, en el peor de los casos un año. Una distribución LTS tiene 3 años de vida en aplicaciones de escritorio frente a 1,5 de una distribución normal, pero la distribución normal como mínimo habrá salido 6 meses después de la LTS. Además, lo normal es que antes que acabe la vida de una distribución se cambie el backport al paquete de la siguiente distribución, salvo que no sea posible por romper compatibilidad.
  3. Una cuestión deseable, pero no imprescindible, es que sea posible una marcha atrás de un paquete "backport" al original (certificado), o que sea posible tener instalados los dos sin consecuencias. Por ejemplo habría que tener cuidado con los archivos de configuración y posibles opciones nuevas.
  4. Se puede considerar ir más allá de la idea original de "backport" y portar todo un bloque concreto, como Gnome. O hacer un "backport" de un componente crítico, como el kernel, que sin embargo afecta a pocos paquetes y rarísima vez a las aplicaciones finales de usuario.

En mi opinión es un buen momento para que en Ubuntu se planteen con más seriedad la fórmula LTS, que ya han confirmado estabilizaran con versiones cada dos años y me parece su aportación más interesante junto con el ciclo predecible de versiones. Lamentablemente Ubuntu entra en todos los frentes (por ejemplo en la de los sistemas "móviles") pero sin demasiada consistencia en comparación con lo que hacen los grandes como Red Hat cuando realmente se ponen con algo.

Mepis decidió volver a estar basada en Debian, por su decepción con Dapper sobre el hecho que no haya más que actualizaciones críticas: Mepis sí pretende tener una distribución más evolutiva, con versiones nuevas de las aplicaciones durante sus dos años de vida de actualizaciones.

La gran pega que veo a Dapper, es que es una versión más sólo que con actualizaciones críticas durante más tiempo, mientras que para Red Hat y Novell su orientación son las versiones enterprise y las otras tienen mucho de campo de pruebas para precisamente que las enterprise sean redondas. Dapper tiene fallos garrafales que no corrigen en temas como que la versión del compilador de c++ y la de gcj no coinciden, o que hay problemas para usar cups desde un sistema remoto. El institucionalizar los backports en las LTS sería un buen punto de inflexión.

Distribuciones evolutivas

No señor, no tiene sentido. Si quiero cambiar de Firefox 1.5 a Firefox 2.0, si necesito una versión de DCRaw que soporte mi cámara de fotos o si me gustaría aprovechas las últimas características de OpenOffice, tengo que migrar de versión mi sistema operativo. Mi Ubuntu Dapper tiene aún garantizadas actualizaciones durante un par de añitos, pero desde el principio sólo son actualizaciones críticas y fallos de seguridad, nada de cambios de versión. Aunque no afecten a ningún otro paquete del sistema y sean versiones totalmente estables.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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 :-)