Glint is an operating system that a newcomer can read from end to end. It is written in one programming language, Crystal, and it runs on machines as small as a 16 KiB microcontroller (a whole small computer on one chip) and as large as a server.

What it's for

Glint is meant to put the user in control of their computer, with the rest of the world in its proper place.

Part of every operating system sits very close to the processor: starting up, managing memory, handling interrupts (signals from devices, such as a key press, that make the processor stop and respond), scheduling work (choosing which program runs next), keeping files. This part changes little between machines built on the same kind of processor. Glint writes it once, plainly, in one language, so a newcomer can understand it. They shouldn't have to learn a pile of other languages and tools along the way: Python scripts, and tools such as Kconfig, flex and bison, each with its own special language. Every extra syntax is another barrier.

What it's made of

• Crystal for every line a person reads, including Glint's shell, the prompt where a person types commands. The shell accepts only Crystal.
• BQ2 (bootstrap-qcow2) to build it. BQ2 is a small system that rebuilds itself from readable source, including the compilers that turn the code people write into instructions a processor runs. Because every tool in that chain can itself be read and rebuilt, nothing that builds Glint is a black box. Glint uses BQ2's tools and nothing else.
• Zephyr, an open-source operating system for small devices. Glint borrows its drivers: the code that knows how to talk to a particular chip or device.
• Linux, run unmodified as a guest. A guest is a second operating system running inside the first, the way a program runs inside a window. Glint stays in charge. Linux drives the devices that only Linux knows how to drive. Glint never includes Linux code in itself.

Zephyr and Linux are where thousands of people already work together to support thousands of chips and boards. That support is far more than one project could keep up alone. Glint relies on it for each particular board, and keeps the part it owns small and readable.

How it's shaped

• Firmware is the small program built into a board that starts it up. Most computers' firmware follows a standard called UEFI, and Glint starts the way any UEFI program does.
• Once running, Glint hosts Linux as its guest. Seen from inside Linux, Glint is a hypervisor: the program a guest runs on top of.
• On the smallest boards, which have no such firmware, Zephyr stands in for it.
• The smallest target is BeagleConnect Zepto, a microcontroller board with 16 KiB of memory. There, Glint's shell compiles small programs, saves them to flash, storage that keeps its contents with the power off, and runs them. Few complete development systems fit that small anymore; CircuitPython, for one, now needs 32 KiB.
• On larger machines, from BeagleY-AI to desktop and server computers, Glint runs Linux as a guest. It also offers Crystal's full standard library, the large set of ready-made code that Crystal programs rely on.

How it's built

Glint grows in small steps, one idea each, and each step is shown working before the next. The steps follow the chapters of xv6, a small teaching operating system from MIT, and its book. Each step cites the passage it implements, so a reader can check the code against the book. docs/TUTORIAL.md walks through every step taken so far, and the Status page says where the work stands today.

What success looks like

Each milestone below links to its evidence once it's done.

1. BeagleConnect Zepto. On BeagleConnect Zepto, Glint's shell compiles Crystal code in 16 KiB of memory, writes it to flash, and loads and runs it. A few source files and a small library, mostly calling ready-built routines, live in flash alongside it. Not yet.
2. Robots. A Glint build compiles a robot from the crystal-robots game from its source file and plays its turns over I2C, a simple two-wire connection between chips. Not yet.
3. Full Crystal. On a server, with a Linux guest providing networking and storage, Glint supports Crystal's full standard library and passes its tests. Not yet.
4. Building itself. A board like BeagleBadge (64-bit ARM, 256 MB of memory, a microSD card, a serial port, supported by Zephyr) runs BQ2 on Glint and rebuilds both Glint and BQ2. It may be slow, but it works. Not yet.
5. Larger machines. From BeagleY-AI to x86 and ARM servers, Linux runs as a guest beside Crystal's full standard library. Not yet.
6. One language. Building Glint needs only Crystal and BQ2's tools: no Kconfig, Python, flex or bison. Done: built on x86-1, which has no Python, flex or bison (x86_64, aarch64).

The virtues behind it

Like every project in this program, Glint follows the four virtues of OCX:

• Clearly stated: anyone can tell what each part does. Glint uses one syntax, so there's one language to learn.
• Loosely coupled: each part can be swapped without breaking the rest. Linux and Zephyr sit behind clean boundaries.
• Demonstrably verified: every claim is shown working, not just stated. Every step boots, and its tests run.
• Parsimoniously bounded: it does no more than it needs to. Glint's own code covers only what a processor architecture (a family of processors that share one instruction set, such as ARM or x86) or a published standard defines. Everything specific to one chip or board comes from firmware, Zephyr or Linux.

Building

Glint must build with the toolset of bootstrap-qcow2 alone: Crystal, LLVM/clang/lld, musl, BusyBox and the rest of BQ2's packages. No Python, flex, bison or dtc. The build driver is written in Crystal. Devicetree and Kconfig handling come from cleave. The Linux guest is a prebuilt, pinned input; Glint's build never builds Linux.

QEMU and its EFI firmware are also built here from pinned source with the same tools. That means Crystal ports of QEMU's Python code generators (decodetree, qapi-gen, tracetool, minikconf), each working from QEMU's own data files and specifications, and Crystal builds of reduced qemu-system-aarch64 and qemu-system-x86_64. The firmware on both is U-Boot with EFI, built with cleave, not EDK2.

Planned commands:

shards build
export ZEPHYR_SRC=/path/to/pinned/zephyr  # required for glint-build; see third_party/zephyr/PIN.md
bin/glint-build aarch64    # -> build/aarch64/EFI/BOOT/BOOTAA64.EFI
bin/glint-qemu             # build the project's reduced QEMU (aarch64 + x86_64) + U-Boot
bin/glint-run   aarch64    # ESP image, boot under that QEMU, serial on stdio
crystal spec               # host-side tests, including a fake EFI system table

Layout (planned)

prelude/          Glint's minimal Crystal prelude (no GC, no libc)
spec/             specs, the fake EFI system table, fixtures
c/                small C sources (the C seam, 1.4)
fs/               file access over EFI and, later, Glint's own FAT
user/             the shell and other programs
boot/             EFI entry, platform interface (protocols by GUID), mode selection
arch/aarch64/     EL2 vectors, MMU, stage-2, GIC/vGIC, timers, PSCI
arch/x86_64/      IDT/GDT, paging, VMX/SVM, APIC
kernel/           scheduler, memory, provider registry
hyp/              vCPUs, guest EFI, guest DT generation, virtio devices and backends
compat/zephyr/    Zephyr API shim (C headers + Crystal implementation)
third_party/      pinned Zephyr source subset and patches
guest/test/       the bare-metal test guest (4.2)
guest/linux/      pinned guest kernel and initramfs references (checksums only)
tools/            Crystal build, run and Zephyr generator tools
qemu/             QEMU/GLib/U-Boot pins, Crystal build descriptions, generator ports
docs/phases/      one document per phase and per track (T, P, S, C): slices, demo, references
docs/glossary.md  terms used by the plan
docs/             TUTORIAL.md (as-built slice index), threat model, reviews

Working on Glint

Glint is kept in Fossil at https://ollama.openbeagle.org/glint. Runs on the OCX node glint-node commit and push to it. Decisions are recorded in the decision log in PLAN.md, not left in forum threads.

Licence and provenance

Glint's own code is licensed under the Mozilla Public License 2.0. Contributions from others need a Developer Certificate of Origin sign-off. Much of the code is written by AI agents under the maintainer's direction; see CONTRIBUTING.md for the sign-off and the provenance statement.