InterGenOS

A Linux distribution built entirely from source with a custom package manager, a tiered local AI assistant, and integrated AI-driven security auditing.

Website · Documentation · InterGen Studios

InterGenOS puts the user in control of their own machine. Every package is compiled from source with deliberate choices. Every design decision serves one purpose: giving people a system they understand, can modify, and can trust.

InterGen, the local AI assistant, doesn't just help you use your system — it helps you understand and secure it. Hardware-detected tiers run it on everything from a 4 GB laptop to a GPU workstation, fully offline. InterGen Sentinel — its pluggable security-scanner architecture — routes MCP traffic through your choice of scanner before it reaches a tool. A local-only default (Local-Rules rule-based + Local-Qwen InterGen-LLM-backed via your local Qwen model) ships ready to go. Six cloud providers are opt-in: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, and DeepSeek. Frontier AI models in 2026 routinely surface security-relevant findings at scale — pluggable cloud routing lets users opt into that capability through whichever vendor they trust. The user picks which (if any) reaches across the network.

Screenshots

GNOME 49.4 on Wayland with the InterGenOS shell theme.

Desktop ships with the Papirus-Dark icon theme as default; the Cybernetic Blue icon theme by SethStormR is included as a featured alternate, switchable via Settings → Appearance or the first-boot welcomer.

Security-Only Alignment

InterGenOS is built for a world where AI-assisted vulnerability discovery is a foregone conclusion, not a theoretical threat. Recent frontier-AI evaluations have demonstrated working-exploit yields two orders of magnitude above the previous generation, with broad benchmark coverage across major operating systems and browsers — and that capability will proliferate. We build this distribution assuming adversaries have superhuman vulnerability discovery and make every design decision with that in mind. Secure Boot is mandatory. Every package choice is a security choice. Nothing that hides how the system works gets shipped.

Security is not first. It is only.

The Prime Directive

InterGenOS exists to put the user in control of their own machine. Every design decision, every default, every included component must serve this purpose: giving people a system they understand, can modify, and can trust. Any complexity that doesn't serve the user — or that hides how the system works — is not welcome, regardless of how conventional it may be.

The Prime Directive and the security-only alignment above are complementary: a machine the user cannot trust is a machine they do not control.

Features

• Built from source — Based on LFS 13.0 / BLFS 13.0, every component chosen deliberately
• Custom package manager (pkm) — Natural-language CLI with SQLite + text manifest hybrid storage
• System installer (forge) — TUI-based installer powered by pkm, from partition to bootable desktop
• Custom build system (igos-build) — Python orchestrator with YAML templates, dependency resolution, and full build logging
• BLFS package database — 1,030 packages with 3,948 dependencies queryable via SQL, plus a meson feature database for auditing build options across packages
• 5-distro kernel convergence — kernel config derived from Ubuntu, Fedora, Arch, Debian, and openSUSE consensus (3,434 universal options)
• GNOME desktop — Wayland-native with dark theme and InterGenOS branding
• Transparent boot — no Plymouth splash. You watch the kernel hand off to systemd and every service start with [OK]/[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 compromise or hardware change — we give you that surface rather than hide it behind a logo. See docs/users/desktop-experience.md.
• Forge Secure Boot chain — signed shim → MOK-signed GRUB → MOK-signed kernel → MODULE_SIG_FORCE=y modules. The user's own MOK key is the trust anchor; the installer generates it per machine. See SECURITY.md.
• Test harness — 375 tests in installer/tests/ covering installer backend, MOK validation, and Class 1 signing-chain verification; Phase A scaffold for GRUB check_signatures=enforce empirical validation. Additional preflight, repo-publish, SBOM, upstream-check, and download-sources test suites live under tests/.
• Extra tier — 112 packages spanning seven install-helpers for proprietary software (Brave, Chrome, Claude Code, Discord, Edge, Spotify, VS Code) plus open-source applications (Firefox, LibreOffice, Audacity, GIMP, Inkscape, Thunderbird, MPV, Rhythmbox, Transmission), the Rust CLI suite (ripgrep, bat, eza, fd, hyperfine, just, starship, zoxide, and more), and container runtimes (podman, crun, conmon, netavark). Proprietary packages are fetched transparently via pkm.
• InterGen — tiered local AI assistant with permission-gated tool calling, D-Bus activation, and a local LLM stack (llama.cpp). Hardware-detected, fully offline. Text-only by design.
• InterGen Sentinel — Pluggable security-scanner architecture. Local-Rules (rule-based, deterministic) + Local-Qwen (InterGen-LLM-backed via your local Qwen model) ship by default, fully offline. Six cloud providers are opt-in: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, DeepSeek. Schema-pinning, audit logging, and sandbox enforcement are vendor-neutral local plumbing — they apply regardless of which scanner is active.

Meet InterGen

Meet InterGen — your onboard AI assistant. Fully offline, hardware-aware, and built to understand the specific machine it's running on. At intergen setup time, InterGen detects your CPU, RAM, and GPU, then picks an LLM and quantization appropriate to the machine — from a 4 GB laptop on up to a GPU workstation. No cloud, no accounts, no round-trip latency.

What separates InterGen from a generic local-LLM wrapper is the permission model. Every tool call is treated as privileged: the default escalation mode is ask, requiring user confirmation before any action that modifies system state. Tool signatures are pinned against drift between upgrades. A separate audit log captures every tool invocation for after-the-fact review. The AI is a system component, not a hole in it.

InterGen Sentinel routes every MCP tool call through a security scanner of your choice before it executes. The default is local-only: Local-Rules (rule-based, deterministic) and Local-Qwen (your local Qwen model reviewing the call). For richer review, opt into any of six cloud providers: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, and DeepSeek. The user picks which (if any) reaches across the network; everything else stays on the box.

See intergen(1) for the full command surface and /etc/intergen/config.yml for the default configuration.

Tools

Tool	Purpose
pkm	Package manager — install, remove, search, verify, depends
forge	System installer — partition, deploy archives, configure, boot
intergen	Natural-language CLI to the InterGen AI assistant daemon
igos-build	Build system — source to archives with dependency resolution
blfs-query	BLFS database query tool — deps, gaps, chain-cost, versions, meson-flags, meson-audit
populate-meson-db	Meson feature database populator — parses options from source tarballs

Package Tiers

Tier	Purpose
toolchain	Cross-compilation (LFS Ch. 5-7)
core	Full system: kernel, shell, coreutils, systemd, GCC, SSH
base	CLI tools: htop, rsync, strace, screen
desktop	GNOME on Wayland: GTK, Mesa, GStreamer, GNOME Shell
ai	Local AI assistant: llama.cpp, InterGen, InterGen Sentinel
extra	User applications: Node.js, Google Chrome, VS Code, Claude Code

Build System

Single command builds the entire system:

sudo bash scripts/build-intergenos.sh --user <username> --checkpoint

Phases: 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

Resume from any phase with --start-at, stop with --stop-after. Checkpoints saved after toolchain, core, kernel, and desktop phases.

Quick Start

# Build the OS (on Ubuntu 24.04 build VM)
sudo bash scripts/build-intergenos.sh --user <username> --checkpoint

# Query the BLFS package database
python3 scripts/blfs-query.py info samba
python3 scripts/blfs-query.py deps mesa --recursive
python3 scripts/blfs-query.py chain-cost openldap

# Meson feature database — what flags does a package need?
python3 scripts/blfs-query.py meson-flags gtk4
python3 scripts/blfs-query.py meson-audit --tier desktop
python3 scripts/blfs-query.py meson-impact shaderc

# Package management (on a running InterGenOS system)
pkm install alsa-utils
pkm install-helper chrome       # Fetches from Google, installs via pkm
pkm install-helper vscode       # Fetches from Microsoft, installs via pkm
pkm install-helper claude-code  # Fetches from Anthropic, installs via pkm
pkm remove htop
pkm list installed
pkm search audio
pkm info openssh
pkm provides /usr/bin/bash
pkm verify --all

Project Structure

intergenos/
├── igos-build/          # Build system (Python — parser, graph, builder, tracker)
├── pkm/                 # Package manager (Python — install, remove, query, verify)
├── installer/           # Forge installer (Python — TUI + backend)
├── packages/            # 857 package templates (YAML + build.sh)
│   ├── toolchain/       # LFS Ch. 5-7 (28 packages)
│   ├── core/            # LFS Ch. 8 + TLS/PAM/SSH + Forge SB primitives (272 packages)
│   ├── base/            # End-user CLI tools (23 packages)
│   ├── desktop/         # GNOME desktop stack (420 packages)
│   ├── ai/              # Local AI assistant stack (2 packages)
│   └── extra/           # User-facing applications (112 packages)
├── scripts/             # Build orchestrator, chroot scripts, BLFS tools
├── data/                # Curated metadata (meson option-to-dep mappings)
├── config/              # Kernel config, systemd units, gsettings overrides
├── build/               # Sources, patches, logs, archives (not committed)
└── docs/                # Project documentation, governance, security policy, and research

Status

Active development, pre-1.0. Originally built 2015-2016 (build_001 through build_003 on GitHub). Revived March 2026.

Now: 857 package templates across six tiers. First successful GNOME 49.4 desktop boot on Wayland achieved April 7, 2026 — kernel 6.18.10 with config converged from 5-distro analysis. First themed qcow2 image built May 3, 2026 with full GNOME theming applied. The v1.0 archive set is being finalized ahead of the public mirror's first publish. Installer (forge) handles partition → signed boot chain → image deploy → post-install hooks. Test harness covers 375 tests across installer backend, MOK validation, and Class 1 signing-chain verification, plus additional suites under tests/ (preflight, repo-publish, SBOM, upstream-check, download-sources). Public binary mirror infrastructure provisioned at repo.intergenos.org; signing-key ceremony complete (RSA-4096 master with hardware-token signing subs); v1.0 first-publish lands once that archive set is complete.

External reviews: Full codebase reviewed by four external LLMs (ChatGPT, DeepSeek, Gemini, Grok) across build system, installer, orchestration, and package management. Initial audit findings have all been remediated, and hardening continues as new edge cases surface.

Bare-metal installs validated across widely varying hardware — from current laptops back to a ~2012 2nd/3rd-generation Intel Core i5 — each through the full signed boot chain and the end-to-end ISO-installer path.

Upcoming

Items actively in flight or planned before v1.0:

• Forge Secure Boot bare-metal validation — first hardware install with live MOK enrollment and end-to-end signed-chain verification.
• Microsoft shim-review submission — obtaining an InterGenOS-owned MS-signed shim via the rhboot/shim-review sponsor track.
• Public binary mirror first-publish — repo.intergenos.org flips live once the v1.0 archive set is complete; covers signed per-package archive emission, signed InterGenOS.db index generation, and end-to-end pkm sync validation against the live mirror.
• pkm installed as a system tool — packaging pkm itself so pkm install <pkg> works out of the box on a freshly installed target.
• VPS source mirror completion — download-sources tooling refresh plus an upstream-version auto-poller (Components 2 and 3 of the mirror design).
• 35B AI tier scoping — evaluating the 35-billion-parameter local-assistant tier for high-end hardware.
• NVIDIA driver-open packaging — fetch-helper approach for the GPL-compliant NVIDIA open modules.
• Dual-boot Zephyrus playbook — tested alongside-Windows install flow on shared hardware.
• Switchable desktop environments — v1 ships GNOME on Wayland; KDE Plasma, XFCE, and other Wayland-capable desktops planned post-v1, with the per-tier architecture already supporting the split.
• Security Hall of Fame — researcher acknowledgment page maintained alongside the project's responsible-disclosure track.

History

• 2015: build_001 — First LFS attempt
• 2016: build_002, build_003 — 83 packages, fully automated
• 2016-2025: Life happened. Project shelved.
• 2026: Revival. New build system, package manager (pkm), installer (forge), BLFS database, GNOME desktop, a Secure Boot chain the user owns end-to-end, and the conviction that a from-source distribution can be both deeply educational and genuinely accessible — and that security-only alignment is not a luxury for the next decade of computing.

Research

Every major decision is documented. See docs/research/ — 188 markdown documents (plus supporting diagrams and data files) across 27 subdirectories covering:

• Why LFS over Gentoo, Buildroot, NixOS
• Build system design (9 systems evaluated)
• Package management history and design
• Kernel config convergence analysis (5 distros)
• GNOME desktop dependency chain (~370 packages)
• Application roadmap (Flathub/Snap/Arch data-driven)
• Forge Secure Boot design, signing-key custody, MS shim sponsorship research
• FLUX.2 branding pipeline

Acknowledgments

InterGenOS is built on the foundation of Linux From Scratch (LFS 13.0) and Beyond Linux From Scratch (BLFS 13.0). The LFS project and its contributors have made from-source Linux building accessible and educational for over two decades. This project would not exist without their work.

All included packages carry their own licenses as tracked in their package templates. See CREDITS for full attribution.

Legal

InterGenOS ships under a layered licensing posture. The summary table below points you to the operative document for each layer; nothing here is a substitute for those documents.

Layer	License	Reference
Build system, tools, package templates, pkm, Forge, InterGen wrapper, scripts (InterGenOS-authored code)	GPL-3.0-or-later	LICENSE
Individual upstream packages (over 800 build targets and counting)	Upstream's own license (SPDX in each package.yml)	CREDITS, docs/governance/license-policy.md
GPL source availability	§6d network access + §6b 3-year written offer	SOURCES.md
Brand assets (name, logo, color palette, shell-theme name)	Common-law trademark; carved out of GPL-3	TRADEMARK.md
AGPL-licensed packages shipped (ghostscript, mupdf)	AGPL-3.0-or-later, with project posture not exposing as network service	docs/governance/license-policy.md § 3
Patent-encumbered codecs (FDK-AAC, H.264/H.265 — opt-in)	Various; default ISO ships without FDK-AAC linkage	docs/legal/PATENTS.md
Proprietary-fetched helpers (Chrome, Edge, VS Code, Spotify, Discord, Brave, Claude Code)	Each vendor's EULA, accepted at install time	docs/legal/payload-licenses.md
Fetched-at-runtime LLM weights (Qwen via InterGen)	Tongyi Qianwen License, accepted at first launch	docs/legal/payload-licenses.md
Privacy posture	Local-first, no telemetry; GDPR / CCPA disclosures	PRIVACY.md
Export-control posture	ECCN 5D002 self-classified, TSU + ENC license exceptions	EXPORT-NOTICE.md
Contributor sign-off	Developer Certificate of Origin 1.1; Signed-off-by: trailer required	DCO.md
Vulnerability disclosure	Responsible-disclosure flow	SECURITY.md
Contributing	Issue + PR workflow	CONTRIBUTING.md
Project contributor record	Real-person identity list	AUTHORS

For redistributors: you inherit the project's source-availability, trademark, and export-control obligations in your own distribution channel. The respective documents explain what that means for you.

Author

InterGenJLU — InterGen Studios