Redox OS build system: the mirror that makes disk images, not installs

The GitHub repository is a mirror, and the mirror is the build system

Almost everything famous under the name Redox is not in this repository. The description field reads Mirror of https://gitlab.redox-os.org/redox-os/redox, and the first line of the README states that this repository is the Build System for Redox OS. The kernel is a separate repository on the same GitLab host, and the default filesystem, the POSIX library, the shell, the terminal library, the package manager and the display server each have their own repository too. What lives here is a Rust package named redox_cookbook at version 0.1.0, edition 2024, authored by Jeremy Soller, with default-run pointing at a binary called repo. The tree on branch master holds mk/, recipes/, config/, podman/, bin/ and rust-toolchain.toml. A reader who opens this expecting kernel source finds toolchain instead, and a bug report about the operating system itself filed here lands in the wrong repository.

make all emits harddrive.img while make live emits an ISO

The Makefile splits configuration and dependencies into mk/config.mk and mk/depends.mk, then describes outputs rather than steps you type yourself. The default target builds a disk image, live builds an ISO, image and rebuild both clear old artifacts and unmount two paths before re-entering make, and popsicle hands the finished ISO to a graphical front end called popsicle-gtk. Only rebuild also removes the repo.tag marker, so image reproduces a build of the same sources while rebuild forces that tag to be recomputed. The targets stop at an image file; popsicle only passes the finished ISO to popsicle-gtk.

all: $(BUILD)/harddrive.img

live:
	-$(FUMOUNT) $(BUILD)/filesystem/ || true
	-$(FUMOUNT) /tmp/redox_installer/ || true
	rm -f $(BUILD)/redox-live.iso
	$(MAKE) $(BUILD)/redox-live.iso

popsicle: $(BUILD)/redox-live.iso
	popsicle-gtk $(BUILD)/redox-live.iso

image:
	-$(FUMOUNT) $(BUILD)/filesystem/ || true
	-$(FUMOUNT) /tmp/redox_installer/ || true
	rm -f $(BUILD)/harddrive.img $(BUILD)/redox-live.iso
	$(MAKE) all

rebuild:
	-$(FUMOUNT) $(BUILD)/filesystem/ || true
	-$(FUMOUNT) /tmp/redox_installer/ || true
	rm -rf $(BUILD)/repo.tag $(BUILD)/harddrive.img $(BUILD)/redox-live.iso
	$(MAKE) all

The clean target names the case where the container was never built

Two variables shape what this build system will tolerate. PODMAN_BUILD decides whether commands run inside a container, and NOT_ON_PODMAN defaults to 0 under a comment explaining that it exists to tell the cookbook binary it is not safe to execute. In the clean and distclean targets, the container branch first checks whether CONTAINER_TAG is empty. When it is, make prints will not run cookbook clean as container is not built and recurses into the same target with PODMAN_BUILD=0, NOT_ON_PODMAN=1 and SKIP_CHECK_TOOLS=1. The fallback proceeds with tool checks skipped and, with NOT_ON_PODMAN=1, skips the cookbook clean step while still removing the repo and build directories. Read that message as a warning about your setup, not as a completed cleanup.

The tui feature is default-on and its own TODO says the off switch is unfinished

The Cargo manifest enables a terminal interface by default. The features block sets default to tui, and tui pulls in ratatui, ansi-to-tui and strip-ansi-escapes, with ratatui pinned at 0.30 and configured with default-features disabled and the termion feature selected. Directly above the default line sits a comment reading TODO: Actually make without tui feature works. Taken at face value, the opt-out for the terminal interface does not function yet, so the four binaries cannot be assembled as a plain command line tool. The same manifest sets doctest = false on the library, so documentation examples inside the cookbook library are never compiled or run either.

[features]
#TODO: Actually make without tui feature works
default = ["tui"]
tui = ["ratatui", "ansi-to-tui", "strip-ansi-escapes"]

[[bin]]
name = "repo"
path = "src/bin/repo/main.rs"

Every ecosystem repository in the table names the same maintainer

The ecosystem table closes the README by listing twelve repositories with their maintainers. Every one of the twelve names jackpot51. Nine name only that account: kernel, base, redoxfs, relibc, ion, termion, pkgutils, orbital and redoxer. The build system itself, the Redox Book and the website each name jackpot51 together with hatred_45. That concentration is this repository's real dependency, because several Cargo dependencies do not come from a registry. pkgar, pkgar-core and pkgar-keys are pulled from pkgar.git, redox-pkg from pkgutils.git, redox_installer from installer.git and redoxer from redoxer.git, each straight from GitLab at build time. So the layer this repository compiles sits on top of the kernel, the base drivers, the filesystem and the POSIX layer, and every one of those is carried by the account named in the same row of the same table.

The 0.9.0 tag is more than a year older than the last push

The release list and the branch history tell different stories. Tags 0.9.0, 0.5.0 and 0.3.5 were published on 2025-09-22, 2019-03-24 and 2018-03-21, and the note attached to 0.3.5 calls out a new network stack. The repository is not archived, and the last push on master is dated 2026-09-27, well after the newest tag. The manifest version carried on that branch is 0.1.0, which matches none of the three releases. The practical consequence is that version numbers tell you almost nothing about what a build contains. Anyone pinning to 0.9.0 is working from sources more than a year behind the branch that the build system actually compiles, and anyone reading version 0.1.0 has no tag to compare it against. Commit dates are the only reliable signal here, including the gap between 2019-03-24 and 2018-03-21 that separates the two older tags.

The repository answers neither where to install it nor whether it fits your hardware

Two questions a newcomer arrives with cannot be answered from these files: where do I install it, and will it run on my machine. Both are routed away from the repository. Trying out Redox, running in a virtual machine and running on real hardware each have their own page in the Book, hardware compatibility is documented separately, and building has the same shape with a podman build page, a build system reference and a developer FAQ linked out. A HARDWARE.md file does sit at the top level of the tree, and the README links hardware compatibility to a page in the Book. What this repository holds instead is podman/, podman_bootstrap.sh, native_bootstrap.sh, flake.nix and flake.lock, which point to container, native and Nix build setups. Reading the source gives you the machinery and none of the answers about using what it produces.

Editorial conclusion

Treat redox-os/redox as the toolchain behind the Rust operating system, not as the operating system itself. Contributors who need the kernel, the filesystem or the POSIX layer will find those in separate repositories, and anyone who wants Redox on a machine has to follow the Book for the virtual machine and hardware pages rather than anything in this tree. Before committing to a build, check whether the podman container you need actually built, because the clean target then prints that it will not run cookbook clean and falls back to a host-side cleanup with tool checks skipped. Pin by commit date rather than by tag, since the newest release predates the last push on master by more than a year.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. redox-os/redox on GitHub
5. Releases