VivaLinux!

El desarrollador del proyecto Debian Maximilian Attems fue el primero en lanzar la voz de alerta en una entrevista cuando afirmó que el nuevo Red Hat Enterprise 6.0 (RHEL6) se distribuye con un Kernel 2.6.32 "en forma ofuscada".

Attems se refiere en realidad a que Red Hat no incluye en forma separada todos los parches que aplicó al Kernel Linux de su RHEL6, sino un gran "tarball" con todos esos parches aplicados juntos. Aunque este acto en sí no viola su licencia GPLv2 del Kernel, sí hace mucho más difícil a otras distribuciones que se basan en RHEL el trabajo de discernir cuál es el estado de ese Kernel antes de aplicar sus propios parches.

Tal es el caso de CentOS, la distribución comunitaria que es un clon a nivel binario de RHEL, pero también de Oracle Linux 6, que puede descargarse gratuitamente (al contrario que RHEL) y que tiene planes de soporte de U$S 99 por año (¿notablemente menos que los nuevos precios de RHEL6?).

Prontamente, la misma Red Hat Inc. publicó un comunicado de prensa aclarando su postura oficial en todo este asunto:

"Cuando lanzamos RHEL6 hace aproximadamente cuatro meses, cambiamos la versión del paquete de Kernel para tener todos nuestros parches aplicados por defecto. ¿Porqué hicimos este cambio? Hablando sinceramente, el marco competitivo ha cambiado. Nuestros competidores en el mercado del Enterprise Linux han cambiado su estrategia comercial de construir y competir con sus propias distribuciones de Linux, a una en la que directamente se acercan a nuestros clientes ofreciéndoles soporte para RHEL".

Finalmente se anunció así que sólo queda la aprobación de Linus Torvalds para que el módulo de seguridad AppArmor se integre en la próxima versión 2.6.36 del Kernel Linux.

AppArmor está implementado usando los Linux Security Modules (LSM) y permite al administrador asociar cada un perfil de seguridad a cada aplicación para restringir sus capacidades durante su ejecución. De esta manera se puede prevenir que un potencial atacante pueda explotar algún agujero de seguridad y así ganar acceso a los recursos del sistema.

Hace 3 años AppArmor quedó en manos de Novell cuando esa empresa compró Immunix, los de la desaparecida distribución del mismo nombre y también los creadores de ese módulo, para luego despedir a los programadores que lo desarrollaron.

Últimamente un desarrollador de Canonical estuvo trabajando frenéticamente en este módulo para llevarlo al nivel necesario para que su consideración para la inclusion en el Kernel sea un posibilidad real nuevamente.

Mandriva puede estar pasando por unos tiempos de cambios, pero es bueno saber que algunas cosas todavía siguen su curso normal. Por ejemplo, según este mensaje en la lista de correo de "Cooker" (su versión de desarrollo), se anunció que el esperado lanzamiento de las imágenes ISO finales de Mandriva 2010.1 "Spring" está planeado para el próximo 5 de Julio.

Por otro lado, Mandriva pierde a uno de sus desarrolladores del Kernel: Pascal Terjan, que trabajó en esa empresa por casi 6 años, decidió en el momento en que los rumores sobre el futuro de Mandriva habían alcanzado un nuevo fondo, aceptar una larga oferta de trabajo de Google. Terjan se desempeñará como un "Site Reliabilty Engineer" en las oficinas de Google en Londres a partir del próximo 6 de Septiembre. ¿Otros desarrolladores continuarán con el éxodo?

Desarrolladores en el Lawrence Livermore National Laboratory anunciaron en su lista de correo que lograron portar una sustancial parte del sistema de archivos ZFS de Sun/Oracle al kernel Linux. Este port nativo de ZFS puede ser compilado con Kernels hasta la versión 2.6.32 y ya fué probado exitosamente con los de Fedora 12 y los de las versiones 5 y 6 Beta de Red Hat Enterprise Linux (RHEL), todos en sistemas de 64 bits con el Solaris Porting Layer.

ZFS, originalmente desarrollado para Solaris, fué liberado por Sun hace un tiempo bajo la licencia CDDL, pero dada su incompatiblidad con la GPL, únicamente estuvo disponible como una implementación en el espacio del usuario vía FUSE.

En el sitio del Native ZFS for Linux se aclara que su idea es mejorar al sistema de archivos distribuído Lustre con soporte para ZFS. Con el trabajo realizado hasta ahora, Lustre puede usar directamente el ZFS DMU (Data Management Unit), que se conecta a la interface de hardware Storage Pool Allocator (SPA) en lugar hacerlo a través del ZFS Posix Layer (ZPL), que ofrece una interface para el sistema operativo.

Los desarrolladores aún no consiguieron portar el ZPL a Linux, por lo que todavía es imposible montar particiones de ZFS directamente. Supuestamente, la empresa KQ Infotech ya había estado trabajando en eso desde el año pasado, pero cúanto faltaría para aunar ambos esfuerzos es todavía una gran pregunta.

A principios de este año Android era eliminado del Kernel con algunos llegando a afirmar que Google no tenía intenciones de hacer las modificaciones necesarias para integrarlo nuevamente a la rama de desarrollo de Linux principal.

Un mes después Chris DiBona, el administrador de todas las cosas Open Source en Google, explicó que su verdadera intención es fusionar Android al Kernel "en el próximo par de años", un lapso realista que también había sugerido Linus Torvalds antes.

Ahora, tras la reciente Linux Foundation Collaboration Conference, se reveló que Google planea asignar a 2 desarrolladores para trabajar en la integración de las mejoras hechas para el Kernel de Android a la rama oficial de Linux mantenida por Torvalds. Un número de parches ya fueron propuestos para su integración, y estos mismos harían posible fusionar también una gran cantidad de drivers que habían sido excluídos anteriormente. La tarea llevaría tiempo, pero es algo que ocurre frecuentemente en el desarrollo del Kernel.

La actual versión 2.1 "Eclair" de Android corre sobre el Kernel 2.6.29, pero en lugar de un espacio de usuario (userspace) basado en aplicaciones construídas con frameworks como GTK+ (GNOME) o Qt (KDE), el de Android está basado en Dalvik, una máquina virtual Java especialmente diseñada por Google.

Parece mentira, pero ya pasaron 5 años desde que el desarrollo del Kernel Linx se pasó de BitKeeper a Git. Y para conmemorar un nuevo aniversario de ese acontecimiento, se publicó este video, disponible también en formato de alta calidad de 720p y 1080p, en el que se visualizan con unos vibrantes gráficos 3D todos los commits realizados en el respositorio Git del Kernel como son animados por la increíble utilidad Gource.

El código de Android fué recientemente eliminado del Kernel Linux en su actual versión 2.6.33, con Google incluso siendo acusado de intentar "dividir" (fork) su desarrollo para su propio beneficio. Con el fin de aclarar esa situación, Chris DiBona, el administrador de todas las cosas Open Source en Google, explicó en un e-mail que:

"(Android) no es un fork más de lo que lo es Red Hat Enterprise Linux o cualquier otra distribución. Todos los kernels son de alguna manera un fork por cierto tiempo, el truco es mantener ese delta pequeño. Estamos tratando de hacer un trabajo mejor para mantenerlo pequeño".

DiBona quiso destacar también cuán diferente es Android del resto del código en Linux:

"Para el trabajo que hacemos en nuestros sistemas no-móviles (kernels de producción y el resto) estamos muy cerca del principal hoy en día, pero Android no es lo mismo que un servidor conectado a Internet; y pensar que Linux en los móviles es lo mismo que Linux en el servidor o el escritorio es el motivo por el cual, hasta que llegó Android, Linux en los teléfonos celulares fué casi un fracaso total".

Y con respecto a la sugerencia de que la fusión del código de Android podría realizarse a tiempo para la versión 2.8 de Linux aclaró además que:

"2.8 es un concepto al que no todos los desarrolladores del Kernel adhieren, así que podría no ocurrir nunca. Yo estaría cómodo diciendo que nos gustaría fusionar (Android) en el (Kernel) principal en el próximo par de años".

Y esa última prudente previsión encaja muy bien dentro de historia reciente de incorporaciones de "dispositivos extraños" al Kernel Linux que mencionó recientemente el mismísimo Linus Torvalds.

Linus Torvalds confiesa en su blog que no siente un amor particular por los modernos teléfonos celulares:

“Generalmente odio los teléfonos -son irritantes y te distraen cuando trabajas, lees o cuando sea- Un teléfono celular es para mí una oportunidad para ser irritado donde sea que te encuentres. Lo que no es algo bueno.”

A pesar de haber poseído antes celulares de Motorola con Linux y hasta el HTC G1, el primero con el sistema operativo Android, Linus reconoce que raramente los usó y que en su lugar quedaron relegados sólo para jugar a Gálaga o al Solitario en largos vuelos. Pero con la excusa de tener también un GPS y usar las características de navegación de Google finalmente tomó la decisión de comprar un Nexus One, y esta vez su experiencia fué muy distinta:

“¡Qué diferencia! Ya no siento que estoy arrastrando un teléfono "por las dudas" necesite ponerme en contacto con alguien -ahora tengo un útil y lindo artilugio. El hecho de que puedo usarlo también como un teléfono es algo secundario.”

Linus también respondió a los comentarios sobre la reciente exclusión del código de Android del Kernel Linux:

“No me preocupo mucho por el desarrollo afuera-del-árbol para dispositivos extraños. Me gustaría que pudiéramos fusionar a Android, pero también acepto que faltan algunos años para eso. Tuvimos asuntos similares con las cosas de escalabilidad extrema de SGI, y tomó mucho tiempo antes de que el Kernel estándar fusionara todo eso.”

El hacker del Kernel Greg Kroah-Hartman reflexiona en su blog sobre el problema de las modificaciones en el núcleo de Linux hechas por Android, el sistema operativo para dispositivos móviles de Google que está aumentando su popularidad entre los modernos teléfonos celulares de varios fabricantes.

Básicamente, estos problemas, que ya causaron la eliminación de los drivers de Android de la actual versión de desarrollo 2.6.33 del Kernel, se deben a que su código fuente no es convenientemente mantenido por sus desarrolladores. Pero el verdadero motivo de esa aparente inexplicable desidia nos revela un poco más sobre la verdadera naturaleza de Android:

Kroah-Hartman explica que Android "es mucho más que sólo unos pocos drivers raros", se trata de un nuevo tipo de locks que debe ser integrado al Kernel, una infraestructura de framebuffer "totalmente diferente" y de drivers que deben ser modificados para soportar "un modelo de seguridad a veces bizarro".

Pero lo peor de todo es que si Google no fusiona su código con el Kernel las empresas que produzcan drivers u otro código para Android no tendrán la posibilidad de contribuir sus creaciones a la comunidad de Linux, quedando condenadas a ciclos de desarrollo y mantenimiento mucho más largos.

Según Kroah-Hartman, Google no muestra señales de estar trabajando para modificar su código, por lo que intentará exponer "todo el lío de Android" en la próxima conferencia CELF Embedded Linux, a llevarse a cabo del 12 al 14 de Abril.

Después de haber servido como CTO (Chief Technology Officer) de la Linux Foundation por los últimos dos años, Theodore "Ted" T'so anunció en su blog que ya es un orgulloso empleado de Google.

T'so es bien conocido en la comunidad de Linux por ser uno de los principales desarrolladores de Linux y el actual mantenedor de los sistemas de archivos Ext3 y Ext4, los preferidos por prácticamente todas las distribuciones modernas de ese sistema operativo. T'so también se apresuró a aclarar que en Google continuará trabajando en el Kernel y los sistemas de archivos y almacenamiento, comenzando por Ext4.

Es que Google, después de extensivas pruebas de performance, está migrando sus propios sistemas desde el antigüo Ext2 (presentado en 1993) a Ext4. Como dice otro desarrollador de Google en una lista de correo:

“La razón principal de la actualización es que a pesar de que Ext2 ha sido "lo suficientemente bueno" por mucho tiempo, el arreglo de los metadatos en un sistema de archivos anticuado condujo a lo que llamamos "inflación de la lectura". Esto es a donde llegamos cuando hacemos varios pedidos para leer un bloque de datos. En general, la latencia de una asignación de bloques pobre estaba causando problemas de performance”.