7 de mayo de 2009

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...

6 comentarios:

  1. Lo de no preocuparse de los sistemas pequeños me recuerda a algún otro post tuyo donde hablabas de cierta empresa cuyo futuro está bastante en el aire...

    ResponderEliminar
  2. tcmalloc no siempre ayuda. En tests con ebizzy, Linux palma con tcmalloc. Incluso la implementacion de glibc es mejor: http://www.kernel.org/pub/linux/kernel/people/npiggin/ebizzy/ebizzy.png

    Un paseito por malloc():

    http://www.designandcommunication.co.jp/Nakano/Dev/Memory.html
    http://memoryallocators.com/research/testalloc.html
    http://developers.sun.com/solaris/articles/multiproc/multiproc.html

    saludos,

    ResponderEliminar
  3. xose: Por los detalles de la nueva implementación (http://udrepper.livejournal.com/20948.html), dudo bastante que hubiera muchos casos donde tcmalloc no ganara a la libc.

    ResponderEliminar
  4. Diego, estuve leyendo los hilos que linkeaste y es grave lo de este muchacho. Será un genio, un cowboy coder de los mejores, pero no merece estar al frente de un proyecto tan importante. O al menos, que no conteste los bugs, y que alguien de la FSF coordine entre los pedidos y este programador.

    No se puede ser tan arrogante, autoritario y duro con otra gente que te sugiere, comenta y quiere mejorar el producto en el que él participa, y digo participa porque no es de él... sino de toda la comunidad.

    Saludos

    ResponderEliminar
  5. > Debian va a subir a sus archivos una libc alternativa optimizada para sistemas embebidos y derivada de la glibc de GNU.

    Aclarar que Debian ya cambio a eglibc el 5-may:

    eglibc (2.9-11) unstable; urgency=low

    * Switch to Embedded GLIBC (EGLIBC), sources taken from the 2.9 branch.

    ResponderEliminar
  6. Respecto a Ulrich Drepper y sus manias, ojeate: http://udrepper.livejournal.com/7326.html

    tcmalloc es muy rapida, pero demasiado glotona para ser la malloc por defecto.

    jemalloc es igual de rapida de tcmalloc e ideal para ser incluida por defecto. De hecho, es el malloc de FreeBSD, NetBSD, Firefox, Varnish.

    En lo unico que falla malloc-glibc(>=2.10) actualmente, es gestionando mas de 128k que delega en el kernel, y madvise(2) se vuelve algo loca.

    respecto a parches de cualquier proyecto GNU: http://sourceware.org/ml/libc-help/2008-10/msg00046.html

    ResponderEliminar