RCU en espacio de usuario

Los intentos de portar RCU a espacio de usuario (urcu) no eran nuevos, pero por lo visto se ha conseguido el detallazo final de licenciarlo bajo la LGPL.

RCU es una técnica de sincronización patentada por IBM e introducida por ellos mismos en Linux. El código es GPL, pero el permiso concedido por IBM para utilizar la patente es otro tema, e IBM solamente concedía permiso para utilizar esa patente bajo código GPL, lo cual imposibilitaba una reimplementación LGPL o propietaria. Pero los creadores de urcu sabían que en espacio de usuario la GPL es un gran inconveniente, asi que por lo visto se han puesto en contacto con IBM para conseguir permiso para usar la LGPL, y se lo han concedido.

Sobresaltos en la libc de la FSF

Via LWN me he encontrado este blog, donde cuentan como Debian va a subir a sus archivos una libc alternativa optimizada para sistemas embebidos y derivada de la glibc de GNU. Lo interesante es que debian no planea ofrecerla como opción, sino ¡usarla como libc estándar y abandonar la de GNU!

La verdad es que no es tan sorprendente. Quien a lo largo de los años haya estado atento a los chascarrillos del mundillo, sabía que este día tenía que llegar. El mantenedor de la glibc, Ulrich Dreeper (empleado de Red Hat) es un pésimo mantenedor y lo lleva siendo muchos años. Es bruto y arrogante, capaz de rechazar código útil por razones caprichosas. Se trata del típico líder de proyecto que acaba creyéndose dueño absoluto no solo de todas y cada una de las líneas de código, sino de los caminos por los que ha de avanzar el proyecto.

Su gestión del proyecto excluye a gente competente, impide que se cree una "comunidad", con lo cual, aunque él sea un magnífico programador, la libc va acumulando deficiencias técnicas que tardan en resolverse por falta de gente. Desgraciadamente, su situación recuerda a otros proyectos que acabaron en forks, como Xfree86. Si piensan que exagero, echen un ojo a los enlaces al bugzilla que incluyen en el post: 1, 2, 3, 4. No son una excepción, creanme.

En cuanto a las deficiencias técnicas, la implementación de malloc ha tenido durante muchos años un pésimo rendimiento multihilo, que solamente se ha solucionado muy recientemente, en glibc 2.10 (que es tan reciente que ni Ubuntu la usa aun, aunque si Fedora 11). Mientras tanto, la gente, por ejemplo muchos usuarios de mysql, han tenido recurrido durante años al tcmalloc de google, que es capaz de doblar el rendimiento del benchmark sysbench en ciertos casos. Tal vez tampoco se habría solucionado ese problema con un buen mantenedor, pero es seguro que hubiera habido más posibilidades. Tambien es sabido que se ha negado a permitir la optimización la libc para sistemas embebidos por la simple razón de que él no las tiene simpatía y las considera irrelevantes, aunque sean tan utilizadas como ARM -la segunda plataforma más utilizada en Linux despues de x86, y quizás pronto sea la primera-, negando cosas tan comprensibles como hacer opcional la compilación de ciertas partes de la librería, respondiendo a quien estuviera en desacuerdo que la glibc era para sistemas grandes, y que como es para sistemas grandes no merece la pena preocuparse de los sistemas pequeños, y que quien necesite una libc para sistemas embebidos que use una de las muchas que hay especializadas en esos entornos. Por supuesto, es cierto que esas libcs especializadas son imbatibles en uso de memoria, pero no por eso parece lógico prohibir mejorar la libc en ese aspecto. El kernel Linux las ha permitido y, a pesar de no ser un SO embebido está empezando a ser más utilizado en esos sistemas más que los propios SOs especializados, porque ante la desventaja del mayor uso de memoria está la enorme ventaja de ser tecnológicamente superior. Según el post, la glibc oficial no permite hacer cosas tan esperadas como permitir utilizar otras shells aparte de bash o ser compilado con la opción -Os (optimización de tamaño). Muchos dispositivos embebidos usarían encantados la glibc si pudieran, pero al no facilitarles las cosas les han obligado a recurrir a libcs alternativas que a pesar de ser eficientes en uso de memoria, tienen otras desventajas.

El proyecto en cuestión, eglibc, no es un fork, sino una "rama" de la glibc a la que añaden ciertas opciones para sistemas embebidos. Gracias a eso a debian le resulta muy fácil sustituir una glibc por otra, ya que debería ser totalmente compatible. Incluso parece que les resulta ventajoso, porque Debian soporta muchas arquitecturas y esta eglibc facilita el trabajo con ellas.

Sin embargo, no parecen tener interés en "asesinar" a la glibc. De hecho, requieren la asignación de copyright a la FSF a pesar de no ser un proyecto de la FSF, con el claro objetivo de que la glibc oficial pueda incluir cualquier parte de su código. Por eso, es de esperar que a largo plazo la situación de la glibc de la FSF mejore, de una manera u otra. Pero si no lo hace, es de esperar que eglibc prospere, al igual que lo hizo X.org, y acabe siendo mejor que la propia glibc. De momento, Ubuntu probablemente esté interesada en esta eglibc para su distro para sistemas embebidos, que usa ARM...

Windows en la encrucijada de los teléfonos "modernos"

Aunque repita la misma introducción mil veces en este blog, insisto en que Apple ha dado un vuelco a los móviles no solo por su interfaz y la pantalla táctil, sino tambien por haber sido la primera compañía que ha introducido todo un SO tradicional dentro de un móvil. Si, ya había teléfonos con Linux, pero la mayoría de ellos lo utilizaban solo como un kernel embebido regordete pero potente y gratuito: ha sido el iPhone quien ha terminado adelantándose a todos.

Debido a las restricciones tecnológicas, los móviles empezaron su andadura con SOs embebidos que eran tan cutres como el hardware en el que corrían. Llegó un punto en que empezaron a resultar económico los móviles con procesador y RAM capaces de albergar versiones reducidas de los SOs tradicionales, es decir, dejaron de ser "dispositivos embebidos" para ser simplemente PCs portátiles, aunque fueran basados en ARM. Pero los fabricantes siguieron, por inercia, y porque no tenían otra cosa, con sus SOs embebidos, incapaces de explotar toda la capacidad de las cada vez más potentes generaciones de hardware.

Fue entonces cuando Apple halló el hueco para colarse, creando una versión reducida de OS X para ARM que era capaz de funcionar en hardware que tenía un precio aceptable y que lo tendrá aun más en el futuro. Usar su propio SO les permitió centrarse en lo que verdaderamente ha dado el éxito al iPhone: la pantalla pluritáctil (reconozcan que suena más cool que "multitáctil") y el software. Y reducir costes y tiempo, pues solo mantienen una base de código, y no varias. Vi una vez una comparativa de velocidad del navegador del iPhone con otro móvil con un SO embebido. El iPhone le daba mil vueltas. ¿Por qué? Porque el iPhone estaba usando exactamente la misma pila TCP/IP que usa en sus ordenadores de escritorio y en sus servidores, el mismo navegador web, la misma implementación wifi. El otro teléfono, basado en un SO embebido, tenía una pila TCP/IP y wifi propia, no optimizadas para los ratios de transferencia de las conexiones 3G y las redes Wifi. Y su navegador web era una versión embebida limitadísima y con un motor javascript lentísimo.

Android siguió los pasos del iPhone (aunque han tenido que reinventar el entorno de programación de cero, basándolo en Java) y se está incorporando poco a poco a su estela, igual que Palm. ¿Y qué ocurre con Windows? Pues tienen un problema, porque para seguir la tendencia necesitarían una versión reducida de XP. Bien, esa versión existe, pero...es solo para x86, lo cual obliga a Microsoft a seguir en móviles con Windows CE. Y así van a tener que seguir como mínimo durante 2 ó 3 años, pues hasta entonces Intel no tendrá nada (recordar que vendieron su plataforma ARM, Xscale) que pueda utilizarse en móviles sin fundir la batería a velocidades alarmante. Esta es la encrucijada de Microsoft.

Respecto a Windows CE, no es que sea mal SO, pero en realidad es un descendiente de los SOs embebidos equivalentes a los que se utilizaban cuando los móviles no tenían muchos recursos. CE es el SO que dominaba en los Pocket PCs, PDAs y demás artefactos hace casi una década: artefactos hoy desfasados. Es útil para dispositivos con pocos recursos, y sigue siendo muy útil en esos dispositivos, pero no en los móviles modernos, que han dejado de ser embebidos, y que necesitan un kernel como el de Windows XP, Vista o 7, donde MS mantiene una inversión mucho más alta y que, exceptuando algunos aspectos específicos como las capacidades como SO de tiempo real, está más evolucionado tecnológicamente. Sin embargo, como ya está dicho, ese kernel no está portado a ARM, al menos públicamente, y no parecen tener intención de cambiar la situación, asi que de momento no tienen otra elección que CE.

En cuanto al entorno de programación, a diferencia otros SO embebidos, de esos raros que tienen sus propias APIs y su propia manera de hacer las cosas y tienen POSIX solo como una "capa de compatibilidad" y no como algo nativo (como $DEITY manda), el CE si que tiene compatibilidad con su POSIX particular, es decir, Win32, las MFC y todo el universo Windows. Es, por así decirlo, una implementación reducida de Windows sobre el kernel de CE del mismo modo que XP lo es sobre NT y el 98 lo era sobre W9X. La diferencia es que mientras que entre XP/Win 2000/NT 4.0 había mucha compatibilidad con Windows 9x, en CE no tenían que preocuparse por eso, y han desarrollado un sub-mundo alternativo más incompatible, pero no hasta el punto de ser completamente diferente. Además, tambien se puede utilizar .NET, que es multiplataforma (al igual que las aplicaciones java de Android, y a diferencia de iPhone, que apuesta claramente por ARM). Asi que en este aspecto, aunque haya pequeñas diferencias, se podría decir que Windows CE está bastante preparado para acoger hordas de programadores experimentados en plataformas Microsoft.

Sin embargo, ciertas partes del entorno Windows de CE son una vulgar imitación, o mejor dicho reimplementación, de sus equivalentes de escritorio. Mientras que Apple utiliza el mismo Safari para el escritorio y para el iPhone, Microsoft tiene un IE de escritorio y, aparte, el IE Mobile, que está obsoleto excepto para navegación básica, y que ni tan siquiera es compatible en cuanto estándares con su hermano mayor ni con muchas páginas modernas. ¿Dónde vas con un móvil de última generación sin navegador decente? En este aspecto, hay que decir que Opera ha salvado el culo a Microsoft.

La situación de Microsoft en la encrucijada de los móviles es por tanto dificil: Por una parte Microsoft debería tener interés, como lo están teniendo Apple y Google, en usar un kernel y entorno base -y aquí se incluye el navegador- para ordenadores DE VERDAD, y no versiones embebidas, aunque solo sea por unificar todo en una sola base de código, pero les limita su dependencia de x86 por el momento, hasta que Intel pueda competir con ARM. Competencia en la que es de suponer que estén muy interesados, pero que va a dejar 2 ó 3 años de superioridad y libre albedrío a iPhone y Android. Por otra parte, su entorno de programación no ofrece gran dificultad de adaptación a los programadores Windows, pero se encuentra con un gran problema adicional: la falta de uniformidad. Mientras que en el iPhone los desarrolladores saben exactamente para qué dispositivo están desarrollando, saben que el dispositivo es pluritáctil, saben la potencia de la CPU, saben las capacidades de su chip gráfico, en Windows tienen que soportar aplicaciones diseñadas para todo tipo de dispositivos con diferentes tipos de entradas, algunos táctiles, otros no, unos con un buen chip gráfico, otros no....

En resumen, que veo a Windows bloqueado en el mundo de los móviles. Previsiblemente invertirán toneladas de recursos en modernizar Windows CE y su entorno, intentarán portar el IE real de escritorio a Windows CE (probablemente su mayor problema en estos momentos: así de importante se han vuelto los navegadores)...pero será poner parches a un viejo neumático, mientras que iPhone y Android (y Palm) tendrán terreno libre para dominar a sus anchas.