VivaLinux!

Y después de haber sido "incubado" desde finales del año pasado en la Apache Software Foundation (ASF), el sistema de control de versiones centralizado de Subversion (SVN) finalmente ya es oficialmente un proyecto de primer nivel en la prestigiosa organización sin fines de lucro. Un comité de directores de la ASF así lo votó ayer y la comunidad de SVN se apresuró a festejarlo poco después. El nuevo hogar de Subversion ahora puede encontrarse en subversion.apache.org.

Aunque para los actuales usuarios de SVN todo esto significará poco, sí es un indicio indiscutible del ascenso en la aceptación del modelo de desarrollo compartido pero descentralizado de otros sistemas de control de versiones más modernos como Git, Mercurial y Bazaar, a costa de la popularidad de los viejos sistemas centralizados como SVN. Lo que a su vez hace inevitable la pregunta:

¿Se está convirtiendo Apache en el cementerio de elefantes de los proyectos de código abierto?

Red Hat comenzó a migrar a sus clientes desde Xen a KVM comenzando a medidados del año pasado como parte de su nueva estrategia de virtualización construída completamente sobre la máquina virtual basada en el Kernel Linux (proyecto que a propósito lidera desde que compró Qumranet en el 2008). Su distribución Red Hat Enterprise Linux (RHEL) se convertiría poco después en la primera en soportar comercialmente a KVM.

Ahora Novell quiere seguir esos mismos pasos, apostando también fuertemente a KVM, pero bajo sus mismas reglas. Y así comenzaría a hacerlo con su proyecto AlacrityVM, un nuevo hypervisor basado en KVM pero "enfocado en la performance" que ya demuestra unas mejoras notables.

Según la página de AlacrityVM:

“Los entornos virtualizados a menudo imponen significativas penalidades en la performance en una carga de trabajo determinada cuando se los compara con equivalentes nativos. Este proyecto está motivado en la creencia de que esto no tiene que ser necesariamente así, y que no necesitamos hardware exótico para conseguirlo. AlacrityVM demuestra que la mayoría de los cuellos de botella en la performance se deben a pilas de software sub-óptimas.”

Adobe estuvo recibiendo duras críticas últimamente, notablemente también la del mismo Steve Jobs, por culpa de su plataforma Flash. Como parte de su defensa, en su blog Open at Adobe se publica un artículo donde intentan explicar por qué no pueden abrir el código del reproductor de Flash. Y aparentemente el culpable sería un viejo conocido:

“La principal razón por la que no podemos el Flash Player como Open Source es porque hay tecnología en el reproductor que no es nuestra, como el códec de video de alta definición estándar de la industria, H.264. Adobe paga por ese códec para que el video se reproduzca confiablemente en todo el mundo, en varios navegadores y sistemas operativos. Así que lo hacemos tan abierto como podemos - liberando las especificaciones.”

Las especificaciones del formato de archivos de Flash (SWF) sí están abiertas, y teóricamente cualquiera puede hacer su propio reproductor, incluyendo a Apple. Gracias a esas especificaciones es que sí existen reproductores libres, como Gnash y Swfdec.

La promesa de Nokia de hace dos años se hizo realidad hoy mismo, cuando finalmente el gigante finlandés de la telefonía móvil abrió todas casi todas las 40 millones de líneas código fuente de su sistema operativo Symbian bajo la licencia EPL (Eclipse Public Licence); que notablemente no requiere que sus usuarios contribuyan sus modificaciones de vuelta a la comunidad.

La mayor parte del código está disponible en el sitio de desarrolladores de Symbian, con algunos componentes amparados bajo otras licencias similares a la EPL y algunas herramientas bajo la Symbian Foundation License (SFL). El código de estas últimas está disponible sólo a las instituciones que se hagan miembros de la Symbian Foundation.

Adelantándose a rematar cualquier inevitable comparación con el sistema operativo Android de Google, Lee Williams, el director ejecutivo de Symbian Foundation aclaró que:

“Cerca de un tercio del código de Android está abierto y nada más. Y lo que está abierto es una colección de middleware. Todo lo demás está cerrado o es propietario”.

Symbian actualmente hace funcionar a la mayoría de los teléfonos de Nokia (aparentemente más de 330 millones) y también a otros de algunas empresas más, como Sony Ericsson, Motorola, Samsung y Panasonic. ¿Suficientes para atraer a más desarrolladores?

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.

Hasta este momento la muy anticipada versión 2.8 de GIMP no tenía ni siquiera una fecha de lanzamiento tentativa, prefiriendo sus desarrolladores sólo mencionar que sería lanzada "cuando estuviera lista". Ahora es el contribuyente de ese proyecto Martin Nordholts el que adelanta en su blog que finalmente hay una fecha estimada y que esta sería el próximo Lunes 27 de Diciembre.

Obviamente, esa fecha todavía debe considerarse como un objetivo tentativo, que entre otras cosas ayude a los desarrolladores de GIMP a orientar mejor su trabajo.

Por otro lado, Nordholts reporta además que se avanzó en la refactorización y la "limpieza" del código para implementar la próxima única ventana de GIMP y que también se agregará soporte para múltiples ventanas acopladas (como se muestra en la captura de arriba).

Con este brevísimo mensaje se anunció que el "Steering Committee" del GCC (GNU Compiler Collection) aceptó el frontend gccgo para su inclusión en su versión 4.5 o posterior, el que agregará soporte para el lenguaje de programacón Go de Google en la imprescindible colección de compiladores del proyecto GNU.

Esta noticia llega sólo días después de que en el último el índice de TIOBE, empresa que publica mensualmente un ránking de la popularidad de los lenguajes a nivel mundial, Go apareciera por primera vez en el puesto número 13 convirtiéndose en el escalador más rápido de todos y ubicándose sólo detrás de Objective-C (el del iPhone y Mac OS X) a pesar de haber sido lanzado oficialmente hace menos de 3 meses.

Además de C y C++, GCC incluye actualmente frontends para lenguajes como Ada, Fortran, Java, Objective-C y Objective-C++; otros frontends disponibles pero que todavía no son parte oficial de GCC incluyen a Cobol, D, Pascal y Modula-2/3, entre otros.

La semana pasada YouTube y Vimeo presentaron las versiones Beta de sus sitios con soporte de HTML5 para ofrecer, por primera vez, la reproducción de sus videos usando el códec h.264 sin necesidad del plugin de Flash, pero sólo para Google Chrome, Internet Explorer y Safari. Para aclarar por qué Firefox no está entre los navegadores soportados, Mike Shaver, el vice presidente de ingeniería de ese proyecto, explica en su blog el motivo por el cual Mozilla no licencia el uso de ese códec.

Básicamente, h.264 no es un códec apropiado para Mozilla por dos principales razones: su costo de licenciamiento y su naturaleza de código cerrado. Así que, mientras que Google, Microsoft y Apple pagaron por una licencia para incluirlo en sus productos, Mozilla no lo hizo y no lo hará. Sin esa licencia es ilegal (en muchos países) "usar o distribuir software que produzca o consuma contenidos codificados con h.264".

En palabras del mismo Shaver:

“La web es innegablemente mejor porque Mozilla entró en el mercado de los navegadores, pero hubiera sido imposible hacerlo si habría existido un costo de licenciamiento requerido para usar HTML, CSS, JavaScript y otros”.

h.264 puede ser, cuestionablemente, mejor que Theora en este momento, pero lo mismo podría haberse dicho de Flash hace 10 años comparándolo con la mejor tecnología libre disponible en aquel entonces. Sin embargo, hoy todos sabemos cuál es el precio que pagamos, y seguimos pagando, por hacer a la web dependiente de ese pedazo de software propietario.

La talentosa diseñadora gráfica venezolana Tatica, reconocida por sus contribuciones al proyecto Fedora, está publicando en su blog la serie de podcasts Gimp100 que en los próximos 3 meses presentará una colección de videos demostrando las técnicas básicas para el uso de GIMP, el querido programa libre de edición de imágenes digitales en formato de mapa de bits.

Los cuatro muy recomendables videos podcasts publicados hasta ahora incluyen: Selección rectangular, Herramienta de selección libre, Blanqueando dientes y Piel de porcelana (el más reciente, reproducido arriba), todos disponibles en español y también en inglés.

Matthew Papakipos, el director de ingeniería del proyecto Chrome OS de Google confirmó en una larga entrevista que ese sistema operativo incluirá su propio reproductor multimedia. Concretamente, sus desarrolladores estarían trabajando en este momento en "integrar un reproductor multimedia en Chrome y en Chrome OS":

“La gente a menudo se confude acerca de esto, y es un punto bastante sutil pero importante. Porque de alguna manera, lo que estamos haciendo es integrar el equivalente de Windows Media Player dentro del mismo Chrome.

Cuando uno tiene una computadora, hay otra cosa que necesitas: necesitas una manera de reproducir JPEGs, MP3s y PDFs y todo eso cuando estas online. Por ejemplo, puedes tener una llave USB con unos MP3s que te gustaría conectar y escuchar. Puede que no haya ninguna página web para controlar esa actividad, pero es claramente algo que necesitas ser capaz de hacer en cualquier sistema operativo o navegador.

Así que estamos trabajando mucho para hacer que Chrome y Chrome OS puedan manejar esos casos también.”

Otros cambios muy interesantes también incluirían la forma en que se manejan los documentos enlazados en las páginas web: por ejemplo, cuando uno hace click en un enlace tipo mailto: en lugar de abrir la típica aplicación de escritorio configurada por defecto, podría abrirse GMail. Otros documentos, como imágenes JPEG podrían abrirse en un sitio web, como Picasa en lugar de arrancar el visor de imágenes tradicional.