2026-09-03 ·20 min de lectura · #linux #security #ai #leadership #build-in-public

Cuando la comodidad desarma a Linux

Omarchy encontró la puerta de entrada que Linux llevaba años buscando, y para abrirla retiró barreras que costaron décadas de experiencia: agentes lanzados sin aprobaciones, grupo docker por defecto, NOPASSWD ALL a un comando de distancia. Sobre la diferencia entre ocultar complejidad y eliminar controles, sobre lo que aprende quien entra por esa puerta — y sobre por qué un proyecto que enciende la guerra cultural no puede después declarar neutral el humo.

Omarchy parece haber encontrado algo que muchas distribuciones Linux llevan años buscando: una presentación atractiva, una identidad reconocible y una experiencia que permite instalar el sistema y comenzar a trabajar sin recorrer primero un largo catálogo de decisiones técnicas. Para quienes llegan desde macOS o Windows, la promesa es seductora: un escritorio rápido, coherente, orientado al teclado y preparado para desarrollar con agentes de inteligencia artificial.

Sería fácil reducir las discusiones alrededor de Omarchy a la vieja oposición entre administradores veteranos que disfrutan de la complejidad y usuarios nuevos que sólo desean que su computadora funcione. Esa lectura, sin embargo, deja fuera el problema importante. La controversia no es si Linux debe resultar hospitalario. Por supuesto que debe serlo. La cuestión es qué se elimina para producir esa hospitalidad y qué idea del sistema aprende quien entra por esa puerta.

Una interfaz amigable puede ocultar complejidad accidental mientras conserva las propiedades esenciales del sistema. También puede eliminar controles porque interrumpen el flujo deseado. Ambas decisiones producen comodidad inmediata, pero sólo la primera permite que el usuario crezca sin tener que desaprender después una concepción equivocada sobre la seguridad.

En Omarchy, varias decisiones recientes sugieren que las barreras construidas durante décadas de experiencia en Unix y Linux fueron consideradas principalmente como fricción. El problema no está únicamente en algunos errores de código. Está en una visión según la cual un sistema excelente es aquel que deja de preguntar, deja de interponerse y permite que aplicaciones y agentes actúen con la mayor autoridad posible.

Las barreras no existen para detener al propietario

Una justificación recurrente dice que Omarchy está pensado para una computadora personal de un solo usuario. Su propietario pertenece al grupo administrativo, conoce la contraseña y puede ejecutar sudo; por tanto, permitirle usar Docker sin contraseña o dejar que un agente modifique el sistema no cambiaría sustancialmente la situación.

Este razonamiento confunde a la persona propietaria con todos los procesos ejecutados bajo su cuenta.

Que yo pueda autorizar una operación administrativa no significa que deban poder hacerlo silenciosamente mi navegador, una extensión, un paquete de npm, un script de compilación, un tema descargado, una aplicación comprometida o un agente que interpretó incorrectamente una instrucción. El diálogo de sudo, la ventana de Polkit, el sandbox y la solicitud de aprobación no están ahí para impedir que administre mi propia máquina. Están ahí para impedir que cada proceso herede automáticamente toda la autoridad potencial de su propietario.

El modelo seguro distingue, al menos, tres sujetos:

La persona, cuya intención puede ser confiable.
El programa, que puede contener errores o estar comprometido.
Los datos que procesa ese programa, que pueden proceder de un tercero hostil.

La experiencia acumulada de Unix enseña que esos tres sujetos no deben confundirse. Un sistema de escritorio moderno no deja de ser un entorno con múltiples niveles de confianza por tener una sola cuenta humana.

Cuando la comodidad equivale a autoridad ambiental

Omarchy 4.0.0 —la serie Quattro— reunió dos decisiones especialmente problemáticas. Por una parte, su lanzador de agentes iniciaba a Claude con --permission-mode bypassPermissions y a Codex con --dangerously-bypass-approvals-and-sandbox, una bandera que la propia ayuda de Codex reserva para entornos aislados desde fuera. Por otra, el usuario se incorporaba por defecto al grupo docker.

La segunda decisión parece inocente cuando se describe como la posibilidad de ejecutar Docker «como usuario normal». En una instalación tradicional, sin embargo, el daemon de Docker se ejecuta como root. Quien puede comunicarse libremente con su socket puede pedirle que monte el sistema anfitrión dentro de un contenedor y que lo modifique con privilegios de administrador. La propia documentación de Docker lo advierte sin rodeos: el grupo docker concede al usuario privilegios de nivel root.

La combinación era más importante que cada pieza por separado: un agente trabajando sin aprobaciones, como un proceso ordinario del usuario, podía alcanzar silenciosamente al daemon de Docker y obtener control completo del anfitrión. Los permisos de Linux no habían dejado de funcionar. Funcionaban exactamente como habían sido configurados. Lo que se había vuelto irrelevante era la frontera entre la sesión del usuario y root.

Omarchy 4.0.1 corrigió ambas situaciones. Claude y Codex pasaron a lanzarse con --permission-mode auto y --approve-for-me, modos que aprueban por revisión automática sin renunciar al sandbox, y la pertenencia al grupo docker dejó de ser automática para volverse una decisión voluntaria. Es una corrección importante. También es una confirmación de que el señalamiento no era una exageración ideológica de administradores incapaces de aceptar un sistema cómodo.

Conviene anotar el alcance real de la corrección. Los demás agentes —grok, gemini, copilot, crush, opencode— conservaron sus banderas de modo yolo, con el argumento explícito de que sus modos intermedios se detendrían a preguntar y colgarían una ventana desatendida. La comodidad de lanzar y olvidar sigue siendo el requisito que ordena el diseño; lo que cambió es que dos agentes encontraron la manera de cumplirlo sin desarmarse del todo.

Hay otros ejemplos de la misma orientación. Omarchy ofrece un mecanismo que escribe temporalmente usuario ALL=(ALL) NOPASSWD: ALL en /etc/sudoers.d/ y programa un temporizador de systemd para retirarlo: quince minutos por defecto, o los que se le indiquen. El propio manual reconoce el costo con franqueza: mientras la función está activa, «cualquier cosa que corra como tu usuario puede hacer cualquier cosa como root sin que se le pregunte». Y añade, con razón: «ése es el propósito completo, y también el riesgo completo».

Además, se reportó que un reinicio anterior al vencimiento descarta el temporizador transitorio pero deja el archivo de autorización en disco, con lo que el acceso sin contraseña sobrevive indefinidamente. El script contempla el caso —limpia el archivo huérfano la próxima vez que alguien lo invoca— y el propio comando advierte al usuario que debe volver a ejecutarlo si reinicia antes de tiempo. Esa es exactamente la forma de la dificultad: la frontera que se decidió retirar hay que reconstruirla después con scripts, temporizadores y la buena memoria de quien la desactivó.

Errores de código y errores de concepción

No todos los problemas descubiertos en Omarchy fueron decisiones deliberadas. Algunos fueron vulnerabilidades ordinarias de implementación: títulos de videos capaces de alterar comandos, acciones de notificaciones construidas como cadenas ejecutadas mediante bash -lc, nombres de dispositivos, temas, aplicaciones o direcciones web que atravesaban componentes sin la validación adecuada, archivos temporales predecibles y ayudantes privilegiados que confiaban en rutas de ejecución inseguras. Sería incorrecto afirmar que el proyecto quería esas vulnerabilidades. También sería insuficiente tratarlas como accidentes completamente independientes de su arquitectura.

Cuando la prioridad es minimizar los puntos de autorización y permitir que distintos componentes produzcan acciones inmediatamente, es fácil normalizar el intercambio de cadenas de texto que después se convierten en comandos. Un título procedente de Internet deja de verse como un dato hostil y comienza a verse como una pieza conveniente de la orden que abrirá un video cuando se pulse una notificación.

La solución segura consiste en mantener una separación estructural: el programa es una cosa y cada argumento es otra; los datos nunca vuelven a interpretarse como código. Omarchy terminó corrigiendo su sistema de notificaciones para transportar vectores de argumentos en lugar de cadenas de shell, de modo que —en palabras del propio cambio— «los datos que controla un atacante son siempre un solo argumento y nunca pueden volver a interpretarse como comando». Es justamente el tipo de solución que décadas de experiencia en seguridad recomiendan desde el diseño, no después de publicar la vulnerabilidad.

Lo mismo sucede con las migraciones y los scripts administrativos. Bash no es inseguro por naturaleza, pero una colección de scripts imperativos capaces de modificar cualquier parte de /etc, instalar o retirar paquetes y continuar después de fallos parciales es difícil de razonar, probar y revertir.

Versiones anteriores de Omarchy llegaron a declarar que el firewall estaba habilitado cuando las reglas existían, pero el servicio no se encontraba realmente activo. Quattro ha comenzado a trasladar más componentes hacia paquetes Arch firmados, pruebas y configuraciones mejor delimitadas, pero las sucesivas correcciones de seguridad muestran el costo de haber construido primero una gran superficie de acciones privilegiadas y haberla endurecido después.

¿Una puerta de entrada a Linux?

La defensa más interesante de Omarchy no afirma que esas decisiones sean ideales, sino que pueden constituir una puerta de bienvenida para nuevos usuarios. Si Linux quiere crecer en el escritorio, dice el argumento, debe dejar de exigir a cada persona que se convierta en administradora de sistemas antes de realizar trabajo útil.

La primera parte es correcta. La conclusión no necesariamente lo es.

Una puerta de entrada debe conducir a alguna parte. Una distribución introductoria cumple esa función cuando ofrece interfaces sencillas sobre mecanismos correctos. Un gestor gráfico puede instalar un paquete mediante Polkit sin obligar al usuario a estudiar sudo, repositorios y firmas el primer día. Más adelante, si desea comprender el sistema, descubrirá que la interfaz administraba por él conceptos que siguen teniendo sentido.

Una distribución deja de ser un puente cuando sustituye esos mecanismos por otros con una semántica distinta. Si el usuario aprende que el buen sistema es aquel donde el agente nunca pregunta, Docker nunca requiere autorización y las protecciones de arranque deben desactivarse porque son «esquemas de seguridad de Microsoft», su experiencia no se vuelve fácilmente transferible a Fedora, Debian, Ubuntu o Arch.

La llegada a otra distribución no se experimentará como el acceso a una capa más profunda. Se experimentará como una regresión:

¿Por qué este sistema defectuoso me pide autorización para hacer lo que Omarchy hacía correctamente?

Omarchy puede convertirse así en una excelente vía de acceso a una estética y a un flujo de trabajo construidos sobre Linux, sin ser necesariamente una vía de acceso al modelo de Linux.

La seguridad también enseña

Los puntos de autorización tienen una función pedagógica, aunque rara vez se presenten de esa manera. Hacen visibles algunas fronteras:

Esta operación sólo afecta mis archivos.
Esta otra cambiará todo el sistema.
Este programa quiere acceder al micrófono.
Este contenedor solicita recursos privilegiados del anfitrión.
Este agente intenta salir de su directorio de trabajo.
Esta aplicación desea conectarse a Internet.

Windows mediante UAC, macOS mediante TCC y Gatekeeper, y Linux mediante permisos, sudo, Polkit y distintos mecanismos de aislamiento presentan esas fronteras con resultados desiguales. Sus diálogos pueden estar mal diseñados, repetirse demasiado o no explicar suficientemente el riesgo. Eso justifica mejorar su experiencia, no enseñar que toda interrupción es un defecto.

Si una persona aprende que un buen sistema nunca debe interponerse, es probable que no sólo rechace las distribuciones Linux que conservan esas barreras. También puede considerar que macOS y Windows están sobreingenierizados precisamente cuando intentan limitar el acceso a archivos, dispositivos, credenciales o funciones administrativas.

Se produce entonces una inversión normativa: el sistema que renuncia a las fronteras parece moderno y amigable; el que las conserva parece torpe y hostil.

Aprender únicamente después del desastre

Podría argumentarse que el usuario terminará entendiendo estas cuestiones a medida que gane experiencia. Pero el mecanismo de aprendizaje disponible es preocupante.

Si su trabajo es trivial y nunca encuentra un incidente visible, concluirá que las advertencias eran exageradas. Si el sistema sufre daños menores, quizá los atribuya simplemente a que «Linux se rompe». Y si finalmente comprende el valor de las barreras porque pierde información, filtra credenciales o compromete profesionalmente una máquina, habrá aprendido mediante una experiencia desproporcionadamente costosa.

La primera posibilidad puede ser la más común. Una configuración insegura no provoca necesariamente desastres cotidianos. Puede funcionar durante años. La ausencia de daño visible no valida el modelo de seguridad; sólo significa que todavía no coincidieron una vulnerabilidad, contenido hostil y una consecuencia observable.

En una estación de desarrollo, además, una intrusión puede no romper nada. Un proceso no necesita root para copiar llaves SSH, tokens de servicios en la nube, sesiones del navegador, repositorios privados o código fuente. El usuario podría no experimentar nunca la mala experiencia que supuestamente le enseñaría la lección, porque no sabría que ocurrió.

La transferencia negativa de hábitos

Una buena distribución para principiantes permite trasladar lo aprendido: paquetes, servicios, procesos, permisos, propiedad, registros, actualizaciones y recuperación. No es necesario comprenderlos todos al comenzar, pero las abstracciones iniciales deben corresponder con las primitivas que se encontrarán después.

Omarchy puede enseñar habilidades valiosas: terminal, Git, editores, herramientas de desarrollo y automatización. Sin embargo, en administración y seguridad corre el riesgo de producir transferencia negativa: hábitos que después deben desaprenderse.

Esto no sólo afecta al usuario individual. Una comunidad acostumbrada a ejecutar agentes sin restricciones, instalar mediante scripts remotos o tratar la aprobación como una molestia puede comenzar a producir documentación, herramientas y proyectos que presuponen esas mismas condiciones. La elección local se transforma entonces en una expectativa cultural acerca de cómo deberían funcionar todos los sistemas.

Cómo sería una verdadera distribución puente

Nada de esto implica que los agentes deban quedar confinados a escribir sugerencias ni que Linux deba preservar cada fricción histórica. Es posible construir una experiencia mucho más amable sin otorgar autoridad ambiental irrestricta.

Una distribución realmente orientada a agentes podría ofrecer:

Operaciones tipadas, como «instalar paquete» o «reiniciar servicio», en lugar de una shell administrativa general.
Autorización mediante Polkit que explique con claridad la acción y su alcance.
Contenedores rootless.
Sandboxes separados por proyecto.
Permisos temporales limitados a una capacidad concreta, no NOPASSWD: ALL.
Modos peligrosos voluntarios, visibles, auditables y que fallen de manera cerrada.
Un historial de acciones con posibilidad de reversión.
Interfaces que permitan consultar opcionalmente el comando o mecanismo subyacente.
Documentación que relacione cada comodidad con las primitivas normales de Linux.

El principiante podría utilizar el sistema desde el primer momento. Cuando sintiera curiosidad, descubriría gradualmente qué ocurre debajo. La comodidad sería una interfaz sobre la seguridad, no su sustitución.

La política del «sistema sin política»

El entusiasmo alrededor de Omarchy tampoco se explica sólo por sus decisiones técnicas. Las entrevistas de DHH proporcionaron un segundo disparador de atención: la promesa no era únicamente un escritorio atractivo y orientado a agentes, sino una nueva institución que serviría de contrapeso a una cultura de Linux supuestamente capturada.

En una entrevista de agosto de 2026, DHH afirmó que Linux estaba «infiltrado por malditos maniáticos y payasos», y unos minutos después rechazó lo que llamó la «persecución de los códigos de conducta». En medio, esto:

the goddamn cancer that is around both Nix and so many of the other institutions in the Linux world is one of the reason we’re like, we need a counterweight.

Al mismo tiempo presentó Omarchy como una «carpa amplia» en la que cualquiera sería bienvenido si sólo quiere divertirse con las computadoras. La fuerza promocional de la escena está precisamente en esa combinación: primero se identifica un enemigo difuso; después se ofrece el proyecto como refugio frente a él.

El material de partida no fue completamente imaginario. Nix atravesó conflictos reales acerca del patrocinio de empresas militares, la moderación, el liderazgo y la distribución del poder; su propia fundación reconoció en 2024 «una serie de crisis recientes en nuestra comunidad, relacionadas con problemas de comunicación, liderazgo, moderación, representación y poder de decisión». Pero de ahí no se desprende que «Linux» —el kernel, cientos de distribuciones, escritorios y proyectos independientes— haya sido secuestrado por una izquierda coordinada. La generalización sustituye un mapa de conflictos concretos por un antagonista cultural lo bastante grande como para explicar cualquier desacuerdo.

Tampoco se presentó una mejora técnica específica que hubiera sido impedida por una regla contra el acoso. El código de conducta vigente del kernel de Linux promete una participación «libre de acoso» y enumera como comportamientos inaceptables, entre otros, los insultos, los ataques personales o políticos, el acoso público o privado y la publicación de datos privados sin permiso. Es legítimo discutir su alcance, sus procedimientos o una decisión particular de sus responsables. Algo muy distinto es insinuar que esas normas, por existir, impiden que la tecnología avance. Quien afirma esa relación causal tiene que demostrarla.

No hace falta especular si quienes rechazan esas reglas desean acosar a otras personas o simplemente temen ser sancionados injustamente. El problema observable es retórico: una restricción básica sobre la conducta se presenta como una restricción sobre el pensamiento, y la protección de quienes podrían sufrir hostigamiento se rebautiza como persecución de quien tendría que abstenerse de hostigarlos.

La oleada de apoyo desde la derecha tampoco fue una asociación inventada exclusivamente por críticos externos. El propio DHH lo reconoció públicamente:

I appreciate that folks on the right are excited about new institutions in Linux land that aren’t captured by clowns and nonsense. But Omarchy isn’t anti anything in its foundation. It’s PRO having fun with beautiful, agentic computers without turning it all into politics.

Las dos frases conviven mal. Un proyecto no puede encender la mecha de la guerra cultural, beneficiarse de la atención resultante y después describir el humo como algo completamente ajeno.

Aquí aparece la contradicción central de la «carpa amplia». Una comunidad puede permitir formalmente la entrada de todo el mundo y, al mismo tiempo, comunicar con claridad quién encontrará reconocimiento y quién será objeto de burla. Si quienes valoran los códigos de conducta son presentados como payasos, maniáticos o un cáncer, la bienvenida es asimétrica. La derecha que escucha una validación de su denuncia contra lo woke recibe una señal de pertenencia; las personas que necesitan reglas explícitas contra el acoso reciben la señal de que su preocupación es el problema.

Decir «aquí no hacemos política» no corrige esa asimetría. Con demasiada frecuencia sólo significa que las posiciones del fundador se aceptan como paisaje neutral, mientras que objetarlas cuenta como introducir política en el espacio. La neutralidad no consiste en permitir que todos descarguen el mismo ISO. También involucra las condiciones bajo las cuales pueden participar, disentir, contribuir y esperar que los conflictos se resuelvan sin que su identidad se convierta en material de provocación.

En este caso, además, la separación entre autor y proyecto es especialmente débil. Omarchy se promociona literalmente como Linux «por DHH», y DHH ha utilizado su voz pública para asociar la distribución con una respuesta a la supuesta captura cultural de Linux. Sus otras intervenciones públicas forman por ello parte razonable del contexto ético. En 2025 escribió que Londres se había vuelto «completamente extranjera. Ajena, incluso» por la disminución de británicos nativos, llamó «pesadilla demográfica» a ese cambio y describió como «reconfortante» una marcha encabezada por Tommy Robinson. En julio de 2026 comparó el aumento de lobos con la presencia de personas romaníes en espacios públicos y cerró así:

When wolves get out of control, you shoot them. When gypsies take over public spaces, you deport them.

No es necesario adivinar una intención oculta para juzgar esa formulación como racista y xenófoba. Tampoco hace falta afirmar que toda analogía convierte automáticamente a su autor en nazi. Basta reconocer por qué la deshumanización de una minoría étnica europea no es una metáfora inocua, especialmente cuando el Consejo de Europa recuerda que más de medio millón de personas romaníes fueron asesinadas durante la Segunda Guerra Mundial, después de siglos de estigmatización, deportación y persecución.

Mientras tanto, la Fundación Omacom afirma haber obtenido compromisos por 13 millones de dólares en menos de dos semanas. Resulta tentador concluir que ondear banderas de derecha es lucrativo. Lo demostrable es más limitado: la retórica produjo una enorme visibilidad, una audiencia política se reconoció en ella y el financiamiento llegó con extraordinaria rapidez. No podemos saber, a partir de anuncios públicos, qué proporción respondió a afinidad ideológica, entusiasmo técnico, relaciones personales o cálculo comercial. Convertir la coincidencia en causalidad sería repetir el mismo defecto que criticamos en DHH.

Eso no vuelve irrelevante la pregunta ética. La controversia surgida cuando 1Password comprometió 300.000 dólares para la fundación —con rechazo de clientes y objeciones internas de empleados— muestra que no se trata de una inquietud imaginaria. La empresa intentó separar su apoyo a Omarchy de las posiciones personales de DHH, pero esa separación es difícil cuando el proyecto conserva su nombre en la marca, su voz en el reclutamiento y su criterio en la dirección.

Usar software escrito por alguien no equivale automáticamente a aprobar todas sus opiniones. Una licencia libre permite estudiar, modificar y bifurcar el código precisamente para reducir esa dependencia personal. Pero adoptar, recomendar, contribuir, construir una comunidad o financiar no son acciones idénticas. Cuanto más se pasa del uso privado a la amplificación pública y al apoyo institucional, más razonable es considerar no sólo la calidad del código, sino también la gobernanza que se fortalece y el espacio social que se ayuda a normalizar.

Por eso, que Omarchy se ofrezca «para todo público» no cancela el escepticismo ético si se promociona en una tienda de ideas excluyentes. No obliga a un boicot ni produce una respuesta única para cada usuario. Sí vuelve insuficiente la sonrisa burlona con la que se pretende declarar neutral, después de haber hecho de la provocación política una parte del escaparate.

Conclusión

Omarchy merece crédito por haber construido una experiencia capaz de entusiasmar a personas que quizá nunca habrían considerado Linux. Su identidad, coherencia visual y apuesta por los agentes responden a necesidades reales. También ha reaccionado con rapidez ante las vulnerabilidades recientes: creó un equipo de seguridad, corrigió configuraciones peligrosas, comenzó a exigir paquetes firmados y trasladó varias acciones hacia mecanismos más estructurados.

Pero una respuesta rápida no vuelve equivocadas las críticas. Muchas correcciones recientes reparan problemas que la propia distribución introdujo al retirar fronteras conocidas, al considerar que el usuario y todos sus procesos compartían una misma confianza, o al privilegiar la ejecución sin interrupciones por encima de la separación de capacidades.

La misma cautela debe aplicarse a su relato cultural. Un proyecto no se vuelve apolítico porque acepte descargas de cualquier persona. Después de presentarse como contrapeso a instituciones pobladas por «payasos» y atacar los códigos de conducta como persecución, no puede tratar como una mera confusión ajena el entusiasmo que despierta entre quienes desean expulsar lo woke del software libre. La apertura de una licencia y la neutralidad de una comunidad son propiedades distintas.

La pregunta importante no es si Linux debe resultar más cómodo. Debe hacerlo. La pregunta es si la comodidad se construirá haciendo comprensibles y manejables sus mecanismos de seguridad o convenciendo a los nuevos usuarios de que esos mecanismos nunca debieron existir.

Una puerta de bienvenida que obliga a desaprender el edificio entero para poder avanzar no es una transición tersa. Un sistema que sólo enseña el valor de sus barreras después de una pérdida grave no es verdaderamente amigable: simplemente ha trasladado el costo desde el momento de la autorización hasta el momento del incidente. Y una comunidad que proclama recibir a todos mientras ridiculiza las normas creadas para que algunos puedan permanecer no es una carpa neutral; es una carpa en la que alguien ya decidió qué posiciones cuentan como política y cuáles pueden pasar por sentido común.