Skip to main content
Projects

Argo OS

Custom Gentoo Linux distribution running on callisto-galileo with KDE Plasma 6, Hyprland, and a distributed build system

February 23, 2026

Argo OS

Argo OS is a custom Gentoo Linux distribution running on callisto-galileo (10.0.0.100). It's not a fork and it's not a derivative — it's a Gentoo install with an opinionated configuration, a custom package management layer (apkg), and a distributed build system that means the workstation never touches a compiler.

The whole point is a desktop that's fully under control. Every USE flag is intentional. Every service is managed by OpenRC. Every binary package is built by the swarm and delivered ready to install. Gentoo gives you that level of control, and Argo OS is what happens when you actually use it.

Hardware

Argo OS runs on callisto-galileo, the primary workstation:

Component Spec
CPU Intel i7-4790K (4 cores / 8 threads)
GPU NVIDIA RTX 4070 Ti
RAM 32 GB DDR3
Network 10.0.0.100 (Jove LAN)
Storage NVMe root + SATA data drives

The i7-4790K is aging, but it's a solid 4-core chip with hyperthreading, and the RTX 4070 Ti handles everything from Hyprland compositing to CUDA workloads. The 32GB of RAM is enough for KDE Plasma, a browser with too many tabs, multiple development environments, and the occasional VM.

More importantly, since callisto-galileo is a driver system that never compiles packages locally, CPU performance barely matters for system updates. The build swarm's 62 cores across 4 drones handle all compilation. callisto-galileo just pulls the binaries.

Init System: OpenRC

Argo OS uses OpenRC, not systemd. This is a deliberate choice, not an accident of defaults. OpenRC is:

  • Shell-script based and readable — you can open any init script and understand it
  • Lightweight — no PID 1 bloat, no journal daemon, no login manager, no network manager baked into init
  • Gentoo-native — Gentoo has excellent OpenRC support since it was developed by Gentoo developers originally

Common Commands

# Service management
rc-service sshd start          # Start a service
rc-service sshd stop           # Stop a service
rc-service sshd restart        # Restart a service
rc-service sshd status         # Check status

# Runlevel management
rc-update add sshd default     # Enable at boot
rc-update del sshd default     # Disable at boot
rc-status                      # Show all services and their states
rc-status -a                   # Show all runlevels

Never use systemctl, journalctl, or any systemd commands. They don't exist on this system and referencing them in documentation or scripts is a mistake.

Logging

Without systemd's journal, logging goes through the standard syslog. Check /var/log/messages for system logs, and individual service logs live in their expected locations (/var/log/nginx/, /var/log/emerge.log, etc.).

# System log
tail -f /var/log/messages

# Portage log
tail -f /var/log/emerge.log

# Kernel messages
dmesg -w

Desktop Environment

Argo OS runs a dual desktop setup:

KDE Plasma 6

The primary desktop is KDE Plasma 6. It's the daily driver for general use — file management, browser, terminal emulators, system settings. Plasma 6 is a Wayland-first release, and on Argo OS it runs under Wayland with the NVIDIA proprietary drivers.

KDE's configurability is the reason it's here. Every panel, every widget, every keyboard shortcut is tuned. The system tray shows Tailscale status, build swarm notifications, and hardware monitors. Virtual desktops are mapped to specific workflows — development on desktop 1, browser on desktop 2, terminal grid on desktop 3.

Hyprland

Hyprland is the tiling window manager alternative, available as a separate session. It's a dynamic tiling Wayland compositor with smooth animations and scriptable configuration. When the work calls for a distraction-free terminal-heavy session — multi-file editing, build monitoring, SSH sessions to the fleet — Hyprland's tiling layout is faster than manually arranging Plasma windows.

The Hyprland config lives in ~/.config/hypr/hyprland.conf and is version-controlled. Keybindings follow a vim-inspired pattern (Super+hjkl for focus, Super+Shift+hjkl for move), and workspace rules automatically send applications to their designated workspaces.

Both desktops run on Wayland with the NVIDIA proprietary driver stack. Xwayland is available for legacy X11 applications that haven't been ported yet.

Binary Package System

This is the part that makes Argo OS different from a standard Gentoo install. callisto-galileo is a driver system — it never compiles packages locally. Every package is pre-built by the build swarm and served from the binhost.

The DRIVER Principle

On a typical Gentoo system, running emerge -uDN @world kicks off hours of compilation. On Argo OS, it installs pre-built binaries in minutes. The workflow:

  1. Run emerge -puDN @world to see what needs updating (pretend mode, no action)
  2. Submit the package list to the build swarm via build-swarm submit
  3. The swarm's 62 cores across 4 drones build everything
  4. Binaries land on the binhost at 10.0.0.194
  5. Run emerge --usepkg --usepkgonly -uDN @world on callisto-galileo
  6. Packages install from binaries — no compilation

The --usepkgonly flag is critical. It tells Portage to only use binary packages — if a binary isn't available, the install fails rather than falling back to source compilation. This is intentional. If a package isn't in the binhost, it means the swarm hasn't built it yet, and you should figure out why rather than silently compiling it on the workstation.

Binhost Configuration

The binhost is served from dr-tb (10.0.0.194), the bare metal Gentoo box that doubles as a build drone. Portage on callisto-galileo is configured to pull binaries from it:

# /etc/portage/binrepos.conf
[binhost]
sync-uri = http://10.0.0.194/packages
priority = 9999

When the swarm completes a build, the binary packages are synced to dr-tb's package directory. callisto-galileo's Portage picks them up on the next emerge --sync or direct install.

USE Flags and Profile Sync

The build swarm and callisto-galileo must have identical USE flags, profiles, and keyword settings. If the swarm builds a package with USE="X11 wayland" but callisto-galileo expects USE="X11 wayland vulkan", the binary won't match and Portage will reject it.

The swarm's configuration management ensures this. All drones share a synchronized make.conf, package.use/, package.accept_keywords/, and profile selection. When callisto-galileo's configuration changes, the swarm configuration is updated to match before the next build cycle.

apkg

apkg is a custom package management tool built on top of Portage. It was built intentionally to learn how Portage and emerge work under the hood — not by accident, not because emerge is broken, but as a learning project that turned into something genuinely useful.

apkg simplifies common Portage operations into shorter commands while preserving full access to emerge's capabilities underneath. It's part of the Argo OS ecosystem and has its own documentation page in this docs hub.

# apkg examples
apkg search firefox        # Search for packages
apkg install www-client/firefox  # Install (binary-only on driver)
apkg update                 # Check for updates
apkg world                  # Full @world update workflow

See the APKG Package System page for full documentation.

The Five-Part Journey

Argo OS is documented in a 5-part series in the Obsidian vault, covering the entire journey from "I want to try Gentoo" to "I have a distributed build system":

Part Title Content
Part 1 The Argo OS Journey Complete narrative (Oct 2025 - Jan 2026)
Part 2 Blog Series 32-episode blog series covering the build
Part 3 Technical Deep-Dives Technical reference material
Part 4 Navigation Hub Knowledge base index
Part 5 Developer's Journal apkg and build swarm development logs

The blog posts in the homelab-series/ collection on argobox.com cover the public-facing version of this journey, with the Galactic Identity System applied for sanitization.

Network Position

callisto-galileo sits on the Jove network at 10.0.0.100. It has direct LAN access to:

  • Build swarm gateway: 10.0.0.199:8090 (argobox-lite)
  • Orchestrator: 10.0.0.201:8080 (on Io)
  • Binhost: 10.0.0.194 (dr-tb)
  • Monitoring: Prometheus (10.0.0.199:9090), Loki (10.0.0.199:3100), Grafana (10.0.0.199:3000)

For reaching the Kronos network (Dad's house), callisto-galileo uses Tailscale subnet routing. The Kronos hosts (Titan at 192.168.50.196, MasaiMara, Casablanca, Margaritaville) are accessible through their Tailscale IPs without any manual VPN configuration.

File Locations

Key Argo OS files and directories on callisto-galileo:

Path Purpose
/etc/portage/make.conf Master Portage configuration
/etc/portage/package.use/ Per-package USE flags
/etc/portage/package.accept_keywords/ Keyword unmasking
/etc/portage/binrepos.conf Binhost configuration
~/.config/hypr/hyprland.conf Hyprland configuration
~/.config/plasma-workspace/ KDE Plasma settings
/var/log/emerge.log Portage operation log
/usr/local/bin/apkg apkg tool
/usr/local/bin/build-swarm Build swarm CLI

Why Gentoo?

Because understanding your operating system matters. Every Gentoo system is built from source (or in this case, from binaries built by a swarm you control). There's no installer making decisions for you, no default configuration you didn't choose, no services running that you didn't enable.

Is it more work than installing Ubuntu? Obviously. Is it worth it? For a system that's a daily driver workstation, development machine, and the anchor point for a homelab build system — absolutely. The control Gentoo gives you is the entire point of Argo OS.

argo-osgentoolinuxdesktopbinary-packages