Aperture Institute GLaDOS — an operating system in Rust, with a language model in the kernel
GLaDOS / Download

Download GLaDOS ISO

Six images, all bootable UEFI ISOs. Each one is a FAT32 EFI System Partition wrapped in an ISO 9660 filesystem with an El Torito boot entry pointing at it, and all three layers come from this project's own ISO writer. The difference is invisible to your firmware and was not invisible to write.

Release historyCurrent release

FileModelContextSizeNotes
glados-1.2.27-nomodel.isoKernel only—33 MBKernel only. Boots to a desktop, reports that it has no model, and everything except inference works.
glados-1.2.27-smollm2-135m.isoSmolLM2-135M512133 MBFour times faster per token than Qwen3, and the only image that fits QEMU's 516 MB disk ceiling. The one to reach for under emulation.
glados-1.2.27.isoQwen3-0.6B512576 MBThe middle size. Small enough to be quick, large enough to write coherent sentences.
glados-1.2.27-qwen35-2b.isoQwen3.5-2B hybrid5121.8 GBThe flagship. Three layers in four run as linear attention, which is what keeps the cache small at this size.
glados-1.2.27-qwen35-2b-8k.isoQwen3.5-2B hybrid81921.8 GBThe same weights with room for a long conversation before the cache becomes a ring.
glados-1.2.27-qwen35-2b-32k.isoQwen3.5-2B hybrid327681.8 GBThe largest context this kernel will hold. The cache alone is 768 MiB of heap.

Sizes are of the images themselves. The context column is how many tokens the model can hold before its cache becomes a ring and begins evicting the oldest turns.

Take the SmolLM2 image if you are running this under emulation. QEMU's built-in FAT support caps the whole emulated disk at 516 MB, so it is the only one that fits. On real hardware, the Qwen3-0.6B image is the one to start with.

The same files are browsable in the archive index if you prefer a directory listing, and older releases are listed under news.

Checksums: SHA256SUMS. Worth verifying. A truncated download still flashes, still boots, and then fails somewhere that has nothing to do with the truncation, usually while loading weights.

Flashing it

Write the image to a USB stick. It is a hybrid image, so any of these work:

# Linux / macOS. Check the device name first, this overwrites it
sudo dd if=glados-1.2.27.iso of=/dev/sdX bs=4M status=progress oflag=sync
  • On Windows, Rufus in DD mode.
  • Anywhere, balenaEtcher handles the ISO directly.
Secure Boot has to be off. The kernel is unsigned and there is no Microsoft-signed shim in front of it, so firmware with Secure Boot enabled will refuse to load it. What it tells you about that refusal is usually "no bootable device", which is true in the same way that a locked door is not a wall.

Booting it

  1. Write the image and leave the stick in.
  2. Reboot and open the firmware boot menu. Commonly F11, F12, F8 or Esc.
  3. Pick the USB device listed under UEFI.
  4. Watch the boot log. It prints the memory map it was handed, the size of heap it managed to get, every device it finds on the PCI bus, and a pass or fail line for each self-test.

That log rewards a read. Twenty-six sections run at boot, twenty-three of which can be re-run on demand as named suites: fifteen sets of published cipher vectors through the crypto primitives, the heap and the timer, the ACPI namespace walk against your own firmware's tables, and a check that the grammar the sampler is given admits exactly the applet names it should. An ECDSA bug once sat visible in that output for an entire debugging session while the person reading the screen was scrolling past it.

What you get

A Windows 3.1-styled desktop with a window manager, a taskbar and a terminal, and behind that a shell. gen generates text and ask answers a question, both from the model in kernel space. if lists interfaces, dhcp takes a lease, dns resolves a name and https example.com / fetches a page over a TLS 1.3 connection that this kernel negotiated itself, down to the X25519 key exchange. battery reads a charge by evaluating the AML your firmware ships in its DSDT, because on a laptop there is no other way to get one. agent hands the model a goal and a step budget: it picks an applet through a grammar that makes wrong names unreachable, reads what the applet prints, and writes a transcript to /ai/episodes. think poses a question to the same mind while the shell stays yours. crypto, tensor and model re-run the self-tests on demand, and help lists the rest.

Hardware support, honestly

Development happens against one laptop, an MSI Thin GF63 12UC, and that is the only machine any of this is meaningfully tested on.

It should boot on most x86-64 UEFI systems. Nothing in the boot path is vendor-specific and the graphics path is plain GOP, which every UEFI implementation provides. Storage and networking are a different story, because a driver has to match a chip: there is one for Intel e1000, one for Realtek RTL8168, one for NVMe and one for xHCI, and that is the whole list. So expect a working desktop and a working model, and treat your disk and your network card as an open question.

The battery reading is a further open question, and in the other direction. It goes through an interpreter that runs your firmware's own bytecode, which is universal by construction, but the embedded controller it reaches through has never had its success path exercised: QEMU models no controller, so under emulation only the timeout is proven and every figure shown is a fallback rather than a reading.

Frequently asked questions

Is the GLaDOS ISO free?
Free to download and free to run. The source is published under all-rights-reserved, which means you are welcome to read it and not to redistribute it or build derivatives from it without asking.
Will it damage my computer or my files?
It runs from the USB stick and installs nothing. NVMe writes are locked at boot and only unlock if the driver finds a disk region that was explicitly set aside for it, and every error path locks them again. On a laptop whose disk is entirely allocated to Windows there is no such region, so storage initialisation fails and says so, which is the intended outcome.
Which image should I take?
The SmolLM2 image if you are running it under emulation, because it is the only one that fits QEMU's 516 MB disk ceiling and it is four times faster per token. The Qwen3-0.6B image on real hardware with 2 GB of RAM. The 2B images want 5 GB, and 8 GB for the 32k context variant.
Can I run it in a virtual machine?
Yes, with UEFI firmware, which means OVMF. Use the SmolLM2 image: QEMU's built-in FAT support caps the whole emulated disk at 516 MB and every other image is larger than that. Give the guest at least 2 GB of RAM as well, because the weights are read into memory before ExitBootServices and the guest has to have somewhere to put them.
Why does it need Secure Boot disabled?
Because the kernel is not signed by a key your firmware trusts. Getting one would mean going through a Microsoft-signed shim, which is a distribution and paperwork problem, not a technical one.
How fast is the model?
Generation is bound by memory bandwidth, so the useful rule is that each token costs roughly one pass over the weights. That makes the 570 MB Qwen3 checkpoint about 4.4 times slower per token than the 135 MB SmolLM2 one. Around 155 MB of Qwen3 is the output classifier alone, which is why restricting that final matrix multiply to the tokens a grammar can actually reach is such an effective optimisation.
Does it send anything anywhere?
No. There is no telemetry, no update check and no network activity at all unless you type a command that causes some. The model runs locally because there is nowhere else for it to run.