The Arch Linux Hate Manifesto

Installing Fedora:

Click next.

Installing openSUSE:

Click next, configure things if you want.

Installing Debian:

Answer some questions.

Installing Arch:

Welcome, initiate.

You boot the ISO.

There is no graphical installer greeting you.

There is a shell.

The shell looks at you.

You look at the shell.

The shell says:

You wanted Linux.

Prove it.

You partition your disks.

Format them.

Mount them.

Bootstrap a system.

Generate fstab.

Chroot.

Set locale.

Set timezone.

Configure networking.

Create users.

Configure sudo.

Install a kernel.

Generate initramfs.

Install a bootloader.

Configure the bootloader.

Enable services.

Reboot.

Congratulations.

You have accomplished manually what an installer has been doing since your parents were young. The installer never demanded respect for it, either.

The installer is a job interview you conduct with yourself. You answer every question correctly and reward yourself with a computer that still cannot open a fucking browser.

Yes.

That is actually true.

Installing Arch manually can teach useful things:

• partitioning;
• mounts;
• EFI;
• bootloaders;
• filesystems;
• chroot;
• package management;
• networking;
• service management.

This is a legitimate educational benefit.

But there is an important distinction:

Educational value is not operational superiority.

Rebuilding a carburetor teaches you a lot about engines.

It does not mean carburetors are superior to electronic fuel injection.

Manually installing GRUB does not make GRUB run better.

Typing:

pacstrap -K /mnt base linux linux-firmware

does not increase system reliability through spiritual merit.

You merely did the installer's job.

This is the central disease.

There exists a particular kind of Linux user who subconsciously ranks distributions like:

Ubuntu
↓
Fedora
↓
Debian
↓
Arch
↓
Gentoo
↓
Linux From Scratch
↓
writing an operating system yourself
↓
communicating directly with silicon through prayer

and concludes that movement downward represents greater technical sophistication.

It does not.

These distributions optimize for different engineering objectives.

An operating system that requires more user intervention is not necessarily:

• faster;
• safer;
• more reliable;
• cleaner;
• more secure;
• better designed;
• more suitable for production;
• or more capable.

Sometimes it simply requires more user intervention.

A staircase isn't more advanced than an elevator because you did more work.

We must be fair.

pacman is fast.

Its CLI is clean once learned.

Package building is pleasantly straightforward.

PKGBUILD is one of Arch's genuinely excellent ideas.

Arch package infrastructure has an elegance many distributions should envy.

And then someone inevitably types:

pacman -Sy

and accidentally enters the unsupported-reality timeline.

Arch is rolling release.

Its repositories move together.

Therefore partial upgrades are unsupported.

The correct incantation is:

pacman -Syu

Not:

pacman -Sy

because refreshing package databases without bringing the installed system forward can create mismatches.

This is well documented.

It makes technical sense.

But it is incredibly funny that one missing letter can change the operation from:

normal system maintenance

to:

you have violated the social contract.

Arch support thread:

“I ran pacman -Sy foo—”

THREAD LOCKED

The council has convened.

One missing letter and your package set becomes a committee of mutually incompatible alibis. But yes, tell me more about how explicit everything is.

Most operating systems:

Updates available.

Arch:

Before updating, please check current affairs.

The Arch maintenance documentation explicitly recommends checking Arch News before upgrades because certain updates can require unusual manual intervention. It also recommends having rescue media available, dealing with .pacnew files promptly, and avoiding an update immediately before something important if you cannot afford troubleshooting.

That is responsible documentation.

It is also the funniest possible validation of this joke:

Arch isn't an operating system.

It's a newsletter with a package manager.

pacman -Syu

Before continuing:

HAVE YOU READ TODAY'S PAPER?

Debian update:

apt update && apt upgrade

Arch update:

pacman -Syu

but first:

Check Arch News.

Check whether glibc changed.

Check whether NVIDIA exploded.

Check whether your AUR packages still build.

Look for .pacnew.

Read the output carefully.

If you use an important production system, perhaps stage the update elsewhere first.

Arch's own maintenance documentation is basically:

Please maintain Arch.

Yes.

That's the deal.

But I'm allowed to laugh at the deal.

Nothing captures Arch's philosophy better.

A package updates a configuration file you modified.

Arch wisely doesn't overwrite your configuration.

Instead:

foo.conf.pacnew

appears.

Now it is your problem.

This is technically conservative and often preferable to silently mangling local configuration.

But accumulate enough of them and /etc begins sending you passive-aggressive reminders:

sshd_config.pacnew
pacman.conf.pacnew
mkinitcpio.conf.pacnew

Your operating system has left several unread messages.

Your /etc directory has unread messages. Even your configuration files have noticed you keep saying “later.”

And now we arrive at the radioactive core.

The Arch User Repository.

Arch users will tell you:

“Anything is in the AUR.”

This is nearly true.

Need obscure proprietary software?

AUR.

Need yesterday's Git commit?

AUR.

Need some abandoned CLI utility authored by one Bulgarian student in 2013?

AUR.

Need software that has never been packaged by a human being who understands the concept of maintenance?

Oh boy, does AUR have you covered.

The AUR is one of Arch's greatest advantages.

It is also Linux's largest organized exercise in:

“Surely somebody else looked at this.”

This distinction gets blurred constantly.

The official Arch repositories distribute packages maintained through Arch's repository infrastructure.

The AUR distributes user-submitted build recipes.

Arch itself says the PKGBUILDs are completely unofficial, have not been thoroughly vetted, and must be used at the user's own risk. It explicitly instructs users to inspect PKGBUILD, .install, and other repository files for dangerous commands.

Translation:

“Here's shell code from the Internet.”

“You are about to build it.”

“Please read it.”

Which would be fine if humans reliably read shell scripts.

Humans do not reliably read privacy policies.

The theoretical AUR workflow:

find package
↓
inspect package history
↓
inspect maintainer
↓
read PKGBUILD
↓
inspect .install
↓
verify sources
↓
inspect changes since previous build
↓
build
↓
install

The actual workflow:

yay -S whatever

Enter.

Enter.

Enter.

Done.

The same Arch user who spent four hours selecting the perfect initramfs compression algorithm will execute arbitrary community-maintained packaging logic because:

842 votes. Seems legit.

You reviewed the PKGBUILD with the Enter key. An extraordinary technique: the faster you press it, the less responsible you feel.

This is the official sensible answer.

It is also an astonishing security model when applied at ecosystem scale.

Suppose an AUR user has 30 packages installed.

Every update potentially changes:

• PKGBUILD;
• source URLs;
• hashes;
• .install;
• patches;
• shell fragments;
• build logic.

Security doctrine:

Manually code-review all changes forever.

Excellent.

Have we considered replacing TLS certificates with:

“Just visually inspect the server”?

In June 2026, Arch officially announced a high volume of malicious AUR package adoptions and updates.

Not:

one sketchy package named free-robux-bin.

Actual malicious adoptions and updates affecting existing AUR workflows.

Arch administrators started tracking and reverting malicious commits and temporarily restricted AUR functionality. Registration was shut down during cleanup and later reopened with hardened registration. Then another malicious-adoption wave at the end of July caused adoption to be disabled, followed by all pushes being temporarily disabled on August 1.

Arch staff handled an ugly situation.

That deserves credit.

But the incident also punched directly through the fantasy version of AUR security:

“It's fine because PKGBUILDs are transparent.”

Malware can also be transparent.

You still have to fucking read it.

This deserves engraving above every AUR helper download button.

VISIBLE CODE ≠ REVIEWED CODE

The malicious instruction can be sitting right there.

In plaintext.

Completely open source.

Beautifully transparent.

And if 40,000 people execute it without reading it:

congratulations, it was transparently malicious.

Supply-chain attackers do not need to defeat open source.

They need to defeat human attention span.

That is substantially easier.

ArchWiki:

Inspect AUR build files carefully.

Users:

yay -Syu

ArchWiki:

AUR helpers are unsupported.

Users:

paru

ArchWiki currently explicitly warns that AUR helpers are unsupported and users should understand the manual process so they can vet package sources. It even notes that helper behavior can matter for whether users get a proper opportunity to review build files.

There is something deeply Arch about the ecosystem's most famous convenience feature being accompanied by:

“We don't support the convenient way you all use it.”

Arch:

The AUR should be manually inspected.

Community:

I have automated it.

Arch:

That's unsupported.

Community:

I wrote the automation in Rust.

Arch:

Please read the PKGBUILD.

Community:

The automation displays a diff.

Arch:

Please actually read the diff.

Community:

--noconfirm

Security:

bonjour

Arch frequently operates on:

User competence is part of the security boundary.

That philosophy isn't inherently wrong.

Administrator responsibility is real.

But it scales poorly because real users eventually become:

• tired;
• rushed;
• distracted;
• accustomed to routine;
• overconfident;
• lazy.

The 437th yay upgrade feels nothing like the first.

Warning fatigue is real.

The strongest sandbox in the world cannot protect a user whose security workflow is:

“Looks green.”

Correct.

npm has them.

PyPI has them.

RubyGems has them.

Container registries have them.

Vendor repositories have them.

Even signed package ecosystems can suffer compromised maintainers, upstreams, CI systems, signing keys, or distribution infrastructure.

AUR is not uniquely capable of compromise.

The roast is more specific:

AUR's enormous usability value encouraged a user workflow far more convenient than its underlying trust model really deserves.

AUR is phenomenal when treated as:

community-submitted packaging source code requiring scrutiny.

It becomes sketchier when treated psychologically as:

Arch App Store.

Arch advocates say:

“You don't have to reinstall for new releases.”

Correct.

Instead, release day is every day.

There is no Fedora 43 upgrade.

No Ubuntu 26.04 upgrade.

No openSUSE Leap migration.

You simply live permanently inside the upgrade.

Arch solved release-upgrade anxiety by distributing it across the entire calendar.

Arch is often called bleeding-edge.

Arch users frequently object:

“Actually, Arch generally packages stable upstream releases. It's cutting-edge, not necessarily bleeding-edge.”

Fair correction.

Unfortunately your Bluetooth still stopped working Tuesday.

Semantics did not reconnect it.

This distinction matters.

Package A:

upstream stable

Package B:

upstream stable

Library C:

upstream stable

Kernel:

upstream stable

Mesa:

upstream stable

Desktop:

upstream stable

Put their newest releases together immediately and you have:

integration testing.

Congratulations.

You are integration testing.

The components can each individually be stable while the combination has not accumulated the same deployment age as a conservative distribution.

This is not an insult.

It's literally the rolling-release tradeoff.

But stop pretending freshness has no operational cost.

Gentoo deserves plenty of roasting too.

Gentoo user:

“I compiled Chromium for nine hours.”

Why?

“USE flags.”

Fine.

At least Gentoo is honest about the transaction.

Gentoo says:

This distribution gives you absurdly granular control, source-based package management, compile-time feature selection, and enough knobs to recreate dependency hell as an artisanal hobby.

The user knowingly says:

Yes. Give me that.

Respect.

It's deranged.

But internally consistent.

If you spend time on Gentoo, you can actually point at mechanisms like:

• USE flags;
• custom compile options;
• source patches;
• package masking;
• slotting;
• fine-grained dependency configuration;
• alternative implementations.

Whether those benefits justify compiling half the universe is another matter.

Usually?

Probably fucking not.

But the complexity corresponds to a technical degree of freedom.

Some Arch difficulty is simply:

“We deliberately don't configure this for you.”

Which gives control, yes.

But once the configuration is complete, you haven't necessarily created a technically superior machine.

You've created a machine you configured yourself.

Those are different achievements.

The existence of archinstall created a philosophical crisis.

Old-school Arch user:

“Installing Arch teaches you your system.”

New user:

archinstall

Old-school Arch user:

No, not like that.

Arch itself:

Installation successful.

Old-school user watching their cultural gatekeeping evaporate:

:(

If an official installer can automate the sacred ritual without making the resulting system measurably worse, perhaps the ritual was never the source of Arch's power.

Archinstall did in minutes what your origin story describes as a spiritual transformation. The machine boots exactly as smugly either way.

By this logic:

• programmers don't understand compilers unless they bootstrap GCC;
• network engineers don't understand Ethernet unless they solder switches;
• database administrators don't understand PostgreSQL unless they implement a B-tree;
• pilots don't understand aircraft unless they smelt the aluminum.

Abstraction is not ignorance.

The question is whether you can descend into lower layers when necessary.

You do not prove competence by refusing automation.

You prove competence by understanding when automation is trustworthy and when to inspect underneath it.

Ansible-managed Arch:

reproducible configuration.

Btrfs snapshots:

recoverability.

Automated package review tooling:

reduced risk.

Monitoring:

operational awareness.

Testing:

validation.

Arch purist:

But then you're not learning.

My brother, I am operating computers.

This is not a monastery.

Can Arch run servers?

Obviously.

A Linux distribution with current kernels, systemd, containers, networking and a huge package ecosystem can run servers.

The actual question is:

Why?

For a server that benefits from extremely new kernels, Mesa, drivers, tooling, or particular upstream features, Arch can be reasonable.

For a homelab box whose job is:

Jellyfin
PostgreSQL
reverse proxy
some containers
exist quietly

what exactly is Arch contributing?

New glibc?

Weekly kernel excitement?

The freshest Bluetooth stack your headless server has never asked for?

Congratulations.

Your NAS now supports hardware released yesterday.

Jellyfin:

I need ffmpeg and access to the GPU.

Arch admin:

Good news, you're getting systemd 259 tomorrow.

Jellyfin:

Why?

Arch admin:

Rolling release.

PostgreSQL:

Please leave me out of this.

The official Arch maintenance guidance itself says that if Arch is used in production where downtime is unacceptable, updates and configuration changes should be tested on a non-critical duplicate system first.

That's sensible professional practice for any serious environment.

It also makes the homelab scenario magnificent:

“I chose Arch because it's lightweight.”

Three months later:

staging server required.

Debian:

apt upgrade

Your staging environment has the same hostname as production because you believe in learning from experience. Your users are about to experience your learning.

Arch:

new kernel.

User:

Cool.

Tomorrow:

another kernel.

User:

Cool.

Three days later:

another kernel.

Server:

I have been rebooted more times this month than the Proxmox node has in three years.

Arch user:

Freshness.

Eventually the Arch server user discovers:

linux-lts

This is the natural lifecycle.

Step 1:

I want bleeding-edge Arch.

Step 2:

Maybe I'll use the LTS kernel.

Step 3:

Maybe I should pin some things.

Step 4:

Perhaps I want slower-changing packages.

Step 5:

Wait.

Step 6:

Debian.

Desktop user:

I just want to game.

Arch:

Great. Latest Mesa!

That's legitimately excellent.

Arch:

Latest kernel!

Also useful.

Arch:

Latest Wine ecosystem!

Nice.

Arch:

Latest everything else too!

Wait.

I wanted new Mesa.

I did not specifically request an intimate relationship with every upstream project's release cadence.

This is where Arch earns its reputation.

New GPUs and gaming stacks can genuinely benefit from:

• recent Mesa;
• recent kernels;
• recent firmware;
• recent Vulkan;
• recent Wayland improvements.

This is why Arch and Fedora are attractive on newer enthusiast desktops.

But compare the philosophies.

Fedora:

Here's a modern integrated system with new technologies delivered on an approximately six-month release cadence, plus frequent kernel updates.

Arch:

Open the upstream firehose.

Both are valid.

One involves slightly fewer opportunities to learn the names of package maintainers personally.

Normal person:

Stability means predictable behavior and low regression risk.

Arch discourse:

Actually, stability means API/ABI stability, not whether it crashes—

Stop.

We both know what Grandma meant when she said:

“I want my computer to be stable.”

She did not mean:

“I require guarantees concerning upstream interface compatibility.”

Her fucking printer stopped working.

There is always one.

“I've used Arch for seven years and it has never broken.”

Possible.

Completely believable.

Well-maintained Arch systems can be reliable.

Then you ask what they do.

“I read the news, inspect updates, merge pacnew files, maintain AUR packages, use snapshots, keep rescue media nearby, and don't update before important work.”

Sir.

You are the reliability mechanism.

That is not the rebuttal you think it is.

Debian:

Stability is largely a distribution property.

Arch:

Stability is a collaborative project between the distro and Kevin.

Kevin goes on vacation.

Server:

Uh oh.

Experienced Arch users eventually configure Btrfs + Snapper or another snapshot system.

Excellent decision.

Then the distro becomes much more comfortable because bad upgrades are recoverable.

openSUSE user walking past:

“Oh, you discovered the default installation.”

Arch user:

Shut up.

A package update regresses.

Arch solution:

downgrade it.

Fine.

Then remember:

partial upgrades are unsupported.

So now you're carefully navigating package versions inside a distribution conceptually designed around everything moving forward together.

This is not impossible.

It is simply another reminder:

rolling release optimizes for forward motion, not historical serenity.

Sometimes yes.

Debian Stable can make a software version look like it has a mortgage.

But again:

requirement.

If your reverse proxy requires features introduced yesterday:

Arch may win.

If your reverse proxy has worked flawlessly since 2024:

I do not give a fuck whether a newer minor version exists.

Version numbers are not Pokémon.

You don't have to catch them all.

I do not want my server to have an arc.

I do not want:

update episode.

dependency episode.

bootloader episode.

AUR security episode.

NVIDIA episode.

Python transition episode.

I want the server's story to be:

Season 1–12: It ran.

Finale:

PSU failed.

That's acceptable.

Arch server:

latest kernel.

Arch router:

latest kernel.

Arch NAS:

latest kernel.

Arch hypervisor:

latest kernel.

Arch desktop:

latest kernel.

One upstream regression:

homelab-wide live-fire exercise.

This is called:

technological homogeneity.

Or:

putting every egg into the same rolling-release chainsaw.

The whole rack is down. At last: a consistent configuration across all environments.

Arch absolutely teaches Linux.

Because the curriculum never ends.

Semester 1:

Installation.

Semester 2:

Package management.

Semester 3:

initramfs.

Semester 4:

AUR.

Semester 5:

boot failure.

Semester 6:

shared library transitions.

Semester 7:

why the fuck did Electron stop launching?

Graduation:

install Debian on the server.

Ubuntu:

apt

Fedora:

dnf

Arch:

pacman

Okay, Arch wins this one.

No roast.

That's fucking adorable.

Also good.

Seriously.

PKGBUILD + makepkg is elegant enough that packaging random software for personal use is often much less painful than dealing with traditional distro packaging systems.

This makes AUR possible.

It is one of Arch's strongest technical achievements.

Which makes it deeply unfortunate that human nature eventually turned:

easy-to-audit shell packaging recipes

into:

universal unattended app store via yay.

A tool's ergonomics can outrun its trust model.

2026 provided the reminder.

Attacker:

Could we compromise Arch's signed official repository?

Difficult.

Could we compromise the kernel?

Difficult.

Could we compromise pacman?

Difficult.

Could we upload or adopt community packages and count on people treating AUR like an app repository?

Security engineer:

…

Attacker:

🙂

The strongest cryptography in the world eventually encounters:

yay -S cool-new-tool

Arch user updates 27 AUR packages.

Package one:

4-line version bump.

Package two:

2-line checksum change.

Package three:

600-line generated patch.

Package four:

upstream URL change.

Package five:

minified JavaScript downloaded during build.

Package six:

Rust dependency galaxy.

Package seven:

npm.

User:

Yeah, I'm sure I'll perform a meaningful security audit.

The theoretical security model has now collided with economics.

Important point.

The conclusion is not:

AUR bad, never use AUR.

The conclusion is:

AUR is powerful precisely because it delegates trust and responsibility to users. Treating it like an official repository erases the distinction that makes its model tolerable.

Use it intelligently.

Prefer reputable packages.

Read diffs.

Avoid unnecessary AUR dependencies.

Understand what the build executes.

Be more suspicious when packages change ownership/adoption.

And perhaps don't install:

totally-real-google-chrome-premium-cracked-git-bin

because it has three votes.

Arch's philosophy is:

Keep the distribution simple.

The user's experience can become:

Maintain considerable complexity yourself.

This isn't contradictory once you understand what simple means in Arch philosophy.

Simple means:

relatively direct, minimally patched, user-controlled design.

It does not necessarily mean:

low-effort administration.

But newcomers hear:

simple

and imagine:

easy.

Then the ISO boots into a shell.

Arch loves KISS:

Keep It Simple, Stupid.

Arch interpretation:

Don't hide complexity behind distribution automation.

Normal person's interpretation:

Why am I configuring this manually?

Both can plausibly claim KISS.

This is why software engineers have spent fifty years weaponizing the word “simple.”

If your distro doesn't decide something:

you decide it.

If your distro doesn't configure something:

you configure it.

If your distro doesn't integrate something:

you integrate it.

Sometimes this is exactly what you want.

But there is no conservation law where removing distribution policy destroys complexity.

It often transfers complexity from:

maintainer

to:

user.

Arch is extremely good at this transfer.

pacman -Qdt

Arch user:

Orphans!

Remove them.

Application breaks.

Turns out something was using it in a way package metadata didn't capture.

Arch user:

Interesting.

There is that word again.

Interesting is what stable-server administrators call an incident.

Some Arch users update daily.

Others weekly.

Others wait months.

The person waiting months finally types:

pacman -Syu

Terminal:

7.3 GB

User:

God has abandoned me.

ArchWiki:

You were advised to upgrade regularly.

The rolling release has been storing kinetic energy.

Open laptop after six months.

Battery:

41%.

Packages:

Bronze Age.

Run update.

Mirrors have changed.

Keys need refreshing.

One package moved repositories.

AUR package no longer exists.

Python has advanced three geological periods.

Laptop was supposed to check email.

Now you are performing a distribution migration with no version number.

Should beginners use Arch?

If they specifically want to learn Linux internals and accept manual maintenance:

Absolutely.

If they want:

“Linux but Steam”

please stop sending them to the installation guide like you're recruiting for the Foreign Legion.

Fedora exists.

Mint exists.

Ubuntu exists, unfortunately.

openSUSE exists.

A beginner does not need to understand genfstab before playing Baldur's Gate.

Making basic operations difficult can force learning.

This is true.

But forced learning isn't automatically efficient learning.

You can teach filesystem concepts deliberately without requiring a student to manually construct their workstation before they can open Firefox.

Otherwise the optimal computer-science curriculum would begin:

Chapter 1: Build DRAM.