Hemos auditado Omarchy, el sistema operativo «para la era de los agentes». Esto es lo que hay dentro

Análisis técnico de Omarchy 4.0.4 — instalación, arquitectura de sus agentes de IA, auditoría de seguridad y una pregunta incómoda sobre dónde vive realmente la inteligencia artificial en un sistema operativo.

---

Cuando el creador de Ruby on Rails saca un sistema operativo y lo llama «el SO maleable para la era de los agentes», la industria escucha. Omarchy lleva meses acumulando titulares: diez agentes de IA preconfigurados, instalación en menos de dos minutos, un escritorio que promete cambiar la forma de programar.

Nosotros hicimos lo que se hace con cualquier pieza de software antes de dejarla entrar en producción: instalarlo, abrirlo y mirar dentro.

Este artículo es el resultado. No es una reseña de impresiones. Cada afirmación que sigue está respaldada por un comando ejecutado sobre una instalación limpia de Omarchy 4.0.4, y cada una es reproducible en diez minutos por cualquiera que quiera comprobarla.

Adelantamos la conclusión, porque no nos gustan los artículos que hacen esperar: Omarchy es un trabajo de ingeniería mucho mejor de lo que su discurso comercial sugiere, y contiene mucha menos inteligencia artificial de lo que su nombre promete. Las dos cosas son ciertas a la vez, y explicar por qué es el objeto de este texto.

Qué hemos auditado, y cómo

Máquina virtual limpia sobre VirtualBox 7.2.2: 6 GB de RAM, 4 CPU, disco de 40 GB, arranque UEFI. ISO oficial omarchy-4.0.4.iso, 5,8 GB, con su firma SHA-256 verificada antes de instalar. Instalación por defecto, con cifrado de disco LUKS activado, sin tocar una sola opción avanzada.

Es decir: exactamente lo que se encontraría cualquier persona que descargue Omarchy esta tarde.

La instalación: rápida, y con una trampa que no es culpa suya

La promesa de «menos de dos minutos» se cumple. El instalador hace cinco preguntas y se aparta. En una época en la que instalar Arch Linux sigue siendo un rito de iniciación, esto es un logro real y hay que reconocerlo.

Pero la primera vez que arrancamos, no pudimos entrar.

La contraseña del disco cifrado contenía una arroba. Al escribirla en el arranque, el sistema no la aceptaba. No era la contraseña: era el teclado.

El desbloqueo de LUKS ocurre dentro del initramfs, la imagen mínima que el kernel monta antes de que exista el sistema propiamente dicho. Ahí no hay distribución de teclado cargada: siempre es la estadounidense, aunque en la instalación hayas elegido español. La arroba, que en un teclado español se escribe con AltGr+2, allí se escribe con Shift+2.

No es un fallo de Omarchy — le pasa a Ubuntu, a Fedora y a cualquier sistema con disco cifrado. Pero es la clase de detalle que convierte una instalación de dos minutos en una tarde perdida, y ningún artículo sobre Omarchy lo menciona. Si cifra su disco, elija una contraseña sin símbolos o sepa dónde están en el teclado americano.

El segundo golpe: todo al doble de tamaño

Primer arranque del escritorio, y la terminal ocupa la pantalla entera con veinte líneas de texto. Ilegible.

La causa está en ~/.config/hypr/monitors.lua:

local omarchy_gdk_scale = 2
local omarchy_monitor_scale = "auto"

Omarchy asume pantallas de alta densidad — los portátiles caros donde trabaja su autor — y duplica el escalado del sistema por defecto. En un monitor de 1280×800 eso no deja ver nada. La corrección son dos números:

local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1

Merece la pena detenerse aquí, porque explica muchas cosas sobre Omarchy: está calibrado para el hardware de quien lo escribió. Eso no es un defecto, es una decisión de producto legítima y consciente. Pero conviene saberla antes de instalarlo en algo que no sea un portátil de gama alta.

La pregunta del millón: ¿dónde está la inteligencia artificial?

Aquí es donde la auditoría se pone interesante.

Omarchy anuncia diez agentes de IA preconfigurados. Los encontramos, efectivamente, en el PATH del usuario:

claude, codex, gemini, copilot, opencode, crush, cursor-agent, pi, hermes, grok

Ahora bien: nueve de esos diez ficheros pesan entre 111 y 153 bytes. El décimo, hermes, llega a 1.463. Este es el contenido íntegro de claude, y son cuatro líneas:

#!/bin/bash
export MISE_MINIMUM_RELEASE_AGE=0
mise use -g --quiet "claude" || exit 1
exec mise x "claude" -- "claude" "$@"

Son envoltorios. Cuatro líneas que, la primera vez que se invocan, descargan el agente real de internet mediante mise, un gestor de versiones de herramientas de desarrollo.

Conviene decirlo con precisión, porque es fácil ser injusto en las dos direcciones. Los agentes no vienen instalados: vienen cableados. El cableado es real y tiene valor —- el PATH resuelto, las versiones gestionadas, la actualización centralizada—- pero sin conexión a internet no hay ningún agente en esa máquina. Y ninguno de ellos es un componente del sistema operativo: son programas de línea de comandos que funcionan igual en Debian, en macOS o en Windows.

Esto no es un escándalo. Es, sencillamente, la única arquitectura posible. Y la razón merece un apartado propio.

Por qué ningún sistema operativo tiene la IA «dentro»

Es tentador imaginar un sistema operativo con un modelo de lenguaje integrado en su núcleo, atendiendo llamadas al sistema con inteligencia. Es también técnicamente imposible, y conviene entender por qué, porque desmonta de un plumazo el discurso comercial de toda una categoría de producto.

El núcleo de un sistema operativo —- el kernel —- vive bajo restricciones que no admiten negociación:

• No puede bloquearse. Un fallo en espacio de usuario mata un proceso y el sistema sigue. Un fallo en el kernel es un panic: la máquina entera al suelo.
• No tiene memoria abundante ni dinámica. El modelo de lenguaje más modesto que sirve para algo necesita varios gigabytes y, en la práctica, una GPU.
• Debe ser determinista. Un planificador de CPU que a veces toma una decisión distinta con la misma entrada no es un planificador: es un problema.

Un modelo de lenguaje es exactamente lo contrario de las tres cosas: pesado, lento y probabilístico. Ponerlo donde un error apaga el servidor no es innovación, es negligencia.

Por eso, cuando Ubuntu, Windows u Omarchy anuncian «IA en el sistema operativo», en los tres casos hablan de programas normales ejecutándose en espacio de usuario, igual que un navegador. La diferencia entre ellos no está en la tecnología. Está en la curaduría: qué eligen instalar por usted, y qué cosen alrededor.

Y en eso, hay que decirlo, Omarchy hace un trabajo notable.

Lo que Omarchy sí ha integrado de verdad

Frente a los 154 bytes de los envoltorios, el sistema trae 446 comandos propios en /usr/bin, todos provistos por un paquete firmado (omarchy 4.0.4-1). Eso no es un script suelto: es una distribución con criterio.

La joya es el vigilante de caídas. Cuando un proceso se muere, omarchy-crash-watch lo detecta y ofrece diagnosticarlo con un agente. El mecanismo es elegante: en lugar de vigilar ficheros de volcado, sigue el registro del sistema filtrando por el identificador de mensaje que systemd-coredump emite en cada caída, lo que da datos estructurados en vez de nombres de fichero.

El código está, sencillamente, bien escrito. Dos detalles que lo delatan:

Deduplicación de bucles de caída. Un proceso que se estrella en bucle genera cientos de volcados por minuto. El vigilante anuncia cada programa una vez por ventana de tiempo, y —- detalle fino —- solo arranca esa ventana si la notificación llegó a entregarse, porque una notificación fallida que contase suprimiría el resto del bucle.

Defensa contra nombres de proceso hostiles. Los datos de la caída se pasan como argumentos sueltos, nunca interpolados en una cadena de shell. Un proceso llamado ; rm -rf / sigue siendo un nombre, no se convierte en un comando. Es la clase de cuidado que separa el software profesional del script de fin de semana.

La instrucción de diagnóstico, además, está replicada para los cinco agentes principales, de forma que funciona con el que usted haya elegido. Eso es integración de verdad, no una etiqueta de marketing.

Lo mismo vale para VoxType, el dictado por voz sin conexión basado en Whisper: existe como paquete oficial en el repositorio de Omarchy, con cinco comandos propios para instalarlo, configurarlo y elegir modelo. Precisión necesaria: no viene instalado. Hay que pedirlo.

Auditoría de seguridad: qué pasa si lo pone a hacer de servidor

Omarchy es un escritorio y no pretende otra cosa. Pero la tentación de dejar corriendo en él un servicio, un contenedor o un agente que trabaje de noche es evidente, así que lo auditamos con ese criterio.

Lo que está bien, y es más de lo que esperábamos:

Aspecto	Estado
Cortafuegos	ufw activo, política de entrada deny por defecto
Cifrado de disco	LUKS sobre todo el volumen raíz
Paquetes de AUR	Cero. Todo viene de repositorios oficiales firmados
Instantáneas	Btrfs con Snapper: permite volver atrás tras una actualización rota
Permisos elevados	Reglas NOPASSWD acotadas con expresiones regulares estrictas

Ese «cero paquetes de AUR» merece subrayado. El repositorio comunitario de Arch es la vía de entrada habitual de código sin auditar en ese ecosistema. Que una distribución basada en Arch no dependa de él es una decisión de seguridad seria y poco frecuente.

Lo que no está bien:

Hallazgo	Riesgo
SSH con PasswordAuthentication yes y sin fail2ban	Fuerza bruta sin ningún freno
Ningún temporizador de actualización	Distribución rolling sin parcheo automático: el peor de los dos mundos
Sin AppArmor ni SELinux; kernel.kptr_restrict = 0	Sin control de acceso obligatorio a nivel de sistema
CUPS, Avahi y Bluetooth activos por defecto	Superficie de ataque innecesaria fuera de un escritorio

Precisión obligada sobre el tercer punto: sí hay módulos de seguridad del kernel cargados (lockdown, capability, landlock, yama, bpf). Landlock está presente, y es relevante. Pero Landlock solo protege si cada aplicación se acota voluntariamente a sí misma; no es una política de sistema que el administrador imponga. Para un escritorio es razonable. Para un servidor, no basta.

El segundo hallazgo es el más grave y el menos evidente. Una distribución rolling release recibe parches de seguridad constantemente, lo cual es una ventaja enorme… siempre que alguien los aplique. Omarchy no programa ninguna actualización automática. El único temporizador activo en el sistema actualiza la base de datos del buscador de ficheros. Un servidor así acumula vulnerabilidades conocidas hasta que un humano se acuerda de escribir pacman -Syu.

El hueco más interesante está en el kernel

Omarchy compila su propio núcleo (7.2.5-3-omarchy), y lo hace con una opción que llama la atención:

CONFIG_SCHED_CLASS_EXT=y        → sched_ext compilado
/sys/kernel/sched_ext/state     → disabled
Herramientas instaladas         → ninguna

sched_ext es la funcionalidad que permite escribir el planificador de CPU del sistema como un programa eBPF y cargarlo en caliente, sin recompilar el kernel ni reiniciar. Es, hoy por hoy, el único lugar del sistema donde se puede ejecutar lógica personalizada dentro del espacio del núcleo.

Omarchy lo trae compilado, lo deja desactivado y no instala ni una sola herramienta para aprovecharlo. Ni scx_rusty, ni scx_lavd, ni siquiera bpftool para inspeccionarlo.

Que esté desactivado por defecto es la decisión correcta para un escritorio de uso general: un planificador experimental no es lo que uno quiere bajo su editor de código. Pero el resultado tiene su ironía: el sistema operativo que se anuncia como el de la era de los agentes trae tapiada la única puerta por la que la inteligencia podría entrar de verdad al núcleo.

Ahí, y no en los envoltorios de bash, es donde está el trabajo interesante de los próximos años.

Las cifras

Medidas sobre la máquina virtual descrita, con el escritorio arrancado y en reposo:

• Espacio de usuario hasta escritorio listo: 5,47 s
• RAM en reposo: 966 MB con 276 procesos y el entorno gráfico completo
• Paquetes instalados: 949, ninguno de AUR
• Versiones: Python 3.14.7, systemd 261.2, Mesa 26.2.2, Docker 29.7.2, Hyprland 0.56.2

Menos de un gigabyte en reposo para un escritorio completo es un dato excelente, y es mérito de Hyprland y de una selección de paquetes contenida.

Una nota de honestidad sobre el arranque: el total fue de 45 segundos, de los cuales 33 se los llevó el kernel. Ese número es un artefacto de medir dentro de una máquina virtual con disco cifrado y no representa el comportamiento en hardware real. El dato válido, y bueno, es el de espacio de usuario: 5,47 segundos.

Veredicto

Omarchy tiene sentido si usted programa en un portátil moderno, quiere un entorno de desarrollo montado y con criterio sin dedicarle un fin de semana, y le compensa mantener una distribución rolling a cambio de tener siempre la última versión de todo. La curaduría es buena, el código es bueno y la experiencia está cuidada. Los 446 comandos que trae no son relleno: son decisiones tomadas por usted por alguien que sabe lo que hace.

Omarchy no tiene sentido si busca un servidor. No fue diseñado para eso, no se defiende como tal, y la ausencia de actualizaciones automáticas en una distribución rolling es una combinación que ningún responsable de sistemas debería aceptar en producción.

Y sobre la promesa que da nombre a toda la categoría, la respuesta honesta es esta: la inteligencia artificial de Omarchy no está en el sistema operativo, porque no puede estarlo en ningún sistema operativo. Lo que Omarchy ofrece de verdad —- y no es poco —- es no tener que decidir usted qué instalar.

Si eso vale el precio de mantener Arch Linux, es una decisión de ingeniería, no de fe. Y como toda decisión de ingeniería, depende de para qué.

---

Apéndice: lo mismo, en Debian

La afirmación central de este artículo es que esa integración es replicable. Así que la replicamos: portamos el vigilante de caídas de Omarchy a Debian, en dos scripts y una unidad de systemd.

El mecanismo es idéntico, porque systemd-coredump es estándar y no tiene nada de específico de Arch. Los cambios son de criterio, no de tecnología:

• Omarchy ignora las caídas que no son del usuario que ha iniciado sesión. Es lo correcto en un escritorio. En un servidor, el demonio que se estrella es justo lo que hay que saber, así que vigilamos todos los identificadores de usuario.
• La notificación de escritorio se sustituye por un informe en /var/log. El original espera que alguien haga clic. Un servidor a las tres de la mañana no tiene a nadie delante.
• La ventana de deduplicación pasa de 60 a 300 segundos. En Omarchy una notificación es gratis; aquí cada diagnóstico es una llamada de API que cuesta dinero.

Un detalle que conviene saber si va a replicarlo: Debian no instala systemd-coredump por defecto. Sin él, el kernel escribe los volcados según core_pattern y el registro del sistema no tiene nada que leer. Es la razón más habitual por la que un montaje así parece funcionar y en realidad no hace nada.

El código está publicado junto a este artículo y mide unas 80 líneas. Con una advertencia que corresponde hacer: está escrito y revisado, pero todavía no lo hemos puesto a correr en un servidor de producción. Darlo por probado sin haberlo ejecutado sería exactamente el tipo de afirmación sin verificar que este artículo reprocha a otros.

Esa es, al final, la medida exacta de la distancia entre «sistema operativo con IA integrada» y «un servidor normal con un agente instalado»: ochenta líneas de bash y un apt install.