Puede que te suene el nombre, o puede que no, pero Andrew S. Tanenbaum es uno de esos académicos que han marcado a varias generaciones de informáticos. En una reciente conversación difundida por medios como Clarín y ecos en newsletters especializadas, lanzó una afirmación contundente sobre Windows: el sistema de Microsoft arrastra demasiados fallos porque su complejidad lo ha convertido en algo que ni sus propios ingenieros comprenden por completo.
Más allá del titular llamativo, detrás hay una crítica de arquitectura y de filosofía de desarrollo. Tanenbaum, creador de MINIX y autor de una obra clave como “Sistemas Operativos: Diseño e Implementación”, defiende desde hace décadas la modularidad frente a los diseños monolíticos. Sus argumentos no son meras preferencias técnicas: conectan con los errores cotidianos que sufren los usuarios y con problemas de seguridad que alcanzan a infraestructuras críticas.
Quién es Andrew S. Tanenbaum y por qué su voz pesa
Si hay un docente que ha explicado cómo funciona un sistema operativo de arriba abajo, ese es Tanenbaum. Su trayectoria académica y su labor como divulgador han sido fundamentales para entender los cimientos de los OS modernos, y su MINIX nació justo con ese objetivo educativo: que cualquiera pudiera estudiar un sistema real y hacer pruebas sin miedo.
No es casualidad que Linus Torvalds se inspirase en MINIX para arrancar Linux: estudió su diseño, se apoyó en la filosofía de las herramientas de GNU y, con ese impulso, alumbró el kernel que hoy gobierna servidores, supercomputadores, móviles y una buena parte de la nube. La semilla de MINIX fue decisiva en el origen del movimiento open source moderno.
En la antesala de eventos tecnológicos como Nerdearla 2025 en Buenos Aires, y en una entrevista reproducida en Clarín y comentada por voces como la newsletter Dark News de Juan Brodersen, Tanenbaum ha vuelto a las grandes cuestiones: seguridad, estabilidad y la eterna pugna entre kernels monolíticos y microkernels.
Su enfoque no es sólo académico. Según su propia metáfora, muchos sistemas actuales han terminado convertidos en un “plato de espaguetis gigantesco” donde todo toca con todo. Y cuando todo está conectado de ese modo, los efectos secundarios de un cambio se vuelven imprevisibles.
Windows bajo la lupa: complejidad desbordada y poco control
Tanenbaum fue diáfano: “Windows está lleno de errores porque ni Microsoft lo entiende al completo”. Lo que podría parecer un exabrupto se apoya en un dato demoledor: el sistema supera los 100 millones de líneas de código, escritas en varios lenguajes (C, C++ o C#, entre otros), y ningún ingeniero domina más de una pequeña fracción del total.
Cuando nadie sabe más del 10% del sistema, cualquier modificación local puede tener consecuencias inesperadas a nivel global. De ahí que los parches sean constantes y, a menudo, introduzcan nuevos bugs o agujeros mientras corrigen los antiguos. Es un bucle difícil de romper: el tamaño y el acoplamiento hacen que el propio mantenimiento sea una fuente de inestabilidad.
Para ilustrarlo, Tanenbaum recurre a esa metáfora del plato de espaguetis: si tiras de un fideo, se mueve todo el plato. En un código donde todo está entrelazado, prever los efectos de un arreglo es casi misión imposible, y las actualizaciones semanales se convierten tanto en necesidad como en riesgo.
Este es el precio de un sistema que durante décadas ha crecido para cubrir necesidades de miles de casos de uso, soporte a hardware heterogéneo, compatibilidad hacia atrás y todo tipo de integraciones. La suma de componentes, capas y dependencias acabó subiendo la factura de la complejidad hasta el punto actual.
Microkernels y modularidad: la receta de Tanenbaum
La alternativa que propone, y que encarna MINIX, es una arquitectura modular con límites claros entre componentes. En ella, cada pieza —por ejemplo, un driver— opera en su propio espacio, con permisos y responsabilidades acotadas. El resultado es que un fallo local no derriba el sistema completo.
El ejemplo clásico que ofrece Tanenbaum es el del driver de audio: en un diseño modular, el peor escenario tras un bug es que el sonido deje de funcionar o suene mal. No puede tocar el disco ni la red, ni comprometer la seguridad global. Es una contención del daño casi quirúrgica.
Frente a ello, los sistemas monolíticos tradicionales (como Windows o Linux) concentran gran parte de la lógica en un mismo espacio, con componentes fuertemente acoplados. Esa proximidad operativa facilita el rendimiento y la sencillez de ciertas interacciones, pero amplifica los efectos de un error.
¿La pega de la modularidad? Normalmente hay un coste de rendimiento. Más pasos, más conmutaciones, más mensajería entre procesos o servidores del sistema. Para Tanenbaum, el intercambio compensa: mejor un sistema un poco más lento pero mucho más estable y seguro que uno que vuele pero se caiga o quede expuesto.
El cara a cara con Linus Torvalds: rendimiento versus seguridad
Esta tensión entre diseño monolítico y microkernel no es nueva. En los 90, Tanenbaum y Torvalds protagonizaron un debate célebre: Linus defendía un kernel monolítico (más simple de construir y con buen rendimiento), mientras que Andrew apostaba por los microkernels (más seguros y tolerantes a fallos).
Con el paso del tiempo, Linux “ganó” en adopción y se convirtió en el estándar de facto en servidores, nubes y dispositivos. Tanenbaum, sin embargo, plantea una pregunta incómoda: dado el panorama de inseguridad actual, ¿esa victoria es tan clara? Tal vez hubiera sido preferible sacrificar unos puntos de rendimiento para ganar robustez a escala planetaria.
En cualquier caso, su reflexión no niega los méritos técnicos de Linux ni la enorme ingeniería de Windows; pone el foco en que el modelo de seguridad por diseño pesa cada vez más en un mundo hiperconectado, donde un fallo en un subsistema puede convertirse en un incidente global.
Los fallos que sufren los usuarios: del driver a la pantalla negra
Lo que en la teoría suena a arquitectura, en la práctica se traduce en molestias del día a día. Informes de herramientas como Wondershare Recoverit enumeran un ramillete de fallos habituales en Windows 10 y 11 que te sonarán si usas el sistema con frecuencia.
- Actualizaciones que no se completan: procesos de update que se encallan y fuerzan a reiniciar o restaurar.
- Problemas con drivers: conflictos tras instalar o actualizar controladores de hardware.
- Pantallas negras: el sistema arranca, pero el escritorio no aparece o queda inaccesible.
- Errores de sonido: fallos en el audio, dispositivos que desaparecen o dejan de responder.
- Cambios en aplicaciones predeterminadas: ajustes que se alteran sin permiso tras parches o nuevas builds.
Según Tanenbaum, la raíz de buena parte de estos problemas es la interdependencia interna: tocas un componente, y sin querer alteras otro. Al final, cada parche se convierte en una pequeña aventura, y la cadena de actualizaciones nunca parece detenerse.
Quienes administran flotas de equipos lo saben bien: programar ventanas de mantenimiento, testear drivers y validar compatibilidad y copias de seguridad con aplicaciones críticas exige tiempo y método. Cuando el comportamiento no es predecible, el coste operativo crece y también el riesgo de indisponibilidad.
Seguridad: cuando el fallo deja de ser doméstico
Hay un punto en el que la conversación sale del ámbito doméstico y salta a lo nacional. Tanenbaum subraya que actores patrocinados por estados han logrado infiltrarse en infraestructuras críticas de más de 80 países, explotando vulnerabilidades en software clave, con especial mención a Windows.
En sus palabras, ciertos componentes “pierden datos como un colador”. Es una imagen cruda, pero eficaz para entender el alcance: si el sistema es tan complejo que no es posible anticipar las interacciones, las superficies de ataque se multiplican y los adversarios tienen más oportunidades.
El círculo vicioso de parches que arreglan y abren otras puertas crea una dinámica complicada. Aun cuando Microsoft corrige con rapidez, la arquitectura de fondo sigue imponiendo sus límites a la previsibilidad.
Esto no significa que no se avance en seguridad —la industria ha mejorado enormemente—, pero Tanenbaum recuerda que el “cómo” del diseño puede ser tanto o más decisivo que el “cuánto” de los recursos invertidos en remediar.
Mejoras visibles que no tocan el núcleo del problema
Microsoft ha introducido un sinfín de novedades de cara al usuario: Cortana (ahora en retirada), escritorios virtuales, Hyper-V para virtualización, y todo tipo de mejoras en interfaz y productividad. Son avances útiles que sumaron valor para muchos perfiles profesionales y domésticos.
Pero, advierte Tanenbaum, el reto de fondo es estructural: si el corazón del sistema sigue siendo un bloque monolítico gigantesco, la capacidad de entenderlo de punta a punta es limitada. Y sin esa comprensión global, prever efectos colaterales se vuelve cuestión de probabilidades más que de certezas.
En otras palabras, puedes pulir la experiencia, añadir funciones y mejorar flujos, pero si no cambias el modelo de acoplamiento, los costes de complejidad siguen presentes. Por eso aboga por una visión donde la modularidad pasa a ser un requisito de primer orden, no un lujo.
Este enfoque casa con lo que hoy demandan muchos equipos de seguridad: aislamiento de fallos, mínimos privilegios, segmentación y límites bien definidos entre servicios. Todo lo que reduzca el “blast radius” está alineado con buenas prácticas modernas.
Transparencia, comunidad y el papel del código abierto
Otro de los puntos clave es la transparencia. Tanenbaum sostiene que gran parte del software comercial —Windows, macOS y, por extensión, aplicaciones populares— es opaco incluso para sus creadores. Lanza una pregunta con retranca: “¿Alguien sabe lo que hacen Facebook, Instagram, TikTok o Photoshop realmente ahí dentro?”.
El código abierto, en cambio, se parece más a la investigación científica: las ideas se comparten, se reproducen y se mejoran en público. Linux, BSD y otros proyectos mantienen una vitalidad que alimenta la innovación y, a menudo, permite a “aficionados” aportar soluciones que rivalizan con las de grandes corporaciones.
Para Tanenbaum, abrir el código no es sólo una cuestión de filosofía, también de calidad y seguridad. Cuando más ojos miran y prueban, se descubren errores antes y se refinan diseños con mayor rapidez. Obviamente, no es una panacea, pero reduce la asimetría de información que existe en productos cerrados.
En este escenario, su apuesta por arquitecturas modulares se integra bien con la colaboración distribuida: cada módulo puede tener mantenedores claros, límites definidos y procesos de revisión específicos, favoreciendo la responsabilidad y el control.
Lo que la industria puede (y debería) aprender
Sin pretender recetas mágicas, del análisis de Tanenbaum salen varias líneas de acción sensatas que cualquier organización podría considerar si quiere evitar caer en el síndrome del “espagueti gigante”.
- Modularidad con límites estrictos: definir perímetros de responsabilidad, permisos mínimos y canales de comunicación bien especificados.
- Observabilidad por diseño: trazar, medir y correlacionar eventos para entender el impacto de los cambios.
- Gestión de deuda técnica: eliminar acoplamientos innecesarios y refactorizar partes críticas antes de que colapsen bajo su propio peso.
- Seguridad preventiva: aislar drivers y servicios, endurecer superficies expuestas y validar cambios de forma incremental.
- Transparencia y revisión: adoptar prácticas de revisión abierta o, cuando sea posible, abrazar componentes open source con comunidad activa.
Adoptar estos principios no exige replicar MINIX ni tirar por la borda lo construido; significa orientar el rumbo para que, con cada paso, el sistema sea menos frágil y más inteligible. Eso ya es una ganancia tangible a medio plazo.
Mirando el panorama que dibuja Andrew S. Tanenbaum, cuesta no ver el patrón: código inmenso, acoplamiento fuerte y comprensión parcial son la receta perfecta para los errores recurrentes. La modularidad, el aislamiento de fallos y una cultura de transparencia apuntan a un camino más sereno: quizá no sea el más rápido, pero sí el que te lleva más lejos sin quedarte tirado a mitad de trayecto.
