Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Aren't "immutable" distributions really just glorified "live CD's"? Not really seeing the point of them, tbh. It means that users will have to build a custom system image or fiddle with FS overlays just to do system management tasks that are straightforward on all other systems. The single interesting promise of "seamless" A/B updates is a vacuous one, that you could address more effectively on traditional systems by saving a temporary FS snapshot; this would even deduplicate shared data among the two installs, which is very hard to do with these self-contained images.

View on HN

It has always been rather insane to me that user facing applications share packages with the base system.

The atomic distro approach works a lot better for me. Would not go back to a "normal" distro from https://getaurora.dev.

Lots of Linux users hate it, but as a one-time Linux user (about a decade as my main desktop OS) who now does 100% of important computer use on macOS or iOS, I find the division of “stable macOS base all the way through a working and feature-complete GUI desktop; homebrew (and the App Store) for user software; docker and language-specific package/env managers for development dependencies” to be basically perfect. Trying to use linuces where the base system and user packages are all managed together feels insane, now.

It depends a lot on the distro and how volatile it is and what tools are available.

I run Debian stable, and it's not immutable, but it is very unchanging. I don't worry much about system libraries and tooling.

The downside to that is that then userland application are out of date - in enters Flatpak. I run most GUI applications in flatpak. This has a lot of benefits. They're containerized, so they maintain their own libraries. They can be bleeding edge but I don't have to worry about it affecting system packages. I also get much simpler control - no fiddling with apparmor, the built-in Flatpak permission system is powerful enough.

The blind spot then is CLI apps and tooling. Usually it doesn't matter too much being bound to system packages, but if it really does, I can always containerize those too. I only do it for my PHP dev environment.

> I run Debian stable, and it's not immutable, but it is very unchanging. I don't worry much about system libraries and tooling.

I basically did the same with Tumbleweed for a couple of years. Can't stand the point release distros. Lagging behind a year or two when it comes to the DE is not something I fancy. Never liked Tumbleweed much though. Felt very unpolished when using Plasma.

> The blind spot then is CLI apps and tooling.

I can really recommend homebrew. Works well. apt is for the system, homebrew is for user facing CLI apps. :)

I did the same. I have a debian stable. Everything else besides build-essential, firefox and gnome is either docker, homebrew or flatpak

>The blind spot then is CLI apps and tooling. Usually it doesn't matter too much being bound to system packages, but if it really does, I can always containerize those too. I only do it for my PHP dev environment.

Do you encounter any friction getting different containerised tools to talk together? Can you compose them in the classical unix fashion?

I put them on the same container, basically. I bundle my PHP binaries, modules, and tooling all together and then use it on container. It defeats the purpose a bit, but it keeps the system clean. No NPM packages cluttering everything, no composer packages leaking, etc. Cross container, I'm sure, is more complex.

This. I always dreamed of a Debian / Ubuntu Distro where you could fully separate the "SYSTEM ENV" from the Userland ENV with userland referring to system ENV and then if userland ENV has a different, USerland takes presedence when its the user running the command, vs if its some automated service. I do not know if there's something like this for Linux outside of maybe containers? I guess that comes sorta close.

I think GoboLinux might scratch that itch.

Apps are bundled and installed like they are on macOS, and there's a very strict distinction between literal 'System', 'Users' and 'Programs' directories.

Try it before you criticize it.

> It means that users will have to build a custom system image or fiddle with FS overlays just to do system management tasks that are straightforward on all other systems.

What system management tasks? /etc and /var are usually writeable, which is all you need to configure the software on your system. Overlays are for installing new software on the base system, which is only really necessary for something like nvidia drivers because all other software is installable through other means (it's also usually a trivial process). Even if you don't want to use containers, you can use a separate package manager like Homebrew/Nix/Guix/Pacman/etc.

It requires a bit of a mental shift to adapt to if you're only used to traditional systems. It's kind of like the move from init scripts to systemd: it's objectively an improvement in all the ways that matter, but cultural/emotional push back is inevitable :)

I have been using Aurora DX for the last month, and it has been a good experience but has also required a shift in my thinking.

If anything is not included in the base image, you have a few options:

    1. use distrobox to install it in a container, and export the app to the desktop.
    2. use rpm-ostree to install it as a layer.  This is on the slow side, and will slow down weekly updates.
    3. Make your own base image with what you want included.  This is probably cumbersome and requires some infrastructure.

I have a few things in distrobox containers, things which aren't available as flatpaks. The biggest hurdle, for me, was getting wireshark running since the flatpak version can't capture traffic. I had to make a root distrobox container and export the app to my desktop. It works, but there were definitely some hoops to jump through.

I like that updates come through once a week and they aren't applied until I reboot. If I have problems, it is easy to roll back to what I was running before.

I would be comfortable giving my parents an Aurora setup, knowing that they can't easily break it.

I use Bazzite, which ships with the homebrew package manager. Idk if wireshark is available on homebrew, but if it is then you'll be able to use it that way without having to deal with any issues related to containers. Nix is probably another option (you can use Nix as a package manager instead of a distro)

You could also build it from source, although that's definitely more work.

Immutable systems such as this one and Fedora's Atomics and CoreOS/Flatcar have their uses. Whether they make sense for you or for general desktop OSes is another question, but there are many situations where the approach makes a lot of sense.

Really, I don't see a lot of difference between immutable desktop OSes and Android or iOS. That model is not necessarily a bad one when you're rolling out systems that you don't expect the user to need to fiddle with the system management tasks you refer to. If I have 1,000 laptops to manage for a corporate environment, say, or for non-technical users who are not going to fiddle with drivers but might want to install Inkscape (or not).

The advantage of immutable distro over custom OS snapshot is that everyone is booting off the same images. It makes support manageable because behaviors are much more likely to be reproducible. This is what stability is about, not just local system image.

NO!!!! They are in practice more about keeping the core OS very small and stable and putting all packages outside.

Or you can try to install whatever custom packages you need under $HOME, without the need for any special permissions or FS overlays? But yes, saving snapshots is also a good solution.

I guess immutable distros such as this one target people who don't need much customisation and mostly just need what's already there anyway.

>just to do system management tasks

End users should not have to do system management at that kind of low level. They should be able to focus on accomplishing what they actually want to do and not have to maintain the system themselves.

>you could address more effectively on traditional systems by saving a temporary FS snapshot

That's an implementation detail. Every modern OS uses essentially snapshots for A/B updates to avoid wasting storage space.

I understand that disks snapshots with ZFS for example can cover most part of the needed on recovery scenarios.

But immutable OS are helping in progress some sandbox tools and allowing new workflows to manage the OS (virtualized or not).

Reply on news.ycombinator.com