> but I think that’s true of any aspect of a distro.
That's true, but these problems are worked on for a quite long time, and the core ethos of a Linux distribution is being able to be on both sides of the fence (i.e. as a user and as an administrator which can do anything).
For example, in macOS, you can't customize the core of the operating system since the eternity, and it's now sent you as an binary delta image for the OS, and you have no chance to built these layers or tweak them. This increases the ergonomics a ton, because you're not allowed to touch that part to begin with.
However, with Linux, you need to be able to change anything and everything on the immutable part, and this requires a new philosophy and set of tools. Adding esoteric targets like "I really need to be able to install two slightly different compilations of the same library at the exact same version" creates hard problems.
When these needs and the mentality of "This is old, let's bring it down with sledgehammers. They didn't know anything, they're old and wrinkly people" meets, we have reinventions of wheels and returning to the tried and working mechanisms (e.g.: Oh, dynamic linking is a neat idea. Maybe we should try that!)
Immutable systems are valuable, but we need less hype and more sane and down-to-earth development. I believe if someone can sit down and design something immutable with consideration to how a POSIX system works and what is reasonable and what's not, a good immutable system can be built. Yes it won't be able to do that one weird trick, but it'd work for 99% of the scenarios where an immutable system would make sense.
> However, with Linux, you need to be able to change anything and everything on the immutable part, and this requires a new philosophy and set of tools.
Taking macOS as a North Star as a successful mutable Os,
most people don’t need to, and shouldn’t be, touching the immutable parts. I know the assumption is that you need to do that on Linux, but I don’t think a successful distro should require most casual users to go anywhere near that level of access.
If they do for some reason on Linux specifically, why would overlays not be sufficient? They achieve the same results, with minor overhead and significant reliability gains.
> I believe if someone can sit down and design something immutable with consideration to how a POSIX system works and what is reasonable and what's not, a good immutable system can be built.
But someone has done that. macOS is POSIX. SteamOS just works for most people.
I think there are a couple of problems with taking macOS as the so-called North Star of the immutable OSes.
First of all, macOS doesn't have package management at the core OS. You can't update anything brought in as the part of the OS from libraries to utilities like zsh, perl, even cp. .pkg files bring applications in to mutable parts of the operating system, and can be removed. However, OS updates are always brought in as images and applied as deltas.
In Linux, you need a way to modify this immutable state in an atomic way, package by package, file by file way. That'd work if you "unseal, update, seal" while using EXT4 FS. If you want revisions, you need the heavier BTRFS, instead, which is not actually designed for single disk systems to begin with.
You can also use overlays, but considering the lifetime of a normal Linux installation is closer to a decade (for Debian, it can be even eternal), overlays will consume tons of space in the long run. So you need to be able to flatten the disk at some point.
On the other hand, NixOS and Guix are obsessed with reproducibility (which is not wrong, but they're not the only and true ways to achieve that), and make things much more complicated. I have no experience with RPM-OSTree approach.
So, if you ask me we need another, simpler approach to immutable Linux systems, which doesn't monkey patch tons of things to make things work.
> But someone has done that. macOS is POSIX.
Yes, but it's shipped as a set in stone monolithic item, with binary delta updates which transform it to another set in stone item. You can't customize the core OS. Can you? Even SIP sits below you, and has the capability to stop you with an "Access denied." error even if you're root on that system. It's a vertically integrated silicon to OS level monolithic structure.
> SteamOS just works for most people.
SteamOS is as general purpose as a PlayStation OS or car entertainment system. It's just an "installable embedded OS". Their requirements are different. Building and maintaining a mutable distro is a nightmare fuel already, making it immutable yet user customizable is a challenge on another level.
It's not impossible, it's valuable, but we're not there yet. We didn't find the solutions, heck even can't agree on requirements and opinions yet.
Even though macOS won’t let you replace the actual binaries that ship with the OS, you can still replace the binaries that get resolved when they’re called via brew/nix/macports etc.
I again disagree with your assertions that you need to replace the OS contents. You just need to be able to reflow them to other ones. That’s the macOS way, the flatpak way etc..
I think the issue is that you are claiming that you MUST be able to do these things on Linux, and I’d push back and say no you do not.
And your comparison of SteamOS to a console or in car entertainment is flat out incorrect. Have you never booted it into desktop mode? For 90% of users, what are you expecting they need to do in that mode that it’s not “general purpose” enough to do?
Yes, it’s not impossible. It’s been done multiple times , successfully as well.
> you can still replace the binaries that get resolved when they’re called via brew/nix/macports etc.
Yes, but this doesn't make my point invalid and irrelevant. $PATH overriding is as old as this planet itself, and its primary purpose is not to make immutable systems more user-friendly. It's just a way to use your own binaries if you want to override itself.
Being able to use flatpak, etc. on a system doesn't and won't allow you to change the core OS. Being able to reflow things doesn't solve anything about system management, esp. on the long run.
> I think the issue is that you are claiming that you MUST be able to do these things on Linux, and I’d push back and say no you do not.
I'll politely won't move and say that it depends. If you're building appliances or embedded systems, that might be discussed if there's an absolute requirement to remove the update mechanism, but for a server and end-user system which can live more than a decade, this is a core requirement which can't even be discussed, full stop.
> And your comparison of SteamOS to a console or in car entertainment is flat out incorrect.
I don't think so.
> Have you never booted it into desktop mode? For 90% of users, what are you expecting they need to do in that mode that it’s not “general purpose” enough to do?
No, but even Valve doesn't say what you say. What Valve says is "Users should not consider SteamOS as a replacement for their desktop operating system. SteamOS is being designed and optimized for the living room experience." (emphasis mine)
[0]
Its desktop mode is akin to Browser sessions present in consoles, or "Other OS" which used to be in Playstation. IOW, a nicety, not a feature.
> Yes, it’s not impossible. It’s been done multiple times , successfully as well.
Yes, to answer different set of requirements with set of different features. We still have a long way to go with "An immutable, daily driveable, desktop and server distribution which can be maintained, used and updated for a decade" (a-la Debian).
I think there’s been well done immutable systems and it’s something that can be achieved with a mainstream Linux distro.