En la lección anterior quedó claro que Linux es un kernel y que la caja completa es una distribución. Ahora toca responder a una pregunta que parece de cultura general pero que es profundamente práctica: ¿por qué Linux es como es?

Cuando dentro de unos módulos escribas algo como cat acceso.log | grep ERROR | sort | uniq -c, estarás usando un idioma diseñado en 1969 en un laboratorio de New Jersey. Cuando te preguntes por qué la configuración de un servidor son archivos de texto y no un registro binario, la respuesta está en esa misma década. Y cuando te choque que un comando que funciona no imprima absolutamente nada, también.

Esta lección no es un adorno histórico: es la explicación del diseño. Vas a ver de dónde viene Unix, cuáles son sus principios, cómo el proyecto GNU y el kernel de un estudiante finlandés se encontraron por casualidad en 1991, y cómo se desarrolla hoy el kernel que corre en srv-tramontana.

1. Por qué la historia importa para entender el diseño actual
2. Unix en los Bell Labs (1969)
3. La filosofía Unix y sus principios
4. La fragmentación de Unix y el estándar POSIX
5. El proyecto GNU (1983) y la pieza que faltaba
6. Linus Torvalds y el anuncio de 1991
7. Por qué se dice "GNU/Linux"
8. Línea de tiempo: de 1991 a la nube
9. Cómo se desarrolla hoy el kernel

Un sistema operativo no es un producto neutro: es la cristalización de las decisiones de las personas que lo hicieron, en las condiciones en que lo hicieron. Unix nació en un ordenador con 8 KB de memoria que había que compartir entre varios usuarios simultáneos. Esa escasez brutal impuso un estilo: nada de programas gigantes, nada de interfaces decorativas, nada de gastar un byte de más.

Tres rasgos que verás a diario en Linux se explican solo así:

Ese último punto es el más importante de los tres. Que /etc/tramontana/app.conf sea texto plano y no un binario propietario es lo que te permitirá buscarlo con grep, versionarlo con Git, generarlo con un script y desplegarlo con Ansible en 200 máquinas. Todo el Módulo 3 y el Módulo 4 de este curso existen gracias a esa decisión de 1970.

A finales de los sesenta, los Bell Labs de AT&T participaban junto al MIT y General Electric en Multics, un sistema operativo ambicioso, pensado para dar servicio informático como quien da electricidad. Multics tenía ideas brillantes, pero se volvió enorme y lento. En 1969 Bell Labs abandonó el proyecto.

Dos de sus ingenieros, Ken Thompson y Dennis Ritchie, se quedaron con la frustración y con las ideas. Thompson encontró un PDP-7 en desuso y escribió en unas semanas un sistema mínimo para poder seguir jugando a Space Travel, un programa de simulación espacial. Ese sistema tenía un sistema de archivos jerárquico, procesos y un intérprete de comandos. Brian Kernighan lo bautizó UNICS (medio en broma, como un «Multics castrado»), y acabó quedando Unix.

Los hitos que lo cambiaron todo:

• 1969: primer Unix en el PDP-7, escrito en ensamblador.
• 1971: primera edición documentada; aparecen las páginas de manual (man), que seguirás usando en la lección 02-02.
• 1972: Dennis Ritchie crea el lenguaje C.
• 1973: Unix se reescribe en C. Este es el momento decisivo.

Reescribir un sistema operativo en un lenguaje de alto nivel era casi herejía: se perdía rendimiento. Pero ganaba algo mucho más valioso: portabilidad. Hasta entonces cada sistema operativo estaba atado a un modelo de ordenador; a partir de ahí, Unix podía llevarse a otra máquina recompilándolo. Es la razón última de que hoy el mismo Linux corra en tu portátil, en un servidor, en un móvil y en un supercomputador.

Y hubo un accidente afortunado: AT&T era un monopolio telefónico regulado y tenía prohibido comercializar software. Así que distribuyó Unix a las universidades por un coste simbólico, con el código fuente. Generaciones enteras de estudiantes aprendieron sistemas operativos leyendo, modificando y mejorando Unix. De ahí salió, entre otras cosas, la rama BSD de la Universidad de California en Berkeley, ancestro directo del macOS actual.

Esta sección es la más importante de la lección. Los principios que siguen no son historia: son el manual de estilo con el que está escrito todo lo que vas a aprender.

Doug McIlroy, jefe del departamento donde nació Unix, lo resumió así:

«Escribe programas que hagan una sola cosa y la hagan bien. Escribe programas que colaboren entre sí. Escribe programas que manejen flujos de texto, porque esa es una interfaz universal.»

Desglosemos los principios operativos.

En Linux no hay un gran programa «gestor de logs». Hay cat (mostrar), grep (filtrar), sort (ordenar), uniq (contar repetidos), cut (extraer columnas), wc (contar). Cada uno hace una sola tarea y la hace bien.

La ventaja: aprender 30 herramientas pequeñas te da miles de combinaciones útiles, mientras que aprender un programa monolítico te da exactamente lo que su autor previó.

Un documento es un archivo. Un directorio es un archivo. Tu disco duro es un archivo (/dev/sda). Tu terminal es un archivo. La información del procesador es un archivo (/proc/cpuinfo). Un socket de red es un archivo.

¿Por qué es tan potente? Porque con un mismo juego de operaciones (open, read, write, close) manipulas cosas radicalmente distintas, y por tanto las mismas herramientas sirven para todo. Verás esto en detalle en la lección 01-06.

Una tubería (pipe, el carácter |) conecta la salida de un programa con la entrada del siguiente. Fue idea de McIlroy, implementada por Thompson en 1973, y es probablemente la mejor idea de la historia de los sistemas operativos.

Mira este ejemplo con los datos de Tramontana. Supón el archivo /var/log/tramontana/acceso.log:

Salida:

Qué ha pasado, pieza a pieza:

• cat /var/log/tramontana/acceso.log vuelca el contenido del archivo a su salida.
• El carácter | conecta esa salida con la entrada del programa siguiente. Nada se guarda en disco: los datos fluyen en memoria.
• grep ERROR deja pasar únicamente las líneas que contienen el texto ERROR.
• wc -l cuenta líneas (word count, opción lines).
• Resultado: 17 errores en el registro de acceso.

Ninguno de los tres programas sabe de la existencia de los otros. Ninguno fue escrito pensando en Tramontana. Y sin embargo resuelven juntos un problema concreto. Eso es componibilidad, y es el motivo por el que un administrador de Linux puede responder en 10 segundos a preguntas que en otros sistemas exigen escribir un programa.

No te preocupes si ahora mismo no dominas la sintaxis: las tuberías son el corazón del Módulo 3. Aquí solo necesitas entender la idea.

Si todos los programas hablan texto plano línea a línea, cualquiera puede conectarse con cualquiera. Un formato binario, por muy eficiente que sea, rompe esa cadena.

Un comando Unix que funciona correctamente no dice nada. Solo habla cuando hay un problema. Esto desconcierta al principio («¿lo ha hecho o no?») y luego se agradece: en un script que procesa 5.000 archivos, no quieres 5.000 mensajes de confirmación.

El sistema te da herramientas y no te impone cómo usarlas. No hay un «modo correcto» de organizar tus scripts. Esa libertad es potente y también peligrosa: la disciplina la pones tú.

En 1984, la ruptura del monopolio de AT&T le permitió por fin comercializar Unix. El código dejó de circular libremente y cada fabricante desarrolló su propia versión comercial, incompatible con las demás:

A esto se le llamó las guerras de Unix. Un programa escrito para Solaris no compilaba en AIX sin retoques. Los clientes quedaban atrapados con su fabricante. La fragmentación debilitó a Unix justo cuando Windows NT empezaba a comerle el mercado corporativo.

La respuesta fue POSIX (Portable Operating System Interface), un estándar del IEEE publicado a partir de 1988 que define un mínimo común: qué llamadas al sistema debe haber, qué comandos, qué comportamiento del shell, qué señales. Si escribes tu software respetando POSIX, funcionará en cualquier sistema conforme.

Linux no está certificado formalmente como POSIX (la certificación cuesta dinero y a nadie le ha compensado), pero es ampliamente conforme en la práctica. Esto tiene una consecuencia muy concreta para ti: cuando en el Módulo 4 escribas scripts respetando POSIX, funcionarán igual en Ubuntu, en Rocky Linux, en Alpine dentro de un contenedor y en macOS. Es una habilidad transferible, no un conocimiento de producto.

Y una lección estratégica que explica el presente: la GPL evitó que a Linux le pasara lo que le pasó a Unix. Como cualquier modificación distribuida debe publicarse, no hubo forma de crear un «Linux de IBM» cerrado e incompatible. La licencia fue el pegamento que mantuvo unido el ecosistema.

Richard Stallman trabajaba en el laboratorio de inteligencia artificial del MIT, en una cultura donde el código se compartía sin más. A principios de los ochenta esa cultura se desmoronó: los programas pasaron a distribuirse solo en binario y con acuerdos de confidencialidad. La anécdota fundacional es célebre: Stallman quiso arreglar el controlador de una impresora Xerox que atascaba trabajos y no le dieron el código fuente.

En septiembre de 1983 anunció el Proyecto GNU, acrónimo recursivo de GNU's Not Unix: crear un sistema operativo completo, compatible con Unix, pero enteramente libre. En 1985 fundó la Free Software Foundation y en 1989 escribió la GPL.

Durante los años siguientes, el proyecto GNU produjo un arsenal de software de primerísima calidad, la mayor parte del cual sigues usando hoy sin saberlo:

Para 1991 GNU tenía prácticamente todo el sistema operativo... menos el kernel. Su kernel, GNU Hurd, apostaba por una arquitectura de micronúcleo, técnicamente elegante pero endiabladamente difícil de estabilizar. Llevaba años de retraso. Hurd existe todavía hoy y sigue sin ser de uso general.

Había un sistema operativo libre completo esperando un núcleo.

En Helsinki, un estudiante de 21 años llamado Linus Torvalds estudiaba sistemas operativos con Minix, un Unix pequeño y didáctico escrito por el profesor Andrew Tanenbaum. Minix tenía código disponible, pero su licencia era restrictiva y su autor lo mantenía deliberadamente simple para que siguiera siendo enseñable.

Torvalds, frustrado con esas limitaciones y con un PC 386 recién comprado, empezó a escribir su propio kernel. El 25 de agosto de 1991 publicó en el grupo de noticias comp.os.minix un mensaje que hoy es historia:

«Estoy haciendo un sistema operativo (libre y gratuito) (solo un hobby, no será grande ni profesional como GNU) para clones de AT 386(486). [...] Me gustaría saber qué funcionalidades quiere la mayoría de la gente.»

Dos observaciones sobre ese texto, porque enseñan más que cualquier moraleja:

• La modestia era sincera y estaba equivocada. «Solo un hobby, no será grande ni profesional» describe el kernel que hoy mueve la mayor parte de internet.
• La pregunta final es la clave del éxito. «Me gustaría saber qué funcionalidades quiere la mayoría de la gente» no era retórica. Torvalds publicaba versiones cada pocos días e integraba parches de desconocidos. Ese modelo —publicar pronto, publicar a menudo, integrar contribuciones— fue tan innovador como el propio código.

En septiembre de 1991 apareció la versión 0.01: unas 10.000 líneas, sin capacidad de arrancar por sí sola. En enero de 1992, con la versión 0.12, Torvalds tomó la decisión más trascendente de todas: cambiar la licencia a GPL. La licencia original que había escrito prohibía la venta comercial, lo que habría frenado su adopción. Años después él mismo lo calificó como «lo mejor que hice nunca».

El encaje fue inmediato. El kernel de Torvalds necesitaba herramientas de espacio de usuario; GNU las tenía todas. GNU necesitaba un kernel; ahí había uno que funcionaba. La combinación kernel Linux + userland GNU era, de un día para otro, un sistema operativo libre completo y utilizable. La versión 1.0 llegó en marzo de 1994, con 176.000 líneas de código y soporte de red.

Stallman y la FSF sostienen que llamar «Linux» al sistema completo es injusto: el kernel es una parte importante, pero el compilador, el shell, las librerías y la mayoría de las utilidades salieron del proyecto GNU, que llevaba ocho años trabajando con ese objetivo explícito. Su propuesta es GNU/Linux.

Torvalds y buena parte de la comunidad prefieren el uso corto por comodidad. La discusión lleva treinta años y no se va a resolver.

Postura práctica para tu vida profesional:

• Ambos nombres son correctos y todo el mundo entiende los dos.
• En el uso cotidiano y en este curso diremos Linux, por brevedad.
• Debian y algunas distribuciones usan oficialmente GNU/Linux.
• Lo que sí es un error técnico es creer que el kernel es el sistema. Esa parte de la reivindicación de Stallman es simplemente cierta, y ya la tienes clara desde la lección anterior.

Un matiz interesante: hoy existen sistemas Linux sin GNU. Android usa el kernel Linux con la librería Bionic; Alpine Linux (la base de la mayoría de contenedores, que verás en el Módulo 7) usa musl y BusyBox en lugar de glibc y coreutils. En esos casos «GNU/Linux» sería directamente incorrecto.

Merece la pena detenerse en tres momentos de esa línea:

• 1993-1994, las distribuciones. El kernel por sí solo era intratable para la mayoría. Slackware y Debian primero, y Red Hat después, resolvieron el problema de reunir e instalar el conjunto. Es cuando Linux deja de ser un proyecto y empieza a ser un producto.

• 1998-2004, la entrada en la empresa. IBM invirtió mil millones de dólares en Linux en 2001. Los grandes fabricantes de software portaron sus productos. Linux pasó de «juguete de estudiantes» a plataforma con soporte comercial. En paralelo, Google construyó su infraestructura sobre Linux desde el principio.

• 2013 en adelante, la nube y los contenedores. Las funcionalidades del kernel que hacen posibles los contenedores (namespaces y cgroups, que verás en el Módulo 7) llevaban años ahí. Docker las empaquetó de forma usable en 2013 y cambió la industria. Hoy no hay nube sin Linux, y el remate simbólico llegó en 2018 con Microsoft —el mismo que en 2001 llamaba a Linux «un cáncer»— incorporando un kernel Linux dentro de Windows.

Y un dato final que cierra el círculo: en 2001 Microsoft era el gran adversario; hoy es uno de los mayores contribuyentes corporativos al kernel Linux y el dueño de GitHub, donde vive buena parte del software libre del mundo.

Entender el proceso te ayuda a saber qué versión de kernel tienes en srv-tramontana y qué puedes esperar de ella.

Linux sigue un ritmo predecible desde hace más de una década:

1. Merge window (2 semanas). Torvalds acepta todas las funcionalidades nuevas que los mantenedores le envían. Se cierra y se publica la -rc1.
2. Candidatas a release (7-8 semanas). Cada domingo sale una -rc2, -rc3... Solo se admiten correcciones de errores.
3. Release final. Sale la versión estable. Al día siguiente se abre la ventana de la siguiente.

Total: una versión nueva cada 9-10 semanas, aproximadamente. La numeración (5.x, 6.x) es puramente cosmética: Torvalds sube el primer número cuando el segundo se le hace incómodamente grande, no porque haya cambios revolucionarios.

Las versiones normales dejan de mantenerse en cuanto sale la siguiente. Por eso existen los kernels LTS (Long Term Support), que reciben correcciones de seguridad durante varios años (típicamente entre 2 y 6). Son los que usan las distribuciones de servidor.

Ubuntu Server 24.04 LTS parte del kernel 6.8, con parches de seguridad respaldados por Canonical durante todo el ciclo de vida de la distribución. Esto significa algo importante: no verás un kernel 6.14 en srv-tramontana aunque exista. En producción se prima la estabilidad sobre la novedad.

Puedes comprobar tu versión en cualquier momento con un comando que veremos con calma en la lección 01-05:

Salida en el servidor de Tramontana:

Interpretación de cada parte:

• 6 : versión mayor.
• 8 : versión menor (kernel 6.8, la base de Ubuntu 24.04 LTS).
• 0 : nivel de parche de la rama estable.
• 41 : número de compilación de Ubuntu. Aquí es donde Canonical incorpora sus correcciones respaldadas.
• generic : sabor del kernel. Existen otros como aws, azure o lowlatency, optimizados para entornos concretos.

La imagen de voluntarios altruistas ya no describe la realidad:

• Más de 2.000 desarrolladores de unas 200 empresas contribuyen en cada versión.
• En torno al 85-90 % de las contribuciones son de gente pagada por su empresa para hacerlo: Intel, Red Hat, Google, AMD, Huawei, Meta, Oracle, Linaro, Microsoft.
• Se integran del orden de 10 a 15 parches por hora, todos los días del año.

La estructura de decisión es una jerarquía de confianza: los desarrolladores envían parches a mantenedores de subsistema (red, sistemas de archivos, drivers de gráficos...), esos mantenedores los revisan y los agrupan, y quien integra finalmente en la rama principal es Linus Torvalds, con Greg Kroah-Hartman al frente de las ramas estables. Es un modelo meritocrático y notoriamente exigente: los parches se rechazan a menudo y las revisiones pueden ser duras.

• Creer que Torvalds escribió Linux entero. Escribió el kernel inicial y sigue dirigiendo el proyecto, pero hoy su aportación en líneas de código es mínima: su trabajo es integrar y arbitrar. Linux es obra de decenas de miles de personas.
• Confundir Unix, Linux y "tipo Unix". Unix es el sistema original de AT&T y sus descendientes comerciales certificados. Linux no contiene código de Unix: se escribió desde cero imitando su comportamiento. Por eso se dice Unix-like. Este detalle no es trivial: fue el centro del pleito de SCO contra IBM (2003-2010), que perdió sin encontrar código de Unix en Linux.
• Pensar que la historia no sirve para nada práctico. La filosofía Unix es el criterio con el que evaluarás tus propios scripts en el Módulo 4: ¿hace una sola cosa?, ¿se puede encadenar?, ¿habla texto?
• Tratar la elección de licencia como un detalle menor. El paso a GPL en 1992 es la razón de que exista un ecosistema Linux unificado en lugar de veinte variantes incompatibles. Las licencias tienen consecuencias técnicas.
• Consejo. Si quieres profundizar, lee «The Art of Unix Programming» de Eric S. Raymond (disponible libremente en línea). Es el mejor desarrollo de la filosofía Unix que existe y se lee como un ensayo, no como un manual.
• Consejo práctico inmediato. Cuando empieces a escribir scripts, pregúntate siempre: «¿podría resolver esto encadenando herramientas que ya existen?». En Linux, la respuesta es que sí muchísimo más a menudo de lo que crees.

Relaciona cada característica del Linux actual con el hecho histórico que la explica. Justifica cada relación en dos o tres frases:

1. Los comandos tienen nombres muy cortos (ls, cp, mv).
2. La configuración del sistema son archivos de texto en /etc.
3. Existe un estándar llamado POSIX.
4. El mismo Linux corre en un móvil y en un supercomputador.
5. No hay versiones de Linux privativas e incompatibles entre sí.

Luis Ferrer ha escrito para Tramontana un programa llamado analizador-tramontana que lee el archivo /var/log/tramontana/acceso.log, filtra los errores, los ordena, los cuenta, genera un gráfico y envía un correo a Marta. Todo en un único binario, con un archivo de configuración en formato binario propietario.

Evalúa el diseño según la filosofía Unix: indica qué principios incumple y propón una alternativa concreta que respete esa filosofía. Razona qué gana el equipo con el rediseño.

En srv-tramontana ejecutas uname -r y obtienes 6.8.0-41-generic. Marta ha leído que existe el kernel 6.14 y te pregunta por qué el servidor «va desactualizado y probablemente inseguro». Redacta la respuesta que le darías, explicando la numeración y el concepto de LTS.

Solución al Ejercicio 1

1. Nombres de comandos cortos. Unix nació en 1969-1970 sobre teletipos: terminales que imprimían en papel a velocidades de decenas de caracteres por segundo. Escribir era lento y ruidoso, y cada carácter ahorrado era tiempo real ganado. Esa economía se fosilizó en el juego de comandos y nunca se cambió, porque para entonces ya había millones de scripts y de personas que los usaban. Hoy sobreviven por compatibilidad, no por necesidad.

2. Configuración en texto plano. Deriva directamente del principio «el texto es la interfaz universal». Si la configuración es texto, cualquier herramienta genérica puede manipularla: grep para buscar, sed para modificar, Git para versionar, Ansible para desplegar. Un formato binario obligaría a una herramienta específica para cada archivo y rompería toda la cadena de composición.

3. POSIX. Es la reacción a las guerras de Unix de los años ochenta. Al comercializarse Unix, cada fabricante creó su variante incompatible (AIX, HP-UX, Solaris, IRIX...) y los programas dejaron de ser portables. POSIX define el mínimo común denominador de llamadas, comandos y comportamiento del shell para que el software escrito una vez funcione en cualquier sistema conforme.

4. Portabilidad extrema. Es consecuencia de la reescritura de Unix en C en 1973. Al no depender del ensamblador de una máquina concreta, portar el sistema a un procesador nuevo pasó a ser cuestión de recompilar y adaptar las partes dependientes del hardware. Linux heredó ese diseño y hoy soporta más de veinte arquitecturas.

5. Ausencia de forks privativos. Es el efecto de la licencia GPL adoptada en 1992. El copyleft obliga a que cualquier versión modificada que se distribuya lo haga también bajo GPL y con el código fuente. Ningún fabricante ha podido crear un Linux cerrado, y las mejoras vuelven al tronco común. Es exactamente el mecanismo que le faltó a Unix.

Solución al Ejercicio 2

Principios que incumple el diseño de Luis:

Alternativa respetuosa con la filosofía Unix:

Descomponer en piezas ya existentes y encadenarlas, dejando en un script solo lo que es específico de Tramontana:

Explicación paso a paso:

• grep ERROR ... filtra las líneas de error. Sustituye al módulo de filtrado.
• sort las ordena para que las iguales queden juntas, requisito de uniq.
• uniq -c colapsa las líneas repetidas y antepone el número de repeticiones.
• sort -rn reordena por ese número, de mayor a menor (-n numérico, -r inverso): los errores más frecuentes arriba.
• > redirige el resultado a un archivo (lo verás en el Módulo 3).
• mail envía ese archivo por correo. Solo esta parte es "de Tramontana".

Y la configuración pasaría a ser un archivo de texto en /etc/tramontana/.

Qué gana el equipo:

• Menos código propio que mantener: cinco herramientas probadas por millones de usuarios sustituyen a cinco módulos escritos en casa.
• Flexibilidad: si Marta pide filtrar además por fecha, se añade otro grep a la tubería sin tocar nada más.
• Reutilización: el mismo sort | uniq -c sirve para analizar reservas.csv.
• Depurabilidad: puedes ejecutar la tubería paso a paso y ver la salida intermedia de cada etapa. Con el binario monolítico, si el resultado es raro no sabes qué componente falló.
• Automatización: al ser texto y comandos, todo esto se programa con cron (Módulo 3) y se despliega con Ansible (Módulo 7).

Solución al Ejercicio 3

Respuesta para Marta:

«El número no funciona como en una aplicación de móvil, donde el más alto siempre es el mejor. En 6.8.0-41-generic, el 6.8 es la línea base del kernel que Ubuntu 24.04 LTS eligió al publicarse, y el -41 es lo importante: es el número de compilación de Ubuntu, y sube cada vez que Canonical incorpora correcciones de seguridad a esa línea base.

El kernel Linux publica una versión nueva cada 9 o 10 semanas. Ninguna distribución de servidor persigue ese ritmo, porque cada versión nueva trae funcionalidades nuevas y, con ellas, riesgo de regresiones en los drivers y en el rendimiento. Lo que se hace en producción es fijar una línea base estable y aplicarle solo las correcciones de seguridad, una práctica que se llama backporting.

Ese es el sentido de una distribución LTS (Long Term Support): Ubuntu 24.04 LTS se mantiene con parches de seguridad hasta 2029. Cuando aparece una vulnerabilidad grave, Canonical la corrige sobre el 6.8 y publica un -42, un -43, etcétera. Recibimos la protección sin recibir los cambios funcionales.

Así que el servidor no está desactualizado en lo que importa: está en una línea mantenida y recibe seguridad al día. Podemos verificarlo con apt list --upgradable y con el historial de actualizaciones. Instalar el 6.14 nos daría funcionalidades que no necesitamos, nos sacaría del soporte oficial de Canonical y nos expondría a fallos de hardware imprevistos en producción. En un servidor, aburrido es un cumplido.»

Lo esencial de esta lección:

• Unix nació en los Bell Labs en 1969 y se reescribió en C en 1973, lo que le dio la portabilidad que hoy hereda Linux.
• La filosofía Unix —programas pequeños que hacen una cosa bien, todo es un archivo, componer con tuberías, texto como interfaz universal, silencio si hay éxito— es el criterio de diseño que explica prácticamente todo lo que verás en este curso.
• La fragmentación comercial de Unix llevó al estándar POSIX, que es lo que hace transferibles tus conocimientos y tus scripts entre sistemas.
• El proyecto GNU (1983) construyó todo el sistema operativo libre menos el kernel; el kernel de Torvalds (1991) apareció justo a tiempo, y el paso a GPL en 1992 evitó que Linux se fragmentara como Unix.
• El kernel se desarrolla hoy con un ciclo de 9-10 semanas, versiones LTS para producción y miles de desarrolladores pagados por empresas.

Con la genealogía clara, ya puedes entender por qué existen tantos «Linux» distintos y en qué se diferencian de verdad. En la siguiente lección, Distribuciones de Linux, veremos qué compone exactamente una distribución, las tres grandes familias (Debian/Ubuntu, Red Hat/Fedora y Arch), qué significa LTS frente a rolling release, y tomaremos con criterio profesional la decisión que Tramontana ya ha tomado: Ubuntu Server 24.04 LTS para srv-tramontana.