Switching to InterGenOS

If you are coming from Debian, Ubuntu, Fedora, Arch, or another mainstream Linux distribution, this page maps what you already know onto how InterGenOS does things. The goal is not to convince you that everything is different. Most of it is not. The differences that matter are deliberate, and they all serve the same purpose: a machine you understand, can modify, and can trust.

Security is not first. It is only. Every default on this page exists because of that posture.

What is the same

InterGenOS is a Linux distribution. The kernel, the shell, the GNU coreutils, systemd, OpenSSH, and the GNOME desktop all behave the way you expect. Your shell scripts, your dotfiles, your editor, your terminal habits, and the standard command-line tools carry over without translation.

The desktop that ships today is GNOME 49 on Wayland. If you have used recent GNOME on any other distribution, the Activities overview, the app grid, Quick Settings, and the Settings app are all where you left them. The default icon theme is Papirus-Dark.

InterGenOS is built from source on the Linux From Scratch (LFS 13.0) and Beyond Linux From Scratch (BLFS 13.0) foundation. That is a build-time fact, not something you have to think about while using the system day to day.

What is different, and why

Package management uses pkm, not apt/dnf/pacman

InterGenOS ships its own package manager, pkm. It covers the operations you already do under other names, and it accepts the command names you would naturally reach for. The dispatch resolves aliases to a canonical command, so behavior is identical regardless of which name you type.

One important distinction from apt: pkm sync only refreshes the local index. It does not change anything on disk. pkm upgrade is the command that actually installs newer versions. Nothing upgrades on a timer — though a daily check does notify you when upgrades are available (it installs nothing, and you can disable it; see below).

For the full command surface, see The Package Manager.

Proprietary and third-party apps come through pkm install

Software that other distributions reach for via a vendor .deb, a third-party repository, or the AUR is installed through the same pkm install command as everything else. InterGenOS ships a small download-helper for each, and pkm routes to it automatically — there is no separate command to remember:

sudo pkm install chrome       # Fetches from Google, installs via pkm
sudo pkm install vscode       # Fetches from Microsoft, installs via pkm
sudo pkm install claude-code  # Fetches from Anthropic, installs via pkm

Because these are proprietary, pkm will not install one silently. The install stops for an explicit, interactive license acceptance — you cannot complete it by accident:

1. pkm first names the vendor license and asks Continue? [y/N].
2. The vendor’s own installer then prints its license and requires you to type I ACCEPT (exact match, capitals) to proceed. Anything else aborts the install.

Only after you accept does the helper download from the vendor, verify the download against the vendor’s signed metadata (a SHA-256 integrity check), and install. Your acceptance is recorded under /var/lib/intergen/legal/, so a later reinstall of the same version does not prompt again.

No background network activity

This is the largest behavioral change for most people switching:

• No background refresh. The system does not reach out to the network until you explicitly run pkm sync or pkm install.
• No telemetry. There is no popcon, no countme equivalent, no usage analytics.
• No unattended upgrades. The system stays exactly as it is until you command a change.
• A daily update check, opt-out. One timer (pkm-check-updates.timer) compares your installed packages against the index you last synced and shows a count of available upgrades (a tray indicator and a login message). It downloads and installs nothing, reaches no further than your local index, and turns off with sudo systemctl disable --now pkm-check-updates.timer.

If a package ships under a non-OSI license, pkm halts and shows a banner requiring your explicit consent before downloading.

How that compares to the package managers you may know:

A signed boot chain you own (Secure Boot optional)

On other distributions, Secure Boot is often something you disable to get work done, or a chain you do not control. InterGenOS ships a signed boot chain where the trust anchor is your own MOK key, generated per machine by the installer, Forge: signed shim, MOK-signed GRUB, and a MOK-signed Unified Kernel Image. Secure Boot enforcement is optional — the current fleet ships with it off, and you can enable it (and enroll your MOK) on hardware that supports it. dm-verity seals the live install image.

If you enable Secure Boot you enroll your MOK at install time; either way the machine boots through a chain you can audit. See the Forge installer guide.

Transparent boot, no splash

There is no Plymouth splash screen hiding the boot. 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. Reading boot output is a real practice for noticing a compromise or a hardware change, so the system gives you that surface rather than covering it.

A local AI assistant, fully offline

InterGenOS ships InterGen, a tiered, hardware-detected local assistant built on Qwen models. At setup time it detects your CPU, RAM, and GPU and picks a model and quantization that fit the machine, from a 4 GB laptop up to a GPU workstation. It runs fully offline with zero telemetry, no accounts, and no cloud round-trip. Every tool call is permission-gated; the default mode requires confirmation before anything changes system state.

Paired with it is InterGen Sentinel, a pluggable security scanner that reviews MCP tool calls before they execute. The default is local only: a deterministic rule-based scanner plus a local-Qwen-backed reviewer. Six cloud providers are strictly opt-in, and you choose which (if any) ever reaches the network: Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek. This opt-in cloud routing is called Phone-A-Friend (Frontier/Cloud Escalation). Schema-pinning, audit logging, and sandbox enforcement are local plumbing that applies no matter which scanner is active.

What you should know before switching

InterGenOS is version 1.0-dev (build id v1.0-dev1) and under active, pre-1.0 development. A few expectations to set:

• GNOME on Wayland is the only desktop today. Switchable desktop environments such as KDE Plasma and XFCE are on the roadmap and are not part of the current system. If you require a non-GNOME desktop right now, this is not yet the system for you.
• The package set is from-source and curated, not exhaustive. As of June 2026 the build comprises roughly 857 package templates across six tiers (toolchain, core, base, desktop, ai, extra). These counts drift as the set is finalized. If a piece of software you rely on is not yet packaged, you can build it yourself in the meantime.
• The public binary mirror is being finalized. The signing-key ceremony is complete and mirror infrastructure is provisioned at repo.intergenos.org; the first public publish goes live once the v1.0 archive set is complete.

Migrating your data and habits

Because the userland is standard, the practical migration is the ordinary one:

• Copy your home directory, dotfiles, and project files as you would between any two Linux machines (rsync, an external drive, or your usual backup).
• Reinstall applications with pkm install <pkg> — the same command covers proprietary or third-party apps (e.g. pkm install vscode), which prompt for vendor-license acceptance the first time.
• Your shell configuration, SSH keys, and Git setup carry over unchanged.

There is no in-place upgrade path from another distribution. InterGenOS is a fresh install through Forge.

Where to go next

• Frequently Asked Questions
• Forge installer guide
• The Package Manager