Han sido meses de tensión, dimisiones sonadas y acusaciones de sabotaje que parecían más propias de un drama televisivo que de un foro de ingeniería. La comunidad de desarrollo del kernel de Linux, históricamente unida bajo la batuta de Linus Torvalds, ha vivido su particular cisma por culpa de un lenguaje de programación. Pero tras meses de incertidumbre y de un ambiente que el propio Torvalds llegó a calificar de "casi religioso", la batalla ha llegado a su fin con una victoria definitiva.

El fin de la etiqueta "experimental". La noticia ha saltado en la cumbre anual de mantenedores del kernel (Maintainers Summit), el encuentro donde se decide el rumbo técnico del sistema operativo más importante del mundo. Allí, el consenso entre los desarrolladores clave ha sido absoluto: Rust se queda. La etiqueta de "experimental" se retira y el lenguaje ya se considera una parte central (core) del kernel. Se cierra así la puerta a quienes pedían dar marcha atrás y volver al monolingüismo de C.

De las dimisiones a la estabilidad. Este desenlace llega tras un camino lleno de minas. Hace apenas unos meses, la situación parecía insostenible. Figuras clave como el español Miguel Ojeda o Wedson Almeida Filho, ingeniero de Microsoft, llegaron a apartarse o dimitir agotados por lo que calificaron de "tonterías no técnicas". Se enfrentaban a una resistencia feroz por parte de veteranos defensores de C, que veían en Rust una amenaza a la estabilidad y mantenibilidad del código.

En Genbeta

Hay una mala costumbre que hace perder los papeles a Linus Torvalds cuando programa el kernel de Linux. Y tiene toda la razón

El fantasma del sabotaje. La tensión alcanzó su punto álgido cuando desarrolladores como Hector Martin (Asahi Linux) acusaron públicamente a mantenedores veteranos como Christoph Hellwig de obstaculizar deliberadamente la integración de Rust. Se hablaba de rechazo de parches críticos y de una actitud hostil que buscaba que el proyecto fracasara por inanición. Hellwig llegó a calificar la iniciativa de "cáncer", polarizando aún más a la comunidad entre quienes veían en Rust el futuro de la seguridad de memoria y quienes lo veían como una invasión innecesaria.

Por qué ha ganado Rust. Como lenguaje moderno y alabado, Rust ofrece garantías de seguridad de memoria desde su diseño que C simplemente no puede igualar sin un esfuerzo humano titánico. En un mundo donde la ciberseguridad es crítica, la capacidad de Rust para prevenir desbordamientos de búfer y errores de gestión de memoria antes incluso de compilar ha pesado más que la curva de aprendizaje o la tradición de 34 años de código en C.

Un nuevo capítulo. El kernel entra en una nueva etapa de bilingüismo oficial. No significa que C vaya a desaparecer mañana. Sigue siendo el lenguaje dominante y lo será por muchos años, pero sí significa que los nuevos drivers y componentes críticos podrán escribirse en Rust con total respaldo oficial. La comunidad ha decidido evolucionar en lugar de atrincherarse. Las heridas de esta "guerra civil" tardarán en cicatrizar, y todavía queda esperar a ver consecuencias personales, pero el proyecto técnico sale reforzado y modernizado.

Imagen | Marcos Merino mediante IA

En Genbeta | Ha trabajado manteniendo el kernel de Linux desde hace 25 años y tiene claro el motivo de su éxito: el egoísmo

Cuando pensamos en Linux, inevitablemente aparece la imagen de un simpático pingüino gordito y relajado: Tux. No es un logotipo oficial en el sentido habitual de la palabra, pero se ha convertido en uno de los símbolos más reconocibles del mundo del software libre. ¿Por qué un pingüino? ¿Y de dónde salió 'ese' pingüino en particular?

Los inicios de Linux y la necesidad de un símbolo

A principios de los 90, Linus Torvalds, un joven estudiante finlandés, publicó el código de un nuevo núcleo de sistema operativo inspirado en Unix. Este kernel, al que bautizó 'Linux', pronto comenzó a atraer a programadores de todo el mundo que aportaron mejoras, drivers y herramientas.

La comunidad creció rápido y, como ocurre en muchos proyectos colectivos, surgió la necesidad de un emblema. No tanto un logo corporativo, sino una especie de mascota que reflejara el espíritu abierto, divertido y comunitario del proyecto (era algo muy común entre los proyectos 'open source' en aquella época).

Mascotas de 'GNU', 'Linux' y 'FreeBSD'.

La noche del pingüino viviente

Una anécdota contribuyó a cimentar la idea. En una entrevista, Linus contó que, durante una visita a un zoológico en Canberra, Australia, fue mordido por un pingüino. Desde entonces, decía en broma que estaba "infectado por el pingüino" y conservó simpatía por ese animal.

Esa simpatía le llevó a asegurar en alguna ocasión que, cada vez que pensaba en Linux, lo imaginaba como un pequeño pingüino simpático y juguetón. Una historia que empezó a difundirse entre los colaboradores del proyecto...

El nacimiento de Tux

En 1996, la comunidad organizó finalmente un concurso para elegir la mascota de Linux. Fue entonces cuando Larry Ewing, un joven estudiante de informática, presentó su propuesta: un pingüino regordete, de cara tranquila, sentado con las ¿alas? ¿aletas? descansando sobre la panza.

Lo dibujó usando GIMP (GNU Image Manipulation Program), el software de edición gráfica libre por excelencia, que por entonces estaba aún en sus primeras etapas de desarrollo. La imagen gustó tanto que rápidamente se adoptó como la representación no oficial del sistema.

En Genbeta

El dueño del primer PC con Linux (se lo instalaron a traición mientras dormía) cuenta cuál fue el nombre original del sistema operativo

Respecto a su nombre, 'Tux' surgió como un juego de palabras... aunque hay varias versiones sobre su significado:

• Una de ellas sostiene que proviene de 'Torvalds UniX' (puesto que Linux es una variante del sistema Unix, y fue creado por Linus Torvalds).
• Otra lo relaciona con la palabra inglesa tuxedo ('esmoquin', en espñaol), por el aspecto "elegante" del pingüino con su pecho blanco y cuerpo negro.
• Lo más probable es que ambas coincidencias reforzaran la elección.

Un símbolo sin dueño

A diferencia de las marcas registradas de las empresas tecnológicas, Tux nunca fue propiedad exclusiva de nadie: el propio Larry Ewing publicó su dibujo con una licencia abierta, permitiendo que cualquiera lo utilizara y modificara, siempre y cuando se le reconociera la autoría. En todo este tiempo, jamás ha cobrado por su uso.

Esa decisión encajaba perfectamente con el espíritu del software libre y ayudó a que el pingüino se multiplicara en todo tipo de contextos: distribuciones de Linux, camisetas, pegatinas, videojuegos...

'Tux' protagoniza varios videojuegos, como este 'Tux Racer' o el famoso 'Super Tux Kart'

Con el tiempo, Tux se convirtió en mucho más que la mascota de un sistema operativo: pasó a ser un símbolo de resistencia tecnológica frente al monopolio de los sistemas propietarios. 

Hoy en día es habitual ver a Tux en congresos de software libre, ferias tecnológicas y hasta en merchandising fuera del ámbito estrictamente informático. Es una de las pocas mascotas de software reconocidas incluso por personas ajenas al 'mundillo' del 'open source'.

Imagen | Marcos Merino mediante IA

En Genbeta | Linus Torvalds rechazó una oferta de Steve Jobs para trabajar en Apple. Y no tuvo que ver con el dinero

En 2025, cuando el almacenamiento en la nube y los SSD parecen haber desterrado definitivamente a cualquier clase de soporte magnético, un pequeño milagro retroinformático acaba de ocurrir: el controlador 'ftape', aquel viejo módulo del núcleo de Linux que permitía leer unidades de 'floppy tape', ha vuelto a la vida.

Sí, hablamos de esas unidades de respaldo en cartuchos QIC (o, en español, 'cartuchos de cuarto de pulgada') que se conectaban al controlador de disquete de la placa base, o a veces al puerto paralelo, y que parecían condenadas al olvido junto con las cintas VHS.

Cartuchos de cuarto de pulgada, QIC y miniQIC. (vía Wikimedia)

El proyecto, rescatado por Dmitry Brant, consiste en una modernización del código original del driver creado en los años noventa por Claus-Justus Heine. La versión oficial incluida en el núcleo de Linux se mantuvo en la serie 3.04, publicada en 1997, y continuó ahí —sin apenas cambios— hasta que fue eliminada en 2006, con Linux 2.6.20, debido a su escasa utilización.

Mientras tanto, de forma paralela y al margen del kernel, el autor siguió desarrollando el controlador hasta alcanzar la versión 4.04a en el año 2000, que sería la última antes de que el proyecto quedara abandonado (y en la que se basa el nuevo proyecto).

¿Por qué revivirlo?

A primera vista puede parecer un ejercicio de arqueología informática sin mucho sentido a estas alturas. Sin embargo, hay dos comunidades que agradecen esta 'resurrección':

• La de los fans de la retroinformática: y es que hay más usuarios entusiastas de lo que parece buscando experimentar con hardware antiguo y necesitan herramientas modernas para darle utilidad.
• La de los usuarios dedicados rescate de datos: todavía existen por ahí cintas guardadas con información valiosa almacenada en este formato, y poder acceder a ellas es crucial en algunos casos.

En Genbeta

"Tomaremos caminos separados". Un conflicto interno motiva al creador de Linux a suprimir de un plumazo 10 años de trabajo

¿Alguien va a empezar a hacer copias de seguridad en cintas QIC en 2025? Por supuesto que no. Pero gracias a este proyecto, quienes aún tienen datos atrapados en esos cartuchos tienen ahora una forma de recuperarlos. 

Por eso, la prioridad del proyecto ahora mismo es clara: leer datos antes que escribirlos, con énfasis en modos 'forenses' capaces de ignorar tablas de volúmenes o errores de corrección (ECC).

¿Cómo funciona?

De todos modos, el nuevo 'ftape' no pretende ser un módulo de producción ni volver a formar parte del kernel oficial. Brant lo distribuye como un módulo independiente (lo que se denomina 'out-of-tree'), lo que permite compilarlo manualmente con `make` (usando el código y las instrucciones de su GitHub oficial), aplicándolo al núcleo Linux 6.8 o superior.

Una vez hecho eso, sólo queda:

• Cargar los módulos generados con scripts específicos para cada tipo de unidad (FDC, Ditto Max, paralelas…).
• Interactuar con los dispositivos creados en `/dev/nqft0`, `/dev/rawqft0`, etc.
• Extraer datos recurriendo a utilidades clásicas como `dd`.

Eso sí: el soporte de hardware sigue siendo tan limitado como en los noventa, porque depende de chipsets concretos de controladoras de disquete o de configuraciones de BIOS.

En Xataka

Viviendo la vida (casi) sin interfaz gráfica: así trabajan los linuxeros que ven todo dentro de una consola en modo texto

"¡Está vivo!", dijo el chatbot

Más allá del valor técnico del driver, lo fascinante de este caso es comprobar cómo este tipo de proyectos se benefician hoy de una herramienta que no existía en el año 2000: los modelos de lenguaje de gran escala (LLMs).

Modernizar un driver que quedó congelado hace un cuarto de siglo implica adaptarlo a cambios profundos en las APIs internas del núcleo, en la gestión de memoria, interrupciones, e interfaces de dispositivos.

Lo que antes podía ser una tarea hercúlea que se prolongase durante meses, hoy se convierte en una colaboración hombre-máquina donde el programador guía y los modelos de IA ayudan (sólo ayudan) a traducir sintaxis, encontrar equivalencias y sugerir refactorizaciones.

Vía | Mixx.io

Imagen | Marcos Merino mediante IA

En Genbeta | Este usuario avanzado de Linux probó Windows 11 y ha optado por quedarse (para su sorpresa) por estas razones

Todo proyecto de desarrollo de software está condicionado, en menor o mayor medidas, por tensiones internas. Incluso proyectos tan consolidados como el del kernel de Linux (no es que falten ejemplos recientes).

Y es que, en los últimos meses, un conflicto entre Linus Torvalds, el creador y principal mantenedor del kernel de Linux, y Kent Overstreet, desarrollador del moderno sistema de archivos Bcachefs, se ha salido de control hasta provocar lo impensable: la eliminación de más de una década de trabajo del kernel.

¿Qué es Bcachefs y por qué era tan prometedor?

Bcachefs es un sistema de archivos moderno desarrollado por Kent Overstreet, exingeniero de Google, durante más de 10 años. Diseñado con características de última generación como snapshots, cifrado nativo, soporte para RAID y una alta eficiencia en SSD, se planteaba como un competidor serio frente a sistemas como Btrfs, ZFS o incluso EXT4 (el más común en Linux).

Desde su inclusión inicial en el kernel 6.7 a comienzos de 2024, Bcachefs fue considerado 'experimental', pero su potencial lo convertía en algo muy prometedor para los usuarios y desarrolladores avanzados del ecosistema Linux.

Sin embargo, desde sus primeras interacciones con la comunidad del kernel, Overstreet demostró ser un desarrollador tan brillante como conflictivo. Y eso nos ha llevado al punto actual.

Un conflicto más allá de meras diferencias técnicas

Los problemas surgieron durante el desarrollo del kernel 6.16. Concretamente en la fase conocida como 'release candidate', en la que sólo se permiten correcciones de errores. Sin embargo, Overstreet envió un "pull request" que incluía una nueva funcionalidad: una opción de montaje para reparaciones de emergencia.

Esta violación del proceso molestó bastante a Torvalds, quien ya había rechazado previamente la inclusión del código por considerarlo inapropiado para esa fase. A pesar de la advertencia, Overstreet insistió, lo que llevó a Torvalds a aceptar los cambios con una dura sentencia:

"He integrado este código, pero creo que tomaremos caminos separados cuando llegue la próxima ventana de fusión, en la versión 6.17".

En Genbeta

Hay una mala costumbre que hace perder los papeles a Linus Torvalds cuando programa el kernel de Linux. Y tiene toda la razón

Torvalds también criticó abiertamente la actitud de Overstreet, acusándolo de haber creado una situación en la que "no se puede ni siquiera cuestionar las correcciones de errores" sin provocar una reacción hostil. En un ecosistema donde la revisión por pares y el debate abierto son pilares del progreso, esa actitud era inaceptable. Torvalds añadió con frustración:

"Lo cierto es que, en ese punto, ya no me siento nada cómodo participando".

La tensión no era nueva. Overstreet ya había sido suspendido del desarrollo del kernel 6.13 en 2024 por violaciones al código de conducta, debido a comentarios agresivos hacia otros desarrolladores. Estas actitudes deterioraron la cooperación dentro de la comunidad y disuadieron a otras empresas y colaboradores de participar en el desarrollo de Bcachefs.

La decisión de Torvalds

Ahora, Torvalds ha decidido eliminar por completo Bcachefs del kernel. La razón oficial se centra en los constantes conflictos técnicos y personales con Overstreet, así como en la preocupación por la estabilidad del sistema.

Una de las gotas que colmaron el vaso fue la inclusión apresurada de la función 'journal-rewind', a pesar de que contenía errores sin resolver. Este tipo de comportamiento, que ignora el consenso y los procesos comunitarios, va en contra del ethos del desarrollo colaborativo de Linux.

Aunque en condiciones normales eliminar un sistema de archivos ya integrado sería impensable por el principio de "no romper flujos de trabajo de los usuarios", en este caso se considera justificado dado que Bcachefs aún era experimental.

¿Qué pasará con Bcachefs?

"Eliminar Bcachefs del kernel de Linux es probablemente la mejor manera de poner fin a esta disputa. Pero me temo que los usuarios pagarán el precio", reconoció Overstreet, aceptando la decisión con resignación.

Su respuesta sugiere que la historia de Bcachefs podría continuar fuera del kernel principal, aunque ya sin el respaldo de la estructura oficial de Linux. Existen varias rutas para su supervivencia:

• Desarrollo externo: La comunidad puede mantener el proyecto fuera del kernel oficial, permitiendo que los interesados lo integren manualmente en sus sistemas.
• Uso mediante FUSE: Es posible implementar Bcachefs como un sistema de archivos en espacio de usuario, aunque con menor rendimiento.
• DKMS: Los usuarios avanzados podrían compilar el soporte de Bcachefs en sus propios kernels, como se hace con algunos drivers propietarios como los de Nvidia.

Imagen | Marcos Merino mediante IA

En Genbeta | Ha trabajado manteniendo el kernel de Linux desde hace 25 años y tiene claro el motivo de su éxito: el egoísmo

Hace 25 años, recién pasada la resaca del 'Efecto 2000' y de la explosión de la burbuja de las 'puntocom', se produjo un encuentro que estuvo a punto de cambiar la historia del software moderno: Steve Jobs, el visionario detrás del resurgimiento de Apple, intentó reclutar nada menos que al creador de Linux, Linus Torvalds, para que trabajase en su compañía, a la que había retornado triunfalmente como CEO tan sólo tres años antes.

Pero lo que parecía una oportunidad de oro fue rechazada de manera tajante por Linus. ¿El motivo? Según afirma el finés, lo que le convenció en ese momento no era pensar en el dinero, la fama, o el prestigio de trabajar para uno de los gigantes de Silicon Valley, sino la libertad de desarrollar lo que prefiriese en cada momento.

Un encuentro, una negativa

Linus Torvalds, que en ese momento trabajaba en la empresa de procesadores Transmeta, fue invitado por Steve Jobs a la sede de Apple en Cupertino. Allí, Jobs le hizo una oferta que muchos considerarían de esas ue uno 'no puede rechazar': unirse al equipo de Apple para trabajar en el desarrollo de su sistema operativo basado en Unix. La promesa era clara y ambiciosa: "Unix para la mayor base de usuarios".

Sin embargo, había una condición innegociable en esa oferta: que Linus dejase de trabajar en el desarrollo de Linux. Para Torvalds, eso era una línea roja, como recordaría tiempo después en una entrevista para Wired:

"Lo que él quería era que trabajara en Apple haciendo cosas que no tuvieran que ver con Linux. Y eso era inaceptable para mí".

Más allá del dilema ético de verse obligado a abandonar el proyecto que él mismo había creado desde cero, había una razón técnica de peso: Torvalds despreciaba el microkernel Mach de macOS (el mismo que Apple había usado para implementar su propia versión de Linux, MkLinux), pues consideraba que no era una base sólida ni eficiente para un sistema operativo moderno.

En Genbeta

Apple no siempre apostó por amurallar su ecosistema. Incluso tuvo su propia distribución de Linux muchos años antes que Microsoft

Dos visiones del liderazgo

Este tipo de decisiones no eran nuevas para él. A Torvalds se le ha descrito como un 'arbitro técnico' con un olfato infalible para elegir la solución correcta entre múltiples posibilidades, aunque eso le haya valido ganarse cierta fama de 'borde' con los años (algo que, por cierto, se ha vuelto a poner a prueba recientemente con el conflicto en torno a la adopción del lenguaje Rust en el kernel, que ha desembocado en sonadas dimisiones).

Aunque a menudo se le haya presentado como el equivalente a Bill Gates en el campo 'open source', Linus Torvalds comparte algunos puntos en común con Steve Jobs: ambos son líderes carismáticos, obsesionados con la calidad y los detalles. Las similitudes finalizan ahí, claro, pues donde Jobs lideraba con un sentido estético casi artístico; Torvalds siempre ha hecho gala de una visión puramente ingenieril.

Esa diferencia quizá también marcó el camino de ambos: mientras Jobs acumuló fama, fortuna y celebridad, Torvalds eligió una vida más privada, centrada en la tecnología y su familia.

Una decisión que marcó un camino

A día de hoy, Linus Torvalds continúa siendo el guardián del kernel de Linux, una pieza fundamental que hace funcionar cada día millones de dispositivos móviles Android, de servidores de internet y  de superordenadores. Aunque su carrera no lo haya llevado frecuentemente a la portada de revistas de negocios ni a estar en el centro de adquisiciones multimillonarias, su legado técnico es incuestionable. Según sus propias palabras:

"No tengo la fama ni la fortuna de Jobs, pero estoy contento de haber hecho lo correcto".

Y es que, en una industria en la que frecuentemente las decisiones se rigen por beneficios inmediatos o presiones externas, la negativa de Torvalds supone un ejemplo para muchos: a veces, mantenerte fiel a tu proyecto y a tus convicciones puede ser la decisión más acertada a largo plazo.

Imagen | Marcos Merino mediante IA

En Genbeta | Steve Jobs estaba convencido de que un ratón solo debía tener un botón… hasta que la realidad le llevó la contraria 

Cuando pensamos en Apple, la imagen que suele venir a la mente es la de una compañía obsesivamente cerrada en su ecosistema: sus dispositivos están diseñados para funcionar entre ellos, y ejecutar software no autorizado o sistemas operativos alternativos en hardware Apple ha sido, durante años, una tarea desalentadora.

Por eso, resulta casi inconcebible que Apple haya sido una de las primeras grandes tecnológicas en desarrollar su propia distribución de Linux... ya en los años noventa. Mucho antes que Microsoft, de hecho, pese a su actual fama como compañía 'pro-open source'.

Hablemos de MkLinux (Microkernel Linux)...

¿Qué era MkLinux?

Se trató de una distribución de Linux desarrollada en 1996 como un proyecto conjunto entre Apple Computer y el Open Software Foundation Research Institute en Grenoble, Francia. Su objetivo: portar Linux a la arquitectura PowerPC, usada en los Macintosh de la época.

Pero MkLinux no era una simple versión de Linux. Estaba diseñada para funcionar sobre un núcleo Mach 3.0, un microkernel desarrollado originalmente por la Carnegie Mellon University. En esta arquitectura, el núcleo de Linux no accedía directamente al hardware, sino que operaba como una tarea en espacio de usuario sobre Mach... un enfoque de 'kernel sobre kernel' que resultaba tan innovador como complejo.

En Genbeta

Sistemas operativos BSD, los 'primos' menos conocidos de Linux... entre los que se encuentra Mac OS X

Apple + Linux: una alianza inesperada

El resultado de los esfuerzos de Apple fue una distribución basada en el popular Red Hat Linux, adaptada al entorno Mac, que se presentó oficialmente durante la Apple Worldwide Developers Conference (WWDC) de 1996. De hecho, Apple repartió CDs gratuitos con la distribución a los asistentes.

Se distribuía en CD-ROM, debido a que en 1996 la mayoría de usuarios tenía acceso a Internet por módems de 56k, lo que hacía inviable descargar imágenes ISO grandes. Incluso se vendió acompañado de manuales técnicos, tanto en inglés como en japonés.

No es una exageración decir que, en aquel momento, Apple abrazó activamente el software libre: incluso hospedó el sitio oficial de MkLinux en sus propios servidores. Y hay que recordar que, detrás del proyecto estaban figuras destacadas como Ike Nassi, vicepresidente de herramientas de desarrollo en Apple, y un equipo mixto de ingenieros tanto en Cupertino como en Grenoble.

Captura de pantalla de MKLinux

¿Qué lo hacía especial?

1. Diseño híbrido: MkLinux usaba el microkernel Mach para gestionar recursos de bajo nivel, y ejecutaba el kernel de Linux como proceso sobre él. Esto permitía separar componentes del sistema operativo, una aspiración clásica de los defensores del diseño microkernel.
2. Compatibilidad con hardware Apple: En una época en la que ejecutar Linux en un Mac era casi imposible, MkLinux ofrecía soporte para una amplia gama de modelos, incluyendo máquinas con buses NuBus y PCI.
3. Primer acercamiento oficial de Apple al software libre: MkLinux fue la primera iniciativa pública de Apple en el mundo del código abierto, algo impensable hoy bajo su modelo cerrado actual.

MkLinux tenía luces y sombras, eso sí: aunque ofrecía una experiencia Linux bastante completa, el uso del microkernel Mach imponía una penalización de rendimiento (no tan distinto de usar Linux sobre WSL). Así, los usuarios de la época notaron que era más lento que Mac OS 7 u 8 en el mismo hardware... pero mucho más estable para ciertos usos, como servidores y estaciones de trabajo.

En Genbeta

Microsoft acaba de lanzar una nueva distribución de Linux: la compañía sigue abrazando al sistema que un día llamó “cáncer”

El ocaso (y olvido) de MkLinux

A medida que el soporte oficial por parte de Apple disminuyó, la comunidad tomó las riendas del proyecto a través de la MkLinux Developers Association. Sin embargo, el surgimiento de otras distribuciones como LinuxPPC o Yellow Dog Linux, que usaban un kernel Linux más tradicional (sin microkernel), fueron desplazando gradualmente a MkLinux... hasta que el proyecto fue oficialmente abandonado en 2002.

Sin embargo, su legado sobrevivió en el código y en las ideas que más tarde influirían en XNU, el propio núcleo de macOS.

A pesar de su breve existencia, MkLinux dejó una huella significativa:

• Sirvió como base experimental para la adopción del kernel Mach que hoy aún forma parte de macOS (como componente del núcleo XNU).
• Demostró la viabilidad del software libre en plataformas Apple, en una época donde Apple estaba al borde del colapso financiero.
• Fue anterior a cualquier movimiento similar de Microsoft, que no lanzó su primera distribución oficial de Linux hasta Azure Sphere OS en 2018, y no creó una propia desde cero hasta 2021 con CBL-Mariner.

Imagen | Marcos Merino mediante IA

En Genbeta | ¿Importa el "ecosistema Apple"? Mi experiencia usando Windows con iPhone y macOS con Android

Durante más de dos décadas, Greg Kroah-Hartman (autor de 'Linux Kernel in a Nutshell') ha estado en el corazón del proyecto Linux, manteniendo partes fundamentales de su kernel, el núcleo del sistema operativo más utilizado del planeta. En una reciente entrevista con The Pragmatic Engineer, Greg ha revelado algunas dinámicas internas inesperadas del desarrollo del kernel de Linux.

Desde servidores hasta televisores inteligentes, pasando por satélites, routers y la mayoría de teléfonos Android, Linux está en todas partes.

Pero, ¿cómo se construye un proyecto de esta magnitud? ¿Y cuál es la razón de su éxito? Según Kroah-Hartman, la clave reside en un factor inesperado: el egoísmo bien canalizado.

Un ecosistema que abarca todo

A pesar de su bajo perfil, Linux es omnipresente. Está en más de 4.000 millones de dispositivos Android, en la Estación Espacial Internacional, los sistemas de control del tráfico aéreo europeo, cargadores de coches eléctricos, servidores web, televisores Samsung, y hasta en los módems 5G. Kroah-Hartman bromea al respecto:

"Nos hemos apoderado del mundo sin que nadie se diese cuenta".

Pero este dominio no ha surgido por accidente: el kernel de Linux es mantenido por una comunidad global, compuesta por más de 4.000 desarrolladores al año provenientes de más de 500 empresas, incluyendo a gigantes como Google, Intel o IBM.

El egoísmo que sostiene al mundo

vía Marcos Merino (IA)

A pesar de su apariencia altruista, el éxito de Linux está cimentado, según Kroah-Hartman, en egoísmo. Pero no en cualquier forma de egoísmo, sino en el estratégico: las empresas y desarrolladores individuales contribuyen al kernel para resolver sus propios problemas, ya sea agregar soporte para un nuevo hardware, mejorar la eficiencia energética o facilitar la integración en sus productos.

Pero aquí viene la genialidad del modelo: "Si tú arreglas un problema que tienes, seguramente estás solucionando el problema de otros también". Así, lo que comienza como una mejora local termina beneficiando al ecosistema entero.

En Genbeta

El kernel de Linux lleva desarrollándose 34 años. Un debate sobre lenguajes de programación está logrando intoxicar el proyecto

Decía el economista y filósofo Adam Smith que "no es de la benevolencia del carnicero, cervecero o panadero de donde obtendremos nuestra cena, sino de su preocupación por sus propios intereses". Pues, aparentemente, obtenemos Linux gracias a ese mismo principio.

Un ejemplo claro de eso sería el soporte para dispositivos embebidos con batería. Varias empresas querían optimizar el kernel para sus smartphones y smartwatches... pero el resultado no solo mejoró el rendimiento en dispositivos móviles, sino que también redujo el consumo energético en centros de datos, ahorrando así miles de millones en infraestructura.

Cuando colaborar paga en reputación (y en ahorrar costes)

Greg insiste en que contribuir a proyectos como Linux es una de las mejores formas de crecimiento profesional: cada parche enviado demuestra habilidades técnicas, colaboración y conocimiento profundo del sistema.

Cerca del 80% de quienes aportan al kernel lo hacen como parte de su trabajo: para muchas empresas, contribuir al desarrollo de Linux es más rentable que crear y mantener su propio sistema operativo.

Entre Linux y una solución comercial, Kroah-Hartman se pregunta retóricamente quién ganará a largo plazo:

"[Podría pensarse que la solución] comercial, porque tienen incentivos, van a crear cosas profesionales, mientras que aquí es más por valor intrínseco. Pero [...] IBM sabía que podía invertir dinero, contratar desarrolladores y recuperar esa inversión.

A largo plazo les sale más barato. Ellos ganan dinero vendiendo soporte y hardware. Red Hat gana dinero vendiendo soporte. Intel gana dinero vendiendo chips. Esas son las empresas que contribuyen a Linux: lo hacen porque quieren vender otro producto".

En Genbeta

Hay una mala costumbre que hace perder los papeles a Linus Torvalds cuando programa el kernel de Linux. Y tiene toda la razón

Calidad por presión social. Presión social por transparencia

El hecho de que todo sea público genera una presión invisible pero poderosa. Como dice Kroah-Hartman: "Mi nombre está en este cambio de código. Sé que todos lo van a ver. Eso me obliga a hacer un mejor trabajo".

A diferencia de empresas cerradas donde el código solo lo ve un equipo, en Linux el código está a la vista del mundo. Esto eleva el estándar de calidad y promueve mejores prácticas, documentación y claridad.

Confianza, burocracia y colaboración

El proceso de contribuir es sorprendentemente accesible. Un cambio típico —como agregar el soporte para un módem USB— puede tardar apenas una semana y media desde su envío hasta ser incluido en una versión estable del kernel. Todo se gestiona por correo: se envía un parche con su descripción, se discute públicamente, se revisa, se aprueba y se integra.

Para los cambios más sensibles —como partes del núcleo central— el proceso es más estricto. No por burocracia, sino por necesidad:

"Si desapareces, alguien debe poder mantener tu código. Así que más vale que sepas lo que estás haciendo, o que inspires confianza".

Empezar a colaborar poquito a poco

La entrevista también ayuda a despejar una duda: para los curiosos, contribuir a Linux no requiere ser un experto en sistemas operativos. Muchos comienzan corrigiendo errores de estilo, mejorando comentarios o solucionando errores simples. Lo importante es aprender el flujo de trabajo y entrar en la dinámica colaborativa.

Y la recompensa va más allá de lo técnico: es una forma directa de mejorar profesionalmente, demostrar capacidad real y aprender de algunos de los mejores ingenieros del mundo.

El kernel nunca está 'terminado'

La constante aparición de nuevos dispositivos, procesadores, redes y usos exige que el kernel evolucione constantemente. Cuando le preguntaron si Linux está cerca de completarse, Kroah-Hartman respondió: "Terminará cuando dejen de hacer nuevo hardware". Y no parece que eso vaya a ocurrir pronto.

Imagen | Tian 2992 en Flickr

En Genbeta | El 'vibe coding' está revolucionando la programación. Y también haciendo destrozos muy grandes en el código 

El desarrollo del kernel de Linux ha sido, históricamente, un ecosistema en constante cambio, en el que Linus Torvalds (creador, y líder de su equipo de desarrolladores) ha ido tomando decisiones que han permitido que el sistema operativo fuera progresando hasta su estado actual.

Sin embargo, ahora las cosas parecen haberse 'gripado' un poco en el kernel de Linux. De todas las cosas que se habían tocado en el mismo, el lenguaje en el que está escrito nunca había estado en la lista.

Pero ahora, la (supuestamente aprobada, aunque nadie lo diría) propuesta de integrar Rust como un segundo lenguaje de desarrollo, no sólo ha generado un profundo debate entre desarrolladores, sino que parece haberlo sembrado de minas.

Desde su propuesta en 2021 por Miguel Ojeda hasta las recientes dimisiones de ingenieros clave, la controversia en torno a Rust ha alcanzado un punto crítico tras la dimisión de Héctor Martín, desarrollador de Asahi Linux. Ya os hablamos hace un par de días del propio Martín, pero ¿cómo le está afectando todo esto al ecosistema Linux?

¿De dónde venimos?

Rust es un lenguaje de programación diseñado para evitar errores de memoria y mejorar la seguridad en la concurrencia. Estas características suelen ser altamente valoradas en el desarrollo de sistemas críticos (como lo es el kernel de Linux), donde los errores de memoria pueden generar vulnerabilidades explotables.

En abril de 2021, Miguel Ojeda propuso un RFC (Request for Comments) para integrar Rust en el kernel. La idea central era que Rust se utilizara, al menos inicialmente, en el desarrollo de drivers, sin que eso supusiera reemplazar el código base en C.

En Genbeta

Máxima tensión entre desarrolladores de Linux por el enfrentamiento C vs. Rust: Linus Torvalds ve un "tono casi religioso" en el debate

Sin embargo, la propuesta también encontró resistencia por diversas razones:

• Curva de aprendizaje: Los mantenedores de código tendrían que aprender Rust para poder mantener y depurar el código.
• Impacto en el rendimiento: Los "wrappers" necesarios para la interoperabilidad con C podrían afectar el rendimiento.
• Carga de mantenimiento: La coexistencia de dos lenguajes dentro del kernel podría generar problemas a largo plazo.
• Compatibilidad con el modelo de memoria de Linux: Rust utiliza el modelo C11 de LLVM, diferente al del kernel de Linux, lo que plantea problemas de integración.

A cara de perro

A medida que avanzaban los debates, la comunidad de desarrolladores se dividió en dos grupos:

1. Los defensores de Rust, entre ellos empresas tecnológicas como Google y Microsoft, que argumentan que la adopción de Rust mejorará la seguridad del kernel.
2. Los opositores a Rust, encabezados por mantenedores clave, quienes ven la introducción de un segundo lenguaje como un obstáculo para la estabilidad y mantenimiento del código.

Uno de los puntos más problemáticos ha sido la aparente resistencia de algunos desarrolladores a aceptar código escrito en Rust, incluso después de que se diera oficialmente luz verde a la integración en el kernel de este nuevo lenguaje.

Así, se han reportado casos de ignorancia deliberada de parches, lentitud extrema en las revisiones y críticas agresivas a los desarrolladores de Rust. Un ejemplo notable es el de Christoph Hellwig, quien ha rechazado rotundamente la inclusión de Rust en su área de desarrollo, refiriéndose a este como "un cáncer que no debe propagarse al 'core' del kernel".

Esta actitud ha sido vista por algunos como una demostración de cierto sesgo por parte de Torvalds y el resto de líderes del proyecto, sobre todo teniendo en cuenta que, mientras otros desarrolladores han sido sancionados por "lenguaje inapropiado", Hellwig no ha recibido reprimenda alguna.

Un espectáculo lamentable

Uno de los acontecimientos más significativos de esta crisis ha sido la dimisión de Wedson Almeida Filho, ingeniero de Microsoft y uno de los principales impulsores de Rust en el kernel. Wedson renunció hace cinco meses, tras años de esfuerzo por integrar Rust, afirmando que el problema no era técnico, sino humano. Su salida fue seguida por declaraciones de apoyo de Lina, VRtuber y desarrolladora de Asahi Linux, que afirmó sentirse igual de frustrada por la actitud hostil de la comunidad.

Otros desarrolladores, como Greg Wettstein, también han expresado su descontento con la falta de liderazgo en el tema: describió el conflicto como "un espectáculo lamentable" y criticó la pasividad de Linus Torvalds a la hora de gestionar este problema.

En Genbeta

Usar Rust en Linux está siendo muy polémico. En Android ya se han demostrado sus grandes virtudes reduciendo bugs

La (no) respuesta de Linus Torvalds

Y es que Linus Torvalds, creador de Linux y máxima autoridad en su desarrollo, ha mantenido una postura ambigua respecto a Rust: su comentario "on the whole I don't hate it" ("en general, no lo odio") ha sido interpretado de maneras muy distintas a ambos lados del debate.

Torvalds se encuentra en una encrucijada: si apoya Rust, podría poner en su contra a veteranos mantenedores de código que se oponen firmemente a la idea; si lo rechaza, decepcionará a las empresas y desarrolladores que han invertido tiempo y recursos en la iniciativa.

Esta indecisión ha generado incertidumbre, permitiendo que el conflicto escale sin una resolución definitiva y contribuido a la salida de varios desarrolladores. En definitiva, ha generado un ambiente de innecesaria tensión dentro de la comunidad.

Ya sabemos de dónde venimos. ¿Y ahora? ¿A dónde vamos?

La controversia ha demostrado que la integración de nuevas tecnologías en un proyecto tan grande y antiguo como Linux no es un proceso sencillo. Sin un liderazgo claro y una resolución firme, la comunidad se arriesga a seguir perdiendo talento.

Si bien Rust ofrece beneficios en términos de seguridad, la forma en que se ha manejado su adopción ha dejado mucho que desear. La falta de un consenso claro y la resistencia de algunos sectores (llegados a este punto, nadie parece muy dispuesto a transigir) podrían traducirse en el fracaso de esta iniciativa.

Una cosa es segura: lo que ocurra en los próximos meses podría definir no solo el futuro del uso de Rust en el kernel, sino también la cultura de desarrollo de uno de los proyectos de software libre más importantes del mundo.

Imagen  | Marcos Merino mediante IA

En Genbeta | Rust parecía el lenguaje ideal para programar videojuegos. Este estudio acabó abandonándolo tras tres años centrados en él

El ecosistema Linux se ha visto sacudido con la segunda renuncia en pocos días del popular desarrollador Héctor Martín (conocido por su trabajo en ingeniería inversa y soporte de Linux en hardware no oficial, como las videoconsolas Wii y PS4).

De la primera de dichas renuncias te hablamos hace unos días: se despidió del equipo desarrollador del kernel del sistema operativo después de que nada menos que el propio creador de Linux le 'echara la bronca' por llevar a redes las polémicas internas sobre la integración del lenguaje Rust.

La renuncia de la que nos hacemos eco hoy afecta a Asahi Linux, el proyecto que creó y que venía liderando para lograr (con bastante éxito, cabe señalar) que Linux se ejecutase de manera nativa en los chips Apple Silicon (M1, M2 y posteriores)...

...que hacen uso de una arquitectura y hardware propietario sin documentación pública, lo que dificulta programar para los mismos si no cuentas con el respaldo de Apple.

¿Qué ha pasado?

Ambas renuncias están relacionadas, claro: Martín citando como motivos de esta última el "agotamiento", la presión de los usuarios y la falta de apoyo dentro de la comunidad del kernel de Linux.

Su salida marcará ahora un punto de inflexión para la integración de Linux en dispositivos Apple Silicon y constituye, para algunos, un ejemplo de los problemas sistémicos dentro del software libre.

En Genbeta

Todo lo que puedes hacer con Asahi Linux en un Mac M1 a día de hoy: así es el proyecto para tener Linux en ordenadores de Apple

Resumen de lo ocurrido

• Martín llevaba tiempo enfrentándose a dificultades a la hora del 'upstreaming' (integración de código en el kernel oficial de Linux), lo que convirtió la labor de desarrollo en una experiencia frustrante.
• La comunidad de usuarios de Asahi comenzó a exigir cada vez más funcionalidades, desde soporte para nuevas generaciones de chips hasta mejoras en gráficos y compatibilidad de hardware ("¿Cuándo tendrá soporte para M3/M4?", "Asahi Linux es inútil sin compatibilidad con monitores USB-C"...).
• En 2024, además de enfrentar problemas personales y acoso online ("No puedo trabajar con personas que forman camarillas a mis espaldas y mienten sobre sus intenciones"), el desarrollador sufrió una creciente disminución en las donaciones, lo que puso en duda la sostenibilidad del proyecto.
• El conflicto sobre la integración de Rust en el kernel de Linux (que Martín defiende contra la resistencia de otros desarrolladores del kernel) y la falta de respaldo de Linus Torvalds ("Tal vez el problema seas tú", le dijo a Martín) han terminado siendo las gotas que han colmado ahora el vaso.

El futuro de Asahi Linux sin Martín

A pesar de su salida, Asahi Linux seguirá adelante. El equipo de desarrollo ha anunciado una nueva estructura de liderazgo compartido, con el objetivo de garantizar la estabilidad del proyecto. Además, han establecido Open Collective como el principal mecanismo de financiación, sustituyendo a las donaciones personales que venía recibiendo Martín.

Las prioridades inmediatas del proyecto incluyen:

• Mejorar el soporte para las generaciones M3 y M4 de Apple Silicon.
• Implementar mejoras en audio, gráficos y compatibilidad con dispositivos externos.

El legado de Martín en Asahi Linux es innegable: su trabajo ha permitido que Linux funcione de manera eficiente en hardware de Apple, algo que muchos consideraban imposible cuando nuestro protagonista puso la idea sobre la mesa.

En Genbeta

Tres desarrolladores que trabajan gratis han evitado pérdidas millonarias a algunas de las mayores compañías tecnológicas del mundo

Burnout en la comunidad open source

El caso de Héctor Martín no es aislado. En los últimos años, numerosos desarrolladores de software libre han denunciado el agotamiento provocado por la carga de trabajo, las exigencias de los usuarios y la falta de reconocimiento.

La situación se ha agravado con la reducción de la financiación, lo que obliga a muchos desarrolladores a trabajar en condiciones insostenibles... algo grave cuando tenemos en cuenta que la falta de mantenimiento en estos proyectos puede generar vulnerabilidades de seguridad críticas.

Vía | Marcan.st

Imagen | Marcos Merino mediante IA

En Genbeta | Máxima tensión entre desarrolladores de Linux por el enfrentamiento C vs. Rust: Linus Torvalds ve un "tono casi religioso" en el debate

El ecosistema Linux acaba de verse envuelto en una amarga polémica después de que Christoph Hellwig, un influyente desarrollador del kernel, fuese acusado de intentar sabotear el proyecto Rust for Linux (R4L).

La controversia ha estallado después de que Hector Martin, desarrollador en proyectos como Asahi Linux, haya denunciado públicamente que Hellwig no sólo se oponía a la inclusión de Rust en el kernel, sino que había reconocido estar dispuesto a obstaculizar activamente su desarrollo.

Recordemos que hace cuatro meses ya hubo dimisiones entre los desarrolladores del kernel por este tema, y el propio Linus Torvalds tuvo que salir a la palestra a rechazar el "tono casi religioso" de ambos bandos del debate.

¿Qué es 'Rust for Linux'?

Rust for Linux es una iniciativa cuyo objetivo es permitir el uso del lenguaje de programación Rust dentro del kernel de Linux. Rust es ampliamente reconocido por su seguridad en memoria, lo que podría reducir significativamente vulnerabilidades comunes en el código escrito en C, el lenguaje predominante en el kernel de Linux... pero que cada vez más voces piden dejar de lado.

Sin embargo, la integración de Rust ha sido un tema controvertido dentro de la comunidad de desarrolladores. Mientras que algunos la consideran una evolución natural que mejorará la estabilidad y seguridad del kernel, otros (como Hellwig) argumentan que agregar un nuevo lenguaje rompe con la cohesión y mantenibilidad del proyecto.

En Genbeta

Máxima tensión entre desarrolladores de Linux por el enfrentamiento C vs. Rust: Linus Torvalds ve un "tono casi religioso" en el debate

La controversia: ¿Sabotaje o legítima oposición?

El debate se intensificó cuando Hellwig rechazó una serie de parches fundamentales para la implementación de Rust en el kernel, particularmente aquellos relacionados con las abstracciones de DMA (siglas en inglés de 'acceso directo a memoria'). Según Martin, la ausencia de estas abstracciones condena el proyecto al fracaso, ya que sin ellas la mayoría de los controladores en Rust no podrían funcionar adecuadamente.

Así lo explican en Reddit:

"Christoph está obstruyendo el esfuerzo de Rust para Linux, de una manera que no deja ninguna solución alternativa posible que lo apacigüe que no sea abandonar el proyecto, y lo hace después de que el proyecto Rust para Linux fuera aceptado en el kernel de Linux [...]".

"El mecanismo de sabotaje aquí es rechazar una parte crítica y fundamental del proyecto R4L, de tal manera que sin ella, todo el esfuerzo se derrumba, a pesar de que, sobre el papel, no rechaza (ni tiene la autoridad para rechazar) el todo".

"Esto es un sabotaje de manual, como dañar o destruir una pieza de una máquina grande para hacer que toda ella funcione mal".

Si bien insiste en que su postura no se debe a un odio hacia Rust como lenguaje, sino a la complejidad adicional que introduce en la base de código de Linux, sus detractores denuncian su actitud como meramente obstruccionista.

En Genbeta

Usar Rust en Linux está siendo muy polémico. En Android ya se han demostrado sus grandes virtudes reduciendo bugs

Además, Hellwig ya había descrito en el pasado a R4L como un "cáncer", lo que ha llevado a Martin a sugerir su expulsión del proyecto Linux por violar el Código de Conducta del kernel.

Reacciones de la comunidad

La disputa ya está generando un intenso debate más allá del círculo de desarrolladores del kernel, llegando a foros como Reddit, donde queda clara la fuerte polarización existente: mientras algunos usuarios apoyan la posición de Hellwig, defendiendo la opción de mantener Linux 'monolingüe' en C, otros consideran que su rechazo a Rust es irracional y motivado por una mera resistencia al cambio de algunos desarrolladores veteranos frente a un paradigma de programación más seguro.

¿Cuál será el desenlace?

El futuro de Rust for Linux ahora depende en gran medida de la decisión de Linus Torvalds, el creador del kernel de Linux. Si Torvalds aprueba los parches de R4L, la oposición de Hellwig quedaría invalidada. Sin embargo, si Torvalds decide respaldar a Hellwig, el proyecto podría estancarse o incluso desaparecer.

Independientemente del desenlace, esta controversia deja en evidencia una profunda fractura dentro de la comunidad del kernel de Linux, donde las decisiones técnicas y la cultura de desarrollo están en constante tensión.

Imagen | Marcos Merino mediante IA

En Genbeta | Rust parecía el lenguaje ideal para programar videojuegos. Este estudio acabó abandonándolo tras tres años centrados en él