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