System Abstract
Xirtux UNIX System is a minimal research operating system derived from the BSD lineage, designed for operators who prefer source trees to service agreements. The system assumes local control, visible mechanisms, and durable documentation as core virtues. It is not a general-purpose distribution for casual use; it is a workshop for understanding systems through direct engagement.
The distribution ships with a small, auditable kernel, a conservative userland drawn from the BSD tradition, and a ports-like package system bridged to the pkgsrc ecosystem. All tooling is designed for the operator who administers their own machine and reads the manual before asking questions.
Xirtux UNIX System has no telemetry, no cloud dependency, no required network activation, and no subscription model. It is distributed as a single ISO image with complete source visibility. The project believes that an operating system is a tool, not a service, and that the operator owns the machine absolutely.
OPERATOR NOTE: This system assumes familiarity with Unix conventions, the C toolchain, BSD make, and manual page navigation. New users should begin with the Xirtux Handbook (man xirtux) after installation.
Operating Principles
- FIG. P1 — Small kernel, readable tree. The kernel source tree is deliberately constrained. Every subsystem must justify its presence. The goal is a kernel an experienced operator can read and understand in a reasonable period.
- FIG. P2 — Conservative networking stack. Network protocols are implemented defensively. No experimental congestion algorithms, no hidden telemetry, no auto-negotiated cloud services. The network stack serves the operator, not the network.
- FIG. P3 — Local-first tooling philosophy. All system tools operate on the local machine by default. Remote operations require explicit operator intent. The system never assumes an internet connection.
- FIG. P4 — Source-visible system architecture. Every component of the base system ships with complete source code. The build process is documented, reproducible, and does not require binary bootstrap blobs. Operators are encouraged to read the source.
- FIG. P5 — No decorative complexity. Features are added only when they solve a demonstrated problem for system operators. Cosmetic enhancements, animation, transparency effects, and graphical boot splashes are not part of the base system.
- FIG. P6 — Operator owns the machine. The operator has root access, unrestricted file system control, and full authority over every installed component. The system does not hide configuration behind automated tools. Manual pages are the authoritative interface.
SYSTEM CONSTRAINT: These principles are not marketing. They are engineering constraints enforced by the build system and the project governance document (see src/SYS_CONSTRAINTS). Each principle is illustrated in the diagrams that follow.
Small Kernel, Readable Tree
FIG. P1 — Kernel subsystem approval model. Solid lines: justified subsystems accepted into the tree. Dashed red: rejected proposals. Kernel targets ~18,000 lines of C — readable by an experienced operator in a single session.
Conservative Networking Stack
FIG. P2 — Conservative networking stack. Each layer applies operator-configured filters. No protocol auto-negotiation, no hidden telemetry, no cloud dependency. Rejected external influences crossed out on the right.
Local-First Tooling Philosophy
FIG. P3 — Local-first tooling architecture. Left: local machine with tools defaulting to local operation. Right: remote boundary only reachable through EXPLICIT INTENT barrier. The system never assumes an internet connection.
Source-Visible System Architecture
FIG. P4 — Source-visible build pipeline. Every component ships with source. Build is documented and reproducible. Binary blob bootstrap rejected (crossed out). Ports integrate via pkgsrc where upstream source is available.
No Decorative Complexity
FIG. P5 — Feature gate. Every proposal passes through the DEMONSTRATED PROBLEM? diamond. Green path: real problems → approved. Red path: cosmetic features (boot splashes, animations, rounded corners, color output) → /dev/null. The irony of this diagram existing on an elaborately styled website is noted.
Operator Owns the Machine
FIG. P6 — Operator sovereignty. The operator (root) has unrestricted authority. Three pillars: filesystem control, plain-text configuration, manual pages as the authoritative interface. Rejected below: hidden config, automated tools, subscription models. The machine serves the operator.
System Architecture
FIG. 2A — Simplified component diagram. Solid lines indicate direct API linkage. Dashed lines represent build-time or packaging relationships. Click any component for related documentation.
Command Demonstration
The following examples illustrate the core Xirtux UNIX System operator commands. These are not emulated or containerized — each command interacts directly with the system it runs on.
operator@xirtux:~ $ xpkg audit [xpkg] scanning installed package database [xpkg] checking against pkgsrc-vulns-2026Q3.db [xpkg] 0 known vulnerabilities in 847 installed packages [xpkg] system integrity: NOMINAL
operator@xirtux:~ $ xsys rebuild [xsys] rebuilding base system from /usr/src [xsys] target: amd64 [xsys] kernel: OK (38s) [xsys] userland: OK (142s) [xsys] release: OK (17s) [xsys] build complete — artifacts in /usr/obj
operator@xirtux:~ $ man xirtux XIRTUX(7) Xirtux UNIX System Manual XIRTUX(7) operator@xirtux:~ $ rcctl show sshd enabled running ntpd enabled running syslogd enabled running xirtuxd enabled running httpd disabled stopped
OPERATOR NOTE: All commands use manual pages as authoritative
documentation. Run man xirtux-intro for a guided
introduction to the system toolchain.
Compatibility Matrix
Subsystem support status across target platforms for revision 0.7-BETA.
| Subsystem | Status | Notes |
|---|---|---|
| amd64 | ● STABLE | Primary target. Full kernel, userland, and ports support. |
| arm64 | ◐ EXPERIMENTAL | Boots to multi-user. Device tree for Pi 4, Apple M1/M2 in progress. |
| pkgsrc bridge | ● STABLE | Full pkgsrc via xpkg. 24,000+ packages. |
| bhyve / jails layer | ◐ EXPERIMENTAL | Virtualization and container isolation. bhyve port functional. |
| retro workstation | ◐ EXPERIMENTAL | Profile for ThinkPad X220/T420 era machines. |
| laptop austerity mode | ○ PLANNED | Minimal power profile. Target: 0.8W idle. |
| i386 | ◐ EXPERIMENTAL | Legacy 32-bit support. Community-maintained. |
| ZFS root | ● STABLE | OpenZFS 2.2 integrated. Boot environments, snapshots, native encryption. |
SYSTEM CONSTRAINT: Support classifications evaluated quarterly by the Xirtus Systems Research Group.
Download & Build
Xirtux UNIX System is distributed as a single installable ISO image. The complete source tree is available for local building. No network registration, activation key, or account required.
BUILD TARGET: amd64
$ ftp https://cdn.xirtux.org/pub/xirtux/0.7-BETA/src.tar.xz $ tar xJf src.tar.xz -C /usr/src $ cd /usr/src $ make build [xsys] rebuilding Xirtux UNIX System 0.7-BETA [xsys] operator confirmation required — see make(1) and xsys(8)
No warranty. No telemetry. No cloud requirement. Provided by the Xirtus Systems Research Group under the BSD 2-Clause License. Operators assume full responsibility for their systems. Read the manual. Understand your machine.
╔══════════════════════════════════════════════════════════════════════════════╗ ║ ║ ║ UNITED STATES GENERAL SERVICES ADMINISTRATION ║ ║ FEDERAL INFORMATION PROCESSING STANDARD ║ ║ ║ ║ X I R T U X (R) U N I X O P E R A T I N G S Y S T E M ║ ║ ║ ║ TRUSTED COMPUTING BASE — DEPARTMENT OF WAR — UNCLASSIFIED ║ ║ ║ ║ DOCUMENT CONTROL NUMBER: XRX-DC-7704-ALPHA-VOID ║ ║ DISTRIBUTION: AUTHORIZED PERSONNEL ONLY ║ ║ CLASSIFICATION: UNCLASSIFIED // FOR OFFICIAL USE ONLY ║ ║ ║ ╚══════════════════════════════════════════════════════════════════════════════╝
Xirtux UNIX System is Forward Thinking Reliable Systems Architecture — an operating system for people who read documentation, inspect source code, and administer their own machines. It has no investors, no engagement metrics, and no growth targets. It has a kernel, a userland, and a manual.
DISTRIBUTION: PUBLIC DRAFT | REVISION: 0.7-BETA | DATE: 09 JUL 2026
Prepared by the Xirtus Systems Research Group — Windowless Computing Lab No. 4