MeeGo y su pequeña ventaja en la salida

El proyecto MeeGo ha tenido 6 presentaciones en la conferencia "Linux Foundation Collaboration" -últimamente hay una barbaridad de estas conferencias-, y en una de ellas, Arjan Van De Ven, ex-Red Hatero y trabajador de Intel, describe la organización de la nueva distro:

"Architecture maintainers are responsible for integrating hardware-specific patches into the single MeeGo source base - upstream first" policy for patches!". Es decir, los fabricantes tendrán que ocuparse de conseguir por su propia cuenta la inclusión en el kernel de las modificaciones y drivers que utilicen para que Linux soporte su harware.

Los fabricantes de hardware, ya se ha dicho por aquí varias veces, solo piensan en vender hardware. Se olvidan pronto del software. Se dan, por esta razón, casos de fabricantes de hardware que han adaptado toda una distro para su producto sin preocuparse de contribuir el código. Luego han puesto a la venta el dispositivo, han publicado el código modificado en un FTP, y se han olvidado del asunto. Pueden hacerlo así, claro, y en algunos casos no importa. Para eso está el software libre.

Otros muchos, en cambio, pronto descubren lo contraproducente de este sistema. Tienen que mantener el software, y se encuentran con miles de líneas de código que tienen que cargar a su espalda. Tarde, descubren que mucho mejor hubiera sido preocuparse de adaptar el código y meterlo en upstream en su día. El mejor ejemplo de esto es Android. No quisieron contribuir su código al kernel. DiBona -el jefe de opensource en Google- despreció las críticas que se hicieron al respecto. Creían que podían vivir solos, por su cuenta. Ahora se encuentran con una situación infernal: Las decenas de empresas interesadas en Android están basando su trabajo en un repositorio interno de Google. La cantidad de código no presente en upstream está creciendo rápidamente.

Ahora, Google se encuentra con que cada vez que quieran actualizar el kernel de Android, tienen que hacer un esfuerzo enorme para portar todo ese código a la nueva versión (lo mismo que les pasa con los kernels de sus servidores, que tienen 300.000 LoC de parches sobre un kernel 2.6.26).

Tras todo este nulo esfuerzo por sincronizarse con upstream, Google no solo se encuentra con que les hubiera costado menos contribuir que mantener el código por su cuenta, se encuentran con que más de un teléfono que hoy lleva Android no podrá actualizarse en el futuro. Drivers propietarios no actualizados, bases de código desactualizadas, no mantenidas. Ahora, tarde ya -pero mejor tarde que nunca- han contratado a dos programadores con la única misión de incluir el código de Android en upstream, para arreglar el problema. Bienvenida sea esta magnífica iniciativa, pero MeeGo, con su política de "upstream first" (la misma que usa Red Hat), tiene el problema resuelto de antemano.

Dejándome en evidencia

En la serie de tres entradas que hice farfullando sobre las tiendas de aplicaciones, me jugué la boca diciendo que creía firmemente que Apple acabaría extendiendo la App Store a toda la gama Mac.

Hoy, Steve Jobs confirma explícitamente -últimamente está contestando a mucha gente mediante email, curiosa iniciativa mediática- que de App Store en OS X 10.7, nada de nada. Porca miseria. En realidad no me doy por vencido: La pregunta contiene dos cuestiones diferentes, y la respuesta es demasiado genérica.

En cualquier caso, da igual: Si Steve no quiere una App Store, Ubuntu si, y francamente tiene una magnífica pinta.

El plugin ODF de Oracle para Microsoft Office

Oracle ha empezado a cobrar por el plugin ODF que Sun desarrolló para Microsoft Office. Mucha gente parece haberse escandalizado por ello, y yo también al principio...pero al final ha acabado pareciéndome incluso buena idea.

Y es que a quien más daño hace no disponer de ese plugin es, en realidad, a Office. Dado que se puede decir que ODF ha triunfado, la carencia de buen soporte de ODF es un problema para Office, y una ventaja para Openoffice.

RHEL 6 Beta 1

Red Hat ha anunciado la disponibilidad de la primera beta de Red Hat 6. Se trata de un evento muy importante, dada la importancia de Red Hat, y para ellos en particular es un importante salto hacia adelante: RHEL 5 fue publicado en 2007 y su base ya es vieja. Por ejemplo, su kernel base es el 2.6.18 (estamos por la 33), y aunque tienen disponibles paquetes alternativos con versiones más nuevas, y han portado varias novedades de versiones nuevas a 2.6.18, sigue siendo un lastre de cara a los nuevos clientes (los programas que se certifiquen para RHEL tienen que soportar esa versión). Y quien dice el kernel, dice todo lo demás.

Asi que RHEL 6 es un importante lavado de cara. La base con la que se compararán otros SOs, el espejo en el que se mirarán otras distros. De este modo Red Hat recoge beneficios de todas las mejoras que los programadores de la compañía han hecho en todos estos años.

¿Qué hay de nuevo en esta versión? La documentación de la Beta aun no está completa, pero los aspectos fundamentales están claros. Basado en el kernel 2.6.32, promociona a Ext4 como sistema de archivos primario, y mención a XFS como opción escalable, y a btrfs como experimental. LVM tiene varias mejoras. , varias mejoras tambien en el apartado de gestión de energía, con la inclusión del modo "tickless". Inclusión de toda una suite para facilitar la gestión de clusters. Inclusión tambien de Netlabel (que permite aplicar políticas SELinux a paquetes de red), y, por supuesto, adopción sin complejos y sin backports de todo lo relacionado con KVM y libvirt, y abandono de Xen como host. Sin olvidar el gestor de procesos CFS y los "control groups" que tanto juego darán a los admins. Y perf y Systemtap a todo trapo, claro. Y KMS.

En resumen: Nada que pueda sorprendernos. Todo lo que ya conocemos y usamos en distros como Fedora, Ubuntu o Suse desde hace 3 ó 4 años. Al fin y al cabo, se trata de una distro que se centra en la estabilidad. Hay que compararlo, claro, con lo que han estado utilizando los clientes de Red Hat hasta ahora, que por cuestiones de estabilidad han preferido no arriesgarse aun con algunas de estas cosas. Pero si tenemos en cuenta de dónde sacan el dinero las empresas que más contribuyen código libre, como Red Hat, esta renovación supone sangre nueva, un impulso.

Un detalle cargado de significado: Incluyen y consideran una novedad importante a Nouveau, el driver para tarjetas Nvidia.

Javascript

Tener un blog que pretende seguir e incluso predecir las modas tecnológicas de Internet tiene sus riesgos. Cuando uno escribía, hace pocos años, de aplicaciones web que sustituirían a las aplicaciones de escritorio de toda la vida -es lo mismo de lo que hablaba todo el mundo-, uno intentaba hacerse una idea de como sería la cosa más allá de las palabras huecas de los evangelizadores, preguntándose cómo funcionarían sus engranajes. Sin embargo, a medida que el futuro se va haciendo presente, las realidad va desbancando a las imágenes. Llega Gmail, llega Google Maps, llega Google Reader, llega Google Docs, llegan mejoras drásticas en la ejecución de Javascript, y el progreso tan idealísticamente anhelado se hace un hueco en la vida cotidiana y se convierte en algo muy útil y con piezas muy bien ensambladas, pero pierde su halo de ideal y maravilloso, que ya no sorprende a nadie (excepto a unos pocos e interesantes casos). Lo olvidamos y pasamos a anhelar el siguiente invento que los medios nos prometen para dentro de pocos años, y que no hará sino repetir el ciclo de permanente ilusión-desencanto que nos causa nuestro hambre insaciable de progreso material.

Esto viene a cuento de lo que ya se ha anticipado en internet varias veces: la posible ascensión de Javascript a lenguaje el que se acabarán escribiendo no ya las aplicaciones web, sino todo tipo de aplicaciones que tengan requisitos "generalistas". Se puede opinar que no es un lenguaje bonito, que si sus entornos de desarrollo, que si diferencias entre navegadores, que si no permite acceder al software ya existente, que si cualquier otra cosa. Pero tarde o temprano tocará incluir funcionalidades de redes sociales, implementar interacción con alguna cosa de Google, o utilizar una librería que esté escrita en Javascript. Cosas así, ya saben. Sumas de factores que acaben impulsando a los desarrolladores en masa hacia entornos basados en ese lenguaje. ¿Por qué C++/Win32 creció tanto en los 90, por ejemplo? Su ascenso sorprendió a muchos críticos y despistados lo mismo que hoy nos sorprende el navegador.

El caso es que Gnome Shell, el gestor de ventanas/escritorio de Gnome 3.0 está escrito en Javascript. ¿Es un absurdo o una genialidad? Puede ser una nueva ocurrencia lingüistica de la comunidad gnomera, o una genialidad que le de gran relevancia en un mundo futuro en el que los escritorios sean al estilo de eyeos. Puede ser una pasada de frenada, al estilo de todo aquel asunto ya olvidado de CORBA y bonobo, o no. A un servidor, de momento, le parece añadir un lenguaje más a la eterna discusión gnomera de cuál debe ser el lenguaje prioritario para implementar aplicaciones. Pero igual me equivoco.

Nuevo mazazo al Itanium

Hoy hemos sabido que Microsoft no soportará Itanium más allá de Windows 2008 R2. Que los de Redmond pasen de Itanium es comprensible, dado que es un procesador utilizado principalmente en un sector dominado por Linux. Ahora bien, se nos recuerda en esa noticia que Red Hat tampoco soportará Itanium en RHEL 6 (cuya beta, por cierto, podría ver la luz en menos de un mes). ¿Quien quedará para soportar Itanium? ¿Debian? ¿OpenVMS? Definitivamente, no parece un gran rival como procesador de "propósito general".

Todo apunta a que la muerte del Itanium se está acelerando con más rapidez de la que se esperaba. Ni los evidentes sobornos a analistas de mercado han podido ocultar la realidad. Hace unos años anunciaron la "Itanium Alliance", que prometía invertir en el Itanium mucho más dinero del que las previsiones de ventas más optimistas podrían devolverles (es decir, que esa alianza era un farol). Su última versión, el Tukwila, incluye el nuevo bus QPI, que entre otras cosas está diseñado para que sus placas puedan utilizar, con tan solo un cambio de BIOS, procesadores x86-Xeon o Itanium. Intel dice oficialmente que hace esto para que los fabricantes de servidores puedan ahorrar dinero haciendo una sola plataforma para ambos; a mi me parece una estrategia deplorable para que, una vez asesinado el Itanium, sus clientes se pasen a Xeon y no a otros competidores. Aunque con el anuncio de Microsoft, quizás no les de tiempo a engañarles.

Parece que finalmente será así como comenzará el fin de esta desgraciada arquitectura, especialmente desgraciada ahora que las GPUs le hacen dura competencia precisamente en lo que sobresalían. De todos modos, era una arquitectura horriblemente compleja. No sé si ustedes saben algo de formatos de instrucciones. Si su universidad les obligó (como desgraciadamente me pasó a mi) a estudiar en alguna ocasión el formato de instrucciones de los VAX o el horrible formato comprimido de los x86, sepan que son un jolgorio comparado con Itanium. Si el diseño de compiladores es uno de los campos más difíciles del software, sepan que Itanium complica esta tarea hasta el punto de que algunos de los problemas que plantea son a día de hoy irresolubles. Y, a pesar de que se suponía que todo ese diseño debía servir para simplificar la CPU, lo cierto es que los Itanium han batido en varias ocasiones los records de número de transistores. Definitivamente, el apodo "Itanic" que le dieron en The Register fue una profecía.

(PD: Perdón por la prolongada ausencia de actualizaciones)