> What is different here?

I don’t understand how this is a question.

What’s different is that it comes configured this way out of the box, silently, without warning. It’s functionally equivalent to opting in to giving all user accounts root privileges, which is not what anyone expects the default configuration to be.

You can choose to configure your installs this way if you choose to do so. It should not come this way quietly by default.

> I always make my user part of the docker group

I don't, and I migrated to Podman because Docker is poorly designed and full of footguns. For example, it it will silently overwrite iptables rules and punch holes in your firewall.

I don't think this is as widely known as you believe: I use dockerd via colima so it's not a limitation I've encountered - if I had, I likely would've switched to podman wholesale instead of compromising my system.

Either way though, I would hope it's self-evident to most that taking glaring security holes in a single app (docker) & transforming them into glaring security holes in an entire OS is generally not desirable.

A distro should be secure-by-default. Omarchy’s design here was insecure by default while the docs have the impression that Docker might be running rootless. Pairing insecure defaults with docs that claim better security is bad.

> I always make my user part of the docker group, so my NixOS also has this, and any Ubuntu I’ve used over the past year.

You may do that, but I don't. I always use sudo to manage the few docker containers I need, and I prefer podman where possible specifically because I can run it rootless.

If you want to give your user passwordless root for convenience, go ahead, but that should never be the default.

>Everybody knows this.

I didn't know this.

It depends on what distinction you’re making…

If you are asking concerning security, the answer is that it’s an insecure default that should have protected an unwitting user.

If you are asking concerning consistency with real world situations, then there is no difference and it feels like the fit is over a somewhat controversial figure (DHH) and how he created the distro’s recent release without reading any of the code himself. The counter is that no one installing a distro actually understands how their distro is configured, and trusts someone else’s judgement. Here that judgment was farmed out to AI, and while that is controversial, the uncomfortable truth is that this is how an awful lot of real people are told to configure their Docker installations.

IMO Docker running as a root daemon is a bad idea in the first place and I’d much rather use Podman’s rootless containers.

This. Was also super confused when I saw the post. Like every docker guide literally screams at you when you use rootfull docker. Either add yourself to the docker group with `newgrp` for a termimal session or use rootless docker.

“This house has a hole in its roof but I cut several holes into my roof to water my indoor plants so what’s the problem?”

[flagged]

[flagged]

I just switched over to it from Ubuntu. So far the nice thing is that it gives you a fully decked out hyprland setup without any of the hassle and pretty good UX.

The problem I've always had with trying out a tiling window manager like hyprland is you're going to spend a very long time trying to get everything just right. With Omarchy I get a really nice hyprland setup right out of the box.

I recently customized my own Bazzite install to use hyprland plus other customizations, there's really not much different than what omarchy did. It's pretty much that with some pre installed apps. Anyone that gave them funding is an idiot IMO.

There's definitely appeal in key-driven window managers in general. Projects like i3 and Niri are popular. But you can get that with any Linux distro (albeit not many have it set up that way by default). You don't generally choose a distro just for whatever DE/WM it happens to start with.

What I don't get is that VS Code has solved this perfectly via the command palette - you just bring up the prompt and start typing and it will find you the command you actually need without having to memorize anything.

Well the whole point is to have a good foundation and then make it actually yours, and the only necessary key binds are probably SUPER+K for the key bind cheatsheet and SUPER+SPACE for the menu.

Also the community is large so there's usually someone that has already had your issue and resolved it. The amount of themes and plugins are growing everyday.

A bare arch+hyprland install really feels terrible to use and has a much larger barrier to entry than Omarchy.

https://plugins.omarchy.org

https://omarchythemes.com

That is the appeal. It's an opinionated distro designed around keyboard navigation.

There's a segment of people who are into customizing their desktop environment as a hobby and end in itself.

Personally I've never really been into it, and these days I have a broad and revolving set of machines I have to use, so this sort of thing is absolutely not worth the bother. I just install KDE Plasma and use the computer.

I got here because it was the first time I saw a tiling window manager on an Omarchy video. I was on windows my entire life, so when i saw it and how bad windows got, I decided to give it a try. A few months since I de-omarchyfied the system and went straight back to arch. And now still on it.

I should have gone with something like cachyos as games are important to me, but I think at the time hyperland wasn't an option (i don't remember). I know it is now.

Being hyprland keybinding skilled removes a lot of the desktop interaction surface, it's a worthwhile investment. People who've used tiling window managers for a while will tell you that it gets natural at a point, then a whole class of friction that normal WMs cause just goes away.

We had people salivating over a spinning Compiz 3D cube 20 years ago, and some still don't understand the ricing factor.

On average, you can either have a discoverable GUI for noobs, or a configurable, keyboard driven system that's a giant pain to learn and configure.

Omarchy aims to find a middle ground between those two.

I for one hold out for them releasing an optimized XFCE variant - don't by any means dislike keyboard driven software but I like it as an extension of a regular functional UI experience not as a "argh the windows are stuck in xyz pattern until I re-remember xyz combo"-experience: the UI surface is not the speed limit in my optics, rather it is the apps I use or (increasingly due to local AI) the computational hardware limits of my machine.

> I saw a couple video demos recently, and was horrified that it seemed one had to memorize a dozen key binding shortcuts to really use it.

Whoa! You have to _learn_ something to use it well? Yikes. Not for me.

It’s that age old “start a docker container with the docker socket in the container and you are effectively root”. What are we talking about here? This is not new?

I think they mean that Omarchy is pretty much vibe-coded. Probably just an assumption.

The fact comments like this get downvoted because what they say is inconvenient is one of the major signs AI has fundamentally broken HN.

It was already hard to have technical conversations in public, now there is a contingent determined to make it utterly impossible, and they are succeeding.

You didn't switch away from windows to get superior software?

Also, the statement was valid because it will be true for most. It doesn't matter that you read it and it wasn't true for you, as long as it's true by the numbers, it's true, because it's one-to-many communication not one to one.

> etc. the list is endless.

Why is the list endless? I don’t even remember the last time I check or change any on my mac settings. And my unix things haven’t been touched in months. My debian server is basically frozen at this point.

[dead]

Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.

It's not the same thing as allowing some AI contributions under strict guidelines.

Ah yes, the solution to software with massive security holes is for everyone to vibe code their own software with massive security holes.

But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.

Sadly, true. I know a person who gets AI news from that YouTuber and quotes him like he’s a household name and pays him for some repackaged chat models. It’s tedious and hard to talk to them about basic/remedial aspects because their education from YouTube is half-heard and superficial. I’m trying to get him to invest the time in hands-on experience and then we can talk about that. When you’re deep into these channels, you’re not gaining experience and you can’t easily start until you pull away.

There is only so much a human can master in his lifetime. And if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing you yap about on camera…

Not a single mention of Pirate Software yet?

as primarily influencers they make money from your attention, not from promoting or making good software.

I like the very non-windows very non-mac ui of omarchy.

Fedora is an arse to use. most of the distros for non free software are targeted at stable RHEL, so are miles out of date.

You only get 6 months of updates, at which point everything break subtly, or not if you use nvidia.

ubuntu with a custom GUI is the way forward, at least compared to fedora.

is there a fedora 44 ws with non free package built in ?

> As a developer who mostly wants a Mac-like Linux distro without the associated noise

I'm required to use Ubuntu at work. Coming from Mac, apart from the menu bar at the top, on Gnome, I've been able to customize the keyboard shortcuts, remap the keyboard so that Ctrl works like Cmd, and use extensions like Dash to Dock[1] and themes like Whitesur[2] to replicate something that almost works like a Mac.

The keyboard remapping and customizing keyboard shortcuts were all done within default the default settings app.

The only things missing are some keyboard shortcuts like Ctrl+A/V to move to the beginning and end, and the Ctrl+Shift+C/V behavior on the terminal instead of Cmd+C, which I've just worked around by using VSCode's terminal and configuring it to copy when I press Ctrl+C with some text selected.

[1] https://extensions.gnome.org/extension/307/dash-to-dock/

[2] https://github.com/vinceliuice/WhiteSur-icon-theme

Why doesn't Ubuntu fit the bill? You can even install hombrew on it. Everything works like a mac with no fuss.

Also the only reason I left Linux was due to hardware. Ubuntu was convenient enough.

> In a different way you can see this in this thread where instead of discussing why Omarchy has the bug

There's nothing interesting to discuss. Rootless OCI-compliant containers exist, and Omarchy ignored them. The "convenience" of the solution they chose simultaneously opens an enormous attack surface that the maintainers didn't consider.

This is why I don't believe the "give me a macOS distro" people - even Apple wouldn't do this. If you want a preconfigured Mac-like distro, then you should use GNOME and not a pre-riced desktop with hundreds of dotfiles. You don't have to use Arch either, you can go with a graphical install of Fedora or CachyOS if you want. This will give you a system that you can understand, maintained by people with a minimum standard of quality, that actually resembles the workflow of macOS. There is no Niri or Sway rice that will magically make your system make sense, and this is why I think a lot of the Mac and Windows expats should just use a normal desktop.

> if you encounter a problem with Arch and ask about it

It's probably already documented on Arch wiki or it's a generic Linux issue that has already been solved by someone (that has been my experience with Cachy).

Basic docker users are the same as angry haters I guess.

Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.

Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.

So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.

macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.

You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.

Android is basically a different OS that happens to reuse parts of the Linux kernel.

Funny because there is a 101 level Qubes RCE on front page right now.

There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one.

The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers.

The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions.

It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise.

It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc.

It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else).

You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).

I mean SElinux plus cgroups is probably good enough. Although as soon as it talks to the desktop environment all bets are off.

Bubblewrap is a less powerful version of sandbox-exec, but the macOS architecture is much larger than just that. In effect macOS runs everything under bubblewrap, in such a way that users don't notice but apps are meaningfully sandboxed and root exploits barely matter.

and Firejail

Flatpak uses Portals to let the user grant access to different files/directories, apparently they don't have access by default: https://docs.flatpak.org/en/latest/sandbox-permissions.html

I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal

I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.

I don't think flatpak allows access to hidden files so even those with access $HOME cannot do this.

Yep, but pretty much every single piece of software you've installed on your system can read and write files to your home directory in a silent way without root, and that's where your most important files are on a desktop machine (API tokens, secrets, client projects, etc.).

I have my own opinionated Arch / niri set up and there's 1155 packages installed. That's 1155 opportunities for a package to be compromised. This is also why I try very hard to avoid the AUR and only use it as a last resort (I use 2 packages from it). It doesn't guarantee safety but the official Arch package repos do seem to have more checks and bounds vs the AUR.

Same if an attacker can run arbitrary docker commands.

but not as root

But very few people are using their systems in ways that fit the Unix security model, which was designed for multi-user mainframes with only trustworthy software.

I challenge anyone to name even one thing that requires sudo on a Linux desktop not better handled with systemd user units, Linux Capabilities, rootless docker, etc.

There is. Simply do not install sudo and do not allow access to root at runtime. I am serious. There is absolutely nothing you cannot run unprivileged these days. Can even run sshd from a systemd user unit in your home folder, and even assign port 22 to it if needed with Linux Capabilities.

on Windows the UAC (GUI sudo equivalent) requires actual user input (keyboard, mouse) on a dialog presented in a secure way (can't be faked by malware)

> You need root in order to overwrite sudo in the first place I think

You just need write access to .bashrc or similar.

> This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges.

Unprivileged malware will be waiting with a root payload ready to fire the next time you tap your yubikey.

Look at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo.

It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar

No, the above attack writes that function into bashrc, meaning the next time the user runs sudo themselves, you harvest their password.

You do not need root to run that shell function, nor to get it loaded into a shell's environment.

They didn't say anything about overwriting the sudo binary, and that is not required, which I think was their whole point was to show exactly how that is not required.

Any user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.

It’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.

Because it is trivial for unprivileged malware to phish the password and escalate to root. No production system should ever ship with sudo.

For a single user, opinionated, modern, developer focussed OS, this is completely and utterly on par. Using docker as a developer without this is just plain annoying.

Adding your user to the docker group is in the official Docker install instructions, I wouldn't call that "random copy paste guides".

The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.

You mean, just how it is on Windows?

*rootfull docker.

Rootless docker is perfectly fine.

That’s awesome! Everyone has different tastes. Personally I love GNOME because it’s extremely productive and works out of the box.

DHH created a distro for what he personally needs for work, and his company uses Zoom.

It's that simple.

Well, DHH is a moron. I don't know if he always was, but he clearly is now.

Somehow I doubt DHH and company would be OK sacrificing ""developer experience"" for security... There is still a non-trivial amount of docker-compose files and Docker incantations that don't work 1:1 with podman and podman-compose. Adjusting them would require Omarchy's users underatanding podman, and I doubt this will align with the opinionated nature of Omarchy..

Compose files work just fine. The gap with Docker has basically closed, and the few things you can't do or that behave differently are precisely the things Docker shouldn't be doing.

except that all three things are getting a lot of social media clout.

they just keep pumping out short form videos or yapping heads talking about how they use x to do y better than any of the old stuff...

I think this is the OP's point. they all exist because there is a lot of noise about them existing and being used.

There is a major difference between uploading your dotfiles to github and shipping it as a mass-marketed distro.

At the very least they could have documented this sort of security trade-off if it actually is an intentional choice.

If you are adding yourself to the docker group, you have presumably read the documentation and its warnings. Does an Omarchy user know the distro has made the decision on their behave?

TFA spells out why this is wrong better than I could.

> There is another important aspect of this configuration. It was opt-out, not opt-in. A user did not have to actually use Docker. The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.

> Security-sensitive defaults matter precisely because many users reasonably assume that the operating system defaults to secure and will inform or prompt them to opt-in to less secure settings.

I have passwordless sudo anyway. XKCD knows why the password is pointless.

lol. people will vote you and not realize the irony.

just look at all the comments "this is a fair and common mistake" that are not being ironic.

And he politically aligns with a lot of people.

> The fact that it is almost an anagram of monarchy is probably a plus for DHH.

I spend way too much time online; but it's good to know I am not this terminally online.

Thank you! Sounds horrible.

I don’t know what a DHH is though, probably not important.

You realize you are exemplary hater when you feel an urge to post comments like this

At least is secure(tm)

WSL2 is also a virtual machine.

WSL2 is also a VM. docker relies on the linux kernel apis, so it must be ran inside a linux VM on macos or windows

I’d rather run real Linux in a VM than a buggy appropriation of it in WSL

Isn’t WSL2 vm based?

Those two aren't as close

Why is it always the people with the worst opinions who make the most stuff though? Why aren't the rest of us making popular stuff?

Well thats what I've noticed lately here on HN, complaining is #1, everything else follows. lol.

He's a person, just like you are. Let him know then, he has an email and you can message him publicly on X.

What he is or what random blog posts present him as?

[dead]