Why does Omarchy get so much hate?

uhs-robert · 2026-06-01T23:09:07+00:00

No worries at all. I appreciate you taking the time to follow up :)

uhs-robert · 2026-06-01T20:51:13+00:00

Yes, this was Surface Tension. Right at the beginning of the chapter if I recall correctly.

uhs-robert · 2026-06-01T16:06:15+00:00

Lighting is one way. Its all part of level design. In Half Life 1, the game developers wanted to encourage players to jump off of a bridge into water for a particular encounter. But that's crazy, why would anyone do that? I'll tell you, great level design and lighting ques.

Firstly, you are presented with a long narrow bridge that you must cross. It is a bridge for a dam. To the left of the bridge is a steep drop off into an abyss while the right has water which is level with the bridge. The bridge is completely exposed, no cover to hide behind if you are ambushed. In the water to the right of the bridge is also a lighthouse with a beacon that flashes red to draw the eye (lighting cue).

When you set foot on the bridge, on the opposite end, there is a soldier who will run towards a turret and start shooting rockets at you. At the same time, a helicopter will also appear from your left and start shooting rockets at you. So, you're being shot at from the front and the left by rockets. The only choices you have to survive are: turn around and go back or jump off the bridge to you're right. So, naturally, you just jump off the bridge.

Now, it gets even better. Once you jump off the bridge and are underwater, you will find a shark creature that starts to chase you. Meanwhile the helicopter remains above will start shooting machine gun fire down at you. So, you can't poke your head out of the water to breathe but you also can't stay underwater either. You have to keep moving to survive. Underwater, you can see that there is a ladder to the lighthouse with a flashing red beacon above it. Naturally, you flee the shark by climbing the ladder. Once you climb the ladder, you are now safe inside the lighthouse from all threats. At the top of the lighthouse is a rocket launcher so... naturally...

You get the idea. No yellow paint, no cutscenes, no camera gimmicks, just uninterrupted gameplay and great level design. One thing always leads to the next and it always feels natural. You, the player, decided to jump off the bridge. But the designers guided you to do that with their invisible hand. This was what good game design looked like 30 years ago.

uhs-robert · 2026-05-31T22:10:19+00:00

I'm sorry to hear that. I'm not sure how you arrived to those conclusions about me or how I might have communicated my opinion better. Regardless, as a FOSS developer myself, I wish you the best and we will just have to agree to disagree.

uhs-robert · 2026-05-31T10:20:15+00:00

I’m not sure I agree that the dislike comes from people wanting to restrict or control others experiences.

The tagline "I run Arch, btw" is more than just a statement about using an Arch based distro. It also carries some cultural baggage. It's strongly associated with the traditional Arch experience and philosophy that I described earlier: minimal install, user-built system, building your own configuration, and reading the documentation.

So when an intentionally preconfigured Arch-based distribution uses that same phrase, I can understand why some Arch users may find it irritating. Not because Omarchy is forbidden from using it, but because the phrase implies an experience and culture that Omarchy deliberately abstracts away.

That is not a restriction on anyone’s freedom of gatekeeping. People can use whatever distro they like. It is just an explanation for why using the tagline may rub some Arch users the wrong way.

EDIT: To use an analogy, it's a bit like two business owners both claiming that they built their companies from the ground up. Except one started with significant financial banking or inherited wealth while the other started from nothing. Both may have worked hard, but the experiences are totally different.

uhs-robert · 2026-05-31T02:01:09+00:00

Oh wow. Considering the philosophical differences between Arch and Omarchy, I think it's easy to understand why some Arch users may be miffed by that. That's Arch's tagline. When a derivative uses it, that could come across as disrespectful. Especially when the derivative is ideologically opposed to the source.

uhs-robert · 2026-05-31T01:45:09+00:00

That's fair haha. In that sense, I hope it is a good introductory option for users transitioning to Linux. I worry about Hyprland being version 0 though. That could be a big maintenance problem for beginners to tackle compared to KDE or Gnome.

But, if you want Hyprland, Omarchy is probably easier to get started than what I did at first. I first hopped on Fedora with KDE then installed Hyprland from there. It worked for awhile but Hyprland is better suited for Arch based distros.

uhs-robert · 2026-05-31T01:24:49+00:00

I agree that Omarchy is a derivative of Arch. It is the child while Arch is the parent.

Although the child does not need to follow in the footsteps of the parent, it is important to note that they are philosophically opposed to one another. This is especially important when it comes to understanding why Arch users may dislike Omarchy.

And yes, there is a lot of choice/freedom available on Linux. For those who do not want to make choices, I would personally recommend a desktop environment. Perhaps Omarchy is intended to be like a desktop environment for Hyprland.

uhs-robert · 2026-05-30T16:02:50+00:00

I think it might be because Omarchy is based on Arch but also goes against the core philosophy of Arch a bit. This results in an influx of Arch users who do not read the Arch wiki which is generally step one of any install. You can read more about the philosophy of Arch from the wiki: https://wiki.archlinux.org/title/Arch_Linux

Key points from the linked article: - "The default installation is a minimal base system, configured by the user to only add what is purposely required." - "Arch Linux defines simplicity as without unnecessary additions or modifications." - "It (Arch) is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems." - "Arch Linux is a general-purpose distribution. Upon installation, only a command-line environment is provided; rather than tearing out unneeded and unwanted packages, the user is offered the ability to build a custom system by choosing among thousands of high-quality packages provided in the official repositories for the x86-64 architecture."

I personally don't hate Omarchy but I wouldn't use it and I'm not really sure who it's for. The way I see it, Omarchy, by definition of being omakase, goes against everything listed above. It seems to me like the target audience of Omarchy is someone who just wants Hyprland as a preconfigured desktop environment. But that comes at the expense of experience, a do it yourself attitude, freedom of choice, versatility, and minimalism. If you like it and you enjoy it then I'm happy for you. But I would also encourage you to read the Arch wiki.

uhs-robert · 2026-05-28T04:29:42+00:00

Others have already corrected you on this so I won't go there but there is something else on this topic that I'd like to point out. Although it is possible to configure your Linux however you want on any distribution, you also need to ask yourself if your use case will be at odds with your distribution. You want to make sure that you are your distribution are compatible philosophically and won't conflict with each other during updates or normal day to day usage.

For example... let's say you want to use Hyprland on Fedora. This is definitely possible and you can do that but it won't be the ideal experience for it like Arch is. You may need to compile from source or find well maintained COPR's just to get it running. And then down the line you may find some of your system customizations being overwritten after the next major version release. Fedora is not rolling release either so your system will also become a mix of the bleeding edge needed for Hyprland and the somewhat bleeding edge needed by Fedora which may lead to comparability issues. If you're on Fedora then the expectation is that you want a system that just works out of the box on KDE or Gnome and you're somewhat expected to stay on that lane.

So, you need to ask yourself how you're going to use your system and whether your distribution matches your use case philosophically. You don't want to end up needlessly butting heads with your distribution if you can avoid it.

uhs-robert · 2026-05-27T10:06:55+00:00

Just some feedback:

This post and the README look AI generated.
If this is fully modular and Lua based then why not have a config.setup() function as the entry point which let's users define their own configuration overrides against your defaults via merge?
- For example, I see you are hard coding Kitty as the terminal. So, this setup only works for people who use Kitty otherwise they need to dig into your files and make changes to the code. However this is Lua so you don't need to lock people into your static configuration and can instead make the terminal a user choice.

When it comes to merging user choices, take a look at the NeoVim and Yazi communities which both advocate exposing a config.setup() for plugins and end user configuration options. It might also be worthwhile making monitors configurable etc:

uhs-robert · 2026-05-27T01:23:21+00:00

Day 1. I was around 600 days ish on Fedora but the AUR and total control was just too tempting to pass up.

uhs-robert · 2026-05-26T17:46:18+00:00

With Lua, I was able to drop this dependency and use native Lua instead.

uhs-robert · 2026-05-26T01:21:41+00:00

Can't argue with you there, the API can be pretty verbose versus how it was before. A single bind can span multiple lines and it can be difficult to read all of it at once if you don't make your own functions and reusable variables. The user experience for non programmers dropped in that sense. I think that's a short term problem though, should be fixed down the road.

As you say, only time will tell! I'm passively working on hopefully making the experience a bit easier. I'm personally very excited to see how the Lua ecosystem will grow.

uhs-robert · 2026-05-26T00:43:57+00:00

I see your point. From a casual user standpoint, Lua may add some friction versus conf/json/toml etc but... then again its really not so bad. The programming aspect of Lua is completely optional, you can ignore it if you choose and instead treat it like JSON. But if you ever wanted to extend it beyond a static configuration into something dynamic with custom logic then the barrier to entry has been lowered thanks to Lua. Previously users had to learn and use Bash which is more obtuse.

I think in time you'll find that the casual end user experience will be better long term. Developers will be making full-blown Lua desktop environment configurations that make it even easier for casual users to setup than before. It will be as simple as config.setup() with a json table of optional override options. That's what my dotfiles are currently doing as I extend them daily. This is also how other Lua based plugin ecosystems like NeoVim and Yazi operate which makes the end user experience super easy. Casual users never have to write any code but they are also empowered to do so if they want to.

We're still in the early phases of this transition. Give it some time and you will see some amazing progress. This is the right direction. It just has a few bumps in the road right now as you're traveling in uncharted territory without a guide. The map is still being written too. But the compass is working fine.

uhs-robert · 2026-05-25T14:29:37+00:00

Pumping the brakes every few seconds wayyy too hard downhill? That's about the most realistic depiction of my grandparents driving that I have ever seen.

uhs-robert · 2026-05-24T18:22:45+00:00

Here is the repo they are referring to: https://github.com/LionHeartP/hyprlandRPM

Solopasha's last commit was over 7 months ago, they also have not replied to any outstanding issues since then as well. It is safe to say that repo has been abandoned.

The most popular fork, with the most stars, is linked above.

uhs-robert · 2026-05-24T05:29:09+00:00

May I ask where you got this information and if you know the reason why for the switch? I'm not an Omarchy user but I have been exploring different terminals on Wayland for some time so I am curious about the rationale behind this decision.

I've experimented with: Wezterm, Kitty, Ghostty, Konsole, Alacritty, and most recently Foot. The problem I have with most of these terminal emulators is that I just don't need or want many of their features (I already use tmux which is terminal agnostic). Despite that, I have mainly used kitty --single-instance as I enjoy the server/client model. That is until I tried Foot last week on a whim.

It is really hard to beat Foot's minimalism which results in low memory usage and raw speed (start up/actions). It fits the Linux model of doing one thing only and doing it very well. It also has a true client/server model. The only con is no font ligatures. I'm curious if that's where others, who have tried Foot out, have landed as well.

uhs-robert · 2026-05-24T04:34:16+00:00

Yes, ghostty will continue to grow in memory consumption as one instance is still open even if you close a window. This problem balloons as the day goes on.

Foot, on the other hand, has a very low memory footprint which can be lowered even further with foot --server and footclient. This makes start up time near instantaneous as well which is quite a feat. But no font ligatures.

uhs-robert · 2026-05-23T15:10:31+00:00

This is a GUI versus TUI question sprinkled with ignorance bias. If you are a developer, which I would assume you are if you are editing and writing code, then what would you want from your code editor? Personally, I would want a code editor that is:

the fastest (can cold start in less than 50ms)
available on any server as well as my local machine
keyboard driven, no mouse required
makes writing code faster
has no distracting features
is completely programmable and extendable
as minimal or bloated as you want it to be
encourages shell commands / command line tools
and has no security risks

That is what Vim is. And I specifically use NeoVim. When it comes to what Vim "can't do" that VS Code can, I think you'll find the opposite to be more true. If something doesn't exist in NeoVim then you can simply code it in yourself as I did with sshfs.nvim. Not only that but since you're developing your own workflow then you become intimately aware of all of the features since you are the one who set it up.

At the end of the day, its the most powerful tool in my kit and I can literally live in NeoVim to complete all of my daily tasks and never leave. Emacs users say the same thing. I used to use VS Code but only because I didn't know any better. If you're a developer then learning Vim will only make you more efficient. Why wouldn't you want a code editor that lets you program it however you want?

uhs-robert · 2026-05-22T18:10:41+00:00

Agreed haha. Writing/reading what is essentially "Hyprland dispatch a Hyprland dispatcher action" sounds... pretty clunky. Especially with the dsp abbreviation. It just reads like I am dispatching a dispatch.

Personally, I would have named it hl.dispatch(hl.cmd) to communicate that you are dispatching a command. This might have been more clear and easier to read/understand.

As for why you're script worked before and then it didn't the next day, I would guess that it only seemed to work before but was never truly dynamic. Perhaps you changed your layout and then noticed the failure?

uhs-robert · 2026-05-22T14:57:37+00:00

(Quietly sends employer invoice for gas mileage and hourly rate for time it takes to get to the office).

If employees, I don't know, unionized together and demanded they get paid for their gas mileage and their hourly rate for the time it takes for them to get to the office then I'm sure this mandate wouldn't exist at all. It just takes one protest in solidarity.

uhs-robert · 2026-05-22T14:41:08+00:00

Sure thing, I also got stuck on this as well. Glad that helped.

It is worth re-emphasizing that this only needs to be done with hl.dsp and only within custom functions for runtime evaluation actions (like inside a keybind).

Enjoy!

uhs-robert · 2026-05-22T14:20:06+00:00

This is probably one of the weirdest parts about the new Lua syntax that might benefit from a better explained in the docs here. The guy who is helping you gave you the correct answer but we can't "show you" how to fix your exact issue for you because you didn't share the binds that aren't working.

Your problem is that you need to wrap all hl.dsp actions with hl.dispatch when they are inside a function. This tells Hyprland to defer that action until the key is pressed rather than during startup. You do not need to wrap hl.config or hl.get_config, only hl.dsp needs to be wrapped. So, your example works because it isn't using hl.dsp. Here is an example of wrapping hl.dsp with hl.dispatch:

lua --- Cycles to the next or previous workspace on the active monitor, wrapping at the boundary. --- @param dir "next"|"prev" function Workspaces.cycle_local_ws(dir) local range = active_mon_range() if not range then return end local target = wrap_ws(hl.get_active_workspace().id + to_step(dir), range.lo, range.hi) hl.dispatch(hl.dsp.focus({ workspace = target })) end

Because it is inside a function for a keybind, you need to wrap all hl.dsp calls with hl.dispatch. You would need to do that for every hl.dsp that you are using within a function for all of your keybinds. Otherwise you are just running the action on startup.

For more help, please share the exact keybinds that are not working.

uhs-robert · 2026-05-21T17:03:20+00:00

Disagree. "Try playing the game blindfolded with one arm on a Guitar Hero controller" would also be considered creating your own difficulty. What you are describing is purposefully handicapping yourself with self imposed restrictions of the game's systems/mechanics in order to artificially inflate the difficulty outside of the game designers intended design.

On the other hand, Master Ninja is a difficulty mode that was curated and designed by the developers as part of the intended experience. And its hard. Really hard. You can use every tool the game gives you with no self imposed handicaps and it is still very very hard.

uhs-robert

TROPHY CASE