Linux 0.01 cumple 35 años: una primera versión para leer
El 17 de septiembre de 1991 apareció Linux 0.01. Su aniversario invita a recuperar una propuesta poco habitual: examinar un núcleo todavía incompleto, conocer sus límites y contribuir a que pudiera dar el siguiente paso.
Antes de imaginar servidores, distribuciones o instalaciones cómodas, conviene detenerse en una habitación con un ordenador muy concreto. Allí funciona un experimento. Fuera de ella, alguien descarga código y debe averiguar cómo adaptarlo a su máquina. Entre ambas situaciones hay una distancia enorme, y la primera publicación de Linux no intentaba ocultarla.
Lo que se puso al alcance de los demás fue una construcción que podían estudiar. En este aniversario del calendario nerd, la pregunta más interesante no es cuánto se parece aquel Linux al actual. Es qué significaba publicar cuando el destinatario tenía que ser, en buena medida, lector y colaborador.
Agosto, septiembre y octubre no celebran lo mismo
El 25 de agosto, el 17 de septiembre y el 5 de octubre de 1991 corresponden a momentos distintos. En agosto, Linus Torvalds pidió opiniones en el grupo de noticias de MINIX. Septiembre señala la primera publicación del código, la versión 0.01. En octubre anunció públicamente un sistema que ya resultaba más aprovechable. Fundir los tres momentos en un único lanzamiento borra la diferencia entre presentar un proyecto y facilitar su uso.
La entrada histórica de Linux 0.01 registra el 17 de septiembre de 1991, pero también una importación al repositorio Git realizada en 2007. La fecha antigua describe el lanzamiento conservado por el archivo; no significa que se utilizara Git en 1991.
En su recopilación de recuerdos y mensajes de 1992, Torvalds situaba la primera versión aproximadamente a mediados de septiembre. Una fecha archivística precisa y una memoria aproximada son testimonios diferentes. El aniversario de hoy corresponde a los primeros archivos publicados, no al primer mensaje sobre la idea.
Qué encontraba quien descargaba Linux 0.01
Las notas originales de la versión describen un núcleo para ordenadores AT con procesador 386, cuyo código había que configurar y compilar. Entre los requisitos aparecían una pantalla VGA o EGA, un controlador de disco compatible y hasta una distribución de teclado finlandesa incorporada al código. Torvalds afirmaba haber obtenido un núcleo operativo en dos máquinas.
Estos detalles permiten medir el trabajo que separa un prototipo de un producto. Que algo funcione en el equipo del autor no demuestra que otra persona pueda repetirlo sin ayuda. La compatibilidad, la preparación de archivos y las instrucciones forman parte de esa distancia. Ninguna desaparece por asignar un número de versión.
Un núcleo administra recursos y conecta los programas con el hardware. Un entorno utilizable necesita además herramientas, bibliotecas y aplicaciones. Las notas distinguen esos componentes e identifican el software GNU como una fuente importante de herramientas. Por eso no conviene imaginar 0.01 como una distribución moderna en miniatura: lo publicado tenía un alcance mucho más concreto.
Necesitar MINIX no significaba copiar MINIX
Las notas afirman que Linux no contenía código de MINIX y, a la vez, que necesitaba MINIX para ponerse en marcha. Parece una contradicción solo si confundimos la implementación con el entorno que permite prepararla. Un programa puede construirse con ayuda de otro sistema sin heredar su código.
La comparación con un taller resulta útil. Fabricar un aparato en un banco prestado no convierte ese aparato en un trozo del banco. El primer Linux necesitaba una base para preparar archivos y ejecutar su proceso de construcción. La compatibilidad con el sistema de archivos de MINIX facilitaba además el intercambio de datos entre ambos entornos.
La palabra «independiente» suele ocultar varias preguntas: ¿código propio?, ¿herramientas de construcción propias?, ¿instalación autónoma?, ¿mantenimiento independiente? Las respuestas pueden ser diferentes. Hacer visible un diseño nuevo no exigía resolver todas esas dependencias el mismo día.
¿Era una versión que realmente se podía ejecutar?
Aquí conviene conservar una discrepancia. Las notas de 1991 hablan de dos máquinas en las que funcionaba el núcleo, aunque presentan la publicación principalmente como material de lectura. En su retrospectiva posterior, Torvalds describió el código de 0.01 como no realmente ejecutable. Elegir solo una de las dos formulaciones produciría una historia demasiado cómoda.
La conclusión prudente es más limitada: era una publicación de código con obstáculos prácticos importantes, no una experiencia de instalación reproducible para cualquier usuario. Esos documentos no permiten determinar por sí solos qué preparativos, cambios locales o expectativas explican la diferencia. No hace falta inventar esa pieza ausente.
El contraste deja una lección útil: «funciona para su autor», «el archivo se puede compilar» y «otra persona puede reproducir el resultado» son afirmaciones distintas. Una documentación clara especifica cuál se ha probado. Saber que un proyecto acabó triunfando no nos autoriza a atribuir esa claridad a todas sus etapas anteriores.
La portabilidad todavía era una tarea pendiente
El diseño inicial aprovechaba características del 386, y las notas reconocían la dificultad de trasladarlo a otras arquitecturas. También describían el núcleo, el sistema de archivos y la gestión de memoria como código que compartía un mismo espacio durante la ejecución. Ahí se aprecia su enfoque monolítico.
No todos los límites eran simples huecos por rellenar. Algunos procedían de decisiones útiles para hacer funcionar una máquina concreta. Ampliar después el alcance requeriría revisar las suposiciones ligadas a ese hardware. Una solución local puede abrir el camino sin ser todavía una solución universal.
El artículo sobre Dennis Ritchie, C y la portabilidad de Unix ayuda a situar esa diferencia. Escribir buena parte de un sistema en C facilita ciertos cambios, pero no elimina automáticamente las dependencias del procesador. El lenguaje y las decisiones de arquitectura actúan en planos distintos.
El cambio a la GPL llegó después
También la licencia tuvo su propia evolución. Las condiciones de 0.01 exigían que el código estuviera disponible y que se conservaran los avisos de autoría. Al mismo tiempo prohibían cobrar por distribuirlo, incluso para cubrir gastos de manipulación. Esa no era la fórmula de la GPL que se asociaría después con Linux.
Las notas de Linux 0.12 proponen eliminar esa restricción y adoptar las condiciones del copyleft de GNU, dando a quienes habían contribuido la posibilidad de objetar. El texto señala el 1 de febrero como fecha prevista de entrada en vigor. En el contexto de comienzos de 1992, se trata de otro hito, posterior a septiembre de 1991.
La distinción histórica importa porque publicar código y definir las condiciones para redistribuirlo son decisiones separadas. Ambas influyen en quién puede participar y de qué manera. No es necesario atribuir a la primera versión un modelo de colaboración que todavía estaba evolucionando para reconocer su valor.
Un aniversario que se puede celebrar leyendo
Abre las notas originales y busca tres clases de afirmaciones: lo que funciona, lo que falta y lo que depende de una máquina determinada. Después compáralas con el recuerdo posterior de Torvalds. Ese pequeño ejercicio permite separar un documento de la narración que se construye a su alrededor, sin instalar software histórico en un ordenador de uso diario.
Linux 0.01 hizo visible un trabajo cuando aún mostraba sus costuras. Otros podían empezar a entenderlo, discutirlo y mejorarlo. Treinta y cinco años después, esa apertura sigue siendo lo más interesante del lanzamiento: una primera versión no necesita contener todo el futuro para permitir que alguien construya el siguiente paso.