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.
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.
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.
This is the type of security and vulnerability testing that actually matters. In a sea of security researcher noise, thank you for contributing in a meaningful way.
I just want to put this out there, smolmachines is a wonderful program to solve this, I use this mostly for stuff needing docker socket / docker in docker (example strix and agents). (I'm using podman on my host)
OK... and? This doesn't matter for a desktop, because:
1. Having access to the user's home directory is way more serious than being able to install drivers or whatever
2. There are a million other ways to escalate to root by obtaining the user's password
I also don't understand the point of these distros, just install Arch with KDE via archinstall, it literally takes 15 minutes. Why is it that people feel the need to use someone's Arch setup?
Lol! He's gordon ramsay of tech, who's frequently contradictory himself. On Round 2 with lex, he said something like no one lost recently due to using digital Maps. Well, check this one - https://youtu.be/z5ElIor-oXk?si=XfcS1UtC2OWReVXr
He's bashing and insulting all engineers and then asking for their contributions and complaining that not many people are committing code in open source repos.
The point is that there are millions of people out there that are curious about Linux but are put off by anything command line. Distro like this, especially Quatro which has a big focus on agents, makes it more inviting and gives people an instant path to get help/have their problems solved without them having to search archaic error messages
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.
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)
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.
> Ubuntu has the exact same vulnerability out of the box, just with lxd instead.
No, it does not[1]. LXD:
- explicitly warns against this mode of vulnerability. Of course, there's no protection against people who blindly run commands copied from the internets, but the official documentation, at least, for as far back as I can recall, has had clear warning boxes against this, with explanations.
- does not have the track record of bad design that docker has had (IMO).
Yes, it does. None of this information changes the fact that, on a fresh install of Ubuntu Server 24+, the default user can privilege escalate to root using a few LXD commands.
Ah, Ubuntu _Server_. I'm tempted to dismiss this by simply saying "Server Linux != Desktop Linux", but yeah, I don't like that this is on by default either.
I mean, this is a setup that ships with a default password that's the same as the username, and the first thing I do on all my server installs is disable all default user accounts and enable passwordless sudo.
From reading other docs of Ubuntu Server, it appears they relax the root/non-root distinction in other ways too. But I'd probably never have suspected this particular vector of vulnerability.
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.
Why would you want to make this the default for your users, without even telling them? 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??? Makes you wonder how much other crap is there.
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.
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.
I don't use Omarchy, nor would I, but I think that "VERY, VERY" is a little hyperbolic, no? It's a simple `admonish-yellow` warning box that says something vague about root-level privileges and wants me to read more about what this actually means. I would wager that a large amount of people scroll past that with no second thought because it really doesn't come off as that bad. I know I configure most, if not all, of my systems this way. Many people probably don't actually understand the implications of what they are doing, and perhaps the Docker team should actually put a little bit more effort into scaring users off.
Perhaps Omarchy shouldn't have shipped this by default, but the whole point of the system is to be DHH's personal computer just the way he likes it (to include not 1, but 2 shortcuts to Twitter!) - all his products are that way and largely the reason why I don't ever think I could use one long term.
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.
Yup. I've been on zirconium (https://github.com/zirconium-dev/zirconium) for a while, and it's great. Fedora atomic/bootc under the hood with Niri+DMS. Basically bombproof.
Fedora (or debian, or archlinux or whatever distro you choose) doesn't force you into an UI. All of them have minimal, server and/or "flavored" versions and you can always uninstall and install whatever you want.
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.
Counterpoint: I've had very few (and always minor) problems upgrading between major Fedora releases over the years with no more effort than following the well-documented steps to do so, including both traditional and atomic variants, the latter with a wide variety of layered packages as specifically not recommended due to potential problems when upgrading.
And on the server side of things, I ran a Fedora CoreOS VM with a Pihole container that silently and successfully auto-updated both the OS and the service container for years with no intervention on my part.
I had to support fedora on desktop and laptop for a large company.
Worse, it wasn't my job to support those machines, its just my department needed cuda and I was the slowest person to run away when they called for help.
"Archlinux is much easier to install nowadays" is not really the point.
Arch is a more general purpose distro. As a developer who mostly wants a Mac-like Linux distro without the associated noise, if you encounter a problem with Arch and ask about it, you will probably get a lot of irrelevant opinions from all sorts of people that run Arch on everything from embedded devices to large servers. In a different way you can see this in this thread where instead of discussing why Omarchy has the bug (guess what, "default user and all processes launched in that user session have access to root." is a convenience that a lot of developers would like to have), people are recommending their favorite distro instead.
Even though I don't like DHH much, what Omarchy is offering is a user experience that is built with a specific sort of developer in mind; the kind that used to use Linux, moved to Macs for the convenience, and would like that convenience replicated on a Linux distro. That's why people use Omarchy specifically rather than Arch, not the YouTube stuff. I think CachyOS was the equivalent for gamers.
> 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.
> There's nothing interesting to discuss. Rootless OCI-compliant containers exist, and Omarchy ignored them.
Why Omarchy chose to ignore all the rootless OCI-compliant containers; and also why docker itself isn't rootless yet is a pretty interesting thing to discuss. I'm not aware of the specifics being a Mac user myself, but others in the thread (e.g. here https://news.ycombinator.com/item?id=49500186) say that podman still doesn't work 1:1 with docker exactly.
If you disagree, that's a reasonable thing to discuss; but otherwise just saying "ha ha just use the rootless thing" is missing the point.
If you're not going to use rootless containers, then you simply cannot ship the rootful solution as default in a desktop operating system.
There's absolutely meat on the bones regarding root/rootlessness, but that's not the problem at-hand. The problem is shipping vulnerable defaults, and the case is closed.
Homebrew is like giving a bunch of wikipedia randos remote shell access to your computer. There is no enforced code review policy. Any maintainer can make a commit under a pseudonym and merge their own code to main without review.
Homebrew should not be allowed near any machine you need to be able to trust.
I love wikipedia for research. It is great that anon randos can help keep a common encyclopedia maintained with high accountability. If a mistake happens it is quickly corrected.
But that trust model does not work with software.
It is an absolutely insane thing that it is standard practice on MacOS to let any anon rando that signs up to be a Homebrew maintainer execute any code they want on any user computer with no accountability. By the time someone figures that out and corrects it, the damage is done.
Only honest commits by good actors are reviewed. Good for QA but useless for security.
Cryptographic signing is not enforced for commits or reviews, so an attacker that controls a single maintainer Github API key can make a PR with a burner account then "review" and merge their own PR. Time it right and bury it in a dependency of a dependency and you are likely to get away with it. Especially considering they also do not do full source bootstrapping or enforce deterministic builds so including random binary-blobs in tree is a-okay and not sus at all.
The fact everyone is not aware of this is exactly why it is going to work, or already has.
I did once propose to the Homebrew community to enforce commit and review signing but they ultimately refused, worrying that asking people to press a button when it blinks would cause too many definitely smart and useful contributors to leave the project.
> 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.
if you reset the keyboard shortcuts to their defaults and install toshy you can get the ctrl-a/e stuff and copy and paste in the command line with cmd-c/v and a lot of the other mac like keyboard shortcuts. it's really plug and play and works well... can't recommend it enough. (though there are some edge cases that may require some tweaks but overall it's great)
> 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.
The fact that you think this is acceptable shows that you don't appreciate the difference. Again, I haven't used Omarchy but the docs claim that Super + C and Super + V work everywhere, not with all the different exceptions you mention.
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.
Hah. I know a person who gets his 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.
> they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap
100%! When the US attacked Iran, they became experts on wars; when Iran closed the strait, they turned experts on foreign policy, diplomacy, and negotiation; they were doctors during COVID; now they are SME in flooding and disaster control after the Nepal incident.
It’s sad, but a lot of software folks have decided to become influencers and not pursue expertise. I remember before you’d mostly be reading boring looking blogs to follow experts in the industry. It seems like the mindshare has moved to flashy videos by people that aren’t experts, but are great at communication. Similar to how if you want to watch some diy video on YouTube, you’ll get much better information from a poorly produced snd edited video from someone that knows what they’re talking about vs a well produced and edited video from someone that has no idea what they’re talking about.
I don't think I've ever actually seen a theo video, but I stumbled across this and think I've seen all I need to know. 3:45 even references your criticism.
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.
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.
I think I get your point as omarchy represents a different kind of UI, but if it was just about getting a rock solid stable working environment, Fedora or Ubuntu with either Gnome and KDE work perfectly fine. I don't even use a third party terminal (just konsole). Keyboard driven terminal workflows works fine on KDE for me.
The problem is not the hype, the problem is that it's a vibe coded distro. AI lowers the bar substantially in terms of needed competence and diligence to create something like this. Of course bugs and issues are present in human created software as well, but now that everyone can vibe code a distro the chances of low quality software are much greater.
Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it.
So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you.
On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility.
Unfortunately implementing an Apple style architecture on Linux would be very difficult.
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.
Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has for example 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) 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.
Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).
On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.
I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.
You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.
It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.
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 isn't the case at all. Please learn about Apple's security architecture before making sweeping claims like this, it is very deep and has nothing to do with user namespace sandboxes. Windows also has a sandboxing architecture, it's just not as good as Apple's.
FlatPak's security architecture is an attempt to sort of head in the same direction, but they are a decade+ behind and will probably never get there.
Sigh. Qubes had some great security design and implemented it the only way time/funds would allow: by cobbling together a lot of unfortunately very complex and broken things built for a different security model decades ago.
Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS.
what are you on about? The fact Qubes has to exist proves Linux is insecure. QubesOS is not a Linux distro. It just happens to ship dom0 as a Fedora VM. But it doesn't just support Linux, it also supports Windows and BSDs. None of Qubes security guarantees come from the Linux kernel.
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.
I hate to be defending Omarchy but I think for the modern desktop OS like Linux or Windows or Mac OS, "root" is not what it used to be.
Like if I have something on my dev machines which is important from an enterprise perspective it is the credentials that I use to check things into the git repository or log into the postgresql database that are in some file or keyring or the credentials I used to log into some corporate IT system with my web browser. Or the Microsoft Word document with confidential plans, or the spreadsheet with personal data on 30,000 people that I don't really need to have, etc.
The "root" barrier is of limited effectiveness against those sort of attacks but the barrier between users is less important on a personal computer as opposed to the "minicomputer" world that gave birth to Unix.
In 1989 my school had a cluster of Sun Workstations running Unix for which student, faculty, and staff had accounts and it was a real threat model that you might steal the homework assignment of another student or you might take screenshots of the screen of the computer center's director that would let you watch him reading his email his email and such.
I more concerned that Apache is running under a "httpd" account or IIS is running under its own account so that I do have controls on what can be exfiltrated by that route but...
The modern developer is likely booting up a sinatra or JAXB or a httpx server on some high numbered port running as their own user so if they're going to get hit with data exfiltration or remote execution against a dev server the scope is most user files.
I would say that the traditional notion of Unix root and normal user accounts is outdated, no longer useful for how people use computers today. On my personal laptop, malicious code having access to my user files is as bad as having root access - I'm the only user of my machine - and I don't have any convenient way to create more granular security zones among software running as my own Unix user.
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.
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.
I'm sure "superior software" is true for most, but that's a much wider goalpost than the people specifically worried about security/vulnerabilities. One of the biggest factors pushing people to Linux lately is the increasing number of ads and annoyances being crammed in to Windows. Security has been moderate for a long time.
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.
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.
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.
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.
Can you say what you prefer? I'm always down for alternative UX flows and with hyprland being so user specific it's hard to see how people leverage it across the spectrum.
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.
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.
> 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).
Yeah, I mean when I set up my last distro I just installed claude and told it what I wanted and in about 30 minutes it was up and running. No need to install random distros!
The nice thing about wayland is you can easily combine a compositor/window manager with a wayland desktop shell and get a lot of the stuff you used to have to fiddle with when using like i3 for free. For example, I use niri with the “dank material shell” desktop shell and get status bar, notifications, clock, suspend/resume, etc. all “out of the box.”
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.
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.
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.
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.
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.
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 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.
Then it's not for you, or you can't vision how 5 minutes of learning can save you hours of future time.
Having to know like 5 keybinds and no taskbar is absolutely the point and it's a beautiful concept of how to use your computer. And it works, if you are open to relearning just a bit.
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
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.
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.
Omarchy is obviously a badly vibecoded distro. Even the basic concept is kinda dubious, not just the execution.
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.
"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).
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.
HN has been fundamentally broken for a long time, there's nothing new or special about AI. It just joins a loooong list of topics where people abuse downvotes and flagging to punish people they disagree with.
Ironically, the right fix is to replace human moderation with AI. Every so often I think about creating an HN or old-Reddit style discussion website that gets rid of user driven moderation entirely in favour of "polite but free speech" rules, assessed by LLMs on the fly, along with ways for users to label comments with various adjectives for both their own filtering and training a RecNet. A bit like a mashup of Reddit, HN, Slashdot and new ideas.
Doing that from Europe is tricky due to the lack of the first amendment, but could be worth a try anyway. It could probably be sold to an American if local laws become too difficult.
Yes. An additional reason is that both X and Reddit are no longer viewable without logging in. This might attract readers, though perhaps not posters, who need to log in anyway. But your free speech rule might make the forum one-sided over time because users whose views are excluded elsewhere would concentrate there.
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?
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).
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.
> 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.
> 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.
Assuming you mean "they don't actually want to use Arch" as a criticism (rather than a truism), I think that's fair for a distro described as "Arch linux but configured X way". I don't think it's a good criticism for something like SteamOS which is configurable but is aiming hard for "it just works".
Actually we do. I like pacman for example. And don't mind going thru archinstall for a test install once to learn. But my workstation, I'd not like to have to develop, even if I do like configuring minimal installs for other uses like kiosks.
I like and use Arch daily. My "way" was just to get past the fdisk squirrel catcher. After that it was as easy as Ubuntu. I'm not bragging, I wish I'd read the manual but was too impatient for that. I suspect I'm not the only arch user that arrived at it using similar approaches. I might even be a target user for DHH's distro but the bloat (and to some extent the vibe coding) holds me back.
I didn't realise there was a correct way to use Arch, or that there were people authorised to explain what it is. Is that an Arch-exclusive service, or is it available for other distros as well?
You say the whole point is ending up with a system configured the user's way instead of some celebrity's way, and then you go on to tell us what we are actually allowed to want. That's a bit rich.
Starting from someone else's config and then changing whatever annoys you is making the choice, it just skips the part where you spend a weekend reading about display managers to arrive at the same place. That is what dotfiles have been for since roughly forever.
By your standard, anyone who used archinstall from the official ISO isn't really using Arch either, and I suppose the truly enlightened path is Linux From Scratch, compiled this morning, on hardware you soldered yourself.
It might be a mistake but not a serious one, like it's a common setting they had on for convenience of development without being too insecure, but forgot to leave it out of public release.
So there's nothing weird. It being on originally was intentional and not crazy. Only it going all they way wasn't.
Overly active analytics / tracing stuff is not uncommon during dev. Likely they just did it to be able to debug things better in the weirdest cases; doing a full session replay basically when you have the whole original state of the repo
What exactly is special about rolling a custom arch in this instance? Like, why does this get so much attention? Do web developers really care about what DHH does that much?
Like, I get it if thats the case. Say, if Chris Lattner or Andrej Karpathy rolled some ML GPU programming distro I'd probably care about it and try and see if it made me more productive.
I thought that’s pretty much the way all technology goes. Just seems silly to take promotion an operating system that’s essentially a lot of config files atop existing work seriously from someone that made a popular web development framework 20 years ago. That’d be like me caring about a distro Gavin king made because he made hibernate in the 2000s at jboss.
He leveraged his past success as a web developer to get into online culture war punditry. Now he's a prominent race-baiting reactionary.
There's a sort of cult of personality around him at this point. His acolytes follow him for his nativist views, and then adopt his technology unthinkingly.
I don't know why my comment was downvoted above. This isn't a serious distribution and you shouldn't expect it to be. It's a vanity project of a niche alt right tech bro, and this is the level of rigor you should expect.
Yeah that’s exactly it. Seems he’s manufacturing a lot of culture war bullshit just to bring attention to a less than interesting distro. If it wanted to be the “hyperland“ distro as so many distros are (built to bring one de/wm to users prepackaged) that’d be one thing. If he wanted to show people how to roll their own opinionated distro the way gentoo or lfs kinda did that’d be another too! But seems it’s neither of these, and purely vanity to me.
I don't use Podman desktop but I haven't had any issues at all with basic Podman. It just seems like a better overall design. It would be great if Docker copied the rootless / daemonless approach if possible.
For me the problems are always when I pull some image (like GitLab) and try to get it to work with podman. Or the hoops you have to jump through with podman-compose (user lingering, systemd services, privileged ports (80,443) [yeah I know it's a feature]). Docker just works, Podman (I feel) still requires stuff that makes it less declarative (to get to a running infra).
Still, having a gitlab runner with a docker in docker setup that can access the host docker socket is not something you do lighty, so I am eyeballing buildah etc.
I guess what really grinds my gears is that I'd use podman a looooot more if it could nicely coexist with Docker. I'd use Docker for the big services and podman for all my own stuff. But that is just not possible (at least not afaik), so it is also difficult to switch step by step (yes VMs, bla bla, but it's all complicating).
> 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.
> 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 more or less security theater.
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.
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)
> The attacker could use `chattr -i .bashrc` with the same privileges before editing your bashrc.
No. Setting flags requires root privileges, sudo was implied. At least on my system.
> Also you will want to do the same to .profile (because of LD_PRELOAD etc).
Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.
Absolutely. Docker is a boiling mess of baked-in convenience workarounds (ie vulns). It's an orchestration layer (like k8s with containers), not a real security boundary like VMs. OTOH, single-purpose VMs are basically just as easy these days and those can still pull in containers as needed.
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.
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.
You add yourself to the docker group to be able to use the socket. By default, a uid 0 on a docker container is run as root, regardless of the uid of the owner of the container. That is precisely the issue being discussed.
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.
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.
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.
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.
Unfortunately, it's hard to classify something as a "rookie mistake" when the developers behind the most revolutionary enterprise tech in the world have accepted it as "by design" & just put a hard-to-find disclaimer about it on one single page of their dense docs.
It certainly does help quell imposters syndrome whenever it creeps up on my though.
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.
> But, this “vulnerability” is the thing everybody knows about docker since forever
OP’s point exactly - it seemed somehow in their vibecoding workflow, they forgot to even do a human architectural sniff test for the stuff everyone knows. It reflects very negatively on them.
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.
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.
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.
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.
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.
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.
To be fair it's possible the situation has changed since I last checked. But at least it used to be this way (https://flatkill.org/2020/). I'm glad the situation has improved in terms of security, but I'm still not a big fan of the flatpak design as a whole.
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)
UAC is only a sudo equivalent when running under a non-admin user account, at which point it's nearly as convenient to simply run admin commands from a command prompt running as a separate user, or a separate desktop session entirely.
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 write files to your home directory in a silent way.
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.
Arch at least mandates author signed packages which is unfortunately rare these days, but keys do not need to be on smartcards, and code review is not enforced. You compromise the right arch maintainer and you could do some real damage.
Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise.
I do know some of the arch maintainers (e.g. dvzrv IIRC) are working on build infrastructure that would completely automate the build process and HSM signing to separate read-only images on build servers[0, 1, 2]. I haven't heard about updates to buildbtw in a while, but development seems still somewhat active and signstar is mentioned now and then at some conferences. It feels like it is not making any progress, but I don't pay any attention to the development, so it is likely just my perception of it just having been waiting on visible process to it and not seeing it.
I am aware of their work, and while this is better than the status quo, it does even come close to my threat model of "trust no single computer or machine" which is what I must support.
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 ¯\_ (ツ)_/¯
Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target.
Right but that's my point, since 99.99% of users don't rely on U2F I doubt it would be covered or even be rational to cover such edge cases and thus most likely wouldn't work. I'm not saying it's a magical perfect solution, only that being outside of the most popular flow is in itself a protection for the most automated attacks.
Desktop alternative to most uses of sudo: Polkit[1]. For a UAC style prompt, see AeroShell[2].
However, one still SHOULD NOT allow untrusted software arbitrary read/write access to their $HOME, even on a completely secure (and thus, imaginary) OS. No reason why every App X should have access to the files of every App Y.
I mean, I saw this on twitter, and thought ok maybe its a nice exploit. But really? its the usual docker root thing?
I wouldn't even consider that a vulnerability tbh, every personal laptop I had I add myself to docker group. Yes, you can not namespace pids, filesystem, etc, and get root, but it's never mattered.
If someone can run that docker command, they can already read your whole homedir, edit bashrc, etc etc,. and sudo is useless anyways.
Only on a system where you are a user without sudo access, does it even begin to make sense. And if you go to the trouble of intentionally setting up a user without sudo access, you wouldn't be adding that user to the docker group either. In the default install, I assume omarchy adds you to the sudoers as well, making this a perfectly ok thing to do
Even if you participate in the esteemed Red Hat Security Theater and use wayland, flatpaks, etc, most flatpaks can write anywhere in your home dir, so they can do this too.
On standard linux desktop, sudo is not really security, but it is a UX improvement as it adds friction to accidentally doing things to the "system".
I genuinely put companies that invested in this on my blacklist. I don't care about the politics behind it. His whole persona is and was to be edgy and cruel so nothing will change here. But there are probably millions of oss projects that deserve the funding more.
407 comments
[ 0.27 ms ] story [ 21.8 ms ] thread> 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.
> Podman works much better than Docker today.
Nah absolutely not. Especially compose files and networking can be an absolute nightmare with podman.
Every day I wake up and thank the universe for MS making WSL2
1. Having access to the user's home directory is way more serious than being able to install drivers or whatever
2. There are a million other ways to escalate to root by obtaining the user's password
I also don't understand the point of these distros, just install Arch with KDE via archinstall, it literally takes 15 minutes. Why is it that people feel the need to use someone's Arch setup?
He's bashing and insulting all engineers and then asking for their contributions and complaining that not many people are committing code in open source repos.
Rootless docker is perfectly fine.
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.
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.
No, it does not[1]. LXD:
- explicitly warns against this mode of vulnerability. Of course, there's no protection against people who blindly run commands copied from the internets, but the official documentation, at least, for as far back as I can recall, has had clear warning boxes against this, with explanations.
- does not have the track record of bad design that docker has had (IMO).
- supports fine-grained ACLs and user management.
----
[1]: https://ubuntu.com/blog/shared-development-environment-with-...
https://starlabs.sg/blog/2026/06-old-wine-in-a-new-bottle-a-...
And yes, I've tried it myself, it works as advertised.
I mean, this is a setup that ships with a default password that's the same as the username, and the first thing I do on all my server installs is disable all default user accounts and enable passwordless sudo.
From reading other docs of Ubuntu Server, it appears they relax the root/non-root distinction in other ways too. But I'd probably never have suspected this particular vector of vulnerability.
> Omarchy configured its default user as a member of the Linux docker group.
What the fuck? Docker makes it VERY, VERY clear this is unsafe. Feel free to verify the documentation.
https://docs.docker.com/engine/install/linux-postinstall/
Why would you want to make this the default for your users, without even telling them? 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??? Makes you wonder how much other crap is there.
If you are security-conscious, you shouldn’t be using docker anyway.
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.
Because DHH doesn't have a clue what he's doing and is farming his brain out to Claude. Again.
Isn't that the entire selling point of Omarchy?
At the very least they could have documented this sort of security trade-off if it actually is an intentional choice.
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.
Perhaps Omarchy shouldn't have shipped this by default, but the whole point of the system is to be DHH's personal computer just the way he likes it (to include not 1, but 2 shortcuts to Twitter!) - all his products are that way and largely the reason why I don't ever think I could use one long term.
(example: NetworkChuck, Primeagen? and a few others)
also, archlinux is much easier to install nowadays with archinstall [1], so i'm not sure you really need another opinionated layer on top of it
[1] - https://wiki.archlinux.org/title/Archinstall
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.
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.
And on the server side of things, I ran a Fedora CoreOS VM with a Pihole container that silently and successfully auto-updated both the OS and the service container for years with no intervention on my part.
Worse, it wasn't my job to support those machines, its just my department needed cuda and I was the slowest person to run away when they called for help.
Arch is a more general purpose distro. As a developer who mostly wants a Mac-like Linux distro without the associated noise, if you encounter a problem with Arch and ask about it, you will probably get a lot of irrelevant opinions from all sorts of people that run Arch on everything from embedded devices to large servers. In a different way you can see this in this thread where instead of discussing why Omarchy has the bug (guess what, "default user and all processes launched in that user session have access to root." is a convenience that a lot of developers would like to have), people are recommending their favorite distro instead.
Even though I don't like DHH much, what Omarchy is offering is a user experience that is built with a specific sort of developer in mind; the kind that used to use Linux, moved to Macs for the convenience, and would like that convenience replicated on a Linux distro. That's why people use Omarchy specifically rather than Arch, not the YouTube stuff. I think CachyOS was the equivalent for gamers.
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.
Why Omarchy chose to ignore all the rootless OCI-compliant containers; and also why docker itself isn't rootless yet is a pretty interesting thing to discuss. I'm not aware of the specifics being a Mac user myself, but others in the thread (e.g. here https://news.ycombinator.com/item?id=49500186) say that podman still doesn't work 1:1 with docker exactly.
If you disagree, that's a reasonable thing to discuss; but otherwise just saying "ha ha just use the rootless thing" is missing the point.
There's absolutely meat on the bones regarding root/rootlessness, but that's not the problem at-hand. The problem is shipping vulnerable defaults, and the case is closed.
Also the only reason I left Linux was due to hardware. Ubuntu was convenient enough.
Homebrew should not be allowed near any machine you need to be able to trust.
And I'm guessing you go to https://www.britannica.com/ when you want to learn something about a new topic, right?
But that trust model does not work with software.
It is an absolutely insane thing that it is standard practice on MacOS to let any anon rando that signs up to be a Homebrew maintainer execute any code they want on any user computer with no accountability. By the time someone figures that out and corrects it, the damage is done.
Cryptographic signing is not enforced for commits or reviews, so an attacker that controls a single maintainer Github API key can make a PR with a burner account then "review" and merge their own PR. Time it right and bury it in a dependency of a dependency and you are likely to get away with it. Especially considering they also do not do full source bootstrapping or enforce deterministic builds so including random binary-blobs in tree is a-okay and not sus at all.
The fact everyone is not aware of this is exactly why it is going to work, or already has.
I did once propose to the Homebrew community to enforce commit and review signing but they ultimately refused, worrying that asking people to press a button when it blinks would cause too many definitely smart and useful contributors to leave the project.
So instead they chose the honor system.
Just don't.
It's probably already documented on Arch wiki (that has been mu experience).
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
https://github.com/RedBearAK/toshy
The fact that you think this is acceptable shows that you don't appreciate the difference. Again, I haven't used Omarchy but the docs claim that Super + C and Super + V work everywhere, not with all the different exceptions you mention.
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).
But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.
100%! When the US attacked Iran, they became experts on wars; when Iran closed the strait, they turned experts on foreign policy, diplomacy, and negotiation; they were doctors during COVID; now they are SME in flooding and disaster control after the Nepal incident.
Average Theo Video: https://www.youtube.com/watch?v=h1p9zdUtUdo
UI is crucial. If people want something easy to use out of the box without spending days to configuring it
> The exploit has been submitted to CERT/CC, because as it turns out, it affects many other distros as well :) https://x.com/lainshawty/status/2093992795287535705
So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you.
On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility.
Unfortunately implementing an Apple style architecture on Linux would be very difficult.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
The apple apps kind of thing already exists and its called flatpak.
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.
On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.
You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.
It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.
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.
FlatPak's security architecture is an attempt to sort of head in the same direction, but they are a decade+ behind and will probably never get there.
As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.
Qubes is the least bad option for laptops (until Stagex Work ships which I am designing) but there is no reasonable server OS.
I am ripping off the best ideas from xen/Qubes and starting over with: https://distrust.co/blog/enclaveos.html
Like if I have something on my dev machines which is important from an enterprise perspective it is the credentials that I use to check things into the git repository or log into the postgresql database that are in some file or keyring or the credentials I used to log into some corporate IT system with my web browser. Or the Microsoft Word document with confidential plans, or the spreadsheet with personal data on 30,000 people that I don't really need to have, etc.
The "root" barrier is of limited effectiveness against those sort of attacks but the barrier between users is less important on a personal computer as opposed to the "minicomputer" world that gave birth to Unix.
In 1989 my school had a cluster of Sun Workstations running Unix for which student, faculty, and staff had accounts and it was a real threat model that you might steal the homework assignment of another student or you might take screenshots of the screen of the computer center's director that would let you watch him reading his email his email and such.
I more concerned that Apache is running under a "httpd" account or IIS is running under its own account so that I do have controls on what can be exfiltrated by that route but...
The modern developer is likely booting up a sinatra or JAXB or a httpx server on some high numbered port running as their own user so if they're going to get hit with data exfiltration or remote execution against a dev server the scope is most user files.
https://github.com/omacom/omarchy/commit/9285b19d6a72eba3df8...
Don't use vibecoded distros. It doesn't matter whether they fix this or that, or whether you care about a particular vuln. This is not sensible.
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.
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.
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.
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
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.
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.
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).
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.
Whoa! You have to _learn_ something to use it well? Yikes. Not for me.
Omarchy aims to find a middle ground between those two.
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.
Having to know like 5 keybinds and no taskbar is absolutely the point and it's a beautiful concept of how to use your computer. And it works, if you are open to relearning just a bit.
I guess this LLM coding wasn't "Responsible" enough. hahaha
Let the AI bubble pop baby
It's not the same thing as allowing some AI contributions under strict guidelines.
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.
Omarchy is obviously a badly vibecoded distro. Even the basic concept is kinda dubious, not just the execution.
the tech might gets fixed later.
You don't get to gatekeep what distros get financing and users.
https://www.youtube.com/watch?v=NYFGCESmikA
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.
Here you are just wanting to appeal to the guidelines to shut down inconvenient but true statements, again.
Ironically, the right fix is to replace human moderation with AI. Every so often I think about creating an HN or old-Reddit style discussion website that gets rid of user driven moderation entirely in favour of "polite but free speech" rules, assessed by LLMs on the fly, along with ways for users to label comments with various adjectives for both their own filtering and training a RecNet. A bit like a mashup of Reddit, HN, Slashdot and new ideas.
Doing that from Europe is tricky due to the lack of the first amendment, but could be worth a try anyway. It could probably be sold to an American if local laws become too difficult.
Any interest in such a site?
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).
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.
So I think it's a little different. Anybody using an opinionated respin should understand what they're getting.
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 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.
No, they want to use Arch Linux as configured by DHH
You say the whole point is ending up with a system configured the user's way instead of some celebrity's way, and then you go on to tell us what we are actually allowed to want. That's a bit rich.
Starting from someone else's config and then changing whatever annoys you is making the choice, it just skips the part where you spend a weekend reading about display managers to arrive at the same place. That is what dotfiles have been for since roughly forever.
By your standard, anyone who used archinstall from the official ISO isn't really using Arch either, and I suppose the truly enlightened path is Linux From Scratch, compiled this morning, on hardware you soldered yourself.
It’s strange that so many people are trying to call this security error intentional.
So there's nothing weird. It being on originally was intentional and not crazy. Only it going all they way wasn't.
They didn't forget. They never knew it was there. https://news.ycombinator.com/item?id=49502099
Overly active analytics / tracing stuff is not uncommon during dev. Likely they just did it to be able to debug things better in the weirdest cases; doing a full session replay basically when you have the whole original state of the repo
Like, I get it if thats the case. Say, if Chris Lattner or Andrej Karpathy rolled some ML GPU programming distro I'd probably care about it and try and see if it made me more productive.
There's a sort of cult of personality around him at this point. His acolytes follow him for his nativist views, and then adopt his technology unthinkingly.
I don't know why my comment was downvoted above. This isn't a serious distribution and you shouldn't expect it to be. It's a vanity project of a niche alt right tech bro, and this is the level of rigor you should expect.
If only Podman could beat Docker in advertising…
Still, having a gitlab runner with a docker in docker setup that can access the host docker socket is not something you do lighty, so I am eyeballing buildah etc.
I guess what really grinds my gears is that I'd use podman a looooot more if it could nicely coexist with Docker. I'd use Docker for the big services and podman for all my own stuff. But that is just not possible (at least not afaik), so it is also difficult to switch step by step (yes VMs, bla bla, but it's all complicating).
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.
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 more or less security theater.
[1] https://gist.github.com/tokyoneon/34ce1c9e1530a12eb392b1eab0...
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)
No. Setting flags requires root privileges, sudo was implied. At least on my system.
> Also you will want to do the same to .profile (because of LD_PRELOAD etc).
Yeah, that's what I meant with additional files sourced by the shell. I knew about .profile, but I am not sure that's all of it. I think different distros may be set up differently in this regard. Also I am pretty sure, you can define function overwrites/aliases and execute code in any file getting sourced, it's not just LD_PRELOAD attacks.
I didn't know this.
https://github.com/Tecnativa/docker-socket-proxy
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.
As an avid Docker user, where should I begin reading about these issues?
https://docs.docker.com/engine/network/firewall-iptables/
https://docs.docker.com/engine/install/linux-postinstall/
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.
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.
Unfortunately, it's hard to classify something as a "rookie mistake" when the developers behind the most revolutionary enterprise tech in the world have accepted it as "by design" & just put a hard-to-find disclaimer about it on one single page of their dense docs.
It certainly does help quell imposters syndrome whenever it creeps up on my though.
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.
OP’s point exactly - it seemed somehow in their vibecoding workflow, they forgot to even do a human architectural sniff test for the stuff everyone knows. It reflects very negatively on them.
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.
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.
https://x.com/SergioTapiaDev/status/2094187967900266573
"Think outside the box and dream!"
"Here's a world clock widget."
More like, don't use Omarchy, or vibecoded Operating Systems.
Running a descriptor into a shell command is laughably sloppish.
Really good reminder I gotta say
They run completely unsandboxed and are unvetted.
Just overwrite sudo with this evil sudo:
function sudo () {
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.
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.
Psst. There's also this, in typical KDE style: https://github.com/aeroshell-desktop/uac-polkit-agent
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.
Arch is second only to Guix in terms of supply chain security for desktop distributions, but both still have a threat model that cannot tolerate a single laptop compromise.
Stay tuned for stagex for workstations. https://stagex.tools
[0]: https://gitlab.archlinux.org/archlinux/signstar
[1]: https://gitlab.archlinux.org/archlinux/signstar-os
[2]: https://gitlab.archlinux.org/archlinux/buildbtw
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
However, one still SHOULD NOT allow untrusted software arbitrary read/write access to their $HOME, even on a completely secure (and thus, imaginary) OS. No reason why every App X should have access to the files of every App Y.
1: https://wiki.archlinux.org/title/Polkit
2: https://github.com/aeroshell-desktop/uac-polkit-agent
I wouldn't even consider that a vulnerability tbh, every personal laptop I had I add myself to docker group. Yes, you can not namespace pids, filesystem, etc, and get root, but it's never mattered.
If someone can run that docker command, they can already read your whole homedir, edit bashrc, etc etc,. and sudo is useless anyways.
Only on a system where you are a user without sudo access, does it even begin to make sense. And if you go to the trouble of intentionally setting up a user without sudo access, you wouldn't be adding that user to the docker group either. In the default install, I assume omarchy adds you to the sudoers as well, making this a perfectly ok thing to do
Even if you participate in the esteemed Red Hat Security Theater and use wayland, flatpaks, etc, most flatpaks can write anywhere in your home dir, so they can do this too.
On standard linux desktop, sudo is not really security, but it is a UX improvement as it adds friction to accidentally doing things to the "system".
[I don't use omarchy]
Is there a name for a phobia of yt thumbnails?