The things I like most about using Arch are also the things people keep trying to save me from. Setting something up, getting it wrong, reading the documentation and eventually understanding why it works. I didn't come to Linux just to get a different desktop. I wanted to know what my computer was doing.
So when somebody packages that whole experience into a ready-made setup, I understand the appeal. But when the next promise is that an AI can handle the things I don't understand, I start wondering what kind of relationship with my computer I'm being offered. I wanted to become more capable of looking after it myself.
That is my problem with Omarchy. It looks good. Clearly a lot of work has gone into making the pieces fit together. But I think its pitch puts too much value on what I can avoid learning and too little on what I could learn to control. Making those decisions myself was a large part of why I wanted Arch in the first place.
Yes, this is going to be an Arch user explaining why he likes configuring things. You had fair warning from the title.
I've held off on writing this for a while because I really don't want to be the guy greeting someone who's excited about Linux with "you're doing it wrong." I like the momentum Omarchy has around bringing new people in. If someone installs it, enjoys it and finally feels comfortable using Linux, I'm happy about that. The last thing I want is to contribute to the negativity that makes them wonder why they bothered.
So if Omarchy is how you got here, welcome. I hope you stick around. What I want to make a case for is taking the next step, getting curious about the system you've installed and finding out how much of it you can make your own. That's the part I enjoy most, and I'd hate for the promise of an easy setup to make it sound like something worth avoiding.
I Wanted to Know Why
There is something satisfying about looking at your setup and knowing why it's like that. You picked the window manager. You know where the keybindings live. That slightly odd behaviour exists because you changed something to suit the way you work, and you remember what you changed.
It doesn't have to be impressive. Nobody else needs to want your configuration. You understand it, and when you want it to behave differently you have some idea of where to start.
That matters more to me than having a desktop that looks good in a screenshot. I like a beautiful desktop too, obviously, I've spent enough time on zenkai's themes to lose any right to pretend otherwise. But I want to understand the thing underneath it.
Some of that understanding comes from curiosity. Some comes from a much less noble place: something annoys you enough that you finally go and find out how to change it. You read about an option you didn't know existed, find the file that controls it, and suddenly one more part of the system makes sense.
You might not have set out to learn anything that evening. You just wanted your shortcut to work. But now you know something you can use the next time you have a problem.
A Finished Desktop Is Someone Else's Starting Point
Omarchy's own pitch is a working system with the tools and details already chosen for you. It also explicitly says you're free to change everything. The source is available, so I'm not going to pretend this is a locked appliance or that installing it takes away your permission to edit a configuration file.
You can use it as a starting point and learn from it. Reading a working configuration is useful. My criticism is of the direction being sold, not a claim that every Omarchy user accepts it or stops learning.
But you can also stop at the finished desktop. Everything works, the choices look reasonable, and there's no particular reason to investigate what made it work. The opportunities to learn are still available. The reasons that would have pushed you into them have become less immediate.
This is where I think Omarchy's pitch falls short. It puts a lot of emphasis on removing the setup, the decisions and the troubleshooting. Those can be frustrating, but treating them mainly as problems to eliminate undersells what you can learn from them. I'd like to see as much enthusiasm for helping people understand the system as there is for getting them past the need to understand it.
Of course someone with work to do might happily accept that tradeoff. I do too, with plenty of tools. But it is a tradeoff, and I don't think a shorter installation tells us much about how capable we'll feel when we want something the default setup didn't anticipate.
For me, though, being handed a setup where the interesting decisions have already been made can feel pretty boring, even when the result is pretty. I want to try things, disagree with the defaults and work out what I actually like. Getting to a usable desktop was never the whole project.
An opinionated desktop also means adopting somebody else's preferences before you've worked out your own. That can be helpful, but it isn't automatically simpler once you start disagreeing with those choices. Now you have to learn what the underlying tools do and how the curated setup connects them. The complexity hasn't disappeared just because you didn't encounter it during installation.
You Can Put This Together Yourself
Omarchy isn't black magic. There is real work in integrating a desktop and maintaining it for other people, and I don't want to dismiss that. But you don't have to recreate everything Omarchy ships to put together an Arch and Hyprland setup that works for you. You only need the parts you actually want.
I think that is a much more approachable project than people make it sound. Start with a working Arch installation and follow the Hyprland tutorial. Get a terminal open, configure your display and choose a few keybindings. Then add the things you need: a launcher, notifications, a bar if you want one. You don't need somebody else's entire desktop before you can start using yours.
Hardware can complicate things, and a first installation will take longer than your fifth. But choosing a terminal, changing a shortcut and adjusting a configuration file are things you can learn. You don't need years of Linux experience before you're allowed to try. A basic personal setup can be fairly straightforward; getting every colour and animation exactly how you want it is the part you can happily turn into a hobby.
And it doesn't have to look like anybody else's. Maybe you don't want a bar. Maybe you want different shortcuts, fewer animations or a launcher that behaves differently. You get to make those decisions one at a time, and by the end you know why each piece is there.
That is a practical kind of ownership. When a shortcut stops working, you know where you defined it. When you want to replace a program, you know what calls it. You can keep your configuration in Git, see what you changed and go back when an experiment doesn't work out. The time you spend setting it up buys you some independence the next time you need to change it.
Convenience Can Become Dependence
For me, ownership includes being able to disagree with the people who made the tool. I want to remove something they like, keep something they don't, and fix a problem without waiting for their preferred solution. Having permission to do those things matters. Having enough understanding to actually do them is what makes that permission useful.
Omarchy doesn't have to take away the first for me to worry about the second. If every change goes through a menu or an agent, you can end up with a computer you're allowed to modify but don't really know how to investigate. When something stops working, your next step is to ask the same tool for another fix.
That can happen on a manually installed Arch system too. Copying commands you don't understand isn't magically educational because you typed them into a terminal. And a good graphical tool can explain what it's doing better than a page of unexplained shell commands. The interface isn't the deciding factor.
Imagine replacing your launcher and finding that the old one still opens from a shortcut. If you know where the binding lives and what starts the program, that's something you can investigate. If your only approach is to ask an agent to fix it, you have to trust that it finds the actual cause rather than adds another change around it. You might get the shortcut back without getting any closer to understanding your setup.
That is the loss of ownership I'm worried about. The files can still belong to you while your ability to make decisions about them depends on something else. No one has to lock you out for you to feel unable to proceed without help.
This Is the Same Argument I Keep Having About AI
In We Were Not All Terrible Developers I wrote about the idea that generating code removes the need for developers who understand it. This bothers me for the same reason. Getting a working result and learning enough to take responsibility for that result are different achievements.
Omarchy makes the connection quite directly now. Its homepage promotes using agents to troubleshoot and alter the system. That could be useful. An agent that helps you read a log, explains the relevant configuration and lets you check its reasoning could teach you plenty.
But there's another version of that interaction where you describe the problem, accept the changes and move on because it works again. Repeat that enough times and you can accumulate a lot of changes without much understanding of how they relate to one another.
And I think Omarchy leans too hard into selling that convenience. Its homepage even describes "agents that debug all issues." All issues? That is a hell of an expectation to set. I'd want to inspect what changed and test whether it addressed the cause before calling a problem solved. It's still my machine that ends up with the changes, and I still have to live with them when the first fix turns out to be incomplete.
An agent being confident doesn't help me decide whether it was right. If I can't follow the explanation or recognise an unrelated change, I'm approving work I don't understand. Having a second agent approve it doesn't give me that understanding either.
The next time something breaks, what have I learned that helps me fix it?
This is where I get frustrated with the promise that we can skip all the difficult parts. Some difficult parts are just tedious and I'm happy to automate them. Others are where you develop the ability to recognise a bad explanation, question an assumption or work out that the proposed fix has nothing to do with the problem.
You don't automatically acquire that judgement because the tool gives you a detailed answer. You develop it by working through things, checking them and sometimes finding out you were wrong. I want tools that help me do that. I get much less excited when understanding is presented as something I no longer need to bother with.
Heck, use AI to help you build your setup. Have it guide you. Ask which component handles a behaviour, which file controls it and why a particular setting would change it. Ask for a link to the documentation so you can check. Make one change, try it and see whether you understand the result before moving on.
You can literally tell it:
Help me set up Hyprland one step at a time. Explain the choices and the commands before I run them. Show me how to check each change and undo it. I want to understand my configuration, so don't just generate a complete setup for me.
That sounds like a great use of AI to me. You have something to ask when the documentation assumes knowledge you don't have yet, and you still do the work of making decisions and understanding what happened. The point is to become more capable as you go. If you've finished the setup and can explain how to change it yourself, you've gained more than a nice desktop.
Let the Convenience Be Optional
I use Qt for zenkai because I don't want to write a GUI toolkit. But when I needed to understand why the launcher was slow, I had to look into what Qt was doing. The abstraction saved me work. It didn't excuse me from understanding the behaviour my application depended on.
That's what I want from my desktop too. Help me get started, but leave me better equipped to take over. A menu could show me the configuration it edits. An agent could explain a proposed change before applying it and show me how to verify it afterwards. Documentation could make replacing the default tools feel like an ordinary thing to do.
These are the things I'd put at the centre of the pitch. Being able to stop relying on a convenience is a feature worth selling. I want to hear that I can learn to manage my own system, not just that there's always another thing available to manage it for me.
If the only progress we celebrate is how much knowledge a tool lets us avoid, eventually the person trying to understand their computer starts looking like they're wasting time. I think that's a bad direction for Linux, and AI makes it very easy to keep moving in that direction without noticing what we've given up.
What I Want From Linux
I want Omarchy's newcomers to stay. I also want them to discover that the system underneath the presentation is within their reach. They can read the configuration, replace the launcher, change the shortcuts and build something that suits them better. They don't need to wait until they're experts to start becoming more independent.
Whether Omarchy encourages that or makes it feel unnecessary is what will decide how I feel about its contribution to Linux. Bringing people in is good. Teaching them to depend on an agent for every unfamiliar problem would be a poor follow-up.
So yes, I am critical of Omarchy and the AI pitch around it. I want more than a machine that does what I ask as long as the defaults and the agent cooperate. I want to understand enough to take over when they don't.
I chose Linux because I wanted that control. A prettier way to delegate it isn't what I was looking for.
Thank you for your time and patience reading this article
Top comments (0)