The site that is built on every visit

WordPress is the most common way to have a site, and for good reasons: it installs in an afternoon, there is a theme for everything, and a builder like Elementor lets you design without writing code. The price is paid later, in installments. Every plugin is someone else's code running with all of the site's permissions; every postponed update is a door; and the database, the login and the API stay listening around the clock, even if one person edits the site twice a month.

The site all this was tested on belongs to a real client: a retreat center built with WordPress, the WoodMart theme and Elementor Pro, with 64 pages, a gallery, a blog and two contact forms. An ordinary site, of the kind there are millions of. The request was simple: keep it exactly the same, and keep it easy to edit.

One command

What was done by hand on the first day —downloading the rendered site, cleaning what WordPress adds to every file name, re-pointing the forms— is now a verb:

qhatu absorb https://the-site.com/ folder

It reads the sitemaps WordPress publishes, downloads every page and everything it needs —stylesheets, scripts, images in all their sizes, fonts, icons—, and leaves every reference pointing to the local copy. It does not download what is not content: the cart, the admin panel, the feeds, the searches. If part of the site is only assembled by JavaScript in the browser, with --render each page first goes through a headless Chrome and is saved already assembled. On the client's site:

And it does not have to be WordPress: the same verb took a Joomla site, a Squarespace demo that builds everything with JavaScript, and the first website in history, CERN's, with zero broken references in all three.

Identical to the pixel, with a control arm

"Exactly the same" can be measured. The same page of the original and of the copy was opened in Chrome, at 1366 by 2400 pixels, and the two screenshots were compared point by point. On the home page and on a blog post, 0 different pixels out of 3,278,400. For that zero to mean something, the test has a control arm: each screenshot has 216,987 distinct colors, so it is not comparing two blank pages.

And honesty includes what did not come out zero. On a third page, 1,785 different pixels showed up in the menu strip. Before blaming the copy, the original was compared with itself, twice: it gave 1,642 and 0. It is the page itself, which does not paint the same way twice in a row.

No old link breaks

A site with years has links with years: on Facebook, in emails, on other blogs. WordPress answers addresses nobody typed by hand —/?p=123, /2023/05/a-post/, the categories, the feed— and a move that loses them leaves a trail of 404 errors. qhatu builds a table with all of them, and the server checks it before the files. Against the live site: 143 old addresses, none of them a 404 —55 that are still a page and 88 that the table takes to their new place—. And an invented one still gives a 404, which is what has to happen.

Nothing to hack

A WordPress scanner always starts the same way: it asks for the addresses every WordPress has. That same question was asked of both sites, in passive mode —only read requests to public addresses, without trying a single password—:

Nine out of nine against zero out of nine. On top of that, the original announced in its own code the exact version of WordPress and of two of its plugins: exactly what an attacker looks for to cross against a list of known flaws. It is not that the copy has those doors better locked: it does not have them. There is no PHP to execute, no database to query, no users to guess.

Measuring this turned up a detail worth telling. The copy still said "WordPress" in an invisible tag of the HTML, inherited from the original: a scanner read it and announced a WordPress that no longer existed. The absorber now removes it.

And the contact forms, which in WordPress are one more plugin? On the copy they are handled by a WebAssembly function that runs on the server with declared capabilities: it can store what arrives, read the clock and send the notice by email, and nothing else. It cannot read the disk; what it did not ask for does not exist for it. The messages are read in the panel, and download as a spreadsheet. The search magnifier the copy can add to its menu is another function like that: it reads an index published along with the site, and there is no search server to attack.

And if it also sells

Many WordPress sites are also a store, with WooCommerce. A store is not a set of pages: it is a catalog with prices, variants and stock, and a checkout. So it is not copied as HTML: with --as-content, qhatu reads the catalog through the same public API WooCommerce's own cart uses, and every product goes into qhatu's own store with its name, its exact price, its currency, its images and one variant per combination —size, color—, with the sold-out one marked as sold out. The price never goes through a number with a decimal point: it is stored in cents, and at checkout the server recalculates it against the published catalog, so nobody pays whatever they like by sending another number.

It was tested against a real WooCommerce, with the sample products WooCommerce itself ships with: 16 products and 7 variants came in, and an instrument that compares the original store against the copy, product by product and variant by variant, came out identical. Its control arm: after absorbing, a price was changed and a variant sold out on the original, and the instrument named exactly those two differences. Each product's reviews come with it, at the foot of its page. And with a WordPress application password —the kind WordPress itself lets you create for this— comes how many units are left of each product and each variant too: the server counts down what is sold. Then a purchase was made: a hoodie, into the cart, paid with PayPal in its test environment, and the store came back saying the order was paid, with PayPal's capture recorded on the server side.

That store is online, to look at and to buy with play money: tienda.gioser.net.

And it does not look like two sites stuck together. What qhatu builds —the products, the list, the cart, the blog posts— goes inside the original site's header, menu, footer, colors and fonts. Measured: the header of a page that came from the original and that of a product built by qhatu give 0 different pixels. The phone menu opens on the copy even with the original WordPress already turned off, and it no longer offers "Checkout" or "My account", which do not exist on the copy.

Faster, and measured without cheating

Five pages, five cold loads on each side —a fresh browser per load, no cache—, alternating original and copy so that a bad streak on the network does not fall entirely on one side. The medians:

The bytes that travel are practically the same: it is the same page. What changes is the server. And there is a caveat an honest article has to make: the two sites are on different servers, in different places, and the copy was closer to where it was measured from. So the network was separated from the software. Opening the connection costs 392 milliseconds to the original and 179 to the copy; that is distance, not code. Subtracting one round trip on each side, what remains is the work of building the page:

And on a phone there is something more. When publishing, qhatu prepares every large image in several widths and the browser picks the one it needs: on the client's home page, seen at 390 pixels wide, 72% fewer image bytes are downloaded, without moving a pixel on a desktop screen.

And it is still edited, in place

A static copy that cannot be touched would be a museum. qhatu's is edited from a panel that lives at its own address —nothing on the public site links to it—, on the page itself, just as it looks:

• Click on a text and type. A bar offers bold, italics, links, lists, headings and quotes, and the colors are the site's own, not just any picker. Pasting from Word or Google Docs keeps the formatting and throws away the junk.
• Click on an image and replace it. Choosing several at once adds photos to a gallery: each extra one duplicates the item and puts its own in.
• Duplicate, move and delete any block: a card, a section, a list item. And a new page is a copy of another, at whatever address you want.
• The site's palette and fonts on the side. The colors the page uses, counted; change one and see it instantly, and a button applies it to the eighty-odd stylesheets Elementor left behind. Fonts change the same way. If a text stops being readable on its background, the panel says so with the contrast measurement in hand.
• Publishing is a signed act. Saving changes the folder; publishing turns the site into a new, signed version that the server serves whole or not at all. The history says what changed between any two versions, page by page. Going back to the previous one is a button, and it leaves the folder as it was too.

And what the original built with Elementor no longer stays as HTML that can only be touched in place: with --as-content it comes in as qhatu blocks —heroes, columns, carousels, FAQs— that are edited with the block editor and painted with the site's theme. On the client's site, two of its Elementor pages came in as 22 and 12 blocks, five heroes with their background photo and three carousels of ten to twelve photos, without a single widget left without an equivalent and without one image that failed to download.

All of that runs on saywa, tawasuyu's web server. On the machine where this site lives, saywa and the project's own forge have already replaced four programs: the web server, the git forge, the proxy and the PHP interpreter. Someone wrote both pieces from scratch, in Rust, with a rule that repeats across the whole project: what was not measured is not claimed.

What it does not do yet

• Charging real money has not been tested. The store charges with PayPal, and end to end it was tested in PayPal's test environment; with a real account, not yet.
• From WooCommerce the catalog and its reviews come, not the history. Past orders, customers, coupons and shipping and tax rules stay in WordPress.
• Rendering is slow. With --render the client's site took about 30 minutes instead of 6: Chrome loads every page in full.
• There are reader accounts, members-only pages and a newsletter, but no paid membership.
• The speed numbers are from one day and one place. That is why the network separation is there: it is the part that does not depend on where it is measured from.

How to try it

The store in this article is at tienda.gioser.net, and its panel is open: at tienda.gioser.net/_/ anyone can get in with «Try it as an author» and edit it at will; their changes are wiped after 24 hours. The same qhatu builds this journal and the tawasuyu manual, and with one more line in its configuration it becomes a wiki: links by title, each page's signed history, and two people editing the same page at once without overwriting each other. To have the same on your own machine, a freshly created VPS is enough: qhatu server install --domain the-site.com leaves the server, the panel and the certificate running —measured on Debian 13 and Fedora 44, with a test certificate authority: the home page answers over HTTPS seven seconds after having access to the machine— and qhatu absorb brings the WordPress over. qhatu lives in the tawasuyu repository —git.tawasuyu.net, on its own server— under 02_ruway/qhatu, and saywa under 03_ukupacha/saywa. The instruments of this article —exposure, speed, pixels and the store comparison— are in scripts/qhatu-careo/: anyone can run them against their own WordPress and against its copy, and compare.

The program that runs before all others

An init does, at minimum, three things: it starts services in the right order, adopts orphaned processes, and brings back whatever falls over. Sounds small. It isn't: it is the only process that can never fail —if process 1 dies, the kernel panics and the screen freezes— and the only one that watches every other process be born and die. Whoever writes the init decides how your computer boots, what runs with which permissions, and what happens when something goes wrong.

That is why it matters who writes it. And why it is worth looking at who writes it today.

systemd: how the boot process got an owner

systemd was born in 2010 inside Red Hat to solve real problems: shell-script inits were slow, fragile and supervised nothing. Let's say it without caricature: it won because what came before was worse. But it won in a particular way: by absorbing. What began as an init today includes the session manager (logind), the log manager (journald, with its own binary format), the network manager (networkd), DNS (resolved), time, users (homed), partitions (repart), containers (nspawn), a boot loader and a dozen more pieces. No major distribution can remove one piece without breaking the rest: Debian adopted it after one of the harshest votes in its history, and GNOME simply does not fully start without its interfaces.

That is corporate software in the exact sense of the term: it was born to solve one company's problems, grew by absorbing what nobody asked it to absorb, and reached a point where opting out is no longer a practical option. Its creator works at Microsoft today; the project is governed by Red Hat/IBM's calendar. No conspiracy theory is needed: it is enough to note that the piece deciding how almost every Linux on the planet boots has a roadmap, and you are not the one writing it.

And there is a technical argument, colder than the political one. systemd's process 1 parses text configuration files, speaks D-Bus, and carries an enormous surface of C code on its back. In the tawasuyu project that is condensed into a six-word doctrine: "a parser in the init is a bomb." Everything process 1 does beyond the minimum is attack surface in the one process that cannot die.

Arje, in one sentence

Arje covers everything from "you pressed POWER" to "the system is up": its own UEFI boot loader, process 1, supervision, isolation, and compatibility with the old world. And it speaks another language, because it thinks differently:

Five decisions that change everything

1 — The unit is a type, not a text file. A Card is a serialized Rust structure: there is no syntax parser in process 1, there is compile-time validation. A misspelled field is not a warning in a log nobody reads: it is an error before the binary even exists.

2 — Dependencies are capabilities, not names. systemd says "I need nginx.service"; arje says "I need whoever provides this capability." Who provides it is interchangeable, and boot order is not declared: it is computed — a topological sort over the capability graph that detects cycles and discards the unsatisfiable before launching anything.

3 — There is no enable or disable: there is a Seed. What starts your machine is the genesis tree of a single signable object. Changing the boot means editing that object — not creating symlinks nobody later remembers the reason for.

4 — The control bus is authenticated by the kernel. Every privileged request (kill an Ente, freeze, change quotas) arrives with the caller's identity injected by the kernel via SO_PEERCRED — impossible to forge — plus one key verb: RunCard incarnates a new process with the caller's permissions, never the init's. Privilege escalation over the bus is impossible by construction, not by policy.

5 — The supervisor is sovereign. In systemd, systemctl stop always wins. In arje, if the Card says "this is supervised," an external stop is merely a signal, and the supervisor decides whether the Ente comes back. Truly stopping something supervised requires removing it from the graph — which is exactly what an attacker with a shell cannot do.

The boot you can see: six acts became three

The most honest test of an init is not a benchmark: it is watching the screen from the moment you press the button. Seen that way, a typical Linux boot is a succession of flickers — firmware logo, console text, black screen, splash, another black screen, login. Watching a real arje boot with that eye revealed four extra acts (a colored square that was a forgotten placeholder, a menu that blinked every second, console text leaking over the graphics, a second redundant menu). The sequence that remains is three acts, with no black frame in between:

1. loaderArje's own UEFI graph menu: the bootable systems drawn as a graph, with a gradient and the animated chakana. Choosing here takes effect — it is before the kernel.
2. splashThe native chakana, drawn by arje-splash straight to the framebuffer, reusing the video mode the loader left behind. No Plymouth.
3. greeterThe compositor picks up the very same chakana from the splash and dissolves it over the graphical login. Between the two there is not a single black frame.

That "not a single black frame" cost a hunt measured in milliseconds. The graphics engine's instrumentation showed that most of the gap between splash and desktop was turning the panel off and back on — about 1,063 ms of the 1,500 ms total. The cure was to never let go of the panel: the splash keeps its image on screen until the compositor is ready for the handoff.

The last seam showed up when filming the screen in slow motion: between the splash chakana and the desktop one there were still 381 ms of a lit panel with nothing drawn. The kernel log pointed at the culprit —the compositor first presented a plain frame, left over from an earlier handoff— and now its first frame is already the chakana. With a second monitor plugged in there is a blackout: to light it, the graphics driver has to change the display clock, and that turns the panel off for an instant. Nobody can avoid it, but you can choose what is shown: the loader detects the other screen and fades to the shared background in time, so the blackout falls between two identical backgrounds instead of cutting the menu.

And the graph menu installs with a safety net designed for machines nobody is watching: it does not set the firmware's boot order —irreversible on a headless machine— but the one-shot BootNext, which the firmware erases upon use and a guardian re-arms on every healthy boot. A broken loader consumes its one attempt and the machine falls back to the usual boot on its own. One reset, no rescue.

The machine is a soul; the hardware, a body

Up to here, arje is a better init. What follows is another category of thing, and it comes from one sentence in the project's plan: "the machine is a soul; the hardware is a body." The soul is the signed Seed, plus the history of its states, plus a content-addressed store where every binary lives under the hash of its own bytes. Four consequences, all four working:

The full package sounds like version control, and it is: log, diff, checkout, blame, and even bisect — a regression planted in a hundred-commit history is found in seven steps, just like in git, but over your operating system. For those who know NixOS: this is not that. There is no new language and no evaluation — the state is the Seed plus the store, which already existed. What NixOS does not have and this does: the history is signed and non-repudiable, the diff is semantic (objects, not text), and two diverging states merge structurally.

This was not born from a thought experiment. One day in September, a unit placed by hand in a server's Seed disappeared: the Seed regenerates from the live system, and regenerating overwrote. Without history, an overwritten state leaves no trace — it was noticed by accident. With lineage, that lost unit would have been one line of diff: − card minga-host. The init that remembers exists because the init that forgets had already cost real money.

Trust is signed, not assumed

Before incarnating the critical pieces of the boot, arje attests them: each binary's BLAKE3 hash is checked against Ed25519-signed grants, anchored to a root key that lives outside the Seed — so rewriting the Seed is not enough to smuggle in a foreign binary. The same signature covers the three routes by which a Seed can be born (installer, packager, absorption), with a single implementation: the manifest is identical whichever way it comes out. And since the store addresses by content, the same hash that signs the attestation is the name by which a peer can request that binary over the network and reproduce the exact system.

Your programs never notice

The obvious objection: "all desktop software already assumes systemd." It is true, and arje answers it with an explicit compatibility layer — not pretending to be systemd, but serving its interfaces as an edge, with the real logic on the other side:

The bar for that layer was the most demanding software there is on the matter: GNOME 50 starts and paints the complete desktop under arje — gnome-shell, its session services, ibus and portals, verified in a Fedora VM with the screenshot to prove it. KDE, which does not depend on systemd --user, worked earlier. And to migrate an existing machine there is arje-absorb: it reads the configuration of whatever init is there (sysvinit, runit, dinit, OpenRC) in read-only mode —it destroys nothing— and produces a Seed. On the first absorbed server, 11 of the 20 wrapped services ended up promoted to properly supervised daemons.

Measured on metal, not on slides

The project has a rule: what was not measured on a real machine is not claimed. This table is arje's state where it hurts most:

And the honesty of the method includes counting the punches. The most instructive one was not arje's: on a server with a classic init, reboot did nothing — no error, no message. The tool wrote eight bytes into a control file no process had open, and exited successfully. The worst way to fail. Arje had its own (a process-1 deadlock a code comment already warned about; 2,466 zombies from a signal mask execve does not restore), and each one ended up turned into a test and a line in these tables. No init is innocent; the difference is whether its deaths leave an autopsy.

What arje has that systemd doesn't

What it decides not to do

The other half of the design is the list of what arje refuses, with the reasons written down, because an init that absorbs everything already exists and is the problem. There is no enable/disable (the Seed is the model), no drop-ins and no hot reload of units (immutable after boot: less surface, more reasonability), no user manager or partition manager or container engine inside the init (those belong to other pieces of the suite), no heuristic memory killer (there are limits and rules with explicit policy, not a heuristic deciding for you). Every "no" is documented with its why — and that may be the biggest cultural difference with the software it came to replace.

Not yet

• A second monitor still flickers. Booting with an external monitor plugged in turns the panel off for an instant —that is the hardware, and the loader masks it by fading to the background—; and plugging it in with the session open currently costs four flickers where one would do.
• The flicker-free handoff from splash to desktop is certified on Intel graphics. AMD and the new xe driver are not yet verified; proprietary NVIDIA is explicitly out of the seamless path.
• The compatibility logind models a single session. Virtual-terminal switching, multi-session, idle and lid are half-served; it is the gap that hurts most on the desktop, and the plan names it as such.
• There is no declarative networking and no udev rules. arje ships a minimal network bring-up and translates hardware events into capabilities; a complex network topology is solved today with the usual tools.
• Lineage does not version your data. It versions the system — the Seed, the units, the binaries; promising "time travel for everything" would be lying, and the plan says so in those words.
• Attestation starts in warn mode. Flipping it to strict is an operator ceremony —generating their root key and anchoring it—, deliberately manual: rolling out attestation must never leave a machine unable to boot.
• On FreeBSD, arje is the init, but parity is not total: the resource limits that on Linux are cgroups degrade there with a notice, and named pieces remain to be written.

How to see it

Arje lives in the root region of the tawasuyu repository —git.tawasuyu.net, on a self-hosted server— under 03_ukupacha/arje, and also as its own repository that builds on its own: git.tawasuyu.net/tawasuyu/arje. The migration document, DE-SYSTEMD-A-ARJE.md, maps verb by verb what you know from systemd to what arje does differently; the plans and their measurements sit right beside it, with dates and numbers, published as they came out.

What tawasuyu is

tawasuyu is a vertical software suite written in Rust. Among its pieces there is an operating system that boots straight on the hardware, with no Linux underneath; its own graphics engine, Llimphi; a desktop with its window manager; a web browser with its own engine, without Chromium or WebKit; a writing environment where the same text lives in several languages and tones; an ERP, an astronomy engine, mail, music, video and a medical record.

The odd part isn’t the quantity. It’s that none of it rents its foundations: everything rests on the same format, the same identity and the same engine that draws, and none of them has an owner other than you.

Sovereignty, layer by layer

The word has been worn thin by speeches, so it’s worth bringing it down to something that can be checked. On an ordinary computer, every layer has an owner who isn’t the person using it. In tawasuyu, each one has a piece of its own that replaces it:

And the rule behind the table is a single one: what comes from outside enters through a bridge, never into the centre. A PDF opens, a spreadsheet gets imported, a website gets visited; but inside, everything works in the native format, and if tomorrow the maker of that format disappears, what is yours stays readable.

Survival doesn’t belong to the individual alone

So far, this could be the dream of someone who wants to lock themselves inside their machine. But individual sovereignty has a well-known limit: one person alone doesn’t sustain a road, a record or a decision. And that is where the project looks to the Andes.

For thousands of years, Andean peoples sustained roads that crossed a continent and terraces that still yield harvests, without money or alphabetic writing. What sustained them wasn’t a technical device but a way of organizing: ayni, exact and measurable reciprocity; minka, voluntary work for the common good; and the ayllu, the sovereign community as the unit, instead of the isolated individual.

tawasuyu translates that idea into cryptography. A file named by its content has no central index anyone can seize. An identity that is a key doesn’t need a master registry to authorize it or cancel it. And a community that decides by a signature threshold —so many of its members have to agree— doesn’t depend on who owns the server. It’s the same premise, written this time in Rust.

Four regions, one cycle

The name is the blueprint. Tawa is four in Quechua and suyu is region: tawasuyu means four regions. The whole repository is split in four, and each part corresponds to a phase of what happens to information: it is perceived, known, acted upon and sustained.

Yachay is knowing and ruway is doing. Unanchay is related to the signal and to noticing it. Uku pacha is, in the Andean worldview, the inner world, the one below: the place of roots. It’s no accident that sovereignty starts there: whoever doesn’t own the root owns nothing of what grows on top of it.

And it isn’t an administrative division. Moving a program to another region changes what it is. tawasuyu has two programs that work with news: watuy harvests claims and puts them side by side, and lives in perceive; iniy (in Quechua, to believe) verifies them, and lives in know. Collecting a claim isn’t taking it as true, and the code doesn’t let the two be confused.

The chakana: everything goes through the bridge

The logo is a chakana, the Andean stepped cross with a circular hole in its centre. It has been carved in stone since Chavín and Tiwanaku, and it still appears in textiles someone weaves today. Its name comes from chaka, bridge.

In tawasuyu the chakana isn’t an ornament: it’s the diagram. The four regions are its four arms, and at the centre is the bridge. The rule it draws is strict: nothing communicates by skipping ahead; everything goes through the middle. It’s the same rule as foreign formats, seen from above: whatever crosses, crosses at a declared place, where it can be looked at.

Apps woven together like an ayllu

tawasuyu’s applications aren’t conceived as standalone programs. The project’s documentation says it in one line: they are Andean institutions written as software. And almost all of them do the same thing to a different institution: they remove the middleman.

And they are woven together as in an ayllu: work recorded in tampu becomes credit in ayni, the tantanakuy assembly signs its minutes as a community, and those minutes go into a public record. None of those steps needs to ask a company for permission.

Agora and the seal of the ayllu

That idea has its own place in agora, the plaza of identity. A community has its constitution and its own seal, which is only stamped when the members it set itself have signed. The person is sovereign and the community can sign as one, without anyone signing on someone else’s behalf. Agora deserves an article of its own, and it will get one.

A tribute

When the conquest banned the assemblies and persecuted the language, the Andean way of organizing was not lost: Quechua is still spoken and the stepped cross is still woven. In its own way, it is the longest proof of sovereignty there is: what a community sustains outlives whoever tried to take it away.

tawasuyu is a tribute to that architecture. It isn’t a flag: Quechua is the language of many peoples and crosses borders, and the project speaks on behalf of none of them. It learns from them. It takes the idea that resisted the longest —that what endures isn’t what an owner keeps on their server, but what a community sustains— and writes it in the place where today it’s decided who rules: software.

What isn’t there yet

• The operating system of its own doesn’t replace Linux in daily use yet. Today tawasuyu’s desktop runs on a Linux kernel and its drivers; the root of its own exists and boots, but it doesn’t carry everything yet.
• The browser of its own doesn’t open the whole web yet. Its JavaScript engine passes 13.1% of the language’s official test suite (Test262), and the browser 22.1% of the web platform subtests (WPT) already run against it. It grows every week, and the numbers are published as they come out.
• The hardware isn’t sovereign. The processor, the graphics card and their firmware still belong to whoever made them. tawasuyu starts where the silicon ends.
• The names take some getting used to. A newcomer doesn’t know what nakui or kamachiq is without reading its description, and the Quechua on some screens hasn’t been reviewed by a speaker yet. Reviews are welcome.

How to see it

The code is at git.tawasuyu.net —on a server of its own, not on someone else’s platform— and the full map, at tawasuyu.net. To check what this article says, just open the root of the repository: the four regions are the first thing you see.

Its engine is called Llimphi, which in Quechua means color, shine, pigment. It draws the whole suite: the desktop, the editor, the video player, the control panels and the interface of the project’s own operating system. Today 276 pieces of the suite are painted with Llimphi.

Why not use one that already exists

Until May 2026, tawasuyu was drawn with GPUI, the engine behind the Zed editor. On May 26 it was removed entirely, and not on a whim: the project has its own operating system, wawa, which boots straight on the hardware, with no Linux underneath. No existing engine knows how to draw there.

Qt, GTK and Flutter take a conventional operating system for granted, with its window manager, its installed fonts and its memory management. Llimphi was designed from day one to paint both in a desktop window and in the video memory of a kernel that has just powered on. That requirement forced it to be written from scratch.

What “from scratch” means

It is worth being precise, because it is the question every programmer asks. Llimphi did not reinvent every piece. Just as Flutter relies on Skia and GTK on Cairo, Llimphi uses four free projects from the Rust community for the most specialized jobs. Everything else is its own: the way an application describes its screen, how it reacts to each click, the components and the paths that lead to the pixels.

The four community pieces are written in Rust too. That is why the headline says “entirely in Rust”, and stands by it.

How a Llimphi application thinks

Llimphi follows the Elm architecture, named after a language known for applications that almost never crash. The idea is simple: the application does not modify the screen, it describes it. Every time something happens, the engine goes through six steps:

1. inputA click, a key or a gesture arrives.
2. updateThe application computes its new state.
3. viewIt describes how it should look in that state.
4. layoutThe engine works out the position of each box.
5. rasterIt turns that description into pixels.
6. presentIt shows the finished frame.

Since nothing touches the screen directly, no two parts of the program fight over the same button. It is the same reason this style became popular on the web with React, except here it runs natively, with no browser in between.

One brush, four paths to your screen

The most unusual part of Llimphi is that the same drawing can reach the screen by completely different paths, depending on where the application runs. “Looks about the same” was not good enough: each path was put side by side with the others and the pixels were counted.

The “by message” path coming out with zero difference has a practical consequence: an application can live locked away, with no permission at all to touch the screen, and still look exactly the same. Security that costs nothing in appearance.

What it already ships

• Close to eighty components: buttons, tables, text editors with multiple cursors, node graphs, panel splitters, calendars and more.
• Eleven modules that combine components into complete application pieces.
• Real text: right-to-left writing, Chinese characters, emoji, ligatures and input methods for Asian languages.
• Accessibility: every element can declare what it is and what it is called, and the tests query it the way a screen reader would.
• Image-based tests: a screen is compared with its approved version, and any unexpected change makes the test fail.
• A 3D voxel engine that mounts inside the same interface, as just another component.

What it doesn’t do yet

An engine that promises too much loses the trust of whoever tries it, so it is worth saying what is missing too:

• The phone path has been tested on real hardware, but no published application uses it yet. The current Android builds take another path that doesn’t work on every chip.
• Outside its three built-in fonts, text may look different in the kernel and on the desktop. The cause is known: with no operating system underneath, there is nowhere to get more fonts from.
• Part of Llimphi is already published on crates.io, Rust’s official registry, but the release is incomplete and some recent pieces haven’t been uploaded yet.

How to try it

For Rust programmers, the way in is a single package:

cargo add llimphi

The package bundles the core, the themes and the 3D engine. For the rest, the best demonstration is tawasuyu itself: every window in the suite is a Llimphi application.