Creando la distribución. Parte 11. El nacimiento de la distribución Gentoo Linux Hay un momento en el que para un entendido en Linux, éste se convierte en algo más que un nombre y se muestra como algo más maravilloso, potente y truculento que cualquier otra cosa que un desarrollador se haya encontrado. Mi revelación vino mientras estaba trabajando en la Universidad de Nuevo México como administrador de sistemas. Nuestros servidores NT se comportaban bastante bien y tuve algún tiempo extra en mis manos. Instalé Debian en un servidor Pentium 166 y comencé a aprender ... y a aprender y a aprender y a aprender. Y entonces me quedé enganchado. Primero aprendí los entresijos básicos de Linux: cómo manejarse, hacer copias de seguridad, correr Samba, etc. Entonces configuré qmail y Apache y aprendí python y programación de la shell. Construí una Intranet departamental. Instalé Linux en mi casa y probé diferentes distribuciones. Finalmente opté por Stampede Linux. Ya sabe como va la progresión: primero luchas por adquirir lo básico de Linux; luego cuando tienes un conocimiento decente, personalizas tu Linux, aprendiendo sobre la marcha. Ya que Linux no tiene nada que ocultar, puedes explorar la tecnología y herramientas que lo hace funcionar mientras mejoras tu fluidez en Linux. Linux ofrece algo que nunca antes había visto. Si tuviera que expresar ese concepto mágico en palabras, lo llamaría potencial: el potencial para cambiar, para mejorar, para arreglar cosas, y por supuesto, incluso para romper cosas. Conforme actualizaba a las nuevas versiones del núcleo comprobé que Linux mejoraba delante de mis ojos y se transformaba cada día. ¡Y yo quería seguir!, era parte de la transformación. Era divertido. Si es como yo, antes de ser expuesto a Linux y el código abierto, esperaba que esas grandes compañías en Redmond y Cupertino le proporcionaran un sistema operativo de última generación que finalmente funcionara exactamente como quería. Pero, sorpresa, ese sueño nunca se convirtió en realidad. Y mientras estábamos esperando, llegó Linux. Aunque tenía bastantes filos ásperos, nos daba algo para nosotros chicos y chicas hacker que podíamos perfeccionar mientras esperábamos por el siguiente gran evento. Y sonriendo todo el rato continuamos hackeando. Linux tiene que ver con la gente Lo siguiente que aprendí era que Linux tiene que ver con la gente. ¿No es esto bueno? Linux no es solo un puñado de líneas de código. Es una comunidad. Confiamos en esta comunidad para dar respuesta a nuestras preguntas, y llegamos a formar parte de la comunidad cuando empezamos a ayudar a otros contribuyendo con nuestro tiempo y conocimientos. IRC (Internet relay chat) es un gran lugar para conocer gente y gastar cantidades enormes de tiempo. El canal #stampede en irc.openprojects.net llegó a ser mi lugar frecuentado oficial. Ahí fue donde haría mis preguntas sobre Linux. También fue donde empecé a ayudar a otros. #stampede necesitaba usuarios experimentados en Linux para ayudar a los principiantes quién había conseguido instalar la distribución. Como es común en IRC, mucha de la gente con experiencia en Stampede habían perdido su entusiasmo por contestar (una y otra vez) preguntas de principiante. Estaba tan entusiasmado, por conocer realmente las respuestas a esas preguntas de los principiantes, ¡que no podía resistirme a ayudar!. Y así fue como me involucré en Stampede. Era simplemente otro tipo que quería contestar preguntas. Desde luego no era completamente altruista, ya que también me ayudaba a mi mismo a tener un nivel de conocimientos de Linux tal como el que el más experimentado del canal (¡sin mencionar los propios desarrolladores!) pudiera ofrecer. Cuando la gente me pregunta cómo enrolarse en un proyecto de código abierto, les digo que encuentren un lugar en el que puedan ser de ayuda, incluso si es únicamente contestando las preguntas más básicas acerca de Linux. Un deseo sincero de ayudar a otros es una gran entrada en la comunidad Linux porque este sentimiento está en el corazón de todo desarrollo de código abierto (incluyendo Linux). Cuanto menos así debería ser. A lo largo del camino inevitablemente encuentras gente que sabe más que tú. Y debes aprender de ellos cómo los principiantes continúan aprendiendo de ti. También es cierto que mientras ganas experiencia te encuentras oportunidades de ayudar de nuevas formas. Quizá alguno de los desarrolladores de proyectos que te encuentras sugiera algo, o incluso pida ayuda. Te pueden incluso invitar a que seas parte del equipo de desarrollo. Si estas centrado en ayudar a otros, éstos estarían locos si te ignoraran. Si estás ayudando a mucha gente, seguramente seas percibido en la comunidad. Esto fue lo que sucedió entre el proyecto Stampede y yo. Gradualmente me involucré más y más en el desarrollo de Stampede. En breve, fui un desarrollador de Stampede. Con la bendición de skibum (Matt Wood, el principal líder de Stampede), comencé trabajando en una nueva versión del primitivo formato de empaquetamiento .slp de Stampede. Por entonces el formato de empaquetamiento .slp consistía en un fichero .tar.bz2 con un pie añadido al final que contenía información sobre el autor del paquete, una descripción de los contenidos, el creador del paquete, etc. Este enfoque tenía dos serios problemas: los campos eran de longitud fija y el pie realmente no era tan grande, y no había ningún tipo de extensibilidad construida en el formato (no había forma de añadir campos adicionales al formato .slp en el futuro). Obviamente este hecho necesitaba una puesta a punto enorme. Trabajando con los desarrolladores senior de Stampede, escribí una propuesta de como tratar el problema. Entonces comencé a codificar las herramientas prototipo en Python. El nuevo formato (llamado slpv6) era de alguna forma similar al formato IFF del mundo Amiga. Esta nueva generación del formato .slp permitía 2 32 campos. 2 32 categorías de campos, y una longitud máxima de campo de 2 32 bytes. No solo el formato era muy extensible, era más compacto que el texto plano y fácil de analizar. Tanto texto como datos binarios podían ser almacenados en este formato, lo que permitía muchas posibilidades de cara al futuro. La idea era añadir esta cabecera dinámica de nueva generación al final del fichero, produciendo por lo tanto una nueva generación de formato .slp que serviría a los usuarios de Stampede durante los años venideros manteniendo la compatibilidad con el estándar UNIX de formatos de fichero. El desarrollo de slpv6 iba bien y todos los desarrolladores senior estaban felices con mi progreso. Pero, desafortunadamente, dos desarrolladores Stampede de menor nivel querían controlar el proyecto slpv6. No les gustaba el rumbo que yo estaba tomando, y gastaron la mayor parte de su tiempo insultando el nuevo sistema slpv6. A pesar de que pasé horas en discusiones defendiendo la propuesta ante sus ataques, no fueron capaces de resolver nada. Eventualmente quedó claro que eran naturalmente argumentativos y que no se mostrarían contentos hasta que se optara por su camino. Afortunadamente para mi, mi proyecto tenía la aprobación de los desarrolladores senior de Stampede. Pero estas discusiones empezaron a calar en mi, e hicieron el desarrollo de Stampede muy desagradable. ¡Uff! No podía ignorar a estos tipos ya que tenía que dejarme caer por #stampede para chatear con desarrolladores de mayor nivel. Cada vez que entraba en el canal, ellos se volvían combativos, tratando de socavar mi trabajo. Usarían técnicas enrevesadas como solicitar reuniones de desarrollo (realmente era solo una oportunidad de insultar mi trabajo ante los desarrolladores senior). También tratarían de pedir una votación, intentando obtener el control de Stampede. Desde luego solo pedirían una votación cuando pensaran que habían convencido a la suficiente cantidad de gente para ponerse de acuerdo con ellos. A lo largo de todo esto, continué mi desarrollo de slpb6. No es necesario añadir que el desarrollo senior admiraba mi trabajo y quería que continuara con él (sin su apoyo no habría sido capaz de sacarlo adelante). Estos dos tipos pertenecen a una categoría de desarrolladores que a mi me gusta llamar "el freak". Pero aunque hicieron que mi desarrollo fuera muy desagradable, también aprendí mucho de tratar con ellos. En este punto me gustaría ofrecer una exposición de los desarrolladores freak, algo como una vista general y extensa: las cualidades que hacen a un freak, el modus operandi del freak, y cómo el líder de desarrollo del proyecto, puede enfrentarse y posiblemente reformar al freak sin ejercer mucho esfuerzo. Para evitar daño emocional, necesitará un requisito previo: una posición firme. Si no es capaz de enfrentarse al freak en una respetuosa pero firme actitud, no hay esperanza. La meta del freak es controlar lo suficiente de su proyecto para que él o ella se sientan poderosos. El freak usará diversas técnicas para que esto suceda. Primero comenzará criticando con malos modos o se quejará amargamente sobre el proyecto y/o los desarrolladores que trabajan en un proyecto. Entonces se abstendrán de ofrecer ninguna solución constructiva. Tampoco estarán dispuestos a ayudar en el proyecto de ninguna forma hasta que sean promocionados al rol de jefe de proyecto. Su meta es convencerle de darle la mayor autoridad posible para que puedan resolver los problemas que solo ellos, con sus finamente entrenados ojos de freak, pueden ver. Si la crítica y las protestas no son efectivas, solicitarán una reunión de desarrolladores. Esta será su oportunidad de intentar dividir su equipo de desarrollo en dos facciones. Cuando crean que tienen bastante gente de su lado, pedirán una votación (sabiendo que la ganarán). En caso de no ganar la votación o ésta fuera invalidada, intentarían otra reunión de desarrollo la semana siguiente en la cual tratarían de dividir su equipo de desarrollo. Repetirán este proceso continuamente. Si el enfoque de las reuniones de desarrolladores no funciona, los freaks se reformarán. Adoptando este rol intentarán hacer más eficiente (léase: socavar) el opresivo y desagradable proceso de toma de decisiones ejecutivo, intentado reemplazarlo por uno más democrático (léase: fácilmente manipulable). Esto a menudo implica convencerle que debe hacer lo que la mayoría de los desarrolladores deseen. Los freaks adoran esto porque no se pueden anular esas votaciones de reuniones de desarrolladores de ninguna forma (¡jajaja!). Si permite que esto suceda, esta básicamente dándole al freak las llaves de su Lexus. Nos quedamos sin poder. Desde otro punto de vista, los freaks irritarán y distraerán a sus productivos desarrolladores. Entonces convertirán a su equipo en un una masa histérica mientras tratan con gran esfuerzo de reformar la estructura de poder de su proyecto. Si sus esfuerzos son finalmente mitigados, tratarán de reunir la mayor cantidad de detractores y desmembrar su proyecto. ¡Vaya! Puede identificar a estos tipo de forma muy sencilla. son los que no escriben nada de código (ni tienen la intención de hacerlo). En lugar de eso, gastan su tiempo hablando de cosas más importantes. Ya sabe, esas cosas de la gestión. Si es el líder de un proyecto, es muy fácil tratar con ellos. Simplemente dígales que no considerará ninguna propuesta a menos que produzcan algo de código válido. O insista en que están ayudando constructivamente al proyecto actual, lo que incluye obedecer al jefe de proyecto, antes de darles la oportunidad de ofrecer alguna crítica (constructiva). Si escriben buen código o comienzan a ofrecer más ayuda, entonces perfecto. Si no, dígales que abandonen el proyecto. Ellos abandonarán (si los ignora durante el suficiente tiempo), o comenzarán a escribir algo de código y generalmente se volverán más agradables. Desafortunadamente los desarrolladores senior no se encargan de la gestión de los freaks. En otras palabras, permiten que estos dos tipos me molesten a mi (y a otros) continuamente. Aunque los desarrolladores senior estuvieron siempre a favor de mi trabajo desarrollando, nunca hicieron gran cosa para poner a estos tipos bajo control. Por eso un día decidí que sería más fácil para mi crear mi propia distribución en lugar de aguantar a estos dos freaks. Dejé el desarrollo en Stampede y comencé a hacer planes para producir mi propia distro. Aunque me sentía un poco extraño por dejar el proyecto a causa de estos dos desarrolladores de bajo nivel, el hecho que no hubiesen sido manejados de forma adecuada indicaba que el proyecto tenía serios problemas de gestión. Si los desarrolladores de alto nivel no querían o no eran capaces de asegurarse que el esfuerzo en el desarrollo de Stampede era agradable y gratificante, entonces yo no quería estar allí. Una vez fuera, suspiré enormemente de relajo. ¡Uau! Finalmente, las cosas se calmaban y paraban. Ahora era el momento de definir que trataría mi distribución y de cómo contribuiría a la escena de las distribuciones Linux. Una de las cosas que me atrajo de Stampede era su rendimiento (gracias al uso del compilador experimental optimizado para Pentium pgcc). Decidí, por tanto enfocar en primer lugar en el rendimiento. Aparte de minimizar la utilización de la CPU, también quería minimizar la sobrecarga. Demasiadas distribuciones (especialmente esas encogidas y envueltas tan populares) habilitan tantos demonios por defecto que te queda muy poca RAM para abrir un xterm a continuación. Quería que mi distribución fuera pequeña e inteligente, y enfocada en maximizar el rendimiento del hardware en el que corriese. Decidí usar un enfoque holístico y acometer el problema del rendimiento desde todos los ángulos. Pero tenía una seria falta de recursos, ¡ya que era el único desarrollador de mi distribución! ¿Cómo podía crear algo comparable a Caldera o RedHat desde la base, yo solo? La respuesta eran los automatismos. Tenía que escribir guiones para automatizarlo todo, por lo que tendría un consumo de tiempo mínimo en las labores repetitivas. Después de todo, eso es lo que mejor hacen las computadoras ¿no?. Comprobé rápidamente que escribir escribir guiones simples para el tipo de automatismo que necesitaba no iba a ser suficiente. Necesitaba diseñar un sistema completo para generar una distribución Linux desde cero. Con indecisión la llamé sistema ebuild y me puse a trabajar. El sistema ebuild sería capaz de crear automáticamente todos los binarios de la distribución, automatizando todo, desde el desempaquetado y parcheado de las fuentes hasta su compilación, instalación y empaquetado. Después de obtener un prototipo básico de ebuild funcionando, comencé a crear los guiones ebuild para los componentes clave de una distribución Linux (como gcc, glibc, binutils, util-linux, y sus amigos). Mi equipo de desarrollo Stampede se fue convirtiendo gradualmente en mi propio sistema, ya que había rediseñado los guiones de inicialización (basándome en los guiones de inicialización de Stampede que yo había diseñado previamente) y testeado e instalado cada nuevo paquete que había creado. Unos meses después, tenía una distribución Linux, completa y autohospedada. La llamé Enoch y me relajé y sonreí feliz. Pero, ¿que pasó con Enoch?, y ¿cómo evolucionó Gentoo Linux?. Acompáñeme en mi siguiente artículo y le contaré la historia de cómo Enoch se convirtió en Gentoo Linux, y de los muchos nuevos retos que afronté por el camino.
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. |
|