On this page
I picked Arch for one reason: Valve rebuilt SteamOS on Arch for the Steam Deck in 2022 and funds Proton’s development, and Arch felt like the closest thing to what Valve actually ships. Linux gaming had gotten genuinely good by then. So that’s what I put on a machine that mostly does gaming and browsing.
The install taught me more than the OS did
I skipped the archinstall script. Booted the live ISO, partitioned the disk by hand, bootstrapped the base system from a bare shell, wrote my own fstab, and picked and configured the bootloader myself. No GUI held my hand at any point.
The mini PC’s fan doesn’t spin up under the default kernel driver, so before I even had a desktop to log into, I was hunting down an open source driver built for this hardware and compiling it myself just to stop the thing overheating.
Then came the actual desktop: I picked dwm off the list of window managers and rice’d it from there, wrote my own patches for the status bar, scripted the volume keys, wired up network status, and set up dmenu as the launcher.
None of that was strictly necessary to end up with a working box. It’s honestly the part I got the most out of. I understand partitioning, bootloaders, init, and how a window manager and its bar actually fit together now, instead of having clicked through an installer that did it for me somewhere off-screen. I can install pretty much any distro without a GUI at this point and not worry about it.
Ten months in, I switched anyway
I only used Arch for about ten months, mostly for gaming and browsing. Two things moved me off it.
The AUR’s malware problem was happening while I was on it
In June 2026, over 400 AUR packages got compromised, pushing a Linux rootkit and infostealer. Then on July 29 a second wave started from the openconnect-sso package and spread to 200-plus packages, including ones that aren’t obscure at all, like boringssl-git, icloudpd, and pgadmin4-server. Attackers got in either by hijacking maintainer accounts or by adopting packages nobody was maintaining anymore.
The payload ran in two stages. First a loader checked for debuggers, sandboxes, VMs, and CI environments before installing itself via systemd services and cron. Then it pulled down a Tor client disguised as dbus-daemon to fetch a Rust infostealer that went after browser credentials, crypto wallets, password manager data, cloud and AI API keys, SSH keys, and messaging tokens, and could spread to other machines using the SSH keys it stole.
Arch disabled AUR package adoption entirely on July 31, project-wide, with no timeline for when it would come back.
The AUR has no review gate. Anyone can upload or adopt a PKGBUILD, and that PKGBUILD runs arbitrary code the moment you build it. nixpkgs gets bad packages too sometimes, but it’s one monorepo behind pull request review. There’s no equivalent open inbox for anyone to drop a payload into.
I was already managing infrastructure this way
I’d rewritten my homelab as OpenTofu after a dozen hand-managed Docker Compose files turned into something I couldn’t fully account for anymore. NixOS is the same move, one layer down. The OS used to be whatever accumulated from a year of pacman -S; now it lives in my nixos-config repo, a set of files that describes the whole system instead of documenting it after the fact.
Once I’d already made that trade for the homelab, making it for my desktop wasn’t much of a decision at all.
What actually changed
Installing something is editing a file and running nixos-rebuild switch, not running a command and trusting future-me to remember it happened. Rollbacks are free too: I just boot the previous generation instead of digging through whatever backup happened to exist.
nixpkgs still gets its share of bad packages. But someone has to look at a pull request before “adopt an abandoned package and slip malware in” can happen there.
It also pushed me toward what people call the clean host approach: the system itself stays minimal, and anything project-specific, a language toolchain, a database, a CLI, lives in a per-project nix-shell or devenv environment instead of being installed globally. My actual system config barely grows. Everything else is scoped to whatever project needs it, and it disappears when I leave the directory.
What’s still annoying
The Nix language itself is the wall. NixOS as a concept clicked fast; the language took longer. Anything not already in nixpkgs means writing a derivation instead of just makepkg-ing it.
And declarative doesn’t mean automatic, which I learned the hard way. After switching, my CPU ran about 10°C hotter than it had on Arch. The fan driver I’d compiled during the Arch install hadn’t come with me. NixOS didn’t go find it and infer it, obviously, it’s not psychic. If it’s not in the config, it doesn’t exist. I had to write that fan setup into NixOS before it actually did anything.
So, worth it?
For me, yes. I was already running my infrastructure as code, so running my desktop the same way is one less mental model to keep straight. If you don’t care about reproducibility and just want packages fast, Arch still wins there. But between a malware wave moving through my package manager and a system I couldn’t fully describe in a file, NixOS was the same call I’d already made for the homelab, just closer to home.