Creando la distribución, Parte 21. De Enoch a Gentoo, a través de pequeños retrasos y confrontaciones corporativas En mi anterior articulo, comenté la decaída durante mis días en el equipo de desarrollo de Stampede y como abandoné (para alejarme de los freaks políticos, controladores de proyecto y de bajo nivel). A causa de la interferencia con estos observadores de medio pelo, pensé que sería más fácil construir mi propia distribución Linux que continuar mejorando Stampede en esas sucias condiciones. Afortunadamente me llevé una considerable cantidad de experiencia basada en mi (¿puedo decir sustancial?) trabajo en Stampede, incluyendo el mantenimiento de varios de sus paquetes, diseñando los guiones de inicialización y liderando el slpv6 (proyecto de gestión de paquetes de última generación). La distribución en la que comencé a trabajar, llamada Enoch, iba a ser espectacularmente rápida ya que automatizaría completamente la creación de paquetes y el proceso de actualización. Tengo que admitir que esto era una tarea larga, ya que era un equipo de un solo miembro y no podría permitir gastar mi tiempo en trabajo repetitivo que mi máquina de desarrollo pudiera hacer de forma automática por mi. Y como estaba diseñando una distribución desde cero (en lugar de "tejerla" de alguien como RedHat), tenía que recortar trabajo para mi y necesitaba todo el tiempo libre que pudiera gorronear. Después de tener mi Enoch básica preparada y funcionando, volví mi cabeza a irc.openprojects.net y abrí mi propio canal llamado #enoch. Partiendo de esto gradualmente reuní un equipo de diez desarrolladores. En esos primeros días todos nos pasamos por el IRC y trabajamos en la distribución en nuestro tiempo libre. Mientras trabajábamos cooperativa y comunitariamente en ella, encontrando y corrigiendo nuevos errores, Enoch llegó a ser más funcional y profesional día a día. El primer obstáculo en el camino Un día inevitable, Enoch se encontró con el primer obstáculo en su camino. Después de añadir Xfree86, glib y gtk+, decidí incluir xmms (una aplicación de reproducción MP3/CD basada en X11/gtk+) en funcionamiento. ¡Creí que era buen momento de celebrarlo con algo de música!. Pero después de instalar xmms, intenté arrancarlo ... ¡y X se colgó!. Al principio pensé que xmms se había colgado porque usé unas optimizaciones del compilador de locura ("-06 -mpentiumpro", por si se lo pregunta). Mi primer pensamiento fue el de compilar xmms con una optimización estándar, lo cual no solucionó el problema. Por lo que empecé a mirar por otro lado. Después de gastar una semana de tiempo de desarrollo intentando localizar el problema, un usuario de Enoch me envió un correo, Omegadan, que también estaba experimentando cuelgues de xmms. Nos escribimos durante un tiempo, y después de muchas horas de pruebas, determinamos que el problema era una cuestión relacionada con los hilos POSIX. Por alguna razón, una llamada a pthread_mutex_trylock() no retornaba de la forma que debía. Como creador de la distribución, ese era el tipo de errores que realmente no quería encontrar. Conté con que los desarrolladores publicaran fuentes perfectas de modo que pudiera concentrarme en mejorar la experiencia en Linux en lugar de poner en funcionamiento las fuentes erróneas. Desde luego me di cuenta enseguida que no era una expectativa realista, y que problemas como este siempre aparecerían de vez en cuando. Como se observó, el problema no era con xmms, gtk+ o glib. Y no era una cuestión de Xfree86 3.3.5 que no tenía hilos seguros ni hacía bloqueos. Sorprendentemente, encontramos el error en la implementación de los hilos POSIX en el propio Linux, parte de la librería GNU C (glibc) en su versión 2.1.2. En el momento de encontrarlo, me sorprendió que esa parte tan crítica de Linux, tuviera un error tan importante. (Y nosotros usamos una versión lanzada de glibc en Enoch, ¡no una de pre-lanzamiento o versión CVS!). ¿Cómo entonces resolver el problema? Realmente, nunca pudimos obtener una corrección del error, pero en algún momento tropecé con un par de correos en la lista de desarrolladores de glibc con el mismo problema. El desarrollador de glibc que respondió, publicó un parche que nos resolvía el problema. Yo me preguntaba porqué RedHat (que también usaba glibc 2.1.2) no sufría este problema ya que el parche acababa de ser publicado y RedHat 6 estaba disponible desde algún tiempo. Para averiguarlo, me descargué la librería glibc SRPM (source RPM) y eché un vistazo a sus parches. RedHat tenía su propio parche para glibc, hecho en casa, que resolvía el problema con pthread_mutex_trylock(). Aparentemente experimentaron el mismo problema y crearon su propia corrección a medida. Muy mal por no enviar este parche "upstream" a los desarrolladores de glibc para que lo hubieran compartido con el resto del mundo. Pero, quien sabe, quizá RedHat envió el parche para integrarlo y por alguna razón los desarrolladores de glibc no lo aceptaron. O quizá el hilo discutiendo la corrección fue iniciado por una combinación específica de versiones de compilador y binutils y RedHat nunca lo tuvieron en cuenta (aunque tenían un parche para los hilos en su SRPM). Creo que nunca sabremos exactamente lo que pasó. Pero aprendí que los SRPM de RedHat contienen un montón de correcciones de errores y detalles privados que nunca parece que llegue a integrarse por los desarrolladores originales. Voy a despotricar sobre esto durante un rato. Cuando armas una distribución Linux, es realmente importante que cualquier corrección que crees sea enviada a los desarrolladores originales para que sea integrada. Tal y como yo lo veo esta es una de la muchas formas en las que los creadores de distribuciones contribuyen a Linux. Nosotros somos los que realmente hacemos que todos esos programas funcionen como un todo. Debemos enviar nuestras correcciones para su integración mientras unificamos para que otros usuarios y distribuciones se puedan beneficiar de nuestros descubrimientos. Si decides guardarte una corrección de un error, no estás ayudando a nadie; te estás asegurando que mucha gente pierda su tiempo corrigiendo el mismo error una y otra vez. Este tipo de política va en contra de la ética del código abierto y atrofia el crecimiento del desarrollo de Linux. Quizá debería decir que nos "bugs" a todos. Es desafortunado que algunas distribuciones (ejem) no son tan buenas (RedHat) como otras (Debian) acerca de compartir su trabajo con la comunidad Mientras estábamos intentando corregir el problema con los hilos de glibc, le escribí un correo a Ulrich Drepper (uno de los tipos de Cygnus que está fuertemente envuelto en el desarrollo de glibc). Le mencioné el problema de los hilos POSIX que teníamos, y que Enoch usaba pgcc para un rendimiento óptimo. Me respondió que algo como esto (parafraseando) "Nuestro propio compilador del producto CodeFusion tiene un excelente backend para el x86, que produce ejecutables más rápidos que los generados por pgcc." Obviamente estaba muy interesado en probar este misterioso "turbo" compilador que los chicos de Cygnus habían creado. Acto seguido, solicité una copia de Cygnus Codefusion 1.0 para probarlo, y Omegadan y yo nos sorprendimos al encontrar que este compilador era todo lo que Ulrich decía y algo más. !El backend x86 incrementaba el rendimiento de algunas de los ejecutables con alto consumo de CPU (como bzip2) de cerca del 90%! Todas las aplicaciones parecían beneficiarse del incremento de al menos un 10% en el rendimiento en tiempo real, y lo que hicimos fue cambiar de compilador. Enoch arrancaba incluso un 30 ó 40% más rápido. La ganancia en rendimiento eran bastante, bastante superiores de las que ganamos cambiando de gcc a pgcc. Obviamente después de probarlo por nuestra cuenta, queríamos este compilador para Enoch. Afortunadamente, las fuentes estaban incluidas en el CD de CodeFusion y publicados bajo GPL, de esta forma se nos permitía usar este compilador ... o eso creíamos. Hagamos que comience el frikismo Envié un correo al gerente de mercadeo de Cygnus para hacerles saber nuestras intenciones, esperando una respuesta del tipo "Sí claro, adelante, gracias por usar nuestro compilador". En lugar de eso, la respuesta fue que aunque a nosotros se nos permitía (técnicamente) usar el compilador de Cygnus, no se nos permitía incluir las fuentes en Enoch. Contesté preguntando porqué había publicado las fuentes bajo GPL, si ese era el caso. Creo que si hubieran tenido oportunidad, no hubieran usado la GPL, pero debido a que derivaron su compilador de egcs (publicado bajo GPL), no tuvieron esa posibilidad. Es un buen ejemplo de una situación en la que la GPL impidió a una compañía crear un producto propietario basado en código abierto. Mi educada intuición es que Cygnus temía que si nosotros usábamos su compilador, disminuirían sus ventas de productos en caja, los cual sería especialmente extraño ya que ninguno de sus productos de mercadeo (tampoco la revista InfoWorld) mencionaban el nuevo compilador incluido con CodeFusion. CodeFusion fue lanzado al mercado únicamente como un producto "IDE de desarrollo", no como un compilador. En un intento por disminuir sus paranoias, me ofrecí a promocionar CodeFusion y colocar las promociones en nuestro sitio Web con un enlace para ayudar a que subieran las ventas de CodeFusion. Personalmente, no creo que una "turbo" Enoch afectara negativamente las ventas, ya que CodeFusion estaba orientado como IDE. Pero nunca intenté desde luego hacerles felices. El componente IDE de CodeFusion era un producto comercial, y no teníamos ningún deseo o intención (o derecho) a distribuirlo con Enoch. Envié por correo mi (¿generosa?) oferta a Cygnus y recibí otra respuesta extraña. Quería la autoridad de todo nuestros "materiales de mercadeo" (aparentemente, ¡esto también incluía el contenido de nuestro sitio Web!). Otro susto. El equipo de mercadeo de Cygnus parecía no tener idea de como funcionaba la comunidad Linux o la GPL, por lo que decidí cortar la comunicación con Cygnus por un periodo indefinido. Entretanto, creamos una versión "turbo" privada y una "non-turbo" pública, dejando la decisión final para más adelante. Sin embargo, unos meses más tarde integraron el backend x86 de CodeFusion en gcc 2.95.2. Ahora todo el mundo se podía beneficiar del nuevo y bueno backend, no solo la gente que sabía del "compilador GPL secreto" incluido en el CD de CodeFusion. Aparte de ser más estable, gcc 2.95.2 también nos permitió evitar a Cygnus, que por aquél tiempo había sido comprada por RedHat por una suma ridícula de dinero. (Nota: el nuevo backend en gcc 2.95.2 es lo que hizo que las nuevas distribuciones Linux obtuvieran el significante incremento en su velocidad que todos experimentamos. También le dio a FreeBSD 4.0 un incremento en la velocidad sobre 3.3.6. ¿Nota la diferencia?) Gracias a esto y otras experiencias, he aprendido mucho sobre compañías de código abierto con ánimo de lucro. No pasa absolutamente nada por ser una compañía de código abierto con ánimo de lucro. Tampoco hay nada moralmente incorrecto en producir software propietario de código cerrado, si es lo que te gusta hacer. Pero no se entiende que las compañías de código abierto trastornen o no quieran cooperar con el resto del mundo del código abierto, apoyando la GPL o por otros medios. Este es un punto práctico que claramente da sentido a los negocios Las compañías de código abierto deben darse cuenta que el libre intercambio de ideas y código es de lo que sacan beneficio. Oponiéndose a cosas como las prácticas estándar de la GPL, minan el entorno en que confían para prosperar y crecer. Si el código abierto es el substrato del que tu negocio ha brotado, tiene sentido mantener el substrato sano. Comprendo que hay una tentación para guardar al menos un poco de información secreta para obtener ventaja a corto plazo. Código avanzado o técnicas especiales dan una codiciada ventaja competitiva, que podría potencialmente resultar en el incremento de ventas y beneficio. Pero la meta de ser el único proveedor de un producto, debería de ser comercial y no código abierto. El código abierto no permite acceso exclusivo al funcionamiento interno de nada. Eso es lo que significa. Ahora, me bajaré de mi tribuna y continuaré con mi historia. A medida que Enoch estaba más y más refinada, decidimos que un cambio de nombre era lo siguiente, y "Gentoo Linux" nació. Por aquél tiempo habíamos publicado un par de versiones de Enoch (ahora Gentoo), y estábamos preparados para la versión 1.0 de Gentoo Linux. Por entonces, decidí actualizar mi viejo Celeron 300 (overclockeado y fuerte como una roca a 450MHz) a un Abit BP6 de última generación (una placa Celeron dual que acababa de aparecer en el mercado). Vendí mi vieja máquina y ensamblé mi sistema Celeron dual. Después de overclockear los procesadores en algo del orden de los 500MHz, estaba en marcha. Sin embargo noté que mi máquina no era muy estable. Obviamente mi primera reacción fue volver a los 2x366 MHz. Pero comencé a experimentar un problema incluso más extraño. Conforme mi máquina engullía tiempo de CPU, no se bloqueaba. En cambio si dejaba la máquina ociosa durante la noche, había una alta probabilidad que el sistema se colgara completamente. Sí, un error de CPU ociosa - ¡Agh! Después de algunas investigaciones, encontré a otros usuarios de Linux con el mismo problema con esta placa en particular. Un chip en la BP6 (¿Era el controlador PCI?) parecía ser defectuoso o no cumplir las especificaciones, lo que causaba que Linux se colgara cuando no tenía nada que hacer. Era algo más que un simple cabreo, y como no me podía permitir pedir más componentes de PC, el desarrollo de Gentoo se detuvo. Me volví más y más pesimista sobre Linux y decidí cambiar a FreeBSD. Sí, FreeBSD. Y aquí es donde acaba esta entrega -- nos vemos en la Parte 3. :)
Daniel Robbins vive en Albuquerque, Nuevo Méjico. Fue Presidente/CEO de Gentoo Technologies Inc., el Arquitecto Jefe del proyecto Gentoo y es un autor que contribuye en varios libros publicados por MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, y Samba Unleashed. Daniel ha estado envuelto de alguna u otra forma en el mundo de las computadoras desde el segundo grado cuando entró en contacto con el lenguaje de programación Logo y una dosis potencialmente letal de Pac Man. Esto probablemente explica porqué desde entonces sirvió como Artista Gráfico en SONY/Electronic Publishing/Psygnosis. Daniel disfruta de su tiempo con su mujer Mary y su nueva hija Hadassah. Puedes contactar con Daniel en drobbins@gentoo.org. |
|