2026 - Friday, June 19th

Tech · Linux · Systems

A Year on Arch: What I Got Right, What I Got Wrong, and What I'd Tell Myself

March 28, 2026 Fisher Armstrong ~8 min read
Arch Linux iMac Workflow Photography DevOps

Moving a 2017 iMac to Arch Linux was not the path of least resistance. It was, however, the correct decision. A year in, the system has settled into something stable enough to forget about, which is usually the goal.

This is a retrospective of what actually worked, what didn’t, and what would be done differently with hindsight.

Why an iMac, of all things

The decision was not motivated by novelty. The hardware was already available and still capable. The previous setup (Pop!_OS) functioned, but “functioning” was not the requirement.

The objective was control: understanding the system from the ground up rather than inheriting defaults and abstractions.

Design Constraint

Arch was chosen specifically to avoid hidden system decisions and enforce explicit configuration.

What I Got Right

KDE Plasma immediately

No experimentation phase. Plasma was already familiar, configurable, and predictable. A year later, the configuration still matches the original intent.

Using an AUR helper early (paru)

Package access became a non-issue. The AUR effectively eliminated friction for tooling that would otherwise require manual builds.

Not forcing a macOS-like interface

Attempts to replicate previous UI paradigms would have introduced unnecessary friction. Plasma was treated as its own environment rather than something to reshape into a prior system.

Separating homelab and daily driver

Production services remained on a separate machine. This avoided coupling system updates with service uptime risk.

Structural Decision

Decoupling workloads prevented update anxiety from becoming operational friction.

What I Got Wrong

Underestimating photography workflow migration

RAW processing and culling were not drop-in replacements. The tooling existed, but the workflow required rebuilding rather than porting.

Assuming Arch would never require recovery time

Nothing broke catastrophically, but updates occasionally required manual intervention. No rollback plan was initially documented.

Not documenting configuration decisions

Several months later, system behavior had to be reconstructed from memory and dotfiles. This became the largest avoidable time cost.

Failure Mode

Undocumented configuration turns into future reverse engineering.

The Dev Stack Under Load

Across Python, JavaScript, C, and Docker workflows, Arch never became a bottleneck. Package availability was either immediate or resolved through AUR access.

The primary discipline required was procedural: not running full system upgrades without reviewing changes.

Operational Note

Rolling release systems require attention, not automation bias.

What I’d Tell Myself

Document configuration decisions immediately. Treat photography workflow migration as a project, not a side effect. Do not assume familiarity translates across operating systems.

Most importantly, accept that Arch is not fragile, but it is explicit. That distinction matters more than initial setup time.

Final State

One year later, the system remains the daily driver. The only real improvement would have been faster documentation discipline.