posts

No, 2026 Still Isn’t the Year of Linux on the Desktop

As I’ve mentioned before, I started using Linux around 2004, mostly because that was the operating system installed on the computers at the public library in my hometown. Years later, I even ran Linux on my PS3 using Yellow Dog, where I spent countless hours trying to get Adobe Flash Player working in the distro’s browser. By the time I got to college, Debian had become my distribution of choice, and I even attended DebConf in Brazil for a few years. Of course, like any Linux user who has already wasted far too many hours recompiling something that should have simply worked, I also went through Ubuntu, Linux Mint, Fedora, and jumped on the Manjaro hype train when it showed up. In other words, I was a Linux desktop user for many years, and I’m not exactly someone who discovered it yesterday after watching three Hyprland videos on YouTube.

But it was never just Linux. For years I kept alternating between the penguin OS and Windows, trapped in that cycle I think a lot of people who are into technology know very well:

  1. Install some Linux distro
  2. WOW! I can do everything and configure everything. Goodbye, Windows
  3. Run into some important limitation
  4. Spend countless hours like a technology addict trying for days to fix some Nvidia driver issue or completely random incompatibility
  5. Problem solved. I’m going to keep using Linux
  6. Another problem happens, except this time it happens at a critical moment when it absolutely could not happen
  7. Hello again, Windows

And that’s without even getting into gaming, because until 2019 playing games on PC was basically irrelevant to me. Any distro that could run Diablo 3, even after hours of configuration, was good enough. After that I started taking PC gaming more seriously, and while Proton has grown tremendously and the situation today is incomparable to what it was ten years ago, there is a difference between knowing that something can probably be made to work and actually wanting to spend an entire evening figuring out exactly how. When you’re a teenager, that’s entertainment. Once you’re past 30, sometimes you just want to click the damn icon and play.

The years went by, I kept switching between operating systems and, at some point, macOS also joined the fight for my attention on the desktop. The cycle, however, remained more or less the same. Then in 2025 two things happened that changed the way I used Linux. The first was leaving the toxic corporate world and starting to venture into freelance work, which later turned into a company with several projects. The second was discovering Omakub.

Omakub was basically a highly opinionated Ubuntu installation bundled with the tools, configurations and choices of David Heinemeier Hansson, DHH, creator of Ruby on Rails. Later, he started experimenting with Arch and Hyprland, and from that experiment came Omarchy, initially as a kind of paved road toward getting a fully configured Arch and Hyprland environment. DHH himself described the project as his ideal environment for developers and, eventually, what began as configuration files and scripts got its own ISO, its own repository and effectively became a distribution. (world.hey.com)

I got used to Hyprland and the choices made in that environment surprisingly quickly. It felt natural. Within a few days my muscle memory had already adapted to the new shortcuts and it became my main work system. Since I had also started focusing more on PC gaming after 2019, I kept Windows in a dual boot setup so I wouldn’t waste the machine or turn every new game into another side project in domestic reverse engineering. Yes, I know Proton has grown, changed and is now a completely different beast. But by then I was already past 30 and had started developing a fairly healthy allergy to spending three hours configuring something that should take three minutes.

Omarchy kept evolving until it reached Omarchy 4, the famous Quattro, released in August 2026. And that’s when things changed quite a bit. Quattro wasn’t just another wallpaper swap with half a dozen new scripts. The project replaced several separate desktop components with a shell built using Quickshell, added a plugin system and made coding agents first class citizens of the operating system, including shortcuts and crash diagnostics integrated with whichever agent the user had configured. That is literally one of the central ideas behind the Omarchy Quattro release. (github.com)

Now we need to talk about DHH.

Political positioning matters relatively little to me when I’m choosing which operating system to use, as long as certain fairly obvious lines are not crossed. So yes, I found out that DHH is an extremely controversial figure and that today he openly takes clearly right wing positions on several issues. He has written, for example, explicitly arguing for an end to mass immigration in Europe. He is also one of those figures that the AI bro ecosystem on X loves turning into its prophet of the week. But you know what? Fuck it. When I’m choosing a work tool, my concern is technical. I can argue about politics after I turn the computer off. (world.hey.com)

Another controversial topic is AI. And here there is no point pretending we’re still in 2023. In 2026, like it or not, coding agents are already part of the normal workflow for a huge number of developers. DHH himself went from enthusiast to practically an evangelist for this approach, writing that agents had finally started living up to the hype and defending the idea of an entirely malleable Linux computer that could be modified with the help of AI. Modern Omarchy reflects exactly that vision, treating Claude Code, Codex, OpenCode, Antigravity and several other agents as a natural part of the environment. Omarchy’s own manual calls these agents first class citizens. (world.hey.com)

And before someone comes along with the argument that this is just startup kid nonsense from people who have never seen a pointer in their lives, even Linus Torvalds decided to play around with it. In the AudioNoise project, he wrote in the README itself that the Python visualizer had basically been vibe coded and that he used Google Antigravity to build it. That obviously does not mean Linus is vibe coding the entire kernel while drinking coffee, and using this example to claim that would be dishonest. It simply means that even he found situations where having AI write code was a perfectly acceptable tool. You can read it in Linus’s own repository, without having to trust some influencer’s thread. Months later, he also made it clear during discussions about AI use in kernel development that Linux is not an anti AI project. (github.com)

So when I started following the technology world more closely again through X, it became obvious that Omarchy had not merely embraced AI. It had entered a serious relationship with it, put a ring on its finger and started an extremely sexualized honeymoon.

And of course that creates the perfect recipe for hatred from the more purist and ideological corners of the Linux community:

  1. An extremely controversial millionaire
  2. Arch and Hyprland packaged together with very strong opinions about how you should use your computer
  3. A huge amount of automation and abstraction designed to hide complexity
  4. AI shoved into practically everything

Now, none of that is inherently a problem for me. Millionaires putting money into Linux are welcome. A distribution, from my pragmatic point of view, has always been some variation of BASE DISTRO + CHOICES + CONFIGURATION + SCRIPTS, the only difference is how willing each project is to admit it. And being AI first should not be a problem either. My problem starts when the obsession with convenience and speed seems to overtake the technical rigor required to build something that intends to occupy the most privileged possible position inside my computer.

Omarchy Quattro is clearly designed around productivity, integration and convenience. And DHH has been talking for quite some time with enormous confidence about the possibility of developers migrating to Linux en masse. In 2025 he wrote that he had never been more convinced that the famous “year of Linux on the desktop” was coming, and later said that the window for a major shift was open. He wrote it himself. That confidence sounds great. I’d like it to be true too. The problem is that confidence doesn’t stop a distro from doing stupid shit. (world.hey.com)

One of the ugliest examples showed up in the Docker configuration. In the name of convenience, earlier versions automatically added the user to the docker group, allowing Docker to be used without sudo. If you don’t know the implications of that, it can sound like nothing more than a user experience improvement. It isn’t. Docker’s own official documentation warns that permanent membership in that group grants root level privileges because a process with access to the daemon can, among other things, mount the host filesystem inside a container and modify it. Docker’s documentation is explicit about this risk. (docs.docker.com)

And Omarchy did exactly that by default.

Think about that decision for a second. We are talking about a distribution aimed at developers, precisely the kind of people who spend all day running third party dependencies, installation scripts, command line tools, plugins, projects cloned from GitHub and, now, AI agents capable of executing commands almost entirely on their own. In that environment, you decide to remove a security boundary and give any process running as the user a silent path toward root equivalent privileges because typing sudo before docker is inconvenient. This is not some sophisticated academic debate about threat models. It is a bad decision at an almost offensively basic level.

And I’m not misreading some obscure technical detail. The pull request that fixed the behavior starts by explaining that the docker group is equivalent to root and that any code executed as that user could gain a silent, passwordless and interaction free path toward modifying the host. The fix removed the user from that group by default and turned the old behavior into an explicit option accompanied by a warning. Release 4.0.1 included that change as part of an entire collection of security fixes.

With the power of AI, they fixed it quickly. Great.

But the problem was never fixing it with AI. The problem is having to fix something like that after putting the decision into production. What bothers me is precisely the lack of technical rigor before implementation. Anyone with even a little experience administering Linux should look at “let’s automatically add the user to the Docker group to make things easier” and at least have that one second of awkward silence where everyone in the room realizes somebody is about to do some stupid shit. This does not require an NSA security specialist. It is the kind of thing you expect to die during code review.

And Docker was not an isolated case.

Another issue that was later fixed involved Kitty’s remote control configuration. Kitty has a powerful remote control interface capable of manipulating windows, sending text and performing different actions. The feature is legitimate and extremely useful, but Kitty’s own documentation describes unrestricted mode as an extremely powerful interface. Omarchy used this feature for terminal integrations and later had to change its security configuration so remote control requests would only be accepted through local sockets. The fix appears explicitly in the Omarchy 4.0.3 release as “Restrict Kitty remote control to local sockets”. (github.com)

The technical distinction matters. It would not be accurate to say that simply installing Kitty automatically meant any curl command could execute whatever it wanted on the computer. The problem is arguably worse because it is more subtle. With unrestricted remote control accepting commands through the terminal, untrusted content printed into that session could interact with an interface that simply should not have been exposed that way. The current configuration uses allow_remote_control socket-only, specifically to reject requests arriving through terminal output and accept only communication through the configured Unix socket. Omarchy’s current repository explicitly documents that change. Today that restriction is explicitly documented in the project. (github.com)

Another shitty security decision made in the name of convenience.

And this is where the feeling that actually bothers me starts to emerge. Certain parts of Omarchy give off the vibe that someone opened Claude and typed something like “look, make Kitty automatically follow the theme colors and don’t bother me with the details”, got back a solution that worked, watched the colors change and shipped it to production. I’m not saying that is literally what happened. I’m saying that this is the impression created by decisions where the functional outcome appears to have received far more attention than the consequences of the mechanism used to achieve it.

AI is not the problem. Vibe coding is not even necessarily the problem. Linus himself used vibe coding on a personal project because he did not know Python particularly well and wanted to build a visualizer. Perfect. The problem begins when the prototype mentality, the one where “it works, therefore it’s done”, escapes the toy project and enters an operating system that controls my credentials, my projects, my SSH keys, my tokens, my containers and basically my entire professional life. There is a massive difference between using AI to write code and outsourcing your technical judgment about that code to the AI that wrote it.

And that is particularly ironic because Omarchy itself is trying to sell a vision of Linux in which agents can modify increasingly large parts of the computer. DHH calls this idea the “malleable computer”, a computer where Linux being open and configurable allows agents to alter practically any component of the system. I like that idea. In fact, I like that idea a fucking lot. But the more power you hand over to agents, the more important it becomes to reduce unnecessary privileges and create clear boundaries. You cannot simultaneously argue that agents should gain increasing access to the system while treating silent paths to root as a minor UX convenience. (world.hey.com)

As I said, I could hardly care less about what DHH thinks politically. What bothers me much more is the almost messianic posture when it comes to technology, because that is where we enter territory that directly affects a tool I use for work. I do not need to agree with what he thinks about immigration, Europe, the United States or whatever culture war happens to be trending that day in order to use an operating system he created. But when someone talks about Linux as if he has finally discovered the combination everyone else has spent thirty years searching for, I expect the technical rigor to match the size of the confidence.

Did I immediately stop using Omarchy because of all this?

No.

Because despite all this criticism, the system was still excellent at many things. It is beautiful, fast, coherent, pleasant for development and it managed to package an Arch and Hyprland experience that I probably would never have had the patience to build myself. Criticizing those decisions does not change that. Software does not have to be complete garbage in order to have serious problems, just as acknowledging the strengths of a project does not require turning its creator into a prophet.

Except then we return to the cycle I mentioned at the beginning.

And eventually I reached step 6.

During a work presentation, screen sharing would crash the browser. At other times the Hyprland bar would simply disappear without me doing anything. Ghostty would occasionally crash. Small weird things kept appearing here and there. Individually, almost all of them could probably be diagnosed and fixed. I have enough Linux experience to know where to start. I could open logs, search for issues, test configurations, swap components, investigate drivers, ask an agent, run a bisect if I was particularly determined to hate my own free time and, eventually, figure out what was going on.

Except that is exactly the point.

I don’t want to.

When I’m working, my operating system is not my hobby. It is infrastructure. During a client presentation, I do not care whether the bug is caused by Hyprland, Chromium, PipeWire, the driver, the Wayland portal, the kernel, Omarchy or the alignment of the planets. If I click screen share and the browser dies, at that moment the problem is mine. If my bar disappears in the middle of the workday, the problem is mine. If the terminal crashes while I’m doing something important, guess whose problem that is.

That was when I realized I had returned to exactly the same place I was twenty years ago, except now with transparency effects, pretty animations, AI agents and a much sexier bar.

Linux has improved tremendously. Proton completely changed gaming on the platform. Wayland has moved forward. Hardware support improved. Distributions improved. Hyprland is genuinely interesting. Omarchy managed to do things I would like to see copied by many other projects. AI has made it possible to customize and even develop parts of the operating system at a speed that would have seemed ridiculous a few years ago. None of that is in question.

But “the year of Linux on the desktop” has always meant something bigger than “a nerd can use Linux every day as long as he is willing to fix whatever breaks”. That was already true in 2004.

For me, the year of Linux on the desktop arrives when the operating system stops requiring me to be mentally prepared to fix it at the worst possible moment. When sharing my screen in a meeting stops being a potential debugging event. When updating the system no longer comes with that little casino thrill. When I can trust the abstraction to keep working precisely when I do not have time to discover what is underneath it.

Maybe that happens in 2027. Maybe Omarchy ends up being an important part of making it happen. Maybe DHH is right and we really are watching the beginning of a massive shift on the desktop. I have no idea.

All I know is that, for me, 2026 still wasn’t that year.

So…

Hello again, Windows!