PengyOS

# What is PengyOS?

An operating system that is assembled, not derived: every component is chosen on its own merits and justified in writing, the whole system rebuilds from pinned sources, and the result is attested. It keeps Linux and the shared contracts — POSIX, ELF, systemd unit semantics, D-Bus, Wayland, freedesktop — and replaces only what earns replacement.

The genuinely new part is the process

PengyOS is curated and maintained by a continuous human–AI partnership. An agent observes upstream releases and advisories, drafts changes with justifications, builds them reproducibly, and verifies them — but a human signs the security boundary. Release signing, update acceptance and privilege changes never happen without independent verification and a person's sign-off. A system that maintains itself must never be able to silently change its own trust root.

One base, three additive layers

        ┌──────────────────────────────────────────────┐
        │  DESKTOP   = Server + graphical stack + apps  │   the masterpiece
        ├──────────────────────────────────────────────┤
        │  SERVER    = Core  + remote-work + services   │   headless, comfortable
        ├──────────────────────────────────────────────┤
        │  CORE      = the shared, minimal, bootable base│   tiny, builds on it
        └──────────────────────────────────────────────┘
             (all three share one build engine + one verification layer)

Core is the exact base the other two are defined on — not a cut-down subset. A Desktop component never contradicts a Core decision; it only adds. Each edition is a Buildroot target with its own defconfig and board, driven from a single targets.toml.

# The Three Editions

Three editions — four images, counting Desktop NVIDIA — one build engine, one verification layer. This is where each one stands today.

What's inside the base

Applications extend the OS through four lanes, layered by trust: recipes built from source (the default) → upstream artifacts pinned by hash → Flatpak and AppImage sandboxed apps → compatibility guest containers for anything that only exists as a deb or rpm. Proprietary pieces are the exception, not the rule: where hardware needs them (NVIDIA's driver, device firmware) they ship in plain sight, in their own image or package, and are documented — a working machine beats a pure one.

# Status & What's Next

Every edition installs and boots; the release pipeline is what's left.

# How It Maintains Itself

The same loop the rest of the fleet already runs — observe, propose, build, verify, and a human at the boundary — applied to an operating system.

Immutable at the base, mutable at the surface

A live fix is the exception that improves the spec: the agent diagnoses, applies a Tier-1 change, and the fix is captured back into the declarative definition — so the same surgery is never needed twice, and reproducibility is preserved because the definition grew.

# Principles

These are the laws of the project. When in doubt, they decide.

# The Toolkit

The build and maintenance toolkit is essentially complete: 83 tested tools, each a bounded project with its own suite.

Build it yourself

# 0. provision a build host (once, idempotent)
sudo scripts/provision-behoserver.sh

# 1. build an edition — e.g. Core (M2)
cd tools/pengyos-build
python3 -m pengyos_build list  --targets ../../targets.toml
python3 -m pengyos_build build pengyos-core-m2 --targets ../../targets.toml

# 2. boot it headless under QEMU/KVM (UEFI)
cd ../pengyos-qemu-verify
python3 -m pengyos_qemu_verify boot \
    ~/build/pengyos/output/pengyos-core-m2/images/pengyos-m2-x86_64.img --uefi

The verified build host is an x86_64 Linux box with about 16 GB of RAM. Targets are declared in targets.toml.

# Downloads

Nothing to download yet — no images have been published.

# Documentation

Stubbed for now — the documents exist, but they are not published on the web yet.

# Updates

Live at pengyos.catbee.ca/update — on the testing channel while the first releases settle.