El sitio que se arma en cada visita

WordPress es la forma más común de tener un sitio, y hay buenas razones: se instala en una tarde, hay un tema para todo, y un constructor como Elementor deja diseñar sin escribir código. El precio se paga después, y en cuotas. Cada plugin es código ajeno que corre con todos los permisos del sitio; cada actualización que se posterga es una puerta; y la base de datos, el login y la API quedan escuchando las veinticuatro horas, aunque el sitio lo edite una persona dos veces por mes.

El sitio con el que se probó todo esto es el de un cliente real: un centro de retiros hecho con WordPress, el tema WoodMart y Elementor Pro, con 64 páginas, una galería, un blog y dos formularios de contacto. Un sitio común, del tipo que hay a millones. El pedido fue simple: que quede igualito, y que se pueda seguir editando fácil.

Un comando

Lo que el primer día se hizo a mano —bajar el sitio renderizado, limpiar lo que WordPress agrega a cada nombre de archivo, reapuntar los formularios— hoy es un verbo:

qhatu absorb https://el-sitio.com/ carpeta

Lee los mapas del sitio que publica WordPress, baja cada página y todo lo que necesita —hojas de estilo, scripts, imágenes en todos sus tamaños, fuentes, íconos—, y deja cada referencia apuntando a la copia local. No baja lo que no es contenido: el carrito, el panel de administración, los feeds, las búsquedas. Si una parte del sitio la arma JavaScript recién en el navegador, con --render cada página pasa antes por un Chrome sin pantalla y se guarda ya armada. Sobre el sitio del cliente:

Y no hace falta que sea WordPress: el mismo verbo se llevó un Joomla, una demo de Squarespace que arma todo con JavaScript y el primer sitio web de la historia, el de CERN, con cero referencias rotas en los tres.

Igual al píxel, y con brazo de control

«Igualito» se puede medir. Se abrió la misma página del original y de la copia en Chrome, a 1366 por 2400 píxeles, y se compararon las dos capturas punto por punto. En la portada y en una entrada del blog, 0 píxeles distintos de 3.278.400. Para que ese cero signifique algo, la prueba lleva brazo de control: cada captura tiene 216.987 colores distintos, así que no se están comparando dos páginas en blanco.

Y la honestidad incluye lo que no dio cero. En una tercera página aparecieron 1.785 píxeles distintos en la franja del menú. Antes de culpar a la copia se comparó el original consigo mismo, dos veces: dio 1.642 y 0. Es la propia página, que no se pinta igual dos veces seguidas.

Ningún enlace viejo se rompe

Un sitio con años tiene enlaces con años: en Facebook, en correos, en otros blogs. WordPress contesta a direcciones que nadie escribió a mano —/?p=123, /2023/05/una-entrada/, las categorías, el feed— y una mudanza que las pierde deja un rastro de errores 404. qhatu arma una tabla con todas ellas y el servidor la consulta antes que los archivos. Contra el sitio en vivo: 143 direcciones viejas, ninguna en 404 —55 que siguen siendo una página y 88 que la tabla lleva a su lugar nuevo—. Y una inventada sigue dando 404, que es lo que tiene que pasar.

Nada que hackear

Un escáner de WordPress empieza siempre igual: pregunta por las direcciones que todo WordPress tiene. Se hizo esa misma pregunta a los dos sitios, en modo pasivo —sólo pedidos de lectura a direcciones públicas, sin probar una sola contraseña—:

Nueve de nueve contra cero de nueve. Además, el original anunciaba en su propio código la versión exacta de WordPress y de dos de sus plugins: exactamente lo que un atacante busca para cruzar con una lista de fallas conocidas. No es que la copia tenga esas puertas mejor cerradas: no las tiene. No hay PHP que ejecutar, ni base de datos que consultar, ni usuarios que adivinar.

Midiendo esto apareció un detalle que vale contar. La copia todavía decía «WordPress» en una etiqueta invisible del HTML, heredada del original: un escáner la leía y anunciaba un WordPress que ya no existía. El absorbedor ahora la saca.

¿Y los formularios de contacto, que en WordPress son un plugin más? En la copia los atiende una función WebAssembly que corre en el servidor con capacidades declaradas: puede guardar lo que llega, leer el reloj y mandar el aviso por correo, y nada más. No puede leer el disco; lo que no pidió no existe para ella. Los mensajes se leen en el panel, y bajan como planilla. La lupa de búsqueda que la copia puede sumar a su menú es otra función así: lee un índice que se publica junto con el sitio, y no hay servidor de búsqueda que atacar.

Y si además vende

Muchos WordPress son también una tienda, con WooCommerce. Una tienda no es un conjunto de páginas: es un catálogo con precios, variantes y existencias, y un cobro. Así que no se copia como HTML: con --as-content, qhatu lee el catálogo por la misma API pública que usa el carrito de WooCommerce y cada producto entra a la tienda propia de qhatu con su nombre, su precio exacto, su moneda, sus imágenes y una variante por cada combinación —talle, color—, con la que está agotada marcada como agotada. El precio nunca pasa por un número con coma: se guarda en centavos, y al comprar el servidor lo recalcula contra el catálogo publicado, así nadie paga lo que se le ocurra mandando otro número.

Se probó contra un WooCommerce de verdad, con los productos de ejemplo que trae el propio WooCommerce: 16 productos y 7 variantes entraron, y un instrumento que compara la tienda original contra la copia, producto por producto y variante por variante, dio iguales. Su brazo de control: después de absorber se cambió un precio y se agotó una variante en el original, y el instrumento nombró exactamente esas dos diferencias. Las reseñas de cada producto vienen con él, al pie de su página. Y con una contraseña de aplicación de WordPress —la que el propio WordPress deja crear para estos casos— viene también cuántas unidades quedan de cada producto y de cada variante: el servidor descuenta lo que se vende. Después se compró: una sudadera, al carrito, a pagar con PayPal en su entorno de pruebas, y la tienda volvió diciendo que el pedido estaba pagado, con la captura de PayPal anotada del lado del servidor.

Esa tienda está en línea, para verla y comprar con plata de mentira: tienda.gioser.net.

Y no parecen dos sitios pegados. Lo que qhatu arma —los productos, la lista, el carrito, las entradas del blog— va adentro de la cabecera, el menú, el pie, los colores y las letras del sitio original. Medido: la cabecera de una página que vino del original y la de un producto armado por qhatu dan 0 píxeles distintos. El menú del celular abre en la copia aunque el WordPress original ya esté apagado, y ya no ofrece «Finalizar compra» ni «Mi cuenta», que en la copia no existen.

Más rápido, y medido sin trampa

Cinco páginas, cinco cargas en frío de cada lado —un navegador nuevo por carga, sin caché—, alternando original y copia para que una mala racha de la red no caiga entera de un lado. Las medianas:

Los bytes que viajan son prácticamente los mismos: es la misma página. Lo que cambia es el servidor. Y hay una salvedad que un artículo honesto tiene que hacer: los dos sitios están en servidores distintos, en lugares distintos, y la copia quedaba más cerca de donde se midió. Así que se separó la red del software. Abrir la conexión cuesta 392 milisegundos hasta el original y 179 hasta la copia; eso es distancia, no código. Descontando una ida y vuelta de cada lado, lo que queda es el trabajo de armar la página:

Y en un teléfono hay algo más. Al publicar, qhatu prepara cada imagen grande en varios anchos y el navegador elige la que le sirve: en la portada del cliente, vista a 390 píxeles de ancho, se bajan 72 % menos bytes de imagen, sin mover un píxel en una pantalla de escritorio.

Y se sigue editando, en el lugar

Una copia estática que no se puede tocar sería un museo. La de qhatu se edita desde un panel que vive en su propia dirección —nada del sitio público lo enlaza—, sobre la página misma, tal como se ve:

• Clic en un texto y se escribe. Una barra ofrece negrita, cursiva, enlaces, listas, títulos y citas, y los colores son los del sitio, no un selector cualquiera. Pegar desde Word o Google Docs deja el formato y tira la basura.
• Clic en una imagen y se reemplaza. Elegir varias de una vez agrega fotos a una galería: cada una de más duplica el ítem y le pone la suya.
• Duplicar, mover y borrar cualquier bloque: una tarjeta, una sección, un ítem de una lista. Y una página nueva es la copia de otra, en la dirección que se quiera.
• La paleta y las letras del sitio a un costado. Los colores que usa la página, contados; se cambia uno y se ve al instante, y un botón lo aplica a las ochenta y tantas hojas de estilo que dejó Elementor. Las tipografías se cambian igual. Si un texto deja de leerse sobre su fondo, el panel lo dice con la medida de contraste en la mano.
• Publicar es un acto firmado. Guardar cambia la carpeta; publicar convierte el sitio en una versión nueva, firmada, que el servidor sirve entera o no sirve. La historia dice qué cambió entre dos versiones cualesquiera, página por página. Volver a la anterior es un botón, y deja también la carpeta como estaba.

Y lo que el original armó con Elementor ya no queda como un HTML que sólo se toca en el lugar: con --as-content entra como bloques de qhatu —portadas, columnas, carruseles, preguntas frecuentes— que se editan con el editor de bloques y se pintan con el tema del sitio. En el del cliente, dos de sus páginas de Elementor entraron como 22 y 12 bloques, cinco portadas con su foto de fondo y tres carruseles de diez a doce fotos, sin un solo widget que quedara sin equivalente y sin una imagen sin bajar.

Todo eso corre en saywa, el servidor web de tawasuyu. En la máquina donde vive este sitio, saywa y la forja propia del proyecto ya reemplazaron a cuatro programas: el servidor web, la forja de git, el proxy y el intérprete de PHP. Alguien escribió las dos piezas desde cero, en Rust, con una regla que se repite en todo el proyecto: lo que no se midió no se afirma.

Lo que todavía no

• El cobro con plata de verdad no se probó. La tienda cobra con PayPal, y de punta a punta se probó en su entorno de pruebas; con una cuenta real, todavía no.
• De WooCommerce se trae el catálogo y sus reseñas, no la historia. Los pedidos viejos, los clientes, los cupones y las reglas de envío e impuestos se quedan en el WordPress.
• Renderizar es lento. Con --render el sitio del cliente tardó unos 30 minutos en lugar de 6: Chrome carga cada página entera.
• Hay cuentas de lectores, páginas sólo para miembros y boletín, pero no membresía paga.
• Los números de velocidad son de un día y desde un lugar. Por eso va la separación de la red: es la parte que no depende de dónde se mida.

Cómo probarlo

La tienda de este artículo está en tienda.gioser.net, y su panel está abierto: en tienda.gioser.net/_/ cualquiera puede entrar con «Probar como autor» y editarla a gusto; lo suyo se borra a las 24 horas. El mismo qhatu arma esta bitácora y el manual de tawasuyu, y con una línea más en su configuración se vuelve una wiki: enlaces por título, la historia firmada de cada página, y dos personas que editan la misma página a la vez sin pisarse. Para tener lo mismo en una máquina propia, una VPS recién creada alcanza: qhatu server install --domain el-sitio.com deja el servidor, el panel y el certificado andando —medido sobre Debian 13 y Fedora 44, con una autoridad de certificados de prueba: la portada contesta por HTTPS a los siete segundos de tener acceso a la máquina— y qhatu absorb se trae el WordPress. qhatu vive en el repositorio de tawasuyu —git.tawasuyu.net, en un servidor propio— bajo 02_ruway/qhatu, y saywa bajo 03_ukupacha/saywa. Los instrumentos de este artículo —exposición, velocidad, píxeles y el careo de la tienda— están en scripts/qhatu-careo/: cualquiera puede correrlos contra su propio WordPress y contra su copia, y comparar.

El programa que corre antes que todos

Un init hace, como mínimo, tres cosas: arranca los servicios en el orden correcto, adopta a los procesos huérfanos, y vuelve a levantar lo que se cae. Parece poco. No lo es: es el único proceso que no puede fallar nunca —si el proceso 1 muere, el núcleo entra en pánico y la pantalla se congela— y el único que ve nacer y morir a todos los demás. Quien escribe el init decide cómo arranca tu computadora, qué corre con qué permisos, y qué pasa cuando algo sale mal.

Por eso importa quién lo escribe. Y por eso conviene mirar quién lo escribe hoy.

systemd: cómo el arranque consiguió dueño

systemd nació en 2010 dentro de Red Hat para resolver problemas reales: los init de scripts de shell eran lentos, frágiles y no supervisaban nada. Hay que decirlo sin caricatura: ganó porque lo anterior era peor. Pero ganó de una forma particular: absorbiendo. Lo que empezó como un init hoy incluye el gestor de sesiones (logind), el de logs (journald, con formato binario propio), el de red (networkd), el de DNS (resolved), el de hora, el de usuarios (homed), el de particiones (repart), contenedores (nspawn), un cargador de arranque y una docena de piezas más. Ninguna distribución grande puede ya quitarle una pieza sin romper las demás: Debian lo adoptó tras una de las votaciones más ásperas de su historia, y GNOME directamente no arranca completo sin sus interfaces.

Eso es software corporativo en el sentido exacto del término: nació para resolverle los problemas a una empresa, creció absorbiendo lo que nadie le pidió absorber, y llegó a un punto donde bajarse ya no es una opción práctica. Su creador trabaja hoy en Microsoft; el proyecto lo gobierna el calendario de Red Hat/IBM. No hace falta teoría conspirativa alguna: alcanza con constatar que la pieza que decide cómo arranca casi todo Linux del planeta tiene un roadmap, y ese roadmap no lo escribís vos.

Y hay un argumento técnico, más frío que el político. El proceso 1 de systemd interpreta archivos de configuración con un parser de texto, habla D-Bus, y carga sobre sí una superficie enorme de código C. En el proyecto tawasuyu eso se resume en una doctrina de cuatro palabras: «un parser en el init es una bomba». Todo lo que el proceso 1 hace de más es superficie de ataque en el único proceso que no puede morir.

Arje, en una frase

Arje cubre desde «presionaste ENCENDER» hasta «el sistema está en pie»: un cargador de arranque UEFI propio, el proceso 1, la supervisión, el aislamiento y la compatibilidad con lo viejo. Y habla otro idioma, porque piensa distinto:

Cinco decisiones que lo cambian todo

1 — La unidad es un tipo, no un archivo de texto. Una Card es una estructura de Rust serializada: no hay parser de sintaxis en el proceso 1, hay validación en compilación. Un campo mal escrito no es un warning en un log que nadie lee: es un error antes de que exista el binario.

2 — Las dependencias son capacidades, no nombres. systemd dice «necesito a nginx.service»; arje dice «necesito a quien provea esta capacidad». Quién la provee es intercambiable, y el orden de arranque no se declara: se calcula — un ordenamiento topológico sobre el grafo de capacidades, que detecta ciclos y descarta lo insatisfacible antes de lanzar nada.

3 — No hay enable ni disable: hay Semilla. Lo que arranca tu máquina es el árbol genesis de un solo objeto firmable. Cambiar el arranque es editar ese objeto — no crear symlinks que después nadie recuerda por qué están.

4 — El bus de control lo autentica el núcleo. Cada pedido privilegiado (matar un Ente, congelar, cambiar cuotas) llega con la identidad del proceso que lo pide inyectada por el kernel vía SO_PEERCRED — imposible de falsear — y un verbo clave: RunCard encarna un proceso nuevo con los permisos de quien lo pide, no con los del init. La escalada de privilegios por el bus es imposible por construcción, no por política.

5 — El supervisor es soberano. En systemd, systemctl stop gana siempre. En arje, si la Card dice «esto se supervisa», un stop externo es apenas una señal, y el supervisor decide si el Ente revive. Parar de verdad algo supervisado exige sacarlo del grafo — que es exactamente lo que un atacante con una shell no puede hacer.

El arranque que se ve: seis actos eran tres

La prueba más honesta de un init no es un benchmark: es mirar la pantalla desde que apretás el botón. En esa mirada, un arranque Linux típico es una sucesión de parpadeos — logo del firmware, texto de consola, pantalla negra, splash, otra pantalla negra, login. Mirando un arranque real de arje con ese ojo aparecieron cuatro actos de más (un cuadrado de color que era un placeholder olvidado, un menú que parpadeaba a cada segundo, texto de consola filtrado sobre el gráfico, un segundo menú redundante). La secuencia que queda son tres actos, sin un cuadro negro entre medio:

1. loaderEl menú-grafo UEFI propio: los sistemas arrancables dibujados como grafo, con degradado y la chakana animada. Elegir acá sí tiene efecto — es antes del kernel.
2. splashLa chakana nativa, dibujada por arje-splash directo al framebuffer, reusando el modo de video que dejó el loader. Sin Plymouth.
3. greeterEl compositor retoma la misma chakana del splash y la deshace sobre el login gráfico. Entre una y otra no hay ni un cuadro negro.

Ese «ni un cuadro negro» costó una cacería medida en milisegundos. El instrumental del motor gráfico mostró que el grueso del hueco entre splash y escritorio era apagar y re-encender el panel — unos 1.063 ms de los 1.500 del hueco total. La cura fue no soltar nunca el panel: el splash mantiene la imagen en pantalla hasta que el compositor está listo para el relevo.

La última costura apareció filmando la pantalla en cámara lenta: entre la chakana del splash y la del escritorio quedaban 381 ms de panel encendido sin nada dibujado. El registro del kernel señaló al culpable —el compositor presentaba primero un cuadro liso, herencia de un relevo anterior— y hoy su primer cuadro ya es la chakana. Con un segundo monitor enchufado sí hay un apagón: para encenderlo, el controlador de video tiene que cambiar el reloj de pantalla, y eso apaga el panel un instante. Nadie puede evitarlo, pero sí elegir qué se ve: el cargador detecta la otra pantalla y funde a tiempo al fondo común, así el apagón cae entre dos fondos iguales en vez de cortar el menú.

Y el menú-grafo se instala con una red de seguridad pensada para máquinas que no tienen a nadie mirándolas: no fija el orden de arranque del firmware —irreversible en una máquina ciega— sino el intento único BootNext, que el firmware borra al usarlo y que un guardián re-arma en cada arranque sano. Un cargador roto consume su intento y la máquina cae sola al arranque de siempre. Un reset, sin rescate.

La máquina es un alma; el hardware, un cuerpo

Hasta acá, arje es un init mejor. Lo que sigue es otra categoría de cosa, y sale de una frase del plan del proyecto: «la máquina es un alma; el hardware es un cuerpo». El alma es la Semilla firmada, más la historia de sus estados, más un almacén direccionado por contenido donde cada binario vive bajo el hash de sus propios bytes. Cuatro consecuencias, las cuatro funcionando:

El paquete completo suena a control de versiones, y lo es: log, diff, checkout, blame, y hasta bisect — una regresión sembrada en una historia de cien commits se encuentra en siete pasos, igual que en git, pero sobre tu sistema operativo. Para quien conozca NixOS: no es eso. No hay lenguaje nuevo ni evaluación — el estado es la Semilla más el almacén, que ya existían. Lo que NixOS no tiene y acá sí: la historia es firmada y no repudiable, el diff es semántico (objetos, no texto), y dos estados divergentes se fusionan estructuralmente.

Esto no nació de un ejercicio teórico. Un día de septiembre, una unidad puesta a mano en la Semilla de un servidor desapareció: la Semilla se regenera desde el sistema vivo, y regenerar pisaba. Sin historia, un estado pisado no deja rastro — se notó de casualidad. Con el linaje, esa unidad perdida habría sido una línea de diff: − card minga-host. El init que recuerda existe porque el init que olvida ya costó caro.

La confianza se firma, no se supone

Antes de encarnar las piezas críticas del arranque, arje las atesta: el hash BLAKE3 de cada binario se contrasta contra concesiones firmadas con Ed25519, ancladas a una llave raíz que vive fuera de la Semilla — de modo que reescribir la Semilla no alcanza para colar un binario ajeno. La misma firma cubre las tres rutas por las que una Semilla puede nacer (instalador, empaquetador, absorción), con una sola implementación: el manifiesto es idéntico salga por donde salga. Y como el almacén direcciona por contenido, el mismo hash que firma la atestación es el nombre con el que un par puede pedir ese binario por la red y reproducir el sistema exacto.

Tus programas no se enteran

La objeción obvia: «todo el software de escritorio ya asume systemd». Es cierta, y arje la responde con una capa de compatibilidad explícita — no fingiendo ser systemd, sino sirviendo sus interfaces como borde, con la lógica real del otro lado:

La vara de esa capa fue el software más exigente que existe al respecto: GNOME 50 arranca y pinta el escritorio completo bajo arje — gnome-shell, sus servicios de sesión, ibus y portales, verificado en una VM Fedora con captura de pantalla incluida. KDE, que no depende de systemd --user, anduvo antes. Y para migrar una máquina existente está arje-absorb: lee la configuración del init que haya (sysvinit, runit, dinit, OpenRC) en modo sólo-lectura —no destruye nada— y produce una Semilla. En el primer servidor absorbido, 11 de los 20 servicios envueltos quedaron promovidos a daemons supervisados de verdad.

Medido en metal, no en diapositivas

El proyecto tiene una regla: lo que no se midió en una máquina de verdad no se afirma. Esta tabla es el estado de arje donde más duele:

Y la honestidad del método incluye contar los golpes. El más instructivo no fue de arje: en un servidor con init clásico, reboot no hacía nada — ni error, ni mensaje. La herramienta escribía ocho bytes en un archivo de control que ningún proceso tenía abierto, y salía con éxito. El peor modo de fallar. Arje tuvo los suyos (un deadlock del proceso 1 que un comentario ya advertía; 2.466 zombies por una máscara de señales que execve no restaura), y cada uno terminó convertido en un test y en una línea de estas tablas. Ningún init es inocente; la diferencia es si sus muertes dejan autopsia.

Lo que arje tiene y systemd no

Lo que decide no hacer

La otra mitad del diseño es la lista de lo que arje rechaza con razones escritas, porque un init que absorbe todo ya existe y es el problema. No hay enable/disable (la Semilla es el modelo), no hay drop-ins ni recarga en caliente de unidades (inmutable después del boot: menos superficie, más razonabilidad), no hay gestor de usuarios ni de particiones ni de contenedores dentro del init (eso es de otras piezas de la suite), no hay matador heurístico de procesos por memoria (hay límites y reglas con política explícita, no una heurística que decide por vos). Cada «no» está documentado con su porqué — y ésa es quizás la diferencia cultural más grande con el software que vino a reemplazar.

Lo que todavía no

• Un segundo monitor todavía parpadea. Arrancar con un monitor externo enchufado apaga el panel un instante —es el hardware, y el cargador lo disimula fundiendo al fondo—; y enchufarlo con la sesión abierta hoy cuesta cuatro parpadeos donde alcanzaría uno.
• El relevo sin parpadeo del splash al escritorio está certificado sobre gráficos Intel. AMD y el driver nuevo xe no están verificados todavía; NVIDIA propietario queda explícitamente fuera del camino sin costuras.
• El logind de compatibilidad modela una sesión única. Cambio de consola virtual, multi-sesión, idle y tapa están servidos a medias; es el hueco que más se siente en el escritorio y está nombrado como tal en el plan.
• No hay red declarativa ni reglas udev. arje trae un alzado de red mínimo y traduce los eventos de hardware a capacidades; una topología de red compleja hoy se resuelve con las herramientas de siempre.
• El linaje no versiona tus datos. Versiona el sistema — la Semilla, las unidades, los binarios—; prometer «viaje en el tiempo de todo» sería mentir, y el plan lo dice con esas palabras.
• La atestación arranca en modo aviso. Pasarla a modo estricto es una ceremonia del operador —generar su llave raíz y anclarla—, deliberadamente manual: estrenar atestación nunca debe dejar una máquina sin arranque.
• En FreeBSD, arje es el init, pero la paridad no es total: los límites de recursos que en Linux son cgroups allá se degradan con aviso, y quedan piezas nombradas por escribir.

Cómo verlo

Arje vive en la región raíz del repositorio de tawasuyu —git.tawasuyu.net, en un servidor propio— bajo 03_ukupacha/arje, y también como repositorio propio que compila solo: git.tawasuyu.net/tawasuyu/arje. El documento de migración, DE-SYSTEMD-A-ARJE.md, mapea verbo a verbo lo que sabés de systemd a lo que arje hace distinto; los planes y sus mediciones están al lado, con fechas y números, tal como salieron.

Qué es tawasuyu

Tawasuyu es una suite de software vertical escrita en Rust. Entre sus piezas hay un sistema operativo que arranca directamente sobre el hardware, sin Linux debajo; un motor gráfico propio, Llimphi; un escritorio con su gestor de ventanas; un navegador web con motor propio, sin Chromium ni WebKit; un entorno de escritura donde un mismo texto vive en varios idiomas y tonos; un ERP, un motor de astronomía, correo, música, video y una historia clínica.

Lo raro no es la cantidad. Es que nada de eso alquila sus cimientos: todo se apoya en el mismo formato, la misma identidad y el mismo motor que dibuja, y ninguno de ellos tiene un dueño que no seas vos.

Soberanía, capa por capa

La palabra se gastó en los discursos, así que conviene bajarla a algo que se pueda revisar. En una computadora común, cada capa tiene un dueño que no es quien la usa. En tawasuyu, cada una tiene una pieza propia que la reemplaza:

Y la regla que ordena la tabla es una sola: lo de afuera entra por un puente, nunca al centro. Un PDF se abre, una planilla se importa, un sitio web se visita; pero adentro todo trabaja en el formato propio, y si mañana desaparece el fabricante de ese formato, lo tuyo sigue siendo legible.

La sobrevivencia no es sólo de la persona

Hasta acá, esto podría ser el sueño de alguien que quiere encerrarse en su máquina. Pero la soberanía individual tiene un límite conocido: una persona sola no sostiene un camino, ni un registro, ni una decisión. Y ahí es donde el proyecto mira hacia los Andes.

Los pueblos andinos sostuvieron durante miles de años caminos que cruzaban un continente y terrazas que todavía dan cosecha, sin moneda ni escritura alfabética. Lo que los sostuvo no fue un aparato técnico, sino una forma de organizarse: ayni, la reciprocidad exacta y medible; minka, el trabajo voluntario para el común; y el ayllu, la comunidad soberana como unidad, en lugar del individuo aislado.

Tawasuyu traduce esa idea a criptografía. Un archivo nombrado por su contenido no tiene un índice central que alguien pueda confiscar. Una identidad que es una clave no necesita un registro maestro que la autorice o la dé de baja. Y una comunidad que decide con un umbral de firmas —tantos de sus miembros tienen que estar de acuerdo— no depende de quién sea el dueño del servidor. Es la misma premisa, escrita esta vez en Rust.

Cuatro regiones, un ciclo

El nombre es el plano. Tawa es cuatro en quechua y suyu es región: tawasuyu quiere decir cuatro regiones. El repositorio entero está partido en cuatro, y cada parte corresponde a una fase de lo que le pasa a la información: se percibe, se conoce, se actúa con ella y se sostiene.

Yachay es saber y ruway es hacer. Unanchay se emparenta con la señal y con darse cuenta de ella. Uku pacha es, en la cosmovisión andina, el mundo de adentro, el de abajo: el lugar de las raíces. No es casual que la soberanía empiece ahí: quien no es dueño de la raíz no es dueño de nada de lo que crece encima.

Y no es una división administrativa. Mover un programa de región cambia lo que es. Tawasuyu tiene dos programas que trabajan con noticias: watuy cosecha afirmaciones y las pone lado a lado, y vive en percibir; iniy (en quechua, creer) las verifica, y vive en conocer. Recoger una afirmación no es darla por cierta, y el código no deja que se confundan.

La chakana: todo pasa por el puente

El logo es una chakana, la cruz escalonada andina con un hueco circular en el centro. Está tallada en piedra desde Chavín y Tiwanaku, y sigue apareciendo en tejidos que alguien hace hoy. Su nombre viene de chaka, puente.

En tawasuyu la chakana no es un adorno: es el diagrama. Las cuatro regiones son sus cuatro brazos, y en el centro está el puente. La regla que eso dibuja es estricta: nada se comunica saltando; todo pasa por el medio. Es la misma regla de los formatos ajenos, vista desde arriba: lo que cruza, cruza por un lugar declarado, donde se lo puede mirar.

Apps que se entrelazan como un ayllu

Las aplicaciones de tawasuyu no se piensan como programas sueltos. La documentación del proyecto lo dice en una línea: son las instituciones andinas escritas como software. Y casi todas hacen lo mismo con una institución distinta: le sacan el intermediario.

Y se entrelazan como en un ayllu: el trabajo que deja constancia en tampu se vuelve crédito en ayni, la asamblea de tantanakuy firma su acta como comunidad, y esa acta queda en un registro público. Ninguno de esos pasos necesita pedirle permiso a una empresa.

Agora y el sello del ayllu

Esa idea tiene su lugar propio en agora, la plaza de la identidad. Una comunidad tiene su constitución y su propio sello, que sólo se estampa cuando firman los miembros que ella misma fijó. La persona es soberana y la comunidad puede firmar como una sola, sin que nadie firme en nombre ajeno. Agora merece un artículo propio, y lo tendrá.

Un homenaje

Cuando la conquista prohibió las asambleas y persiguió la lengua, la forma andina de organizarse no se perdió: el quechua se sigue hablando y la cruz escalonada se sigue tejiendo. Es, a su manera, la prueba de soberanía más larga que existe: lo que una comunidad sostiene sobrevive a quien quiso quitárselo.

Tawasuyu es un homenaje a esa arquitectura. No es una bandera: el quechua es la lengua de muchos pueblos y atraviesa fronteras, y el proyecto no habla en nombre de ninguno. Aprende de ellos. Toma la idea que más tiempo resistió —que lo que perdura no es lo que un dueño guarda en su servidor, sino lo que una comunidad sostiene— y la escribe en el lugar donde hoy se decide quién manda: el software.

Lo que todavía no

• El sistema operativo propio todavía no reemplaza a Linux en el uso diario. Hoy el escritorio de tawasuyu corre sobre un núcleo Linux y sus controladores; la raíz propia existe y arranca, pero aún no carga con todo.
• El navegador propio todavía no abre toda la web. Su motor de JavaScript pasa el 13,1 % de la batería oficial del lenguaje (Test262), y el navegador el 22,1 % de las subpruebas de la plataforma web (WPT) que ya se le corren. Crece cada semana, y los números se publican tal como salen.
• El hardware no es soberano. El procesador, la placa de video y su firmware siguen siendo de quien los fabricó. tawasuyu empieza donde termina el silicio.
• Los nombres cuestan al principio. Quien llega no sabe qué es nakui o kamachiq sin leer su ficha, y el quechua de algunas pantallas no lo revisó todavía un hablante. La revisión es bienvenida.

Cómo verlo

El código está en git.tawasuyu.net —en un servidor propio, no en una plataforma ajena— y el mapa completo, en tawasuyu.net. Para comprobar lo que dice este artículo, basta con abrir la raíz del repositorio: las cuatro regiones son lo primero que aparece.

Su motor se llama Llimphi, que en quechua quiere decir color, brillo, pigmento. Con él se dibuja la suite entera: el escritorio, el editor, el reproductor de video, los paneles de control y la interfaz del sistema operativo propio del proyecto. Hoy son 276 piezas de la suite las que se pintan con Llimphi.

Por qué no usar uno que ya existe

Hasta mayo de 2026, tawasuyu se dibujaba con GPUI, el motor del editor Zed. El 26 de mayo lo retiraron por completo, y la razón no fue capricho: el proyecto tiene su propio sistema operativo, wawa, que arranca directamente sobre el hardware, sin Linux debajo. Ningún motor existente sabe dibujar ahí.

Qt, GTK y Flutter dan por hecho que hay un sistema operativo convencional, con su gestor de ventanas, sus fuentes instaladas y su manejo de memoria. Llimphi se diseñó desde el primer día para pintar tanto en una ventana de escritorio como en la memoria de video de un kernel recién encendido. Esa exigencia obligó a escribirlo desde cero.

Qué quiere decir «de cero»

Conviene ser precisos, porque es la pregunta que hace todo programador. Llimphi no reinventó cada pieza. Igual que Flutter se apoya en Skia y GTK en Cairo, Llimphi usa cuatro proyectos libres de la comunidad de Rust para los trabajos más especializados. Lo que es propio es todo lo demás: la forma en que una aplicación describe su pantalla, cómo reacciona a cada clic, los componentes y los caminos para llegar a los píxeles.

Las cuatro piezas de la comunidad también están escritas en Rust. Por eso el titular dice «enteramente en Rust» y lo sostiene.

Cómo piensa una aplicación de Llimphi

Llimphi sigue la arquitectura de Elm, un lenguaje conocido por sus aplicaciones que casi no fallan. La idea es simple: la aplicación no modifica la pantalla, sino que la describe. Cada vez que pasa algo, el motor recorre seis pasos:

1. inputLlega un clic, una tecla o un gesto.
2. updateLa aplicación calcula su nuevo estado.
3. viewDescribe cómo debería verse con ese estado.
4. layoutEl motor calcula la posición de cada caja.
5. rasterConvierte esa descripción en píxeles.
6. presentMuestra el cuadro terminado.

Como nadie toca la pantalla directamente, no hay dos partes del programa peleándose por el mismo botón. Es la misma razón por la que este estilo se volvió popular en la web con React, solo que acá corre nativo y sin navegador en el medio.

Un pincel, cuatro caminos hasta tu pantalla

La parte más inusual de Llimphi es que el mismo dibujo puede llegar a la pantalla por caminos completamente distintos, según dónde corra la aplicación. El equipo no se conformó con que «se vea parecido»: puso cada camino lado a lado y contó los píxeles.

Que el camino «por mensaje» dé cero diferencia tiene una consecuencia práctica: una aplicación puede vivir encerrada, sin ningún permiso para tocar la pantalla, y aun así verse exactamente igual. Es seguridad que no se paga en apariencia.

Lo que ya trae

• Cerca de ochenta componentes: botones, tablas, editores de texto con varios cursores, grafos de nodos, divisores de paneles, calendarios y más.
• Once módulos que combinan componentes en piezas de aplicación completas.
• Texto de verdad: escritura de derecha a izquierda, caracteres chinos, emoji, ligaduras y métodos de entrada para idiomas asiáticos.
• Accesibilidad: cada elemento puede declarar qué es y cómo se llama, y las pruebas lo consultan como lo haría un lector de pantalla.
• Pruebas contra imagen: una pantalla se compara con su versión aprobada, y cualquier cambio inesperado hace fallar la prueba.
• Un motor 3D de vóxeles que se monta dentro de la misma interfaz, como un componente más.

Lo que todavía no

Un motor que promete demasiado pierde la confianza de quien lo prueba, así que vale decir también lo que falta:

• El camino para teléfonos está probado en hardware real, pero ninguna aplicación publicada lo usa todavía. Las versiones de Android actuales van por otro camino que no funciona en todos los chips.
• Fuera de sus tres fuentes integradas, el texto puede verse distinto en el kernel y en el escritorio. El origen está identificado: sin un sistema operativo debajo, no hay de dónde sacar más fuentes.
• Parte de Llimphi ya está publicada en crates.io, el registro oficial de Rust, pero la publicación está incompleta y algunas piezas recientes todavía no subieron.

Cómo probarlo

Para quien programa en Rust, la entrada es un solo paquete:

cargo add llimphi

El paquete reúne el núcleo, los temas y el motor 3D. Para el resto, la mejor demostración es tawasuyu mismo: cada ventana de la suite es una aplicación de Llimphi.