I Use Arch, BTW: The Anatomy of an Overrated Myth
I have run Arch Linux on my main desktop or laptop since 2012. Before that, Gentoo. It is time for a ruthlessly honest dissection of what Arch actually is in 2026 — and what the cult around it has made of it.
Arch Linux carries one of the most intense reputations in the digital world. To its faithful, it is the final boss of desktop Linux: minimal, infinitely malleable, rolling-release, bleeding-edge. You construct your environment piece by piece, command by command, mistake by mistake. For a specific breed of operator, that granular control is the entire point.
Somewhere along the way, Arch stopped being evaluated as an operating system and started functioning as a personality test. Installing it became a rite of passage. Manually partitioning a disk, configuring a bootloader, bootstrapping a desktop environment — these acts are framed as initiation into a higher plane of computational enlightenment.
I disagree. Arch Linux is profoundly overrated.
Not because it is useless. Not because it is poorly engineered. It is overrated because the mythology has grown taller than the artifact. Most of what the community celebrates is neither unique nor practical; in places, it is actively hazardous. To raze the obsolete and build anew, you have to strip the romance off first. Here are four visceral reasons Arch receives far more reverence than it has earned.
1. The AUR: Supply-Chain Roulette With a Progress Bar
The Arch User Repository is marketed as Arch’s superpower, and the sheer volume is genuinely impressive. Obscure utility? Niche tool? Proprietary blob? Patched git build the official repos refuse to touch? Someone has usually penned a PKGBUILD for it. That reach is useful.
It is also Arch’s greatest vulnerability.
The AUR is not an official repository. It is a wild expanse of user-submitted build scripts, and that distinction is everything.
When you install software from the official repositories of a major distribution, you are leaning on an established trust stack: maintainers, cryptographic signing, review pipelines, build farms. When you fire up an AUR helper, you are frequently trusting a phantom on the internet who wrote a script that runs arbitrary commands on your bare metal. The script can fetch remote code, execute build hooks, silently mutate your system state. With enough carelessness on your end, that script becomes an efficient, well-paved road straight into your machine.
This is not paranoia. The AUR has already shipped malicious packages — compromised build scripts delivering credential stealers and Linux-targeted payloads. For years the casual community attitude has been: just use a helper, just hit enter, just trust the vibe. That is supply-chain roulette.
The standard defense is: you are supposed to audit the PKGBUILD first. Technically true. Practically meaningless. Manual trust evaluation does not scale. Most users are not tracing every source URL, verifying every checksum, or auditing every transitive build dependency before they mash Enter. If an ecosystem depends on every end-user hand-auditing random strangers’ scripts, the security model has already failed by design.
The AUR is convenient. Convenience is not the same thing as safety. Treat it as a vast risk surface, not a technological flex.
2. Stability Is Not the Same as Maintenance You Get Paid For
Arch users will tell you the system is stable — if you know what you are doing. There is a kernel of truth in that. If you monitor the news page, run cautious upgrades, master pacman, keep your dotfiles pristine, and memorize recovery rituals, Arch runs smoothly.
Listen closely to that condition. That is not stability. That is unpaid system administration.
Arch moves fast. Fresh kernels, fresh desktop environments, fresh drivers, fresh regressions. Being close to upstream is excellent for bleeding-edge hardware; it also means you are first in line for upstream breakage. A working professional does not want their graphics stack, audio daemon, and bootloader mutating under them while they are trying to ship code. Sometimes the job is: open the laptop, write, deploy, trust that today’s update will not summon an impromptu troubleshooting session at midnight.
Arch users routinely rebrand this maintenance burden as empowerment. Not every burden is empowerment. Sometimes it is just sysadmin work you are doing on your own machine, for free, on your own time. Calling it mastery does not change the line items on the receipt.
3. The Installation Myth: Procedural Labor Is Not Mastery
Arch boasts a legendary installation mythology. Boot to a live terminal. Partition the disk. Format the filesystems. Mount the root. pacstrap the base. arch-chroot into the system. Generate the fstab. Once the prompt returns, the operator acts as though they have touched the divine.
Installing Arch does not make you a wizard. It proves you can follow documentation.
The first time, the process is genuinely educational. It teaches the anatomy of a Linux system — partitions, bootloaders, the assembly sequence. That is worth something. But let us not dress procedural labor up as deep engineering mastery. It is the digital equivalent of assembling IKEA furniture: putting the chair together does not make you a master carpenter. If the chair collapses because you skipped a dowel, you were not doing advanced engineering — you were doing tedious setup, badly.
In 2026, pretending that manually assembling the same base system for the thirtieth time is a mark of technical superiority is absurd. Complexity is not inherently virtuous. Sometimes complexity is just friction wearing a fake mustache and calling itself self-education.
4. Security Posture: Minimalism Is Not Hardening
Arch grants you absolute freedom. Freedom is not security.
A default Arch base is minimal, and a smaller attack surface is a real advantage — only if you build on it with paranoid precision. Most users do not run a pure TTY. They bolt on a window manager, a web browser, Bluetooth daemons, virtualization, an AUR helper or three. At that point, the minimalist argument evaporates. The attack surface is whatever you stacked on top, plus whatever those packages dragged in transitively.
The structural issue runs deeper. Arch does not ship a strong Mandatory Access Control system enabled by default. Modern distributions operating under modern threat models use SELinux or AppArmor to confine applications — to deny actions even when standard Unix permissions would allow them. These systems are tedious. They require profiling, debugging, tuning. They are also vital.
Discretionary access control — the traditional Unix permission model — is grossly insufficient today. If your browser is exploited and the compromised process runs as your user, it can freely read your home directory, your SSH keys, your browser profile, your GPG keyring. Arch leaves sandboxing and MAC policy entirely to you. Handing someone a sharp blade and telling them to forge their own hilt is not hardening; it is flexibility. Combine that with the AUR’s ambient chaos and the result is a deeply questionable default security posture for anyone who treats their machine as more than a hobby.
The Verdict: Dissecting the Gatekeepers
The deepest flaw in the Arch ecosystem is not the software. It is the gatekeeping mythology wrapped around it.
Arch is marketed as the operating system for people who truly understand Linux. That framing is intellectually reductive. Understanding Linux means understanding threat models, anticipating system failure, recognizing when boring defaults outclass infinite choice. A Debian server that has run silently for five years is not inferior to an Arch box updated daily. A Fedora workstation with SELinux enforcing by default is not less serious because it used a graphical installer.
Arch is an impressive, fast-moving, exceptionally well-documented tool. The Arch Wiki remains one of the greatest technical resources ever compiled. But the community chronically confuses difficulty with quality. It confuses manual installation with mastery. It confuses package availability with safety.
If the operating system is your primary hobby, if you demand bleeding-edge packages, and if you are willing to scrutinize user-submitted scripts before they touch your machine — Arch is your blade. Wield it.
But if you have started believing the trade-offs are automatically virtues, congratulations: you have been captured by the myth.
The Sovereignty Layer Beneath All Sovereignty
Your operating system is sovereignty layer zero. It is the substrate on which every other defense — encryption, identity, exit infrastructure, your chapter’s coordination protocols — either runs or collapses. Most operators treat it as wallpaper. That is the first compromise you never see.
A sovereign stack does not begin with a VPN or a hardware token. It begins with the question: can I reproduce this machine from a declarative spec, on any hardware, without my hands on a keyboard? If the answer is no, you do not own your environment. You are renting it from your own past self, and your past self is already drifting.
Arch, for all its virtues, answers that question with a shrug. Reproducing an Arch install means re-running a wiki ritual. The Nix expression does not exist; the rollback snapshot is whatever you remembered to timeshift. There is no atomic upgrade path. There is no canonical description of the system that is the system. The Arch way is the procedural way, and procedural knowledge does not survive a wiped disk.
That is why my bare-metal runs NixOS.
NixOS is not a religion and it is not a vibe. It is a single idea executed without compromise: the entire system is a pure function from a declarative configuration to a derivable build. Reproducible. Atomic. Roll-back-able. Declarative end-to-end. You can move a 6000-line configuration.nix to a new machine, run nixos-install, and you have the same machine — same packages, same services, same users, same firewall rules, same secrets layout. The OS becomes data, not procedure. That is the actual answer to layer zero, and Arch never gets there.
Arch is overrated. I am still running it to this day, on machines where the operational profile tolerates ritual and the blast radius is small. But on the hardware that holds my identity, my keys, my chapter’s protocols, and the rails my work runs on — NixOS, by the way. 😉
One-line command, per the editorial close:
# Reproduce your sovereign machine from scratch, on any hardware, in one shot:
nixos-install --flake .#my-machine