Claude Code shipping a version of the lights widget on the ThinkPad, with the widget's own panel open from the bar.
The first Linux I ran came on a stack of floppy disks. It was SLS, early 1990s, and getting the kernel to boot felt like winning something. I moved to Slackware soon after and stayed for years. In early 1995 I turned my personal 386, with 32 MB of RAM, into my university's first web server. That's still one of my favorite sentences to say out loud, and nobody at a dinner party has ever asked a follow-up question.
Everything since then has run on Linux, and almost none of it has been something I looked at. Slackware gave way to Red Hat, then CentOS and Fedora, then Debian. Linux won the server room and then the cloud, and I've spent the last decade building cloud platforms on it. My desk stayed a Mac the whole time. I never thought of that as a contradiction. Linux was where the work ran, and the Mac was where I typed.
A few days ago I installed Omarchy on an old ThinkPad, and the split I'd lived with since that 386 stopped making sense. Linux didn't get more capable last week. Someone finally made the decisions I'd been making for myself since the floppy disks, and that's the part I keep thinking about. Omarchy applies a platform-engineering lesson all the way down to the developer's desktop. Choose good defaults, make the common path coherent, preserve the escape hatches, and make the environment understandable to both the human and the agent.
Installing Omarchy on the ThinkPad T490s.
Everything except the desk
The year of the Linux desktop is a joke older than some of the engineers on my team. Linux itself was rarely the main problem. It runs phones, cloud infrastructure, routers, and most of the supercomputers on the planet. The harder problem was making a laptop feel finished on the first boot.
I think the reason comes down to two taxes. The first is the setup tax. A fresh Linux desktop asks you to choose a distribution, a desktop environment, a window manager, a terminal, a shell, an editor, a font, and a theme. Then it asks you to make all of them agree with each other. The second is the debugging tax. When Wi-Fi, suspend, or display scaling fails, you can end up on a forum thread from 2014 with a fix for a different kernel. Each tax is survivable on its own. Together they explain why so many of us kept the Mac.
That framing also explains why macOS won so many developers in the first place. Apple's advantage was never the kernel. It was the defaults. The hardware matched the software, the terminal was good, and someone else had already made the hundreds of small decisions a working desktop requires. You could change many of them, and most people never needed to.
Two minutes on an old ThinkPad
Omarchy is Arch Linux plus the Hyprland tiling compositor plus a large, opinionated set of defaults, shipped as a single ISO. David Heinemeier Hansson, the creator of Ruby on Rails, started it as a script that turned a fresh Arch install into a configured development desktop. It's now a full distribution on its 4.x line, which he calls Quattro. The "oma" is from omakase, the chef's-choice menu at a sushi bar. DHH picks the tools and tunes the details so you can start working, and the system stays yours to change.
I put it on a ThinkPad T490s with a Core i7 that had been living in a drawer. The longest part of the whole process was me poking around the firmware menu to turn off Secure Boot. The machine wouldn't boot from the USB drive until I did. That took longer than the install, which took two minutes.
Then I braced for the debugging tax, and on this machine it never came. Everything worked. Even the fingerprint reader, which I'd mentally written off as a Windows-only organ, showed up. Omarchy recognized it and had my finger enrolled in about 30 seconds. I kept waiting for the part where I open a terminal and start reading kernel logs, and that part never arrived. I've installed a lot of Linux since those floppies, and I've never had one of my own desktop installs go like this.
Omarchy 4 running on the ThinkPad T490s that had been sitting in my drawer.
The individual choices matter less than the fact that they agree with one another. Terminal, editor, window manager, filesystem, themes, and agent tooling arrive as one coherent opinion instead of a set of projects you have to integrate yourself. Themes switch the terminal, editor, and window manager together. The filesystem is Btrfs with snapshots. A dozen agent command-line tools, including Claude Code, Codex, OpenCode, GitHub Copilot, and Pi, sit on the path as lazy launchers. Nothing downloads until you run one. You pick a default agent during setup, or later with omarchy default agent and the name of the one you want. Someone made the hundreds of decisions, and the system feels better because those decisions were made together.
Omakase doesn't mean you eat everything on the plate. The first thing I changed was the terminal. Omarchy ships with foot. I swapped it for Ghostty because I prefer it, and nothing about the system argued with me. Neovim is the default editor, and it's a good one, but you can run the editor you already know. That distinction matters. A good platform should be opinionated about the common case and permissive about the uncommon one. The hard part is knowing which decisions belong in each category.
The product is the defaults
This is where the distro review turns into something I spend most of my working life on. I run platform teams, and one of the clearest lessons from that work is that a platform's defaults decide whether people adopt it. Nobody studies the architecture of the golden path before they use it. They take the path if the first 10 minutes work, and they abandon it if the first 10 minutes require a ticket. Every choice you don't have to make is a choice you can't get wrong. Every escape hatch you keep open is a reason the power users stay.
Omarchy is that idea applied to an operating system. It takes Arch, which has a reputation for making you earn every working component, and puts a curated layer on top. The pieces are old. The assembly is the product. That's the same bargain the Mac offered developers years ago: good defaults, coherent behavior, and fewer decisions before you can get to work. The difference now is that the environment is designed with agents in the loop.
The debugging half of that story is the part I can't judge yet. Omarchy's own homepage promises agents that debug all issues, and the design assumes you'll ask an agent before you start a web search. On my laptop, nothing broke, so I never tested that promise. A speed claim I haven't verified is a question, not a result. I'll keep it filed as a question until something on this machine fails.
There's already one enterprise data point. 37signals has said it will move its ops and Ruby teams to Omarchy over the next three years. That's a stronger vote than any blog post, mine included.
What happens when the agent belongs there
So I tried the other half of the promise. The agents in Omarchy aren't only there to help fix things. They operate inside an environment whose structure is unusually legible to them, so I asked Claude Code, my default, to build something for it.
The result is a bar widget that controls my Home Assistant lights by room. Click the bulb in the bar and a panel drops down with a row for each room. Each row has an on/off switch and a brightness slider, plus an arrow that expands the room into its individual bulbs. Right-click the bulb and the whole house goes dark. A day later it grew scene chips and a color-temperature slider, both built the same way. It installs with one command, omarchy plugin add. It uses Omarchy's own panel, switch, and slider components, so it follows whatever theme you're running without styling work from me.
The lights panel, drawn with Omarchy's own components so it follows the theme.
What surprised me was how little I had to explain. Omarchy 4 ships a Quickshell-based bar with a plugin system. The agent could inspect the conventions, find the right components, and build to the platform instead of inventing around it. It laid out a manifest, a bar widget in QML, a panel in QML, and a small shell script for the Home Assistant calls. It also handled the part most quick scripts get wrong. The access token lives in a file only my user can read. The script hands it to curl through a file descriptor, so it never shows up in process arguments, environment variables, or the widget's state.
That's more interesting to me than the fact that Claude Code was installed. Installation is trivial. The important part is that the environment exposes enough structure for the agent to understand the platform it's modifying. The plugin model is explicit, the components are discoverable, and the conventions are consistent. The agent doesn't need a private map of the system because the system already has one. On my Mac, Claude Code is an application I installed. On Omarchy, it feels closer to a native participant in the environment.
The code is at github.com/vscarpenter/omarchy-ha-lights, MIT licensed. It has a demo mode with made-up rooms if you want to try it before handing it a token.
What I don't know yet
A few days on one laptop is a small sample, and I want to say that plainly. Arch is a rolling distribution, and rolling distributions accumulate risk over months rather than days. The snapshots should catch a lot of it. I'd like to say that again in six months.
Omakase also cuts both ways. You can swap the terminal and the editor. You can't swap Hyprland without giving up much of what makes Omarchy Omarchy, and Hyprland is keyboard-first. Plenty of excellent engineers don't want to learn a new set of hands. For them, the first week may cost more than the two-minute install saved.
And the corporate question is open. At a large enterprise, a developer laptop has to carry device management, endpoint security, patching, identity integration, and a compliance story. None of that ships on an ISO. I don't expect to see Omarchy on fleets of regulated laptops soon. What would change my mind is a larger company running it as a managed developer endpoint with the security and compliance controls intact.
The alternative for people who want one
macOS is entrenched as the developer machine, and I don't think that changes this year or next. Linux has been capable of being a developer desktop for years. What changed is that the cost of assembling one may finally be disappearing, and that's a platform problem more than a Linux problem. A few days on one ThinkPad can't prove that Linux has won the desktop. It does show what happens when someone treats the desktop like a platform product instead of a box of parts.
The 386 took a stack of floppies. The ThinkPad took two minutes, and most of that was me looking for the Secure Boot switch.