MOROS is a Rust operating system with a real device stack and a command line instead of a desktop

A command line environment, not a desktop, in a codebase that fits in one repository

MOROS describes itself as a text-based hobby operating system written in Rust, targeting computers with an x86-64 architecture and a BIOS. The stated inspirations are Unix, Plan 9 and DOS, and the goal is a simple environment for computing and communication from the command line. That framing matters when you judge the project. There is no graphical shell, no window manager and no package manager, so anyone expecting something that can replace a Linux installation on a laptop is looking at the wrong project. What the repository does contain is a breadth of low level subsystems that most hobby kernels never reach: paging with a bitmap frame allocator, processes with isolated address spaces and demand paging, a userspace with syscalls and device files, a custom filesystem with bitmap allocation and linked blocks, and a network stack with DHCP, IP, TCP, UDP, DNS and HTTP. All of that lives in a tree whose top level entries include src, doc, dsk, run, www, a Makefile, a Cargo.toml and per architecture files named x86_64-moros.json and i686-moros.json.

The device list reads like a checklist of what an OS is expected to support

The feature list in the README is the clearest evidence of the project's scope, and it is worth reading closely rather than skimming. On the hardware side there is an external bootloader using the rust-osdev bootloader crate, AMD64 support through the x86_64 crate, a PS/2 keyboard with customizable layout via pc-keyboard, VGA text mode plus a 320x200 graphics buffer for games and images with a customizable font and color palette, serial output through uart_16550, an Intel 8259 PIC, PCI devices, ATA PIO mode, an AC97 and an SB16 sound card, and support for Intel PRO/1000, RTL8139 and AMD PCNET network cards. On the system side there is heap allocation through linked_list_allocator, ACPI shutdown through the acpi and aml crates, an RTC clock with userspace NTP synchronization, and a random number generator using rand_hc. It is a long list, and it is the sort of breadth that comes from following a structured tutorial path rather than from a product roadmap. The stack of well known crates is the mechanism here: smoltcp supplies the network protocols, and the acpi crate handles power management.

Building an image and booting it under QEMU takes three commands

MOROS runs on x86-64 computers from around 2005 to 2020 and on emulators such as Bochs, VirtualBox and QEMU, with QEMU being the main development platform. The host needs git, gcc, make, curl, qemu-img and qemu-system-x86_64. Cloning and entering the repository is the first step.

$ git clone https://github.com/vinc/moros
$ cd moros

The next step installs the toolchain, and the README gives a make setup target that expands to the rustup bootstrap, a toolchain check and the bootimage crate install.

$ curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain none
$ rustup show
$ cargo install bootimage

After that you build a disk image and launch it.

$ make image output=video keyboard=qwerty
$ make qemu output=video nic=rtl8139

The build takes output and keyboard variables, and the runtime takes output and a NIC model, so the same source tree can produce a VGA session with a QWERTY layout or a serial-only session with an RTL8139 adapter. The test suite runs the same way, inside the emulator rather than on the host.

$ make test

The optionality of output and nic is a small design detail that makes the project usable on a laptop without KVM acceleration.

The Makefile exposes the hardware choices as plain variables

Much of MOROS behaviour is decided by Makefile variables, which makes experimenting cheap. The compilation options are output, which can be video or serial, and keyboard, which can be qwerty, azerty or dvorak, with mode defaulting to release. Emulation options cover arch, set to x86_64 or i686, cpu defaulting to core2duo, smp at 2, memory at 32, and a nic variable accepting rtl8139, pcnet, e1000 or ne2k_pci. Sound selection is sb16 or ac97, audio backend is sdl or coreaudio, and the bootloader can be rust, limine or grub, with a separate bootloader protocol variable for limine or multiboot. A Rust Cargo package publishes a matching set of features, with default = ["video"] and also serial, userspace, limine and multiboot. The build script also derives a version string from git describe, which means a release build is stamped from the tag it was made from rather than from a hardcoded number.

The filesystem does not exist until you type install, and there is no USB driver

This is the part of the setup that trips up newcomers. When MOROS boots and finds no filesystem, it opens a console in diskless mode. The install command sets up the filesystem on a hard drive, which lets you leave diskless mode and log in as a normal user. Running natively on real hardware means writing the bootloader and the kernel to a drive with dd, and the README points at target/x86_64-moros/release/bootimage-moros.bin as the source image. The same README warns twice about consequences: be careful not to overwrite the hard drive of your own operating system when using dd inside your OS, and equally careful with install or disk format inside MOROS if you are not in an emulator. There is also a structural gap in native mode. There is currently no USB driver, so the filesystem will not be available in that case. In other words, the media you wrote with dd is not yet the media the filesystem lives on, which is a real constraint on anyone wanting to run MOROS on bare metal rather than in QEMU.

Userspace Rust programs are linked into their own address region

The userspace side of MOROS is not a mock. The Makefile builds user programs from src/bin with cargo rustc using a release profile, no default features and the userspace feature enabled, then links them with a linker override that sets the text, rodata and bss segments to fixed addresses starting at 0x8000800000, and strips the result with a platform-appropriate strip command, x86_64-elf-strip on Darwin and strip elsewhere. The comment in the build file explains why: userspace programs are linked inside the user memory region, which lives in its own L4 page table entry. The kernel exposes syscalls and device files, so a user program talks to hardware through the same file oriented interface a Unix system uses. The userland also carries a shell and a Lisp interpreter, a text editor and an assembler, along with a set of file and network commands and a collection of games that includes DOOM. The 320x200 graphics buffer with a customizable font exists partly so that those games have somewhere to draw.

A kernel that began as a tutorial exercise, now with a refactor in flight

MOROS started from the seventh post of the second edition of Writing an OS in Rust by Philipp Oppermann, and the stated aim is to demonstrate what can be achieved after completing an OSDev tutorial while reading the OSDev wiki alongside many open source kernels. That lineage explains the structure: the Rust toolchain, the x86_64 crate, the external bootloader, the userspace with its own linker script. The project is not archived and the last push was on 2026-10-15, with the most recent tagged release being MOROS 0.13.0 on 2026-06-22, preceded by 0.12.0 on 2025-09-21 and 0.11.0 on 2024-12-21. The notable caveat sits in a note near the top of the README: the kernel is currently being refactored to support the i686 architecture in addition to x86-64. The i686-moros.json and x86_64-moros.json files at the top level, and the arch variable in the Makefile, show that this multi architecture work is under way rather than finished. The licence is MIT, and a moros crate is also published on crates.io.

Editorial conclusion

MOROS suits people who want to study a complete operating system in one repository, or who want a Rust environment to experiment with filesystems, paging and userspace without leaving an emulator. It does not suit anyone needing a general purpose desktop, and the i686 work plus the missing USB driver show how much of the platform is still in progress. Before adopting it for anything, check that your machine or emulator matches the listed x86-64 range from around 2005 to 2020, and be aware that the filesystem only exists after you run install, since MOROS boots diskless without it. The MIT licence is permissive, and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vinc/moros on GitHub