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.
The functionality provided by such an API could be limited to disabling the account until the password is manually reset given that the client provides a valid email and password. The blast radius for that would be pretty small.
I don't use 90% of the entries in my password manager on a monthly basis so anything that allows me to delay the password change on hundreds of accounts until I need to use the account again would be valuable.
Ironically, you have a very strong opinion on people with strong opinions. Going as far as saying if you have a strong opinion on how to use git means you're a junior is a bit extreme, in my opinion.
I’m sure you could change his mind with a good reason. What reasoned argument can you give as to why it would be better to have a strong opinion about why one type of merge is always better.
Maybe you’ve seen the long term affects of squashing commits in several different contexts, and it always leads to a poor outcome eventually. Sure there might still be reasons to do it, but you’ve never seen a case where it’s worth the cost in the long term. Eventually with experience (and several different contexts), you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
Maybe this doesn’t actually apply to git merges, but I imagine that there are certain things that eventually emerge as having extraordinarily unfavorable trade-off ratios.
It’s hard for me to think of anything off the top of my head, but one example could be using global scope for all of your variables. Sure, it’s a small app now, but do you really want to rewrite everything later when it’s impossible to understand? Of course there are (tiny) benefits to building an app with all global variables, but it’s hard to imagine that is ever a worthwhile trade-off, and I think it’s fair to build a strong opinion that you should use (at least some) local scope.
> you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
I think a "measured" approach here would be to say that the evidence required to convince you that this would be a good idea raises which each new domain in which you see it fail. It's not to say that you cannot be convinced; but it's to say that the burden of proof is heavy.
I think it often is the "multiplication" of severity and frequency. Once burned badly enough gives a lot of weight to your preference, even though it is not what you typically associate with the word "measure".
Same for me. In group situations I always have the pressure to talk so I am not overtalked by other people. This obviously depends on the group, but that's gow I usually feel.
I also have a quite high "response latency" and people just tend to answer and share the stories quicker and more eagerly, so I feel often left out in those situations.
The guy replying to you said it's a pretty unlikely situation, so you treat it the same as other unlikely, but always present, issues that your car might have. You accept his answer.
Or you don't, and argue with him and say that you think he's wrong and it's going to happen too often, that's a fine reply too.
That sounds interesting. I might search for that python explanation, have an eureka moment, then forget most of it in 24 hours. It's happened a couple of times with monads.
I recently went through a "re-structure", and the result was a massive layoff, including Staff-level engineers. So I don't find that as a particularly compelling argument, your job description is never safe anyways.
As a non-native english speaker my internal voice stuttered while trying to read "through tough thorough thought", felt like a real life 4th wall break.
