Oracle pierde la oportunidad de liberar completamente Solaris

Tras muchos rumores, Oracle ha confirmado con toda rotundidad su posición a favor de que Solaris siga siendo software libre. Dicho de otro modo, que las cosas van a seguir como hasta ahora. Desgraciadamente, el estado de las cosas hasta ahora no era precisamente perfecto, y Oracle no parece tener intención de solucionarlo.

Para contribuir código a OpenSolaris, Sun requiere un trámite legal consistente en reconocer a Sun como co-propietario del copyright del código. Esta práctica es común en muchos proyectos, como todos los de la FSF y Apache. Pero esas entidades son fundaciones independientes sin ánimo de lucro, por lo que cederlas o compartir con ellas el copyright no es tan duro para el programador, ya que se tiene la garantía de que las fundaciones van a utilizar esa cesión de derechos en pro del bien común.

El caso de Opensolaris es distinto. El contribuidor al proyecto tiene que ceder sus derechos no a una fundación, sino una empresa con ánimo de lucro y accionariado. Con la compra de Sun, Oracle adquirió también el copyright compartido de las contribuciones de Opensolaris, Java, MySQL, y OpenOffice. Puede utilizar, por tanto esos derechos en beneficio exclusivo para sus accionistas. Y, lo peor de todo: No es que haya posibilidades remotas de que esto pueda pasar, sino que lleva años pasando.

En efecto, Opensolaris es un proyecto totalmente libre, pero además de ese proyecto libre existe un Solaris "oficial", uno que no lleva el "Open" delante, precisamente porque no es "Open", incluye partes de código propietario. En principio, sacar una versión de OpenSolaris con adiciones propietarias es un incumplimiento de la licencia...pero el propietario del copyright puede saltársela (incluso puede publicar varias copias del código con licencias distintas e incompatibles), con lo que la asignación compartida del copyright permite a Sun/Oracle saltarse las reglas de las licencias a su antojo y usarlas en beneficio exclusivo de su accionariado. Y lo mismo hacen con OpenOffice -StarOffice tiene varios añadidos de código propietario-, Java y MySQL. Desgraciadamente, Oracle no tiene intención de terminar con esta situación, a pesar de que podía haber aprovechado la oportunidad para hacerlo:

"Oracle will continue to develop technologies in the open, as we do today. There may be some things we choose not to open source going forward, similar to how MySQL manages certain value add at the top of the stack. It's important to understand the plan now is to deliver value again out of our IP investment, while at the same time measuring that with continuing to deliver OpenSolaris in the open. This will be a balancing act, one that we'll get right some times but may not always

Y me quejo de esto no por capricho idealista, sino por sus nefastas consecuencias para los propios proyectos. Una grande empresa no quiere trabajar con OpenSolaris ni colaborar en su proyecto, si sabe que despues de gastarse mucho dinero en desarrollar una característica solo Oracle va a beneficiarse privadamente de ella. En OpenOffice, Novell/RedHat no están incluyendo ciertas características de OpenOffice en la rama oficial del proyecto precisamente por esta razón. Y lo mismo para Java y MySQL. Habrá que seguir insistiendo...

Lo que trae Linux 2.6.33

¿Es un meme? ¿Es un manifiesto contra la SGAE? ¿Es un nuevo producto de Apple? ¡No! ¡Es una lista de las nuevas cosas que incorpora la version 2.6.33 del kernel Linux! Que acaba de ser anunciada. Resumen: Nouveau (driver para tarjetas gráficas Nvidia) y otras mejoras del subsistema gráfico, soporte de Nintendo Wii y Gamecube, DRDB (dispositivo de bloque virtual distribuido en red), mejoras en perf, llamada al sistema rcvmmsg(), una extensión de seguridad a TCP apodada "Cookie Transactions", compcache (compresión de parte del cache mediante swap), drivers para hardware virtual VMWare y otras mejoras. La lista completa en inglés aquí.

Y, para que vean que me modernizo, esto post ha sido escrito con Blogilo, la aplicación de KDE 4.4 (una auténtica maravilla de versión, por cierto) para escribir blogs.

· Nouveau: Que es un driver para tarjetas gráficas Nvidia, las únicas que quedaban sin drivers libres en Linux. Nvidia no ha contribuido a este driver, sino que ha sido desarrollado mediante ingeniería inversa (y, según se rumorea, documentos supuestamente confidenciales encontrados en oscuros rincons de servidores rusos). Tiene 26.000 líneas de código y ha sido desarrollado desde el 2006. Las tarjetas gráficas son uno de los componentes de hardware más complejos que se pueden encontrar hoy en día, y es muy dificil escribir drivers para ellas incluso teniendo toda la documentación necesaria, con lo que este driver representa, en verdad, un esfuerzo hercúleo que debe ser aplaudido.

¿Por qué usar Nouveau en vez de los drivers oficiales de Nvidia? La nueva y potente tarjeta que has comprado hoy dejará de ser soportada en unos pocos años. Esto no ocurre con los drivers libres. Nouveau (y el driver libre de ATI) soporta más dispositivos que los drivers oficiales. Nouveau no solo soporta chips modernos, tambien soporta otros como Riva TNT y Geforce 2/4MX/4Ti/FX. Las características soportadas, sin embargo, no son comparables, pero Nouveau ya tiene un buen montón de soporte de cosas básicas: modesetting (KMS), suspensión/resumen, Dual Head, y operaciones 2D (EXA, Xrender, vídeo Xv). El 3D está en desarrollo pero está progresando poco a poco. Es de notar que el problema de los famosos "ctxprogs" ha sido resulta, ya que pueden ser autogenerados.

· DRDB: DRDB ("Distributed Replicated Block Device") es un dispositivo de bloques replicado en varios clusters desarrollado por [http://www.linbit.com/ LINBIT]. Su propósito es servir de base para crear clusters de alta disponibilidad (HA). DRDB puede ser entendido como un RAID-1 sobre la red. Para la gestión del cluster se necesita un gestor de cluster (por ejemplo, heartbeat). Ver http://www.drbd.org/, http://www.linux-ha.org

· Mejoras de perf: perf probe, perf kmem, perf bench, perf diff, scrips perl para perf y filtros: Esta versión añade muchas mejoras a la infraestructura de traceado y a la herramienta perf (tools/perf)

perf probe: perf probe es un subcomando que permite crear probes (sondas) de kprobes. Kprobes es un systema que permite insertar puntos de depuración en cualquier parte del kernel para recolectar información, dinámicamente y sin afectar al funcionamiento del sistema. Es el sistema utilizado por Systemtap. Perf probe permite definir sondas utilizando expresiones en C (números de línea, nombres de función, variables). Por ejemplo

Paso 1: Añadir una nueva sonda en una línea de código C: "perf probe -P 'p:misonda @fs/read_write.c:285 file buf count'" (crea una nueva sonda, llamado "misonda", que inspeccionará las variables file, buf y count ). De manera alternativa, puedes tambien usar comandos más simples, como "perf probe sys_open", que añade una sonda al símbolo sys_open symbol (la llamada al sistema open())

Paso 2: Añade una sonda kretprobe en el retorno de una función "perf probe -P 'r:myretprobe vfs_read $rv'"

Paso 3: Si ejecutas "perf list", verás una sección nombrada "kprobes" que lista las sondas que acabas de crear.

Paso 4: Inicia una captura de eventos: "perf record -f -e kprobes:myprobe:record -F 1 -a ls" y tracéalo con "perf trace"

perf bench: perf bench es una pequeña suite de microbenchmarks. En esta versión, solamente hay tres benchmarks: perf bench sched messaging (para medir el gestor de procesos y el IPC), perf bench sched pipe (mide el rendimiento de pipe()) y perf bench mem memcpy (mide el ancho de banda de la memoria). El comando perf bench all ejecutará todos los benchmarks.

perf kmem: Esta herramienta es en gran medida una versión de perf de la herramienta kmemtrace-user. Muestra información varia sobre SLAB.

perf diff: perf diff muestra diferencias de rendimiento entre varias capturas.

scripts perl de perf: Se trata de un motor de scripting para programar scripts de perf trace. Ver perf trace -g/--gen-script y perf trace -s/--script.

filtros perf: Esta característica añade soporte de filtros a la infraestructura de tracepoints, para ser utilizado con la opción "--filter expresión". Por ejemplo, para tracear solo las interrupciones del temporizador: "perf record -e irq:irq_handler_entry --filter='irq==0' -R -f -a sleep 10". O para capturar solamente la IRA 19 cuando se alcanza 'achi': "perf record -e irq:irq_handler_entry --filter='irq==19 && name==ahci' -R -f -a sleep 10"

· recvmmsg(): Se trata de una llamada al sistema que permite llamar de una sola vez varias llamadas de recvmsg(). Para aplicaciones de mucho ancho de banda y paquetes pequeños, el rendimiento y la latencia mejoran enormemente.

· TCP Cookie Transactions: Esta extensión a TCP, llamada [http://en.wikipedia.org/wiki/TCP_Cookie_Transactions Cookie Transactions] (TCPCT), tiene como intención proteger contra ataques DoS como floods SYN y terminación maliciosa de conexiones. A diferencia de las antiguas protecciones SYN, TCPTC no causa conflictos con otras extensiones TCP, pero requiere soporte de TCPCT en las pilas TCP del cliente y el servidor. La razón más inmediata para el uso de TCPCT es el desarrollo del protocolo DNSSEC.

· Controlador del E/S de dispositivos de bloques: Los grupos de control son contenedores virtuales que son creados como directorios dentro de un sistema de archivos especial (generalmente, con la ayuda de herramientas especiales),y se pueden añadir conjuntos de procesos arbitrarios a ese grupo, que puede ser configurado para que tenga un conjunto determinado de propiedades de gestor de CPUs o límites de memoria.

Esta versión añade el controlador del E/S de los dispositivos de bloque. A día de hoy, el gestor de IO CFQ lo usa para reconocer grupos de tareas y controlar el ancho de banda de disco concedido a esos grupos (algo del estilo de las prioridades de CFQ, pero implementado de otra forma).

· Compcache: compresión de swap en memoria: Compcache es un proyecto (en desarrollo, solamente disponible en Staging) que crea dispositivos de bloques en la memoria RAM (/dev/ramzswapX) que son usados como discos swap. Las páginas de swap que se escriben a este dispositivo son comprimidas. Parte de tu RAM se usa como siempre, la otra parte (el tamaño es configurable) se usa para guardar páginas comprimidas, esto incrementa la cantidad de RAM que puedes usar en la práctica.

Esta característica puede ser útil en muchos casos: Netbooks, smartphones y otros dispositivos embebidos, instaladores de distribuciones, clientes tontos sin disco, virtualización, o viejas máquinas sin suficiente RAM para ejecutar software moderno. Las mediciones han demostrado que esta es característica efectiva.

· Mejoras gráficas: Además de la inclusión de Nouveau, está la ronda de mejoras habituales al subsistema gráfico que se han vuelto tan comunes tras la inclusión de GEM y KMS

"Page flipping": Esta característica es necesaria para implementar un escritorio "tearing free" (defecto gráfico por el cual dos frames pueden mostrarse mezclados al mismo tiempo). Se ha añadido una ioctl para el soporte en la API KMS.

Soporte de HDMI para la Radeon R600.

Soporte de overlay de vídeo en el driver i915.

· Soporte de Wii y Gamecube: El proyecto gc-linux.sourceforge.net ha estado trabajando en el soporte de Linux de las consolas de Nintendo, basadas en PPC: Nintendo Wii y Nintendo Gamecube.

· Drivers VMWare: VMware ha contribuido con dos drivers para la GPU virtual y la tarjeta de red virtual vmxnet3 de sus hypervisors. Gracias a udev, esto significa que los invitados Linux ejecutándose en un huésped VMware tendrá un rendimiento gráfico y de red óptimo.

· DesBKLificación de reiserfs: Una de las principales desventajas de reiserfs (y una de las razones por las que la mayoría de las distros usa Ext en su lugar) es que su código gestiona la concurrencia de procesos utilizando un gran bloqueo, el llamado BKL (Big Kernel Lock). Esto sifgnifica que su escalabilidad SPM es muy pobre. Esta versión no soluciona ese problema, pero reemplaza el BKL con un bloqueo específico de reiserfs. En esta versión, ya no hay más trazas del BKL en su código. Ha sido convertido en un mutex recursivo. Esto puede sonar "sucio", pero usar un bloqueo tradicional en reiserfs requeriría una reescritura más profunda ya que la arquitectura existente depende íntimamente en las reglas del BKL. Debido a las semánticas sutiles de los cambios relacionados con bloqueos, algunas cargas podrían tener algunas regresiones y otras pequeñas ganancias.

· Android, fuera del kernel: Los drivers de Android han sido eliminados del directorio Staging. Desgraciadamente, desde el día de su inclusión en ese lugar Google no ha mostrado absolutamente ningún interés en mejorarles para tener unas mínimas condiciones de calidad y poder ser incluidos en la rama principal. Ante las peticiones de mejora, Google ha contestado que si no lo quieren aceptar tal y como está, que mejor cada uno por su lado. Por supuesto, eso es totalmente legal, pero es triste que un proyecto que ha hecho tanto por llevar el software libre a las masas se haya convertido en un ejemplo de libro de como no interactuar con una comunidad de software libre.

Flash, Google, VP8, y el futuro del vídeo de Internet

Uno de los desarrolladores de x264 ha escrito un texto explicando con detalle, y mucho mejor que cualquier otro que se haya escrito hasta ahora, todo el asunto sobre formatos de vídeo para HTML5, H.264, Theora, Flash, ON2, y Google. Una lectura totalmente recomendada.

Por cierto, puestos a recomendar tambien les recomiendo esta extensión de Firefox. No se si he dicho alguna vez en este blog que aumentar el tamaño de las fuentes es una de las cosas que más puede mejorar la "experiencia de usuario", y no por nada relacionado con problemas de vista, sino por pura comodidad. Estéticamente las fuentes grandes están mal vistas, por eso algunos SO las ponen tan pequeñas, obligándonos a los usuarios a usar el ordenador con textos de tamaño idéntico a los de un libro, pero con los ojos a mucha más distancia de la pantalla de la que lo están de un libro. Esa extensión aplica por defecto un zoom de 120% (de todos los elementos de la página, no solo del texto) a todas las páginas por las que navegue.

iPad, y las perspectivas para ARM y Linux

Ahora que ya ha se ha calmado un poco la discusión sobre el iPad, aprovecho para publicar finalmente este post.

Se ha hablado mucho de si el formato del iPad va a fracasar o no (en mi opinión, una cosa tan portable, tan fácil de usar y con tanta duración de batería se tiene que vender), de que si no tiene webcam, de que si las limitaciones monotasking del iPhone OS...no se ha hablado tanto de su procesador ARM, más allá del hecho que es fabricado por la propia Apple. Pero creo que es relevante que este vaya a ser el dispositivo ARM no-teléfono más vendido (previsiblemente). Esto hace al iPad una gran victoria de ARM frente a x86, una guerra fria que este blog sigue con atención.

Usar un ARM marca una diferencia importante: duración de las baterías. Los procesadores ARM son muy eficientes y, de momento -aunque el futuro pueda cambiar la situación-, Intel no tiene nada que les haga sombra. Eso es una ventaja fundamental en cualquier dispositivo portátil, el peor portátil del mundo sería número 1 de ventas si durara 24 horas encendido sin necesidad de recarga. Es ARM lo que consigue que el iPad tenga 10 horas (teóricas) de batería...y es ARM lo que hace que cualquier dispositivo portátil x86 parezca menos competitivo en comparación.

Mencionabamos el otro día que Microsoft y HP se habían adelantado con todas las de la ley a Apple en la novedad del iPad (tampoco debemos olvidar que ya se estaba vendiendo este hardware en otras partes del mundo...y quiero aprovechar este momento para mencionar al iFreeTablet, un tablet...¡español!, y un ejemplo más de que en España no hay solo ladrillos y paro). Pero si incluimos el factor ARM en la ecuación, las cosas cambian.

El tablet de HP ejecuta Windows 7, eso significa que utiliza un procesador x86. No conocemos las especificaciones del prototipo de HP, pero por su arquitectura podemos adivinar un par de cosas: Sus baterías durarán menos que las del iPad. Para durar lo mismo tendrían que incluir más baterías y/o de mayor capacidad, que lo harán pesar y costar más que cualquier competidor ARM.

Por esta razón Apple tiene, además de la ventaja de un SO ideal para el manejo táctil, otra sobre Microsoft y los fabricantes hardware. Y es aquí donde Linux se beneficia: las compañías como HP o Asus tendrán que optar por el recien anunciado MeeGoo o Android si quieren vender hardware que sea muy competitivo con el de Apple. Para el formato tablet, Microsoft no propone Windows Mobile, su sistema operativo para móviles, sino Windows 7: una escisión de plataformas que solo ellos sufren y que la portabilidad de .NET no alcanza a tapar.

Respecto a Windows Mobile, los de Redmon pretenden arreglar su pérdida notable de cuota en el mercado de smartphones con Windows Mobile 7, que curiosamente está siendo anunciado en Barcelona en este mismo momento, mientras tecleo. Tiene notables mejoras en la interfaz; por las capturas observadas podrían ofrecerlo como SO para tablets, pero...eso significaría decirles a sus partners que abandonen sus proyectos x86...¡y la compatibilidad con Win32! Mientras no haya cambio de política, y Microsoft no se decida a portar con todas las de la ley Windows 7 a ARM (o x86 domine a ARM como procesador para dispositivos móviles) el territorio de tablets será un jugoso manjar en el que Linux pueda progresar.

Predicciones 2010

Este año no he hecho ninguna lista de predicciones, me parecía aburrido. Pero tras leer las que hice el año pasado, y comprobar que entre las fallidas -fork de Openoffice, segmentación del iPhone en un modelo barato y un modelo caro, E17- he llegado a "acertar" algunas me he animado, a pesar de que ya estamos en Febrero...

· La prensa digital de pago tendrá éxito.

· Google Wave será remodelado masivamente o eliminado.

· Dado que en este año la economía empezará a recuperarse, o al menos a dejar de caer, veremos una recuperación enérgica de los resultados de las empresas con más futuro -las que durante la crisis sufrieron pocas o ninguna pérdida: Apple, Red Hat, IBM, Google, etc - y un estancamiento de aquellas que están llamadas a ir dejando poco a poco sus puestos a otras.

· Las predicciones de éxito de ARM en Netbooks se harán realidad.

· Habrá rozamientos entre Oracle y la comunidad de MySQL (insisto, es como si Microsoft comprara el copyright y equipo de desarrollo de Openoffice y prometiera mejorarlo para hacerlo competir con Microsoft Office)

· Google solucionará el problema de H.264 de alguna forma: adoptando Theora, un códec nuevo de On2, o proporcionando desinteresadamente algún tipo de garantía legal a Mozilla frente a los ataques de las patentes.

· Android quizás no llegue a sobrepasar en cuota de mercado al iPhone, pero se le acercará (contando con el apoyo de tantos fabricantes, es cuestión de tiempo que les supere)

· Las interfaces basadas en cosas tipo QT/Kinetic, Clutter o Core Animation se empezarán a generalizar de verdad en las aplicaciones.

· Gallium3D empezará a adoptarse en las ramas estables de las distros más importantes, marcando el final de la transición gráfica de Linux.

· Algun distro importante basada en Gnome se pasará a KDE, o al menos planteará la cuestión a su comunidad.

· Steve Ballmer dejará Microsoft.

· Enlightenment 17 verá la luz, y no lo usará casi nadie.

· Surgirá algún tipo de red social, o evolución de red social, que convertirá a Facebook en el siguiente MySpace y atacará a Twitter con efectividad.

No digan que no me arriesgo...

Youtube, H.264 y Theora

Lo queremos todo, esa es una de las máximas de la sociedad moderna. Demandamos que el progreso material nos proporcione todo, y ya. Tras el anuncio de un Youtube HTML5 experimental, me temo que este pensamiento ha aflorado en los internautas, a raiz de las críticas sobre que el experimento no esté usando ya mismo Theora como formato de vídeo, en lugar de H.264.

Nos olvidamos de que hasta hace prácticamente nada, el tag video no existía o no había aterrizado en las versiones estables de navegadores. El mundo no puede cambiar de la noche a la mañana, y los códecs en particular son un territorio donde las costumbres imponen su dictadura por las buenas o las malas. Háganse a la idea de que los formatos MP3 y AAC también están protegidos por patentes y requieren licencias (razón que impide a Fedora soportarlos por defecto), y ambos dominan casi por completo la música digital. Y ello a pesar de que en el sonido las costumbres son más fáciles de atacar que en el vídeo (no se requiere hardware especial para decodificar sonido, por ejemplo). Asi que no nos alteremos. No veo a la gente clamar al cielo porque haya podcasts de software libre en formato MP3, pongámonos en perspectiva antes de clamar al cielo por que Youtube use H.264.

Y ojo, que conste que no quiero confundir la perspectiva con el conformismo. Me parece perfecto hacer una excepción, decidir que se ha colmado el vaso y tener con los códecs de vídeo la rebeldía que no se han tenido con otras cosas. Pero la realidad es la que es, y no sirve de nada meterse gratuitamente con Google, que es una compañía con el suficiente historial como para poder afirmar que a ellos les disgustan los formatos propietarios y patentados tanto como a usted y a mi.

Google está atado por el momento a H.264. ¿Por qué? Porque es el estándar de facto, lo cual puede gustar más o menos pero es un hecho innegable. Es el formato más utilizado en páginas de vídeo con reproductores basados en Flash (la única manera decente de ver vídeo en Internet hasta hace poco - y aun hoy las implementaciones del tag video tienen mucho que mejorar). Eso implica que toda la infraestructura de Youtube está construida sobre H.264. Recodificar su ingente cantidad de vídeos en otro formato seguramente necesitará muchos recursos de hardware extra (empezando por almacenamiento). Además están las cuestiones de calidad y ancho de banda, que aparentemente han sido refutadas en gran medida con Theora 1.1, pero que pueden ser inválidas con nuevas versiones del codificador H.264 que utilice Google (si no lo son ya). Sin mencionar la falta de soporte de aceleración por hardware, necesaria para dispositivos móviles.

Y todo esto sin mencionar que los navegadores más usados del mundo (IE) no soportan el tag vídeo ni lo van a hacer en breve.

Por tanto, ¿puede Google cambiar a Theora? Si, pero es muy difícil hacerlo, y la mayor web de vídeos del mundo no puede permitirse el lujo de cambiar de códec predilecto de la noche a la mañana por puro idealismo sin tener en cuenta muchas cosas. ¿Tiene sentido apostar por un códec que, al menos teóricamente, es inferior a H.264? Quizás prefiera esperar al sucesor de Theora, vaya usted a saber.

La única pista cierta de las intenciones de Google es su adquisición de una compañía experta en estos temas, On2 (compra que aun se está completando). Esta compañía, que es muy relevante en temas de códecs, lanzó hace poco uno nuevo, VP8, del que se afirma que es mejor que H.264. A largo plazo, Google quizás acabe utilizando su propio códec, en vez de otros, y de hacerlo probablemente lo liberaría, como es costumbre de la compañía. Aunque los temas de patentes pueden hacerlo imposible. Sea cual sea el futuro, de momento tenemos H.264 para largo. Y MP3 y AAC, no lo olviden.