ajax80/schema-init
DevOpsLive in productionA minimal PID 1 init system for Linux that supervises services through a weight-state machine instead of unit files and dependency graphs.
A single 892 KB static binary as PID 1 for Linux — services supervised through a weight-state machine, no systemd. Frees ~500 MB RAM and lets the CPU reach 95%+ deep sleep on the same hardware.
- C47.8%
- Python29.5%
- Shell21.9%
- Makefile0.7%
- Dockerfile0.2%
1 Review
schema-init is a fascinating and ambitious systems project: a minimal Linux PID 1 written in C that replaces the usual unit/dependency model with a probe-driven weight-state machine. The README does an unusually strong job explaining both the philosophy and the practical mechanics: service states like NEW_PROCESS, FULL_TRUST, FUNDAMENTAL, DORMANT, and EXCISED; simple .svc files; readiness via ready_path; timers through on_boot_sec / on_active_sec; and runtime control through schema-ctl. The codebase is also refreshingly direct: core behavior is split across init.c, schema.c, service.c, and group.c, with helper binaries for control, subreaping, and journald-compatible log ingestion. The distro profiles for Fedora KDE, Fedora Cinnamon, Debian Cinnamon, and Raspberry Pi Zero W make the project feel much more real than a toy init experiment, especially because the docs include hard-won integration notes around D-Bus, logind compatibility, udev, NetworkManager, desktop sessions, zram, and Pi WiFi boot sequencing.
The strongest part of the repo is how much operational thinking is already encoded into it. Features like cgroup CPU/memory limits, priority classes, watchdog petting via schema-ctl pet, slot gating for hardware deployments, shared-memory status, JSON/KV telemetry, service groups, and boot timing output show that the author is thinking beyond “can PID 1 spawn processes?” and toward supervised, inspectable systems. The included IEC 62304 skeleton and scripts/verify_traceability.py are also notable; the traceability verifier passes and reports full requirements-to-test mapping coverage, which is rare in hobby or early-stage systems projects.
The main improvement area is verification depth. I found traceability checking, design docs, and review notes, but not a conventional automated test suite for the C state machine, service parser, dependency resolver, control socket protocol, timer behavior, or failure transitions. For a PID 1 replacement, small unit tests and simulation tests would add a lot of confidence, especially around edge cases like dependency cycles, malformed .svc files, restart backoff, cgroup failures, and reload behavior. The README is rich but could benefit from a shorter “quick start in a VM/container” path, because the current documentation is dense and partly tied to specific machines and distro setups. I also could not complete a local Docker build here because Docker Desktop’s Linux engine was not running, though the repo does include a Dockerfile and simple Makefile targets.
Overall, this is a serious, personal, technically distinctive project with a clear identity. It is not production-ready in the conservative enterprise sense yet, but it has real architecture, real boot targets, thoughtful compatibility work, and unusually detailed documentation. With stronger automated testing and a cleaner first-run demo path, schema-init could become a very compelling lightweight init experiment for embedded Linux, alternate desktops, and systems researchers.
in four days my repo has grown....yet Thank you — this is one of the most careful reads schema-init has gotten, and you clearly went through the actual code, not just the README. That means a lot for a solo, self-funded effort. You're right about the main gap, and I won't pretend otherwise: the verification story is integration-first, not unit-first. There's a QEMU harness that boots the real binary as PID 1 and gates every change — but the state machine, the .svc parser, the control-socket protocol, timer transitions, and the failure arcs (EXCISED/RECOVERY, restart backoff, dependency cycles, malformed units, cgroup failures) all deserve dedicated unit + simulation tests. That's the next investment. For a PID 1, confidence has to be earned, not asserted. The "quick start in a VM/container" point is fair too — the docs grew up bound to my own machines. A distro-agnostic first-run (boot it in QEMU or a container in under a minute, no hardware) goes on the list right behind tests. (And no worries on the Docker build — that was just your local engine being down; the Dockerfile's fine.) For context, it's moved a fair bit even this week: the systemd-compat surface now answers systemctl, journalctl, Cockpit, logind and timedatectl, and it hosts Docker/containerd with no systemd underneath. Still not enterprise-hardened — you called that exactly right — but it's my daily driver across a five-machine fleet, and that compat surface is where most of the active work lives. Genuinely grateful for the time. Reviews like this are how it gets better.