Filosofía de la ingeniería: Linus Torvalds, el caso especial que desaparece

Ideas clave

• El buen gusto aparece cuando el caso especial desaparece. Reformula la estructura de datos —un puntero a un puntero en lugar de un puntero— y el if del caso límite se queda sin ningún lugar donde vivir.
• “Muéstrame el código” es una epistemología, no un eslogan. Un diseño es una hipótesis; solo el código en ejecución zanja la discusión.
• git convierte la distribución en una consecuencia de su estructura de datos. Los objetos direccionados por contenido hacen que cada repositorio sea igual, así que “la única copia verdadera” nunca existe para tener que defenderla.
• La confianza a escala tiene que estar estructurada, no asumida. Torvalds lo resolvió dos veces: un árbol de mantenedores para saber quién es responsable, y un historial a prueba de manipulaciones para saber qué ocurrió.

El principio

“Quiero que entiendas que a veces puedes ver un problema de otra manera y reescribirlo de modo que un caso especial desaparezca y se convierta en el caso normal, y eso es buen código.” – Linus Torvalds, TED, 2016¹

Torvalds estaba de pie en un escenario de TED sosteniendo dos funciones en C, una junto a la otra. Ambas eliminaban una entrada de una lista enlazada simple. La primera recorría la lista con un puntero prev, comprobaba si la entrada que había que quitar era la cabeza y se ramificaba: caso especial para la cabeza, caso general para todo lo demás. Diez líneas, un if. La segunda función recorría la lista con un puntero a un puntero —**indirect—, de modo que la cabeza no era una posición especial en absoluto. Era simplemente lo primero a lo que ese puntero a un puntero apuntaba. Cuatro líneas, sin if.¹

Tener menos líneas nunca fue lo importante. El condicional de la primera versión existía solo porque el programador modeló la cabeza de la lista como algo distinto del resto de la lista. Elige una mejor estructura de datos —un puntero a un puntero en lugar de un puntero— y la diferencia se esfuma. El caso límite nunca fue inherente al problema; era un artefacto de cómo se había representado el problema. El gusto, en el sentido de Torvalds, es exactamente este movimiento, y es la misma convicción que hace del gusto un sistema técnico y no una preferencia estética: la versión elegante gana no porque sea más bonita, sino porque es más correcta, al tener menos lugares donde poder equivocarse.

Ese instinto —eliminar el caso especial para que el caso límite no tenga dónde esconderse— atraviesa todo lo que Torvalds construyó. También explica por qué su otra frase célebre se lee menos como un manifiesto que como una instrucción: “Hablar es barato. Muéstrame el código.”²

Pruébalo arriba: elimina un nodo intermedio y luego elimina la cabeza en cada modo. En “la manera obvia”, la cabeza activa la rama if (!prev); en “buen gusto”, la cabeza es solo un enlace más, y la misma línea única lo resuelve.

Contexto

Linus Benedict Torvalds nació en Helsinki, Finlandia, en 1969, en una familia de habla sueca. Como estudiante de ciencias de la computación en la Universidad de Helsinki, usaba Minix, un pequeño sistema operativo de tipo Unix escrito por el profesor neerlandés Andrew Tanenbaum como herramienta de enseñanza. Minix era instructivo, pero deliberadamente limitado: Tanenbaum lo mantenía sencillo para que los estudiantes pudieran leerlo entero. Torvalds quería más de lo que se le permitía tener.

El 25 de agosto de 1991 publicó en el grupo de noticias de Usenet comp.os.minix: “Estoy haciendo un sistema operativo (gratuito) (solo un hobby, no será grande ni profesional como gnu) para clones AT 386(486).”³ La reserva entre paréntesis es el error de juicio más citado en la historia del software.

El hobby se convirtió, según cualquier métrica de despliegue, en el kernel más ejecutado de la Tierra: hace funcionar a la mayoría de los servidores web, a todos los teléfonos Android y a la inmensa mayoría de la infraestructura de la nube y la supercomputación.

La arquitectura fue objeto de disputa desde el principio. A comienzos de 1992, Tanenbaum abrió un hilo titulado “LINUX está obsoleto”, donde argumentaba que un kernel monolítico era “un paso gigante de vuelta a los años setenta” y que los microkernels —donde el sistema operativo se descompone en servicios aislados que se comunican por mensajes— eran el futuro.⁴ Torvalds reconoció que los microkernels eran superiores “desde un punto de vista teórico y estético”, y luego siguió construyendo el monolítico porque funcionaba, era rápido y se entregaba. El debate se recuerda como el documento fundacional de un temperamento: la teoría pierde ante un sistema que se ejecuta.

El trabajo

El kernel de Linux (1991-): un monolito que escaló

Linux es un kernel monolítico: el planificador, el gestor de memoria, los sistemas de archivos y los controladores de dispositivos se ejecutan todos en un único espacio de direcciones privilegiado. La crítica de Tanenbaum no estaba equivocada en teoría: un fallo en un controlador monolítico puede tumbar el sistema de una manera que un microkernel sí puede aislar. La respuesta de Torvalds fue empírica. El monolito era más rápido, más sencillo de escribir y podía ser modificado por miles de colaboradores sin que cada uno tuviera que aprender primero un protocolo de paso de mensajes. La arquitectura que perdió el debate académico ganó la guerra del despliegue porque redujo el costo de contribuir.

El kernel es hoy uno de los mayores artefactos de ingeniería colaborativa jamás creados: decenas de millones de líneas, miles de colaboradores por versión. Nada de esa escala se diseñó de antemano. Se fue acumulando, un parche fusionado a la vez, bajo un modelo de desarrollo que Torvalds también tuvo que inventar.

El modelo de mantenedores: la confianza como árbol

Torvalds no lee la mayor parte del código que entra en Linux. No puede: el volumen supera con creces lo que cualquier persona podría abarcar. En cambio, el kernel se gobierna mediante una jerarquía de confianza. Los mantenedores de subsistemas son dueños de sus áreas. Revisan los parches, los integran en sus árboles y envían solicitudes de incorporación hacia arriba, a los lugartenientes y, en última instancia, a Torvalds, que fusiona los árboles en los que confía. Él es el dictador benévolo en la raíz, pero su verdadero trabajo es curar en quién confía, no auditar cada línea que producen.

El árbol de mantenedores es una arquitectura social, y se enfrenta al mismo problema que afronta toda cadena de suministro de software moderna: no puedes verificar todo personalmente, así que la confianza tiene que estar estructurada en lugar de asumida. Es la razón por la que un repositorio no debería votar sobre su propia fiabilidad y por la que el código abierto no es una frontera de seguridad: los muchos ojos solo ayudan si alguien es responsable de mirar. La lista de correo, con su revisión célebremente directa, es el mecanismo que hace legible el árbol de confianza: las decisiones y sus justificaciones son públicas, archivadas y atribuibles.

git (2005): la confianza distribuida como estructura de datos

Durante años el kernel se desarrolló usando BitKeeper, un sistema de control de versiones distribuido propietario cuyo creador concedió al proyecto su uso gratuito. En 2005 ese arreglo se vino abajo en una disputa de licencias, y Torvalds se quedó de pronto sin una herramienta capaz de manejar el flujo de trabajo del kernel.⁵ Así que escribió una. El primer commit de git fue el 7 de abril de 2005; en unos diez días ya se alojaba a sí mismo y gestionaba el kernel.⁶

Lo que hace de git una expresión del mismo principio que el ejemplo de la lista enlazada es su estructura de datos central. git no almacena diffs para luego reconstruir el estado. Cada versión de cada archivo, cada árbol de directorios, cada commit se almacena como un objeto cuyo nombre es el hash SHA-1 de su propio contenido: un almacén direccionado por contenido. Torvalds es explícito en que el hashing “nunca tuvo que ver con la seguridad. Tenía que ver con detectar corrupción.”⁶ La identidad es el contenido: dos archivos con los mismos bytes son automáticamente el mismo objeto, y un solo bit invertido produce un nombre distinto y se puede detectar. Y como “todos los repositorios son iguales y equivalentes”, no hay un servidor central privilegiado: el caso especial de “la única copia verdadera” desaparece de la misma manera que desapareció el caso especial de “la cabeza de la lista”.⁶ La distribución no es una función añadida a git; es una consecuencia de elegir la estructura de datos correcta.

Esa última propiedad —una cadena de commits direccionados por contenido y a prueba de manipulaciones— es la razón por la que el grafo de commits puede cargar significado más allá del código, y por la que pienso en la sesión como el mensaje del commit: el historial es el artefacto, no un subproducto de él.

El método

El método de Torvalds es el pragmatismo impuesto por la evidencia. “Hablar es barato. Muéstrame el código” fue una respuesta literal en la lista de correo del kernel a alguien que describía lo que haría su parche.² Un diseño es una hipótesis; el parche es el experimento. Hasta que el código existe y se ejecuta, la discusión queda abierta.

Por debajo de eso está su afirmación más precisa sobre dónde reside realmente el criterio de ingeniería: “Los malos programadores se preocupan por el código. Los buenos programadores se preocupan por las estructuras de datos y sus relaciones.”⁷ El ejemplo de la lista enlazada es esa frase hecha concreta. Si la estructura de datos es correcta, el código que opera sobre ella es corto y tiene pocas ramas, porque la estructura ya absorbió la complejidad. Si la estructura de datos está mal, lo pagas para siempre en casos especiales, en sentencias if que existen solo para tapar un mal modelo. Preocuparse por el código es tratar los síntomas. Preocuparse por la estructura de datos es la cura.

El método de gobernanza encaja con el técnico. El modelo de dictador benévolo y lugartenientes existe menos para concentrar el ego que para mantener la decisión de fusión responsable ante un único criterio, distribuyendo a la vez la labor de revisión entre las personas más cercanas a cada subsistema. Y la franqueza de su revisión de código —que, según su propia admisión posterior, a veces ha cruzado hacia una dureza innecesaria— viene de la misma raíz: el código se juzga por si es correcto, no por quién lo escribió ni por cuánto esfuerzo representa. El estándar es impersonal incluso cuando la forma de comunicarlo no lo fue.

Cadena de influencia

Quién lo formó

Andrew Tanenbaum y Minix. Minix fue el sistema operativo con el que Torvalds aprendió y aquello que intentaba superar. Tanenbaum le dio un sistema de tipo Unix legible para estudiar y, a través del debate “LINUX está obsoleto”, un contrincante lo bastante afilado como para clarificar exactamente lo que Torvalds valoraba: un sistema que se entrega por encima de una arquitectura que satisface. (Influencia formativa)⁴

Unix y las herramientas GNU. Linux es un Unix por linaje de diseño: procesos, archivos, tuberías, la abstracción de que todo es un archivo. Y solo fue útil porque el compilador, el shell y las utilidades del proyecto GNU ya existían para ejecutarse encima; Torvalds portó bash y gcc antes de que el kernel pudiera hacer gran cosa.³ Construyó la única pieza que faltaba —el kernel— y dejó que las piezas existentes hicieran el resto. Construye lo que necesitas; reutiliza lo que funciona. (Influencia directa)

A quién formó

Todo el mundo del código abierto. Linux demostró que un híbrido globalmente distribuido de voluntarios y empresas podía superar en ingeniería a los equipos propietarios a la mayor escala, y el modelo de mantenedores se convirtió en la plantilla para gestionar los grandes proyectos abiertos.

Todos los sistemas de control de versiones distribuido posteriores. git no solo ganó: se convirtió en el sustrato. GitHub, GitLab y el flujo de trabajo moderno de solicitudes de incorporación están todos construidos sobre el modelo distribuido y direccionado por contenido que Torvalds eligió en aquellos diez días. La estructura de datos sobrevivió a su emergencia.

El hilo conductor

John Carmack y Torvalds llegan al mismo lugar desde especialidades opuestas. Carmack exprime un problema hasta que el algoritmo y el hardware encajan sin nada desperdiciado; Torvalds reformula un problema hasta que la estructura de datos hace que el caso especial se desvanezca. Ambos tratan el rendimiento y la elegancia como la misma propiedad vista desde lados distintos, y ambos se niegan a dejar que la teoría se imponga sobre algo que demostrablemente se ejecuta. El buen gusto, a lo largo de esta serie, nunca significa decoración; significa una corrección que puedes sentir. (Puente de la serie)

Lo que me llevo de esto

La lección de la lista enlazada es a la que recurro más a menudo. Cuando el código le brota un if para manejar “el primero” o “el caso vacío” o “el usuario administrador”, esa rama suele ser una confesión de que el modelo de datos está ligeramente mal. El arreglo rara vez es un if mejor. Es una representación mejor, tras la cual la rama ya no hace falta porque el caso del que protegía ya no puede ocurrir. Esa es la defensa más barata posible: un caso límite que no puede existir no necesita ningún código que lo maneje.

La segunda lección trata de la confianza a escala, y es la que más importa en el mundo en el que ahora construyo —los sistemas de agentes, donde orquestas trabajo que no escribiste línea por línea—. Torvalds resolvió el mismo problema dos veces: socialmente, con un árbol de mantenedores que estructura quién es responsable, y técnicamente, con el historial direccionado por contenido de git que hace qué ocurrió a prueba de manipulaciones. No puedes leer todo lo que produce un agente, igual que Torvalds no puede leer cada parche del kernel. Así que haces lo que él hizo —hacer que la confianza sea estructural y que el historial sea verificable—, que es exactamente por lo que trato el gusto como infraestructura y la cadena de suministro como la superficie de ataque. La disciplina que construyó un kernel a partir de un hobby es la misma disciplina que permite que una base de código acelere en lugar de degradarse: acierta con la estructura y los casos especiales dejan de multiplicarse.

Preguntas frecuentes

¿Cuál es la definición de “buen gusto” en el código según Linus Torvalds?

En su entrevista de TED de 2016, Torvalds definió el buen gusto usando dos implementaciones de la eliminación de un elemento de una lista enlazada. La versión que llamó de mal gusto usaba una sentencia if para tratar como caso especial la eliminación de la cabeza de la lista; la versión que llamó buen código usaba un puntero a un puntero, de modo que la cabeza ya no era un caso especial en absoluto. Su resumen: “a veces puedes ver un problema de otra manera y reescribirlo de modo que un caso especial desaparezca y se convierta en el caso normal, y eso es buen código.”¹

¿Qué creó Linus Torvalds?

Torvalds creó el kernel de Linux, que anunció por primera vez en el grupo de noticias comp.os.minix el 25 de agosto de 1991, y que hoy es el kernel de sistema operativo más desplegado del mundo. En 2005 también creó git, el sistema de control de versiones distribuido, después de que el proyecto Linux perdiera el acceso a la herramienta propietaria BitKeeper. Sigue siendo el mantenedor principal del kernel de Linux.³⁵

¿Por qué construyó Linus Torvalds git, y cuánto tardó?

El proyecto Linux había usado BitKeeper, un sistema de control de versiones distribuido propietario, hasta que una disputa de licencias en 2005 puso fin al acceso gratuito del proyecto. Torvalds escribió git como reemplazo, con el primer commit el 7 de abril de 2005 y la herramienta gestionando el kernel en unos diez días, aunque señala que había pasado meses antes pensando a fondo el diseño.⁵⁶

¿Qué significa “Hablar es barato. Muéstrame el código.”?

Torvalds publicó la frase en la lista de correo del kernel de Linux el 25 de agosto de 2000 como respuesta directa a una discusión sobre lo que haría cierto código.² Captura su pragmatismo: la descripción de un enfoque es solo una hipótesis, y la discusión no queda zanjada hasta que existe código funcional que se pueda ejecutar y probar. (Nota: la frase relacionada “con suficientes ojos, todos los errores son superficiales” es la ley de Linus tal como la formuló Eric Raymond, no una cita del propio Torvalds.⁸)

Fuentes