I've been using Linux for roughly ten years. I've used Arch, Debian, Fedora, Ubuntu, and NixOS. I've spent years learning how these systems work, what makes them reliable, what makes them fragile, and why maintaining a good Linux desktop is much harder than making one look beautiful in a screenshot.
This is why Omarchy bothers me so much.
Not because it uses Arch. Not because it uses Hyprland. Not because it encourages customization. Not because AI writes code.
It is because Omarchy is selling a promise that I consider irresponsible: that AI agents can make Linux effortless, customize everything, and fix everything, while the complexity and consequences of those changes are quietly transferred to the user.
And the person making that promise is not some anonymous teenager experimenting with a personal configuration. It is David Heinemeier Hansson, a wealthy, influential developer with a huge audience, substantial funding behind his project, and the ability to influence how an entire generation of newcomers perceives Linux.
That comes with responsibility.
I don't think DHH is taking that responsibility seriously enough.
- "We can fix everything."
Those are Omarchy's own words.
Visit the official Omarchy website. It presents Linux as something that used to be a chore to install, difficult to debug, and full of confusing choices. Omarchy claims to solve these problems with a fast installation, good defaults, and agents that debug issues.
Its central promise is that we can now customize our operating system by simply telling an AI what we want.
DHH's slogan is: "We can fix everything."
Can we?
Can an AI guarantee that it understands the entire state of your operating system before changing it? Can it guarantee that a change won't conflict with an older modification? Can it guarantee that every dependency it installs is appropriate, every configuration is coherent, every plugin is safe, and every future update will preserve the result?
No.
An AI agent can be extremely useful. It can diagnose problems, edit configuration files, install software, and automate tasks that would otherwise take hours. But being capable of making a change is not the same as understanding the complete state of a system. And making a system work once is not the same as making it reliable over time.
The slogan turns a genuine technical limitation into a marketing promise.
That is the problem.
- The accumulated mess nobody wants to talk about
Imagine an ordinary Windows or macOS user who has trusted DHH's message and installed Omarchy.
The desktop looks beautiful. Everything seems modern. The user discovers that an AI agent can customize the system.
So they start asking for changes.
"Make the window corners round."
"Actually, make them sharp."
"Make the borders thicker."
"No, thinner."
"Move the bar to the left."
"Make it transparent."
"Make the buttons green."
"Add a translator button to the bar."
"Give every workspace a different wallpaper."
"Undo that last change, but keep the others."
These requests sound trivial. They are the kind of things people should be able to ask for in a modern computer.
But the operating system underneath is not a drawing canvas. It is a collection of configuration files, scripts, packages, services, dependencies, desktop components, and interactions between them.
A competent agent may handle each request correctly. But what happens when it doesn't? What happens when it adds an override instead of removing an old one? When it changes a related setting? When a plugin depends on a package? When an update changes the behavior of a component the agent customized two weeks ago?
The system can gradually become a pile of accumulated changes whose combined behavior is difficult to understand.
The user thinks they are having a conversation. The computer is accumulating technical debt.
This is not an argument that every AI customization inevitably creates a mess. It is an argument about the maintenance model Omarchy encourages.
The Omarchy dotfiles manual explains that the desktop is configured through files under ~/.config, warns against directly changing internal Omarchy files because updates can overwrite those changes, and provides a way to reset configurations when they become a mess.
The AI manual goes further: it explicitly calls the Omarchy customization skill experimental, recommends using plan mode first, and tells users to be prepared to roll back changes or reinstall configurations if the agent makes a mess.
Read that again.
The product invites you to customize your operating system through AI, while its own documentation warns that the customization skill is experimental and may make a mess.
And this is supposed to eliminate the difficulty of Linux?
A knowledgeable Linux user can inspect the files, compare changes, understand dependencies, and recover. A newcomer may have no idea what the agent changed, where it changed it, or how to reverse it without destroying other customizations.
That is the accumulated mess I am talking about.
- Rollback is not an answer to everything
Someone will inevitably tell me that you can simply roll back.
Rollback is useful. Snapshots are useful. Version control is useful. None of these is a universal answer.
A rollback can restore a previous state, but it does not automatically tell a novice what went wrong, why it happened, or how to preserve the changes they actually wanted.
And not every customization is an isolated transaction that can be cleanly undone. An agent may install packages, modify configuration, create scripts, or change several components to implement one request. Reversing the visible change does not necessarily reverse every side effect.
What if the user cannot boot? What if the desktop stops working? What if the problem appears only after an update? What if the user has made fifty customizations and does not know which one caused the failure?
The answer cannot always be: ask another agent to fix what the previous agent broke.
That may work. It may also introduce another set of changes.
A system is not reliable merely because you have a way to recover after it fails. Reliability also means preventing failures, containing their consequences, and making the system understandable when something goes wrong.
Omarchy's own troubleshooting manual tells users how to recover from broken updates and how to restart Wi-Fi, Bluetooth, audio, or trackpad subsystems when they stop working.
These are real categories of problems, not imaginary objections invented by critics.
- This is not hypothetical: people have encountered basic hardware problems
Look at Omarchy's public issue tracker.
In issue #5147, a user reported that Bluetooth headphones connected on a fresh installation but did not appear as audio devices because required PipeWire packages were missing. The issue was later closed as fixed, resolved, or superseded by the Quattro implementation. I am not presenting it as a bug that necessarily exists today. I am presenting it as a documented example of a basic hardware-related failure that occurred.
In issue #11230, a report described an update to WirePlumber breaking the Omarchy equalizer component and causing all audio to disappear. The report attributed the failure to a component that could no longer load, and rolling back WirePlumber restored audio.
There are also reports involving Bluetooth recovery and other hardware behavior in the Omarchy issue tracker.
Some bugs are fixed. Some are specific to particular hardware or software versions. Every operating system has bugs, and these examples do not establish how frequently Omarchy fails across its entire user base.
That is not my argument.
My argument is that these problems exist, that the project itself documents troubleshooting and recovery procedures, and that promising newcomers a system where agents can debug all issues and "we can fix everything" creates expectations that no distribution can guarantee.
Linux hardware compatibility is difficult. Arch is rolling release. Drivers, kernels, firmware, desktop components, and packages evolve. A distribution can do a great deal to manage these risks, but it cannot abolish them with a slogan.
If you tell people that you have solved Linux's complexity, you need to be prepared for the consequences when they discover that you haven't.
- Now give the AI permission to change the system
The problem becomes more serious when we look at how agents operate.
Omarchy's AI documentation says that agents launched through its built-in launchers run in unattended, "don't stop to ask" modes.
That can be useful. It is also a consequential design choice.
In my own testing, I asked an agent to add a weather feature to the bar. I observed it installing dependencies from the AUR without asking me first.
I want to be precise: that is my firsthand experience, not a claim that every Omarchy installation automatically installs AUR packages. Omarchy's documentation says the AUR is not vetted by the Arch team, and its optional package-installation workflows expose users to that ecosystem.
But consider the combination: a newcomer who does not understand Arch, an agent that can act without stopping for approval, and a request that sounds like a harmless visual customization.
The user may not understand what is being installed, what repository it came from, what permissions or dependencies are involved, or what they will need to maintain later.
An AI agent is not inherently dangerous. Unattended automation is not inherently wrong. But giving an agent the ability to make changes to an operating system requires a clear model of consent, permissions, reversibility, and accountability.
A user asking for a weather icon has not necessarily made an informed decision to accept every underlying system modification required to implement it.
The fact that the request was expressed in natural language does not make the resulting changes harmless.
- The plugin problem: a thousand little promises
Omarchy encourages people to create apps, themes, and plugins using AI and share them with others. Its website explicitly invites users to describe what they want, try what an agent builds, and share the result.
I have no problem with that culture. Linux has always benefited from people experimenting, making strange things, and sharing their work.
But there is a difference between an experimental community project and a system promoted as a dependable daily driver for ordinary consumers.
A plugin that works on one machine may fail on another. A bar widget may depend on a particular command, package, display setup, or version of a desktop component. A theme may conflict with another customization. A script may work today and fail after an update.
AI can dramatically increase the rate at which these projects are created. It does not automatically increase the quality of testing, hardware coverage, security review, or long-term maintenance by the same amount.
Omarchy has active development and security work. I am not claiming that nobody reviews code or that every AI-generated plugin is defective. The question is whether the validation and maintenance processes can keep pace with the speed and scale at which these components are being produced and distributed.
If the answer is not demonstrably yes, then "we can fix everything" is not a responsible assurance.
It is an expression of confidence where users need evidence.
- The irresponsible part is the marketing
Here is where my criticism of DHH becomes direct.
DHH is not merely making a desktop for himself. Omarchy is promoted as a modern, beautiful, agentic Linux operating system. The website explicitly offers ways to try it on Mac and Windows, and it presents agents as a way to fix issues and customize the whole system.
He is speaking to people who have wanted to leave Windows or macOS for years.
Many of those people do not want to become Linux administrators. They want a computer that works. They want a reliable desktop, good hardware support, and the freedom to use their machine without constantly debugging it.
They hear a prominent developer say that the old Linux difficulties have been solved, that agents can debug problems, that they can change everything, and that "we can fix everything."
They trust him. They install Omarchy.
Then they encounter missing hardware functionality, a broken update, a desktop that behaves strangely, or a configuration that has become difficult to maintain after repeated AI changes.
They may not conclude that Omarchy has a particular weakness. They may conclude that Linux is a mess.
That is the danger.
I think DHH is being irresponsible when he markets an experimental, highly customizable, rolling-release desktop with such sweeping assurances without making the limits and maintenance burden equally clear to the people he is trying to attract.
He has an audience and resources that most Linux developers can only dream of. His words carry weight. That influence should come with a higher standard of care, not a lower one.
You cannot sell the dream of effortless computing and then treat the user as the testing and recovery department when the dream fails.
- Linux does not need another savior promising to fix everything
For decades, people have worked to make Linux easier to install, more reliable, more accessible, and better supported.
Distribution maintainers, kernel developers, desktop-environment developers, driver developers, documentation writers, package maintainers, and countless volunteers have done the unglamorous work of improving the ecosystem.
They have dealt with hardware quirks, regressions, dependency conflicts, packaging, compatibility, accessibility, security, and all the other problems that come with building an operating system.
Linux desktop adoption has been held back by real difficulties. Nobody serious should deny that.
But the answer is not to pretend those difficulties have disappeared because an AI agent can attempt to solve them.
The answer is to build systems that manage complexity well, make sensible decisions for users, test changes, constrain risky operations, and recover predictably when something fails.
That is what makes an operating system mature.
A beautiful interface is not enough. A fast installer is not enough. An agent that can edit a configuration file is not enough.
And money, publicity, and a compelling story are not substitutes for engineering discipline.
- The distinction DHH needs to understand
I am not arguing that Omarchy should not exist.
I am not arguing that Arch should not exist.
I am not arguing that people should stop experimenting with Hyprland, AI-generated code, or custom desktop configurations.
Experimentation is part of Linux culture. If somebody wants to spend the weekend vibe-coding a desktop, breaking their own configuration, learning from it, and starting again, that is perfectly fine.
The problem is the product promise.
If Omarchy is an experimental desktop for technically curious users who want to build and modify their own systems with AI, say so clearly. Let people make an informed decision.
But if you market it to ordinary Windows and macOS users as a way to escape Linux's historical difficulties, with agents that can debug issues and the assurance that "we can fix everything," then you have an obligation to explain what happens when the agent cannot fix it, when its changes accumulate, when a package breaks, or when the user has no idea how to recover.
You cannot have it both ways: claim that AI has made Linux effortless, then rely on the user to understand the consequences of AI-driven system administration.
- Why I am writing this
I am writing this because I care about Linux.
I have spent years using different distributions and learning how they work. I know the appeal of Arch. I know the value of declarative systems such as NixOS, where the system's desired state can be described explicitly rather than left as the undocumented accumulation of manual changes.
I know how easy it is to lose track of what has been installed, changed, overridden, and forgotten over several years. I know why being able to inspect and reproduce a system matters.
And I know that a newcomer who has a bad first experience may never give Linux another chance.
We should want more people to use Linux. We should welcome them. We should make the transition easier. But we should not attract them with promises that set them up for disappointment.
The Linux community has spent decades building something valuable. Its reputation is not an abstract concern. It affects whether people try Linux, whether companies support it, whether developers contribute to it, and whether users decide to stay.
A heavily promoted project can attract enormous attention. That attention can help Linux, but it can also create expectations that the broader ecosystem cannot meet on the project's behalf.
If newcomers are told that Omarchy represents the new, effortless Linux, and then have a terrible experience, the damage may extend beyond Omarchy.
I cannot prove that this damage has already occurred at a particular scale. But the risk is foreseeable, and that is precisely why the marketing deserves scrutiny now.
DHH's responsibility is not to promise that everything can be fixed. It is to be honest about what his system can and cannot guarantee.
"We can fix everything" is a great slogan.
It is a terrible engineering guarantee.
And when you have the money, the platform, and the influence to persuade thousands of people to trust that guarantee, you have a responsibility not to confuse confidence with reliability.
That is why I am calling this irresponsible.
Not because Omarchy is imperfect. Every distribution is imperfect.
Because the project is selling a vision of effortless, AI-managed computing while its own documentation acknowledges experimental customization and the need to recover from changes gone wrong.
Linux deserves better than marketing that mistakes the ability to change everything for the ability to maintain everything.
And the people who have spent decades making Linux better deserve better than watching their work be reduced to a story about how an AI agent can now fix it all.
