Mezzano: a Common Lisp operating system you can boot from a demo image

What Mezzano is, and the problem it addresses

Mezzano is an operating system written in Common Lisp. That single sentence is the whole pitch and the whole constraint. Most operating systems are written in C or a mix of C and assembly, with a small runtime and a thin abstraction over the hardware. Mezzano inverts that: the system layer is Lisp, and the repository layout reflects it. Top-level directories include compiler/, runtime/, supervisor/, drivers/, gui/, net/, file/, system/ and applications/, alongside files such as config.lisp, ipl.lisp and lispos.asd. The .asd extension is the Common Lisp system definition convention, so the build is described in Lisp terms rather than a Makefile.

The audience follows from that. This is for people who want to study or extend an operating system where the language runtime, the compiler and the user interface share one implementation language. The README lists work contributed across releases: a USB stack, EXT2/3/4 support, a GMA950 modesetting driver, hardware accelerated 3D through QEMU's Virgl device, multicore and SMP support, async APIs, DHCP and TCP retransmit, weak hash tables, unboxed structure slots, and short floats implemented as IEEE half floats. Those are the features of a system that is being built, not one that is being supported. Anyone expecting a distribution with an installer and a package manager is looking at the wrong project.

How the system is put together, as far as the repository shows

The directory names describe the architecture better than any diagram would. compiler/ holds the Lisp compiler, and the README notes that Demo 3 introduced a new SSA-based compiler backend supporting unboxed value representations. runtime/ and supervisor/ sit under it. drivers/ covers device support, including the USB stack, the GMA950 display driver and Intel HDA audio. gui/ is the window system, which the README says gained transparency and premultiplied alpha support in the Demo 1 era and more traditional window management in Demo 2. net/ holds the networking stack, and file/ the file systems, with FAT32 arriving by Demo 3 and EXT2/3/4 by the Demo 4 cycle.

The data flow at boot is not spelled out in the README. What is visible is that ipl.lisp sits at the top level next to config.lisp and lispos.asd, and that the source build is delegated to a separate repository, MBuild. The README's instruction for building from source is a single pointer to https://github.com/froggey/MBuild, so the host-side toolchain and the cross-compilation or image-generation steps live there, not here. That split is worth noting: this repository is the system, and MBuild is how you produce a bootable artifact from it.

Conformance work runs through the stack. The README records that the CLOS implementation follows the MOP much more closely than before, that standard-object and structure-object representations were unified, and that Gray streams support was overhauled. For a Lisp user, those details matter more than the file names: they determine whether portable libraries behave the way the specification says they should.

Installing Mezzano: demo image in VirtualBox or QEMU

There is no installer in the usual sense. The README states that demo releases are available through GitHub and that these releases are designed to be run in VirtualBox, though QEMU is also supported. It recommends 2GB of RAM, a virtio-net NIC and an Intel HDA audio controller. x86-64 images are published; the README notes that AArch64 has been made to work on some hardware.

Start by downloading the demo5 release artifact from the project's releases page, then create a virtual machine with the recommended memory and devices and attach the image. The README gives no command line for this. Its own wording for the three settings is short enough to quote directly:

2GB of RAM, a virtio-net NIC and an Intel HDA audio controller are recommended.

After boot, you should land in the Mezzano environment described in the README: a Lisp system with a GUI, an editor, and introspection tools such as DISASSEMBLE and ED that the README says were implemented in the Demo 3 cycle. The README does not document login credentials, a first-run wizard or a recovery path, so if the image does not reach the desktop, the documented route is the #mezzano IRC channel on Libera Chat rather than a troubleshooting guide.

For a source build, the README gives no steps at all. It points to the MBuild repository and says support is available on the same IRC channel. That is the honest state of the documentation: image users get a recommended emulator and a device list, and source builders get a second repository to read.

Where Mezzano stops being the right tool

The README sets expectations bluntly: making Mezzano run on any given piece of hardware or emulator is still typically a project that requires the user to dig into the code. That is not a disclaimer bolted onto a finished product. It describes the support model. If your goal is to run an application on a machine, Mezzano is the wrong layer to reach for, because the work of getting it to boot on your hardware is yours.

The release cadence reinforces the point. The most recent listed release is demo5, dated 2020-07-25; demo4 was 2018-07-28 and demo3 was 2017-04-09. Those are demo snapshots, not a versioned release train with patch releases. The repository itself shows activity later than the last demo (the last push was on 2026-08-16), but the README does not describe a stable branch, a compatibility policy or a migration path between demos. Anyone who builds against the master branch is building against a moving target with no documented rollback.

There is also a hardware ceiling. The README lists drivers for specific devices, such as GMA950 modesetting and Intel HDA audio, and recommends virtio-net and Intel HDA in the emulator. A machine whose network or audio chipset is not covered is a machine where you are writing a driver, not configuring one. The same applies to AArch64: the README says it has been made to work on some hardware, which is a statement about experiments, not about coverage.

How Mezzano differs from a Unix-like hobby system

The closest comparison is a small Unix-like kernel written in C, such as a teaching kernel or a minimal Unix clone. The difference is not the feature list, since both end up with a scheduler, a file system, drivers and a shell. The difference is where the language boundary sits. In a C-based system, the kernel is C, the userland is C, and Lisp, if it appears at all, is a program running on top of the system. In Mezzano, the Lisp implementation is the system. The compiler directory is part of the operating system, not a tool shipped alongside it, and the README's notes on CLOS and MOP conformance are notes about the operating system's own object model.

That has a practical consequence for anyone evaluating the project. Porting a Common Lisp library to Mezzano is not the same task as porting it to a Unix. The README records that Quicklisp was ported by Peter S. Housel and that McCLIM was ported by fittestbits, which shows both that the porting path exists and that it is done by hand, one system at a time. A C-based hobby kernel can lean on decades of POSIX-shaped assumptions in existing code. Mezzano cannot, because its assumptions are Lisp's.

The payoff is introspection. The README mentions DISASSEMBLE and ED as improved introspection tools, source locations tracked for many kinds of definitions, and (ROOM T) printing detailed information about allocated objects. In a C system those facilities are debugger features bolted on from outside. Here they are part of the running image. Whether that is worth the porting cost depends entirely on whether you want to work inside a Lisp image or beside one.

Maintenance, licensing and what a source build costs you

Mezzano is MIT licensed, per the repository's COPYING file. The README also carries attribution for bundled assets: DejaVu Fonts 2.37, some icons from Icojam, and several photographs under CC BY-SA 3.0 and CC BY 2.0 from Wikimedia Commons and Flickr. Those are separate licences attached to separate files, so if you redistribute an image you are redistributing the fonts and artwork with it, and the MIT grant on the code does not cover them. This is a description of what the repository states, not legal advice.

On maintenance, the repository is not archived, and the last push was on 2026-08-16. That is recent, but the demo releases are years apart, and the README does not promise API stability between them. The upgrade cost for a source builder is therefore the cost of tracking master through MBuild: the README gives no upgrade procedure, no changelog beyond the per-demo feature lists, and no documented way to move a working image forward. If you build something on Mezzano, budget for reading the code when it breaks, because that is the documented support path.

For image users the cost is lower and the ceiling is lower too. A demo image is a fixed snapshot. You can run it, explore the GUI and the editor, and use the introspection tools, and nothing in the README suggests you should expect it to receive updates in place.

Editorial conclusion

Mezzano is for Lisp programmers and OS hobbyists who want to read, run and modify a system whose kernel, compiler and GUI are all written in Common Lisp, and who are willing to build through MBuild or boot a demo image in VirtualBox or QEMU. It is not for anyone who needs a supported platform for production work: the README states that making Mezzano run on any given piece of hardware or emulator is typically a project that requires digging into the code. Before investing time, check the release page for the demo5 image, confirm your emulator matches the recommended 2GB of RAM, virtio-net NIC and Intel HDA audio controller, and read the MBuild repository to see what a source build requires on your host.

Frequently asked questions

Official sources

1. froggey/Mezzano on GitHub
2. Issues
3. License: MIT
4. README
5. Releases