Imagine confusing Nix for something a large user base actually wants.
To clarify: SIP is a world-wide large-scale security improvement that people need, especially those that have no clue how their stuff works. Nix is a technical feat that has almost no reach.
No, you're missing something here. What people are after with immutable Linux isn't generally security like SIP provides. 'Immutable Linux' is about many of the features Nix provides, like atomicity of upgrades and rollbacks. But it still also has a packaged base, unlike macOS, and is generally more flexible than any tools for interacting with the base system.
macOS uses a snapshotting filesystem by default but doesn't let you create labeled snapshots, or enable automatic snapshotting without cluttering your snapshot list with time-based snapshots or enabling auto-pruning.
macOS doesn't have any of the features that help with disaster recovery, reverting upgrades, etc., that draw people towards immutable Linux, snapshotting filesystems, etc. This is true of not just NixOS and GuixSD, but also Fedora Silverblue, openSUSE MicroOS, and to some extent even non-immutable distros that run snapper integrations with their package managers, and so on.
On the other hand, part of what people are after with immutable Linux is greater separation from the base system and applications, which macOS 10+ has always had.
The post you're replying to is (rudely, dismissively) noting a disconnect between what people in the Linux community (relevant for this article!) and perhaps also on HN actually care for in immutable OSes and the idea that SIP should be agreeable to the same crowd because it is about 'immutability'. And it's right!
tl;dr: agree, but there are some valuable semantics that matter more than we think.
Do you truly in your deepest heart of hearts believe that the over 2 billion users that get SIP have any clue about what you are talking about? ;-) (probably also what you're getting at anyway)
You wrote about a bunch of facts, which are true, but it also misses the forest for the trees in a different way. Even if you paid everyone to use Nix, they wouldn't be doing it, because it doesn't fit within their use case ergonomics.
And then there are the technical facts, SIP isn't the same as immutability, it's a mandatory access control where root isn't getting any special treatment. I suppose from a end-user's perspective the 'result' feels similar: no matter how much sudo and su you type, writing/modifying isn't happening.
That is what I was getting at in general: immutability (and reproducible builds of course! without those, what is the point of immutability, what would we measure it against?) is surprisingly little-understood for what it is. As you point out, you can for example use it as a chain of snapshots that with writes can go forward in time but never backwards. Or you could see it as a package-based construction where the packages and their contents are not mutable, but which package you use is. Or if we'd be talking about layers, we could have a union-esque representation of multiple immutable layers together forming a complete rootfs.
As far as I understand, BlendOS is mainly Arch + Docker, but with some added WSL2-like UI sugar. That makes it about as immutable as Docker itself, which is to say: depends on how you configure it, since there are no mutability guarantees with docker, only intentions. You can use cgroups2 to make sure the namespace will never be able to write to an actual persistence store, but at that point people are re-inventing ZFS.
SIP itself is best comparable to mandatory access control, where UID 0 doesn't get to bypass MAC. But if you get something that has the right entitlements, it's just another ACL. Imagine getting a busybox binary with the right entitlements: SIP would let you do anything.
> SIP itself is best comparable to mandatory access control, where UID 0 doesn't get to bypass MAC.
Yes. And it's an area where desktop Linux is really lagging— we don't have much in the way of very simple, toggleable MAC. (We just have the heavy duty stuff where you have to write policies per application in a complex DSL.)
But you can see why that's not exciting, and potentially even annoying, to hackers who want features and capabilities. Barriers aren't fun, even when they're useful and necessary.
> As far as I understand, BlendOS is mainly Arch + Docker, but with some added WSL2-like UI sugar. That makes it about as immutable as Docker itself, which is to say: depends on how you configure it, since there are no mutability guarantees with docker, only intentions. You can use cgroups2 to make sure the namespace will never be able to write to an actual persistence store, but at that point people are re-inventing ZFS.
I admit I don't understand why Distrobox uses OCI with Docker or Podman rather than LXC. Docker is centered on containers that are basically glorified, heavyweight processes. Docker is for shipping individual applications, not persistent operating system environments.
LXC containers, on the other hand, really are system containers— they're for whole, persistent environments rather than for individual, disposable processes. And LXC natively supports snapshotting containers, just like you might do on a VM. So with the appropriate container technology, you don't need to reinvent (or leverage) a CoW filesystem on the metal like ZFS or BTRFS.
You could totally have a tool like `blend` wrap `lxc snapshot` or whatever before and after the guest package manager operations to give you the ability to rollback even each ad-hoc action of the various guest package managers. This is how BTRFS snapshot integration works for pacman via Snapper today, for example. Other package managers integrate it via plugins to the same effect. You'd just be applying the same technique across multiple containerized systems here. You would get time travel, if not reproducibility. :)
If I'm not mistaken, Sun did the same thing with Solaris and ZFS; rolling forwards or backwards was just a matter of choosing the rootfs snapshot of choice. You can even run multiple zones from the same base snapshot and have their own (ephemeral) writes on their own timelines. And on BSD we can do similar things with Jails.
Considering all those technologies (LCX, cgv2, Jails, Zones, containerd etc.), you'd think we're all heading for the same goal and might as well combine strengths instead of yet another packaging/state manager method. Maybe once Snap, Flatpak, Nix etc. all get one or two generational replacements we'll get the state/mutability/layered approach right (at least on Linux) and we can all focus on MAC in a way that is less convoluted than LSM/AppArmor etc. But I bet we'll all still be in SBOM hell for years to come before that gets attention again.
