schema-init: a PID 1 written in C that boots Fedora 44 KDE. It imports your systemd units and keeps systemd in GRUB as a fallback (installer ISO)
▲ 0 r/linux

schema-init: a PID 1 written in C that boots Fedora 44 KDE. It imports your systemd units and keeps systemd in GRUB as a fallback (installer ISO)

I'm a plumber by trade. After I became disabled I started dabbling in code, and over the past few months that turned into schema-init, an init system (PID 1) written in C that I build and run on Fedora. To be upfront: I design it, run it on my own machines and break it on real hardware, and Claude fills the enormous gaps in my knowledge and writes much of the code. Every claim below is something I tested on my own hardware.

**Why: I kept running out of memory with only a few browser tabs open, on a machine with 16 GB of RAM. That's what started schema-init. Now, on the same hardware with no RAM upgrade, I can play Cyberpunk 2077 with 15–20 Helium tabs open and Claude running at the same time. Part of that is a smaller base system, and part is that schema-init watches memory pressure and freezes or reclaims background services before the kernel has to start killing things.

**It's not an anti-systemd project.** It reads systemd's own unit files and translates them, and the stock systemd boot entries stay in GRUB. If a schema-init boot ever fails, you pick the systemd entry and you're back on stock Fedora.

v0.4.5 is out, with an installer ISO you can try on a spare machine.

**What it is:** the Fedora 44 Everything netinst plus a kickstart. You get the normal Anaconda GUI. Pick your disk, make your user, install. After install:

- schema-init boots as PID 1 and brings up a full KDE Plasma Wayland desktop.

- The services Fedora enables by default (cron, firewalld, smartd, tuned, the systemd timers) are imported at install and run under schema-init.

- A first-boot wizard offers two optional switches, one reboot each: **schema-udev** (device manager) and **schema-dbus** (a broker for the system and session buses). Each one checks the box afterwards and rolls itself back if it isn't healthy.

- It's all RPMs from a COPR repo. `dnf upgrade` re-execs PID 1 in place, with every running service adopted and no reboot.

- When an RPM enables a systemd unit, a `systemctl` shim catches it and translates it to schema-init's service format. That covers timers, `EnvironmentFile=`, `ExecStartPre=`, socket activation, `Condition*` and forking daemons.

**My daily driver** runs it: a Ryzen 5 1600 with a GTX 1050 Ti on NVIDIA Wayland, and 89 logged boots since July. On its latest boot, userspace was up in 8.9 s and the login screen appeared 2.9 s after PID 1 started, with 53 services. PID 1 itself uses about 4 MB of RAM, and at idle it wakes up 0–5 times per 10 seconds.

**Numbers from an HP laptop** (Celeron, 5400 rpm HDD, Intel graphics, Wi-Fi; an older build, 3-boot medians, details in the README):

- Stock systemd vs schema-init: the desktop drew **4.4 s sooner**, idle RAM was **373 MB lower** (1477 → 1104 MB), and **54 fewer processes** were running.

- In a separate comparison on the same box, swapping dbus-daemon for schema-dbus took another **6.6 s** off desktop-ready.

It's a slow disk, so take the seconds with salt. The RAM and process counts are the solid part.

**Since the first ISO (v0.4.2):**

- Installs now get the services systemd would have run. v0.4.2 installs were missing cron, the firewall and the timers.

- udev runs supervised, so a crash gets respawned instead of leaving devices frozen until reboot.

- Fixed a udisks crash at boot on machines with a CD/DVD drive.

- `dnf upgrade` now repairs older installs in place.

Those were tested with fresh VM installs and a live upgrade on the HP laptop. The v0.4.2 ISO was the one fully installed on that laptop.

**EXPERIMENTAL.** Put it on a machine you can reinstall. Bug reports and "this broke on my hardware" are the most useful thing you can give me.

- Release + ISO: https://github.com/ajax80/schema-init/releases/latest

- Source (AGPL-3.0): https://github.com/ajax80/schema-init

Edit: A couple of things I should have said up front:

- The RAM numbers were taken with a few browser tabs and a game open, not on an idle desktop.

- I build with AI help. Every change gets tested in a VM, then on real hardware, before it ships. The tests and the code are public, so judge it by those.

u/apphat80 — 8 days ago
▲ 3 r/Fedora

Schema-init now runs a full KDE Plasma 6 (Wayland) session on Fedora 44 at ~1.2 MiB RSS — here is what the last four days of development added

Hey everyone,

Following up on the initial Plymouth boot splash integration on AMD hardware (original thread here;

https://www.reddit.com/r/Fedora/comments/1twaxmo/fedora_44_kde_plasma_booting_under_a_custom_pid_1/

we’ve pushed some massive architectural upgrades to master. The engine has transitioned from a minimal boot setup into a highly resilient, daily-driver capable supervisor layer.

Here is what the active top profile looks like right now running a full, live KDE Plasma 6 workspace on Fedora 44:

  • PID 1 Resident Memory (RES): 1264 KiB (~1.2 MiB)
  • PID 1 Virtual Memory (VIRT): 1748 KiB (~1.7 MiB)
  • System Swap: 0.0 Byte allocated / 0.0 Byte used

What the Delta Added:

  • Zero-Downtime Dynamic Reloads (SIGHUP): You can now reload .svc service configurations on the fly without rebooting or dropping the graphical userland. It parses changes into a double-buffered shadow graph, validates dependencies, frees old allocations with zero leaks, and applies changes atomically. It also supports automated eviction (schema-ctl reload --evict) with a 3-second grace window before cgroup cleanup.
  • Hard Cgroup Resource Limiting: To prevent an application or background process from stealing CPU cycles or causing an OOM-killer panic on the desktop, schema-init now reads cpu_limit= and mem_limit= keys directly from the service file. It locks these boundaries down via /sys/fs/cgroup/ in the parent process during a strict sync-pipe window before the child process ever executes, completely eliminating spawn-time resource spikes.
  • Deterministic Env Injection: We’ve eliminated messy runtime shell-sourcing wrappers. Environment variables are parsed cleanly by PID 1 on milestone completion (STATE_PERFECT) during the native process reaping cycle and passed right via execv().
  • Tamper Detection (FNV-1a Hashes): The engine tracks integrity hashes on the service configuration files. If a service configuration is tampered with or corrupted on disk, the reload cycle catches the mismatch and aborts safely to keep the running desktop stable.
  • The "Infinite Loop" Watchdog Fix: We patched a critical edge case in the event loop scheduler. Previously, if all services reached their stable state, the engine would block indefinitely to preserve CPU. Now, the engine utilizes a unified, non-blocking polling sequence that ensures background hardware paths, ready-paths, and watchdogs are actively supervised even when the desktop is completely idle.

The core logic remains strictly written in minimal, auditable C with zero runtime complexity bloat. It proves you don't need a massive, monolithic service manager to run a completely modern, fluid Linux desktop experience.

The updated walkthrough and source code are live here for anyone wanting to break away from standard systemd layers on Fedora:https://github.com/ajax80/schema-init

reddit.com
u/apphat80 — 4 months ago
▲ 7 r/linuxfromscratch+1 crossposts

Running a custom PID 1 on Fedora 44 with KDE Plasma — Plymouth, avahi, and chronyd without systemd

We've been building schema-init — a statically linked C PID 1 that supervises

services through a weight-state machine. No systemd, no OpenRC, no journal daemon.

892 KB RSS, 1 thread.

Today we got Plymouth working on a Fedora 44 / KDE Plasma machine with an AMD

Picasso/Raven 2 GPU. A few things worth sharing for anyone doing similar work:

**Plymouth plugin matters**: The `script` plugin fails silently on this AMD DRM

config. No error, just black screen. `two-step` with pre-rendered PNG frames works.

**The TTY echo race**: Plymouth restores termios on exit, re-enabling kernel echo

before your post-Plymouth script can run. Any buffered keypresses get printed to

tty1 in that gap. Fix is `stty -echo` both before and after `plymouth --wait quit`,

then `tcflush` + `clear`.

**Services you take for granted**: Without systemd, avahi-daemon and chronyd don't

start automatically. Everything needs an explicit .svc file. We're building out the library — avahi and chrony added today.

All documented: github.com/ajax80/schema-init

distros/fedora-kde/README.md has the full install walkthrough.

u/apphat80 — 4 months ago