Everything hyped is usually a counter quality signal

I had just enough issues with archinstall the last time I tried it that I went back to EndeavourOS which essentially gets you a GUI installer and some pre-installed utilities on the stock Arch install. The only significant change I'm aware of is that they use dracut instead of mkinitcpio.

Omarchy imo is best for agent maxxing Mac power users who aren't locked into Apples proprietary apps like Final Cut, audio production software or Adobe and Affinity, so maybe not so great for designers and photographers as the main system.

Vibecoded fixes are quicker

I think this is more about the UI, rather than the install. I haven't tried it myself though.

I think nowadays using quickshell anyone who is so inclined can vibecode their own UI though. I recently made the switch to Wayland/hyprland and rebuilt my polybar on quickshell, even adding widgets that allow getting system info/fine grained system control (interactive Bluetooth, WiFi, Volume, Brightness etc).

Add that annoying theo guy to that list. Cant stand these people, they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap and they've already abandoned it - case in point OpenClaw. Look at the mess of videos those named above put out about it, not a single one uses it anymore.

Just use Fedora. It just werks (most times).

Omarchy seems to be pentested by a bunch of angry haters. Who's pentesting your arch install? :P

I don't find it to be too bloated, and the things I don't like I simply uninstall.

So far its the best Linux Desktop experience I've had, and I hardly have to configure anything out of the box, most of it just works.

i don't understand why DHH is shipping so much bloat in omarchy. The better solution would be to ask if user wants to install bloatware during installation.

the unfortunate thing - is the money pumped into omarchy + the hype around it .... a lot of sheepish followers will just follow the hype.

the tech might gets fixed later.

But, this “vulnerability” is the thing everybody knows about docker since forever. 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. What is different here?

Start a docker container with the docker socket mounted in the container and now you can have yourself mount / as rw. Everybody knows this. How is everybody so shocked here. Many instructions online tell you to make yourself part of the docker group for convenience (like the digital ocean one).

It's definitely not why *I* switched away from Windows

Other than hype, what's the appeal here?

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. Is that rather common now? I'm just a Gnome pleb who prefers discoverability via UI.

On the flipside, once you use an OS that is totally open to agentic stuff, there's no going back really.

I can open Pi and ask it to fix some window tiling issue, help me install shortcuts, help me figure out how to install flatpak vs appimage, etc. the list is endless. I cannot see myself going back to a legacy OS unless I'm forced to by my job for compliance reasons.

"Someone" didn't find that, AI found it. So it's not clear what your point is about vibe coding. Would humans have noticed this problem, especially given that it's not remotely exploitable? (you have to plug in a malicious USB device).

This seems to be quite contrarian considering we had this on the front page of HN the other day: "Debian votes to allow "responsible use of generative AI".

I guess this LLM coding wasn't "Responsible" enough. hahaha

Let the AI bubble pop baby

Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor.

> Unfortunately implementing an Apple style architecture on Linux would be very difficult.

The apple apps kind of thing already exists and its called flatpak.

The issue is not that Linux lacks a central authority that holds some encryption keys and controls what software you can run. The issue is that you should not run any software from a source that can't be trusted. When we used to run only software from community distros or that we compile ourselves, launching a malicious program was a non issue.

Gatekeepers? Someone is pouring something into your ear.

It's easy to disable rootful Docker support in an ISO, but much harder to fix the vulnerable installations. That is not the system working as intended.

And sadly, this stuff isn't bewildering at all. We saw it happen with LARBS, we saw it happen with Manjaro, then Archlabs, and now Omarchy too. All of them endangered themselves by shipping dotfiles that none of their users understood, and few of their developers would justify. When Manjaro's repos conflicted with AUR pkgbuilds, thousands of their users didn't understand that Manjaro had a special repo override for system packages that lags 2 weeks behind upstream. Omarchy tempts the same fate by stacking custom packaging channels and pacman scripts on-top of a system that gets advertised as "regular" Arch Linux.

Distro variety is always a good thing, but there has always been different levels of commitment to it. If I was putting together a Linux system for a kid or someone elderly, I'd just give them Fedora/GNOME instead of trying to get them into larping r/unixporn.

Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)

Docker itself is such a massive security problem. Like it’ll punch through your firewall. Found out the hard way after a misconfigured redis was exposed to the web.

> but I’m not sure this should be framed as Omarchy-specific,

Adding the user to the docker group by default, out of the box, is Omarchy-specific.

EDIT: More accurately, was Omarchy specific, until they realized that it's not a good idea and changed it.

Exactly! I was also surprised by this — that's a sensible default for many people.

However, I agree that it should be opt-in. Docs should be more explicit about that too, they should warn users about risks of going with that option. That excerpt mentioned in the article was rather misleading.

This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.

It's absolutely not Omarchy-specific, Ubuntu has the exact same vulnerability out of the box, just with lxd instead.

Funnily enough it wouldn't work for me as I use passwordless sudo thanks to PAM-U2F with a YubiKey Bio. I mean realistically speaking it probably would as I would just type it thinking "Hmmm weird" but still want to proceed forward ¯\_ (ツ)_/¯

The article specifically calls this out as a preferred option.

I've used docker until recently just because it was what I was used to. It turned out I can basically just `apt install podman` and it'll just work. I might have stayed a bit behind the times with having podman slotted as a redhat thing.

because the distro is all about convenience over security, while selling an aura of technical superiority. Which is the modus operandi that worked for the distro author in the past, when he sold VPS with a big markup, because he also gave a script that did "ssh vps -- curl somebashscript" to do basic webdev taks.

> The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.

just like the vps era. it's all about convenience.

This is a weird metaphor - why do you think people buy matcha at coffeeshops or use peptides? Those two things don't have anything obvious to do with each other, let alone with Omarchy.

Yes.. taste

> Unfortunately implementing an Apple style architecture on Linux would be very difficult.

On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.

As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.

I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users.

If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings.

> Unfortunately implementing an Apple style architecture on Linux would be very difficult.

Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is.

If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.

> it doesn't have any kind of proper desktop sandboxing architecture that really works.

Bubblewrap works.

It is one thing to do things the risky way on your own system and another thing to ship an unsafe and unconventional default to your users.

>when it’s a very common setup to add regular user to the docker group.

As an official configuration? Or in random copy paste guides? The former is very different than the latter. It's not uncommon to disable sudo passwords, but it would be considered a serious security lapse if that were the default on some OS.

Using Docker instead of podman is the first mistake and that is a distro decision (or a "chef" decision, in Omarchy parlance...)

Indeed, and most flatpaks have access to the home directory so are also able to do this even though they're """sandboxed"""

But if an attacker can put arbitrary code into your .bashrc, you are already executing arbitrary malicious code.

Sudo isn't security theater when used for what it was designed for. It's useless for constraining apps you run as your own user ID.

Wow. This never crossed my mind but of course that's so simple. There really needs to be a better solution.

You need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. 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. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.

What? Why is sudo security theater?

that's what I do and what the author recommends as well

Rootless docker is also an option.

> Podman works much better than Docker today.

Nah absolutely not. Especially compose files and networking can be an absolute nightmare with podman.

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.

you probably mean win11 vm script, that's not really a security hole, as the host running the vm you are basically root on windows anyway, unless you bothered to encrypt the drive inside the windows vm

Rootless docker is even an officially supported install method.

Sorta, but there is a reason that no other distro does this by default and that docker itself warns that doing this is effectively giving the user password-less sudo.

So this is a problem in Omarchy specifically since it does the dangerous thing silently and by default while everyone else tries to inform the user of the consequences.

I didn't know that was unsafe.

Well, it's not unsafe because anyone who can exploit it has already fully compromised my PC. It rather involved being on the other side of this airtight hatchway. But I didn't know that putting an actually locked down account in the docker group was unsafe.

> Why would you want to make this the default for your users

Because DHH doesn't have a clue what he's doing and is farming his brain out to Claude. Again.

Debian + KDE is the most effortless setup I've ever used. I also spent years using tiling window managers and I don't see the value

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.

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.

> Did someone configured his own system to work this way and decided it is a good idea to ship it as a part of an "opinionated" distro???

Isn't that the entire selling point of Omarchy?

Default configuration or not, I also imagine the first thing people using docker do is to add themselves to the docker group via sudo.

If you are security-conscious, you shouldn’t be using docker anyway.

Because it's convenient, and the security of this doesn't matter for desktop usage.

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.

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

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.

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

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.

*rootfull docker.

Rootless docker is perfectly fine.

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.

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.

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.

but not as root

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

Same if an attacker can run arbitrary docker commands.

> 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.

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

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

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.

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.

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.

> 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.

WSL2 is also a virtual machine.

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

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

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

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.

and Firejail

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.

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.

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).

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

You mean, just how it is on Windows?

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.

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)

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.

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

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.

Thank you! Sounds horrible.

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

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..

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

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.

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?

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.

And he politically aligns with a lot of people.

Isn’t WSL2 vm based?

which is why you have to hire people who master the art of yap whatever on camera, so the video production guy can have something to work on.

or did you think onlyfans?

UI is desktop environment and (usually) ports to large-use distros cleanly.

- JaKooLit’s Fedora-Hyprland Repository: https://github.com/JaKooLit/Fedora-Hyprland. The most popular automated setup guide and installer for Fedora, bundling Hyprland alongside pre-configured bars, launchers, and

- Official Hyprland Wiki: wiki.hypr.land/Getting-Started/Installation/. The main reference guide for core configuration options, environment variables, and Wayland portal requirements.

- Solopasha Fedora COPR copr.fedorainfracloud.org/coprs/solopasha/hyprland. The primary community repository hosting cutting-edge builds of Hyprland and its ecosystem packages for

- Fedora Discussion Tutorials: discussion.fedoraproject.org. Community walkthroughs covering minimal netinstall setups and distro-specific Wayland troubleshooting.

I run Niri and Dank Material Sell on Fedora. It’s perfect, and better than Omarchy from what I’ve seen. I much prefer scrolling window managers to tilers.

Yeah, GNOME was my previous preference, but I don't see myself going back now

Learning the hotkeys in Omarchy is a bit of a process, but there is a hotkey to show the hotkeys lol (super + K) - and once you get used to them, its super productive, at least to me.

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

This. It’s easy to let happen too. If you’re on a machine that’s not behind NAT then it’s really easy to pwn yourself.

I'm sorry, what?

As an avid Docker user, where should I begin reading about these issues?

Indeed. Podman works great. And kube play unifies container orchestration by using k8s manifests for local orchestration instead of a separate DSL like docker compose.

At least is secure(tm)

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.

> 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.

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.

> if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing

What?

Its perfectly possible to master two things. Video production isnt _that_ hard. Especially as lighting, shooting adding graphics and editing film is much much easier than 10 years ago.

Am I missing something? What does pirating software has to do with that thread?

That's not what I claimed or said, do read my posts please and project less :)

You still have to use rpmfusion, which isn’t a huge deal. It’s maybe 5 min one time and then you are set.

Or you could use one of the Universal Blue spins. Bluefin and Aurora have non-free stuff built in and you can install pretty much any package from anywhere.

Even if you introduce bugs in your UI (which I think is not very likely if you have a basic understanding of your system), the chance that someone would exploit software that literally only runs on your own machine seems extremely unlikely to me.

I've been using arch for over 10 years btw.

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

The whole point of Omarchy is for people who want to use Arch Linux but have it configured the way DHH does.

So I think it's a little different. Anybody using an opinionated respin should understand what they're getting.

It does warn you. It's an opinionated Linux for a modern developer/user. This modification absolutely makes sense in that context.

> I always use sudo to manage the few docker containers I need

I'm afraid that isn't really any better. If the attacker is in position to exploit membership in the docker group, he already has access to the user's .bashrc. He can simply write a function called sudo that wraps the real command and records your password[1]. Unless the user always invokes sudo with /usr/bin/sudo, docker group membership doesn't really make a difference.

Once malware runs as an administrator, getting access to root isn't really that complicated. The boundary between wheel and root is more or less security theater.

[1] https://gist.github.com/tokyoneon/34ce1c9e1530a12eb392b1eab0...

Edit: Oh well, I see now that others have made the same point (https://news.ycombinator.com/item?id=49500588). With the same wording even. I'm half-way tempted to delete my comment so as not to look like a plagiarist, but it seems many posters are unaware of the vulnerability, so I'd leave it here.

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.

“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?”

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

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

My reasons to switch to Linux from Windows were very little about "security" and plenty more about freedom. Sure, it was very nice avoiding running an antivirus, but that was just the cherry on top.

I wanted the freedom to change and "rice" my desktop however I wanted, and the Compiz cube looked awesome. I found Windows condescending and restricting in that regard. Yes, my first reason was the aesthetics, kick me out of the nerds club. (That was also the reason I switched to Mac for 10 years).

My second reason was that I suspected I could learn so much more about computers using Linux full time. And I did.

I was also younger and used to associate Windows with soul-sucking corporate jobs and Linux with new ideas and experimentation. It was us-vs-them. Open Source vs Micro$oft and all that vibe.

Hey, do you have any concerns about malware, in case of using the plugins or themes from these websites ? I was a bit skeptical, considering all the malwares that are being found in the package managers and plugins are pretty much the same thing but as extensions.

> Also, the statement was valid because it will be true for most.

The statement seems more like a preconception than data.

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.

It is kind of nuts how little attention this more-than-controversial-enough aspect of it gets compared to anything else, to the point people don’t even know this about it.

I happen to hate Omarchy for the precise reason I don’t want that sort of interface, but apparently everyone else does, and if they do that’s up to them.

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.

you can pick the best things out of cachy without moving to it wholesale. Like their proton, maybe kernel or mesa

So, one config file? Why would you use a distribution for that?

Eh. That happens sometimes, but its design and track record is really good.

In my personal opinion, SELinux is a rather poor design, and I find that it actively gets in the way of trying to do security well.

I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.

and sydbox

Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing.

Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access.

Also, QubesOS is a thing, therefore QubesOS Linux users have way way better access to sandboxing than MacOS -and- signed devtools packages.

How would you install packages (or update the kernel)?

Windows and Mac each have well thought through and secure solutions to these problems. It just doesn't exist on Linux without serious sacrifice of UX.

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.

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.

Github is awash with people's dotfiles including fully featured DEs built on top of things like Hyprland and Noctalia, and they don't require you to use a mess of a distro to use them.

While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free. Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.

Yes, it reuses all the security features.

Just use podman, as the article suggests.

> 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.

How is that different from creating a new user to run that script? This has been the standard practice on Linux for decades, and it is how I run tools like Codex and Claude on my machine. I wouldn't allow AI tools access to files, mount points, etc, owned by my main user.

This works best for terminal apps; for GUI apps such as Steam and games where running a separate graphical session isn't practical, you can use bubblewrap.

So you're retracting your claim that Bubblewrap doesn't exist/work?

> 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.

If you say no, you can’t use less or cat to read your documents. If you say yes then you are completely unprotected, forever, from anything you might run from the terminal.

> It also needs pervasive kernel enforced app identity

Doing like MacOS needs app identity. But this model is just wrong, because it answers the wrong question. Determining, once, whether Microsoft Word or VSCode may access all your documents, means that any Word document, using valid scripting or an exploit against Word, may access all your documents, and it means that you are fully exposed to anything you look at in vscode (as vscode has almost no security).

The right questions would be: May this document access this file or folder? May this project access anything outside its own folder? May this Python script read your screen? May this AI agent session access this USB device? Kernel-managed app identity is completely unhelpful for any of this.

(Frankly, kernel managed app identity seems unnecessary for most of what Mac does, too. App identity could be set by whatever launches the app, so long as the app’s resulting privileges are not allowed to exceed those of the launcher.)

> And it will suffer from a high degree of centralization where distributors have to approve every app

Please elaborate.

Sure, if you actually think that an Apple-like entitlement system protects you well, then I guess that a non-Apple entitlement system would need some trusted authority to grant entitlements. I do not think it protects anyone very well even if Apple, as the entitlement granter, is considered fully trustworthy.

You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?

https://docs.docker.com/engine/install/linux-postinstall

If the official sudo project had a guide on how to disable passwords, that shouldn't be taken as endorsement of having that as a default config.

Just don't be in the sudo group.

How do you update the kernel?

Take a look at docker-socket-proxy as a somewhat of a counter to this issue:

https://github.com/Tecnativa/docker-socket-proxy

Exposing the docker socket seems like such a rookie mistake to. There's a good reason we've known about docker socket proxies for a very long time.

Also beside that they use ancient package alongside Archlinux. One of those being Chromium. It also used to use Chaotic AUR but now they just automate packages (every 6 hours) in their own repository without any maintainer intervention so it's still open for supply chain issues.

Do you know about docker compose overwriting your carefully set firewall rules? That’s the other docker thing…

In a recent long interview with Lex Friedman, DHH explained that he's essentially doing pure agentic dev on Omarchy now.

https://www.youtube.com/watch?v=NYFGCESmikA

It is, DHH doesn’t seem too shy about it

By the HN guidelines, it’s better to avoid discussing downvotes on HN

You are not missing anything for not knowing but Pirate Software in this context is another youtuber/influencer.

No harm, no foul izacus. I am laughing inside because I'm included in the "angry" group by default (I hate all Linux distros, less than Windows or MacOS) and I'm often a basic docker user but got over major DE customization like Omarchy when I needed to get thing done at a higher rate (back then the coolness was crunchbang).

The Omarchy team admitted it was a mistake and corrected it quickly.

It’s strange that so many people are trying to call this security error intentional.

oh thanks a ton

Windows does have a native sandboxing API that Docker is capable of using IIRC, but nobody uses it.

The macOS situation is even worse in that the kernel lacks the requisite capabilities.

I was watching one guy explaining the xv6 code and it was pretty much one shot with a single camera pointing at the listing on paper. Not sure if you need professional video if you want to really expound on something.

Streaming arbitrary externally-given bytes straight into shell is an opinion, but I feel like it's an opinion some stupid robot had, put there because some trendy humans decided robots have good opinions.

Ah, the opinionated strikes again.

> either have a discoverable GUI for noobs, or a configurable, keyboard driven system

Absolutely wrong. Windows is both and it can be 100% keyboard driven.

I encourage you to think more outside of the box and dream. There is much more you are able to do now, that would have been impossible 2 years ago! :D

https://x.com/SergioTapiaDev/status/2094187967900266573

Isn't the other half of AI that we can afford to look for exploits in one-off software?

> people who want to use Arch Linux but have it configured the way DHH does

Then they don't actually want to use Arch Linux.

The Arch Linux way is to read the excellent wiki documentation, learn about all the choices available, and then make all of those choices so the system is configured the user's way instead of some celebrity's way.

I hope this was an attempt at sarcasm.

The Omarchy team immediately fixed this because it was a security oversight, not an intentional opinionated choice.

Does 'chattr +i .bashrc' reliably prevent this? Always seemed sensible to me. Then again, there are a few files getting sourced by the shell and I am not sure I could spontaneously name them all.

But what exactly are you protecting then?

Linux root/regular-user model comes from an ancient time with multi-user architecture where you defended against one user taking over a big machine they didn't own.

But today on personal computers all the good stuff is inside regular users accounts, and there is nothing valuable to be gained by becoming root.

So the whole security model is broken, it protects the OS system files that nobody cares about, while allowing any piece of software complete access to valuable user files.

The guy who invented Ruby on Rails. He’s been pretty important in web dev and he’s an excellent engineer, although he’s a polarizing figure. He’s always been opinionated and never afraid to ruffle some feathers. More recently, he’s been posting some controversial right-wing stuff online that pissed off a lot of people.

Don't use podman compose unless you want to have a bad experience. Play kube is podman's API for orchestration.

Omarchy is an agent first experience, no? just ask your agent!

You are absolutely right and I'll have Claude read a ChatGPT summary of Paul Graham's hater essay!

Even worse. They don't even have AI review them. I fed the commits that introduced the problem to a few frontier models and they saw several problems, including the aforementioned security problem. Even Mistral saw it. I did have to instruct all models to look for security problems, though, but still.

It's not that we shouldn't use vibecoded distros. It's that we shouldn't use badly vibecoded distros with shitty or non-existent processes.

On Lex Fridman recently DHH was enthusiastically bragging about how he was letting AI generate C++ that he intentionally wasn't even looking at, he was treating it as a pure black box and just submitting the output.

In EU at least you can almost get free as in beer Windows, you can buy a fully legal 2nd hand (resold) Windows license for about $10, the price of a fancy beer.

Windows is already free for ~everyone. Make less idiotic arguments.

Doesn't each app run as it's own user? The OG of security features.

Too much stuff doesn't work with Podman still.

Especially if you're on an SELinux system.

Idk why we need to use sudo to update kernel. In macos, we don't need sudo access?

So the solution is to make your computer basically unusable. I guess that's one way to secure things.

I am not disagreeing at all. Nor am I trying to claim this behavior is safe.

I’m just pointing out the level-set that I’m sure the first time someone installs docker and tries to use it, chances are they are just going to install themselves in the docker group without considering the impact and continue on their day.

The obvious difference is that you have to create that other user (as opposed to denying the ~/Documents request). Also when you curl|bash you normally want to install under current user -- not something you're supposed to do on Linux.

I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...

Per my other comments, it does not really matter if you disable the sudo password or not. If you have a sudo binary at all you effectively are giving every user process root since malware can mask the sudo command and intercept the password so trivially.

You do realize you can do the exact same thing on macOS? Just alias sudo to whatever you want. BSD I assume you can do the same with doas.

No desktop system is safe from your attack, unless you take specific precautions like chattr on the file or chmodding your home directory, but that can lead to weird breakage.

If you're running a malicious user process with write (or read) access to your files, you are arguably already compromised.

Come on. I am sure you don’t like DHH. But he’s always taken security seriously in Rails.

100% this, either use a DE like GNOME or Cosmic if you can't be bothered, or spend a little time looking at someone's dotfiles.

No need to use a whole distribution with 1000 other poor decisions made for you.

Isn't Windows also basically free? Every laptop I buy has a Windows licence stuck to the bottom of it.

The right right question would be: why aren't we enforcing a document to be self-contained? Why are documents agents? Why can any document access anything or indeed, do anything? That's not a document, that's a program!

Bubblewrap isn't a sandboxing architecture, so no. Go look at how Apple designed the macOS/iOS security system and you'll see that a Bubblewrap like tool is only. small portion of it.

Or at least, XP could.

The old human nature tendency of "Just ship it!" and the desire to move on to the next shiny thing on our wishlist doesn't go away with AI. If it anything, it makes it worse.

I am not sure how someone would run an LLM on my computer to look for exploits as the source code is only available on my machine?

That’s like one of two lines of i3status. Awesome if you need something like this one and built it. But don’t pretend that there aren‘t myriad solutions out there that have solved a lot of possible use cases.

Thats the old arch way. New arch is archinstall + AI

Opinionated choice?

I recently used Arch Linux because I have a 4 GiB Mac Air that I want to use for something but it has too little RAM for UI. The installer was user friendly and fast. I got exactly what I wanted.

I don't think that I need Omarchy.

I have only one answer to this:

I'm too old for this shit.

> Then they don't actually want to use Arch Linux.

No, they want to use Arch Linux as configured by DHH

Imo they could have sold it like that, in this case. A warning would be in order though.

The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc. A better way would probably be to use `sudo chown 0:0 .bashrc`.

Also you will want to do the same to .profile (because of LD_PRELOAD etc). And also do the same to any directories in your $PATH (~/.local/bin etc)

Try editing key-values in Regedit using only the keyboard.

Couldn’t you say that about any Arch spinoff? Seems to be the no true scotsman fallacy.

installing arch is enough of a pain that I've been putting off installing it on my desktop for months.

There was no oversight and no security. It's vibe-coders pushing unvetted shell scripts and dotfiles.

They "immediately fixed it" after it blew up on X/Twitter. Just like all the other issues they've had in the past few weeks.

And now they formed a "security team" lol.

Go on, what other docker things should we know?

You basically don’t use sudo on macOS though. Maybe once in a blue moon

No popular Linux desktop, I would grant you. I use QubesOS and my own distro, stagex.

which means you paid for it. just because it comes bundled doesn't mean always it's free. https://en.refund4freedom.org/

> No need to use a whole distribution with 1000 other poor decisions made for you.

I used Vim for a decade (and Linux for much of that time) and the constant tweaking and changing things drives you mad after a while. The more you invent it yourself the more it changes. This is why I prefer MacOS+VSCode these days, which comes with good defaults and simpler VIM-style bindings.

Omarchy sounds like those popular vim configs such as https://astronvim.com/, which I also tried using and also ended up heavily customizing myself. It provided some nice defaults as a baseline but was ultimately comes with too much hyper-customization (which has a lot to do with vim/neovim trying to act like other more modern editors).

Linux in-general is a small portion of the Darwin architecture. One is a monolithic kernel, the other has microkernel IPC security to consider.

Are there any glaring limitations in Bubblewrap you'd like to point out, or are we having the Tannenbaum argument all over again?

Exactly the point. You are already fully compromised, sudo adds no security.

No, you've been charged for every one of those licenses.

You can also just pirate it.

No and you missed the "freedom" part of the adage.

Shopify forced him to be a vibe coder now. Omarchy is a vibe coding distribution.

In the AI world, security issues are just another marketing opportunity.

EDIT: Downvote all you want. He was anti-AI, got a board seat at Shopify and then became an AI influencer. Now additional money is rolling in to Omarchy from Lütke and Steinberger.

Documents containing scripts are genuinely useful, as are, say, Python programs.

As I said, podman requires effort and thought on the user's side, as the rootless part incurs complexity. I do not think that this aligns with the omakase mantra of omarchy. I do not think that DHH does not take security seriously. I think that Omarchy is not meant to sacrifice devex for security.

The freaking point is that basically anything worth running will have that amount of access, even Flatpaks. And you don't freaking know what's malicious before hand.

You start regedit.

cursor up/down, page up/down, or F3 to search, hitting enter to follow directories, until you reach the key.

Hit enter on the key. The values will be displayed.

Hit tab until you are on the key you want to edit.

Hit enter. A popup with the value will appear.

Type the new value, hit enter.

A much more painless process than I anticipated, honestly, and it refreshingly uses the same conventions that used to be used everywhere in windows.

Set-ItemProperty -Path "HKCU:\Software\MyNewKey" -Name "Example" -Value "Blah" :)

> Couldn’t you say that about any Arch spinoff?

I can, and I do.

https://wiki.archlinux.org/title/Arch_Linux#User_centrality

> It 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.

DHH was on the Lex Fridman podcast talking about this recent release of Omarchy in that most of it is "vibe coded". It is mostly just a bash script to configure Linux, but his approach is interesting.

AI as a core part of the OS that can just change or add anything you want. Linux is great for this because it has access to the source code for everything.

He said he didnt review the code line by line, just looked at the shape of it. Whatever that means.

It's something you do literally once.

I think that depends on your point of view. I wouldn't run a program on my computer unless I were sure that it's not malicious. And if you mean that some program I already trust could be exploited, that's true even for the Linux kernel or any sandbox / security solution you would come up with. I'm not denying that there's always a risk, but there's nothing good in running arbitrary code that you can't trust.

It's really disturbing that there's a group of these CEO/investor types that are openly white nationalists, and they're joining forces. I'll never touch any of their products, and I hope they continue to expose themselves on social media.

A python program isn't a word document

Rootless Podman (and rootless Docker for that matter) is not difficult to set up automatically. There is a little complexity involved, namely in configuring subuid and subgid mappings, but not much.

That said, I think Arch Linux itself has a culture that values the wrong kind of simplicity (implementation simplicity) that perversely leads to a failure to adequately grapple with inherent complexity. This leads to brittle implementations, "buyer beware" norms, "you should have run the notes", "this command should never be used", etc. Omarchy inherits all of that from Arch. It also, it seems, carried its own perverse notion of "simplicity".

Yes and?

People write real software using Microsoft Office's scripting features. Sure, it's not "cool" the way that Python is cool, but it works.

And neither Microsoft nor Python has a credible security model.

I was not referring to the setup complexity. Setup is performed just once. I was referring to the runtime complexity that comes naturally from having to take into account non-root user permissions and lack thereof. These peculiarities are quite a low bar, but they are still a non-trivial hurdle in the way of devex.

I am a fedora/opensuse user and happily use podman with selinux.

IME it's not too bad, but I see what you're saying. I guess we're mostly in agreement.