Why I Moved from Arch to Boring Debian Testing

The recent AUR incident did not make me think Arch is suddenly unusable. It did remind me how much trust the whole setup requires.

The short version is simple: malicious packages showed up in the Arch User Repository, looking normal enough for people to install them. That is not a bug in pacman, and it is not really a surprise to anyone who understands how the AUR works. The AUR is a community repository of build scripts. It is not the same thing as the official Arch repositories.

The Arch Wiki has always been clear about this. You are supposed to read the PKGBUILD, understand what it does, and decide whether you trust it.

The Review Problem

In theory, reviewing every PKGBUILD sounds reasonable. In practice, it does not work for me. It is not enough to glance at a few lines and check that nothing looks obviously evil. To review a package properly, you need to understand where the source comes from, what the build steps do, what the install script does, and what every dependency brings in. Some packages pull a small tree of other packages behind them. Each of those has its own assumptions.

At that point the advice becomes less useful than it sounds. Yes, I can read shell scripts. No, I cannot honestly say I understand every dependency well enough to make that review meaningful every time I install or update something.

And the more often you use an AUR helper, the easier it is to stop thinking about it. The workflow starts to feel official. Type the command, skim the output, accept the changes. That feeling is exactly the dangerous part.

The AUR Became Necessary

I tried to keep my AUR usage small. I never wanted a system held together by random community packages. But on Arch, the official repositories were not enough for how I use my desktop. A lot of software is distributed first as .deb or .rpm. Sometimes there is an AppImage. Sometimes there is a tarball. Very often, the convenient Arch answer is the AUR.

That is one of Arch’s strengths. It is also the part I became less comfortable with. The AUR fills the gap between what upstream projects ship and what the official repositories contain. Once you depend on that gap too often, you also depend on the trust model behind it.

Popularity Changes the Threat Model

Arch used to feel like a system mostly used by people who knew exactly what they were getting into. That is less true now.

Projects like Omarchy and CachyOS make Arch-based systems easier to install, easier to recommend, and more attractive to regular desktop users. I do not think that is bad. More people using Linux is good. But popularity changes the incentive structure. A community trust model works best when the community is small, technical, and slightly annoying to enter. In 2026 that is not enough. There are too many bad actors, too much automation, and too much benefit in attacking popular package ecosystems.

The AUR is useful because anyone can contribute. The AUR is risky for exactly the same reason.

Why Debian Testing

So I moved to Debian Testing, currently Forky.

Debian is not perfect, and Testing is not the most conservative choice possible. But it fits what I want better right now. The package ecosystem is closer to what many upstream projects already support, the defaults are boring in a good way, and the whole system feels less dependent on me personally approving community build scripts. I also plan to stay on this version when it freezes instead of jumping immediately to the next testing branch. Need for predictability has been growing in me for some time.