Not sure how I feel about this “distroless” pattern. It’s interesting to be able to get components directly from upstreams from like Gnome, but it makes certain tasks more difficult.
The lack of any distro packages to fall back on when flatpak, distrobox, appimages, and brew fails is simply annoying. I’ve experienced this multiple times.
- When I would flash OSes on my Pixel, I couldn’t use flatpak/distrobox/brew. I would either have to (1) overlay a browser and ADB tools, (2) overlay ADB and maybe use an Appimage browser, or (3) boot into a traditional distro like Debian that has an unrestricted browser. Distroless has no recourse for me here.
- Using sshfs: installing sshfs from brew or distrobox would not work without host configuration changes made by overlaying sshfs. Distroless has no distro package to fall back on
- Using tailscale: tailscale from brew didn’t work. Had to fall back on distro package. Distroless would fail me here, but in this case, I believe Jorge preinstalls it. So simply adopt all of Jorge’s tastes and applications and you’ll be fine…
- No upstream Steam support since there’s no rpmfusion or official valve package to use, you’d have to use something like the unoffical Steam flatpak
While I love Fedora Atomic and atomic distros in general, I constantly feel like they do not think things through. They made the system harder to break, but with severely limited (if you use them the way you’re encouraged to, like no layering). They then address these gaps one by one with more and more solutions that are imperfect and that do not fit all needs.
- Flatpak is good for GUI apps, but not CLI.
- Brew is good for CLI stuff, but does funky PATH things that could break host OS at times (and as mentioned, did not work for sshfs or tailscale for me). KDE Linux initially promoted Brew, but then later recommended not using it at all due to its PATH shenanigans
- Distrobox is good if you need distro packages, but the containerization has limitations with desktop integration and more complex tasks, like I mentioned with flashing OSes on my Pixel.
At least with Fedora Atomic (and containerfiles with bootc stuff), I can get a robust system, seamless OS upgrades, and install any packages that do not work well as flatpaks/distrobox/appimages.
“Distroless” sounds hip and innovative, “a distro without a package manager” doesn’t
We should note that it is super easy to extend a bootc release, and use dnf to install additional packages. It is a docker/podman contanerfile of a few lines.
I have a github repo that adds virtmanager and ghostty to the excellent zirconium release, rebuilds ever day - and then uupd pulls the update every day.
The atomics are not meant to limit you, they are meant to free you to get what you want, usng simple oci tools.
Another great thing is being able to swap distros with simple commands. I installed bluefin, then swapped to zircnium to get niri and dms.
no layering
I foresee a future in which (so-called) sysexts will be used heavily to address the resulting gaping hole. Unfortunately, it’s not perfect either…
Though, I have to say that I find it quite hilarious to see how many alternative package managers are required to replace traditional package managers.
That’s my gripe with Atomic distros. I feel like they don’t take the time to think things through and throw together. Instead, they throw together a new thing to address the shortcomings of the previous five things.
Love them or hate them, it feels like the only player sticking to their guns is Canonical with snap. It’s the only package manager that really does it all: GUI, CLI, IDEs, server, daemons, even the kernel and GRUB. Honestly, when the permission prompting is stable, I might be tempted to give it another chance.
I wonder if they’ll one day just alias a bunch of stuff, kinda like what Ubuntu has done with forcing Snap down people’s throats. So, like:
sudo dnf install bottlesactually doingflatpak install bottles- OR, e.g.,
sudo dnf install tldractually doingbrew install tldr - etc…
I don’t think it’s necessarily bad as long as it’s very transparent on what it actually does (and why). And…, offers choice where applicable*.
Or…, like, introduce a new package manager that basically functions as a front-end. Would that ((and/)or the earlier alias-thing) be worse than sticking to the development of a single package manager until it does all (à la Snap)?
I feel like they don’t take the time to think things through and throw together. Instead, they throw together a new thing to address the shortcomings of the previous five things.
This is a weird statement it’s designed this way on purpose. You seem to be looking for “one package manager to rule them all” in a world that’s purposely splitting things up.
There’s probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn’t need containers for this at all.
It’s frustrating how we have all the pieces to make this work, but they just don’t come together properly:
- Brew isn’t sandboxed and pollutes the environment
- Nix isn’t sandboxed and can’t prefix install (also the DX with Nix really sucks)
- Guix is like Nix but without the packages
- Flatpak doesn’t have the packages
- Snap is proprietary garbage
Maybe this is a hint that I should write my own package manager,
with blackjack and hookersthat works like Nix, but doesn’t hardcode/nix/store, runs everything in bubblewrap and works with SELinux?Coldbrew kinda works like that. It uses bubblewrap and uses Alpine’s packages: https://gitlab.postmarketos.org/postmarketOS/coldbrew.
The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.
I haven’t heard of Coldbrew before, it looks very interesting.
The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.
That’s also how I feel about it. I’ve heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.
I have also been a Bluefin user for a while now…
Could you say more about the PATH issues with brew? Or point me to where I can learn more about them? I was kind of enjoying brew for installing development tools, and was thinking about adopting it on my non-atomic machines too. Should I not do that?
Brew installs both applications and their dependencies. When brew is added to the PATH, it also puts all those dependencies on your PATH.
For the most part, this does not cause issues. The OS usually uses absolute paths for binaries and dependencies. But for some programs, they will rely on PATH and may not be compatible with what brew provides.
Ideally, I think brew should fix this by only adding what you explicitly install to your PATH. When you launch it, it should launch a wrapper script that updates PATH with the homebrew dependencies. Though that wouldn’t exactly work for those who install a shell like zsh since then that would inherit the brew libraries anyway.
Or instead of changing PATH at all, use a fancy linking mechanism like Nix.
Universal Blue does some path tinkering to fix this, not sure how though. KDE Linux also has their own workaround, where they instead prioritize system dependencies over brews so that it’s brew that would break instead of the OS.
Little more info from KDE:
Thanks for the info, I really appreciate it!
So far, I will say that I haven’t run into any issues but it’s interesting to learn about some of the pitfalls/limitations too.
It’s all about trade offs, I guess!
I’ve never tried these “distroless” systems before. Curious about these setups. Have you tried nix pkg manager in place of brew?
I’ve used NixOS, wasn’t that big of a fan. I certainly love the idea, but not the execution. Fedora Atomic just comes out of the box as a more complete, configured system that’s easier to understand.
I have been meaning to use Nix on Atomic, but the problem is that since / is immutable, Nix cannot create /nix and so doesn’t work properly. But there are workarounds for that issue, I just haven’t tried them yet.
Nix certainly fixes the PATH issues of homebrew since it has its unique linking system.
I’ve used NixOS, wasn’t that big of a fan. I certainly love the idea, but not the execution.
Would you mind elaborating on that? I do have some suspicions but I would love to hear what bothered you about it.
- It’s pretty minimal out of the box (a bit like Arch). Unlike Fedora with SELinux or Ubuntu with AppArmor which come configured and enforcing out of the box.
- Nix is a programming language, and a complex one at that. There are plenty of ways to achieve the same goal. But as a novice or even intermediate user, it’s hard to know which is the best way. It also doesn’t help when you go with Way A and later want to do something else, but you find someone’s setup that uses Way B. Should I switch to Way B too? Or should I try to combine both ways into Way C?
- Flakes. First off, it’s annoying to have everyone say that NixOS is declarative and reproducible. Then you look into it a bit more and the story changes to “oh actually you need to enable this experimental feature to get better reproducibility”. But the part that actually annoys me is how everyone uses flakes and expects you to too, but it’s been an experimental feature forever and doesn’t seem any closer to becoming not-experimental.
- Linking issues. Say I install something like nvim with nix, then an nvim plugin wants to install something. That plugin isn’t aware of nix and tries to do things the Unix way, but that breaks. I know there are two solutions/workarounds to this problem; some packages are patched to avoid this and there’s something you can put in your configuration that “emulates” a more traditional environment that’s more compatible.
- I like sandboxing so I would use flatpak in NixOS. But there was some issue with fonts and icons I believe. I can’t remember if this PR fixed it or not: https://github.com/NixOS/nixpkgs/issues/119433
- Not the best UX out of the box. It’s common to find people with nix caches of hundred of gigabytes large because the system doesn’t automatically clean things up.
But the part that actually annoys me is how everyone uses flakes and expects you to too, but it’s been an experimental feature forever and doesn’t seem any closer to becoming not-experimental.
Lix at least doesn’t pretend that Flakes is something obscure.
Then you look into it a bit more and the story changes to “oh actually you need to enable this experimental feature to get better reproducibility”.
This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a
fetchTarballbuiltin function which allows you to pin a specific Nixpkgs commit and output hash.You’re right though, I agree on basically every point (including the part about flakes).
