What InterGenOS Is
InterGenOS is a Linux distribution built entirely from source, designed around a single conviction: the person sitting at the machine should be in control of it. Not the vendor, not a telemetry pipeline, not an auto-updater that changes the system while you sleep. Every package is compiled from source with a deliberate choice behind it, and every default is there to give you a machine you understand, can modify, and can trust.
This page explains the model that shapes those choices, the user-control vision behind them, and — just as important — what InterGenOS deliberately leaves out. It is philosophy, not a command reference. For setup and day-to-day use, see the FAQ and the Forge install guide.
The current version is 1.0-dev (build id v1.0-dev1). InterGenOS is in active pre-1.0 development.
Security is not first. It is only.
Most systems treat security as the top item on a list of priorities. InterGenOS does not have that list. Security is not the first concern competing against convenience, speed, or convention. It is the only lens that gets a veto.
We build assuming adversaries have superhuman vulnerability-discovery capability. AI-assisted vulnerability discovery is treated as a foregone conclusion, not a theoretical threat, and that capability will only proliferate. Under that assumption, the things that get a system compromised are rarely dramatic. They are the quiet ones: a masked error, a blanket “ignore failures,” an unverified “known-good” claim, a feature that shipped degraded instead of fixed. Those are exactly what a capable adversary exploits.
So the working question behind every decision is the same: does this eliminate a silent failure and turn an unverified assumption into a checked gate? If an option masks rather than verifies, it is wrong, and no amount of convenience rescues it.
In practice that means the system is hardened from the moment it boots, not by a script you run afterward:
- A signed boot chain. From a Microsoft-signed shim through GRUB to the Linux kernel and Unified Kernel Images. Secure Boot enforcement is optional and off by default on the current fleet; with it enabled, unsigned kernel modules are not trusted.
- dm-verity integrity. A verified-integrity hash tree is generated over the read-only system image, and its root hash is sealed into the signed kernel command line. A tampered system image cannot boot under a validly signed kernel.
- UKI signing on your own machine. The release-signing key never leaves a hardware token under InterGenOS control. The installer generates a Machine Owner Key (MOK) on your machine, and installed systems re-sign each kernel’s UKI with that key at every kernel install or upgrade. The trust anchor is yours.
- A signed package mirror. The package index is the signed manifest of the whole repository; clients verify the entire index against one signature, and every published archive’s hash is checked locally before install.
- Locked by default. A fresh install ships with no remote access enabled and a default-deny firewall. Server packages bind to localhost unless you deliberately open them. There are no default or blank passwords.
A fuller breakdown of the enforced defaults — AppArmor in enforce mode, systemd sandboxing across daemons, and the build-chain supply-chain protections — lives in the hardening baseline.
A machine you understand, can modify, and can trust
The security model and the user-control vision are not two ideas. They are the same idea from two angles: a machine the user cannot trust is a machine they do not control.
Control begins with transparency. InterGenOS is based on Linux From Scratch and Beyond Linux From Scratch, and every component is compiled from source rather than pulled from an opaque binary you cannot inspect. The build is deterministic by construction — pinned, checksum-verified sources and deterministic ordering — so what you run is what the source tree says you run; full byte-identical reproducibility across independent builders is a documented 1.x goal.
That same preference for the transparent path shows up in smaller, visible ways. There is no boot splash hiding the startup. You watch the kernel hand off to systemd and every service report [OK] or [FAILED]; if a mount breaks or a module misbehaves, you see it the moment it happens. Spotting odd boot output is a real practice for catching a compromise or a hardware change, so we give you that surface instead of covering it with a logo.
InterGenOS ships its own tooling to keep the system legible end to end:
pkm— the package manager. Install, remove, search, verify, and inspect dependencies.- Forge — the system installer. It takes you from partitioning through the signed boot chain to a booted desktop. Forge is InterGenOS’s own installer, not a third-party framework bolted on.
- A signed Secure Boot chain, dm-verity integrity, and UKI signing, all described above — verification you can check yourself rather than take on faith.
The rule that gates all of it: bespoke complexity that hides how the system works is not welcome, no matter how conventional it is. When a clever shortcut and the standard, inspectable path disagree, the inspectable path wins.
What ships today
State things by what is real now, not by what is planned. Today, InterGenOS ships:
- A GNOME 49 desktop on Wayland. Dark theme, InterGenOS branding, Wayland-native.
- Six package tiers — toolchain, core, base, desktop, ai, and extra. As of June 2026 that is roughly 857 package templates across the six tiers (toolchain ~28, core ~272, base ~23, desktop ~420, ai 2, extra ~112). These counts drift as packages are added and revised; treat the live tree as the source of truth, not any fixed number.
- A 20-phase from-source build, in fixed order:
validate → verify-sources → setup → toolchain → chroot-prep → chroot-tools → core → config → core-extra → base → kernel → desktop → ai → extra → bootloader → image → manifest → squashfs → ukis-verity → iso, with an optional publish step. The build always runs through the bootloader, ISO, install, and boot chain, because a clean compile is not the same as a known-good system.
InterGen — the local assistant
InterGen is the onboard AI assistant: tiered, hardware-detected, and offline-first. At setup time it detects the CPU, RAM, and GPU and selects a local model (Qwen) and quantization appropriate to the machine, from a 4 GB laptop up to a GPU workstation. No cloud, no accounts, no round-trip latency, and zero telemetry. It is text-only by design.
What separates it from a generic local-LLM wrapper is the permission model. Every tool call is treated as privileged; the default mode asks for confirmation before any action that modifies system state, tool signatures are pinned against drift across upgrades, and a separate audit log records every invocation. The assistant is a system component, not a hole in the system.
InterGen Sentinel — pluggable security scanning
InterGen Sentinel is a pluggable security-scanner architecture. It routes a tool call through a scanner of your choice before it executes. The default is local-only: Local-Rules (rule-based and deterministic) and Local-Qwen (your local Qwen model reviewing the call), both fully offline.
For richer review you can opt in — explicitly, never by default — to one of six cloud providers: Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek. This Phone-A-Friend (Frontier/Cloud Escalation) path exists because frontier models routinely surface security-relevant findings at scale, and some users will want that capability through a vendor they trust. The user picks which scanner, if any, reaches across the network. Everything else stays on the box, and the schema-pinning, audit logging, and sandbox enforcement are vendor-neutral local plumbing that apply no matter which scanner is active.
What we deliberately exclude
What a system refuses to do is part of its design. InterGenOS leaves things out on purpose:
- No telemetry, analytics, or crash reporting. Zero. There is nothing to opt out of in a settings menu, because the data never leaves the machine to begin with.
- No auto-updates. The system does not change software behind your back. Updates happen when you explicitly run them.
- No silent failures. Every error surfaces. An unverified assumption is turned into a checked gate or it is not trusted.
- No stubs. Placeholder code that pretends to work does not ship. A stub is a lie.
- No proprietary firmware in the core. The core relies on open drivers and firmware. Proprietary blobs are available if your hardware strictly requires them, but they are never forced on you.
- No fixes that only work on a hand-patched box. A change is done only when it lives in the source tree and a clean build reproduces the corrected behavior with zero manual steps. Live-patching is allowed for diagnosis, never as the finished fix.
What is planned, not shipped
To be precise about the line between today and tomorrow: the following are planned and are not part of the current system.
- Switchable desktop environments. v1 ships GNOME on Wayland only. KDE Plasma (Qt6) and other Wayland-capable desktops are planned after v1; the per-tier architecture already supports the split, but they do not ship today.
- Application campaigns. Additional applications are roadmapped (for example creative and productivity tools), but only what is present in the shipping tiers today is current.
When in doubt, trust the running system and the source tree over any roadmap.