Straight answers.
Every default in FoundryOS was an argument somebody had to win. Here's the reasoning — no evangelism, no diplomacy. The formal record lives in the decisions matrix; this page is why it felt obvious.
Why Debian?
Because boring is a feature.
Debian Stable is the most audited, most mirrored, most institutionally trusted substrate in free software. When your base layer's job is to never surprise you, you pick the project whose entire culture is built around not surprising you. Everything interesting FoundryOS does sits on top of that — none of it replaces it.
Why freeze the base instead of rolling?
Because a rolling release makes every morning an upgrade gamble.
Rolling distros are fresh everywhere — including the one layer where a surprise costs you the whole machine: the one that boots it. FoundryOS inverts that. The base is frozen and snapshotted, and freshness lives in layers above it, where a failure is an inconvenience instead of an outage. A package belongs in the highest layer that can host it. That's the whole architecture.
Why do security updates apply themselves when everything else asks first?
Because a known CVE on your disk is worse than any change a security patch might make.
Security fixes from the Debian security archive apply automatically — and only those: the updater is pinned to the Debian-Security origin, so stable maintenance and feature updates can never ride along. And even automatic runs inherit the snapshot-first rule, so if a security patch somehow breaks something, you roll it back from the bootloader like anything else. Consent for change, automation for defense.
Why Flatpak?
Because it won. It survived the winter.
A decade of packaging wars produced exactly one app format that's distro-agnostic, sandboxed by design, backed by the desktop upstreams, and — decisively — where the applications actually are. We didn't pick a side; we acknowledged the outcome. Your browser and IDE come from Flathub at the newest layer of the stack, and the frozen base never has to know.
Why dark mode by default?
Because it won, too.
Most people who get a choice choose dark, so dark is the default and gets designed first — the brand, the apps, the boot splash. But default-first doesn't mean only: every first-party app is built and screenshot-tested in both schemes, and even legacy GTK3 apps get synced to your choice. Light mode is a first-class citizen; it just doesn't get to be the assumption.
Why Crucibles?
Because “just try it” should not be a security decision.
Every developer machine slowly fills with the residue of things tried once. A Crucible is a sealed, disposable workspace — rootless, no daemon, no access to your files unless you explicitly share a folder — so trying software costs nothing and keeps nothing. Delete it and it never happened. The base system never meets the experiment.
Why does Active Directory actually work?
Because the button was already there — it just didn't do anything.
GNOME has advertised enterprise login in its UI for years, and on most distros that button is a trap: click it, watch it fail, then spend an afternoon conjuring realmd, SSSD, and Kerberos configs in a terminal to make it “maybe” work. House rule here: any feature the UI advertises works on a base install. FoundryOS ships the whole join stack preconfigured, and Foundry Control's Domains page shows the join status plainly — with verify and repair one click away, not one wiki-dive away.
Why first-class smartcard PKI?
Because we were the users nobody built it for.
PIV cards, CACs, and YubiKeys are daily reality for developers, government workers, and students — it's a thing now, not an enterprise exotic. On most desktops it's still an afternoon of packages and browser trust-store incantations: second-class support for a common technology. We're the provider now, so we get to do better: Foundry Control registers your card into your browsers per-toggle — Chromium family in one shared store, Firefox family per profile — and it never touches how you log in to the machine. Bloat is out; completeness is in.
Why not an immutable image OS?
Because apt still matters, and agency is the point.
Image-based systems get their safety by taking your system away — you get the layers the vendor built, and everything else is a workaround. FoundryOS keeps the mutable Debian system people actually know, and makes every mutation reversible instead: snapshot before change, roll back from the bootloader, self-heal on repeated failure. Same safety property, achieved without confiscating the machine.
Why Btrfs and snapper instead of something fancier?
Because the boring combination is the one that's in the kernel.
Btrfs snapshots are in mainline, snapper has been shipping in production for a decade, and grub-btrfs makes snapshots bootable from the menu you already have. No out-of-tree filesystem, no custom boot stack, no licensing asterisk — just proven pieces composed carefully and then actually tested on every release.
Why is the AI assistant off by default?
Because trust is something you give, not something we assume.
The diagnosis engine that ships on is deterministic — rules, journals, and diffs, no model, no network. The AI reasoner on top is optional, off until you enable it, and runs on-device or on your own LAN. With it off, nothing about your system goes anywhere. An OS should be private by construction, not by promise.
Why isn't TPM auto-unlock just on?
Because convenience should never quietly weaken the lock.
FoundryOS detects your TPM and tells you plainly what it supports. TPM 2.0 auto-unlock is built on systemd-cryptenroll and adds a keyslot — your passphrase always remains, never replaced, never stashed on disk. The affordance is being rolled out deliberately rather than flipped on everywhere, because disk encryption is the one place “move fast” is the wrong instinct.
Why is there no override flag on the release gate?
Because any override eventually gets used.
The publish pipeline refuses to sign a release unless a real, fully-encrypted, headless install — rollback exercised — passed on that exact commit. There is no --force. The tests behind the gate are cryptographically sealed so nobody, human or AI, can quietly rewrite a failing check into a passing one. A safety property with an exception is a suggestion.
Why is the installer driven through the accessibility tree?
Because accessibility that gates releases can never quietly rot.
Every gated install is performed through AT-SPI — the exact interface a screen reader uses. That's not a testing trick we're borrowing; it's the point. If the installer stops being navigable by assistive technology, the release gate goes red and nothing ships. Most projects treat accessibility as a checkbox audited occasionally; here it is load-bearing infrastructure, verified on every single release by construction.
Why GNOME, and only GNOME?
Because one desktop done rigorously beats five done adequately.
Every FoundryOS release is validated end-to-end — installer driven through the accessibility tree, apps screenshot-tested light and dark, boot health checked. That bar is only holdable for one desktop. GNOME on Wayland is the one with the strongest upstream momentum and the accessibility stack our own test harness is built on. Spins multiply surface area; we'd rather multiply proof.
Disagree with one of these? Good — that's what bug reports and the eventual IRC channel are for. Every answer above is falsifiable against the source, which opens with 1.0.