OpenSUSE Leap 15.6 to Be the Last in Its Current Form
linuxiac.com
linuxiac.com
This may also explain the biggest discrepancy from RHEL being in how SLES packages storage-related stuff (eg. SLES is pro-Btrfs, while RHEL is against, SLES is slow to upgrade mdcrypt, while RHEL isn't etc.)
But this is just a guess.
Whenever I have to deal with "immutable" distributions or attempts to do something immutable (like Snap) on otherwise less immutable systems for individual users, I always end up disabling / removing / uninstalling. It's just an awful end-user experience, if the end user is a human.
I think you mean developers? Otherwise most popular end user OSes are immutable by default these days.. Chrome OS, Android, Steam OS. Honestly it makes sense that we draw a line between platform and applications, and not let application updates/installs break platform.
Imagine your non technical family members install some application that pulls in 100 dependencies one of which breaks the next Ubuntu upgrade..
I hate Android with a burning passion. I pray for a different OS for mobile phones that's actually not as user-hostile as Android (well, MacOS is even more user-hostile... so that's not going to work). I don't think most Android users use it because the like it. There's not much of a choice there.
> Imagine your non technical family members install some application that pulls in 100 dependencies one of which breaks the next Ubuntu upgrade..
I have non-technical family members who use Ubuntu. They had some old laptop that couldn't run Windows anymore, and so Ubuntu was an easy solution to that problem.
So, here's their situation:
1. They don't update anything. There's really no reason to. What they have there works fine. It will break, eventually because of the drive to change and discontinue things unnecessarily, but it will take years. It's unlikely that the laptop will survive that long. And even if it does, they'll just ask me to fix whatever their problem is.
2. Guess how I know about Snap!? Hehe. So, apparently, Ubuntu for desktop comes with this... "feature". And of all things they decided to install Firefox as a Snap package. And of course it's broken. And of course there's no easy way to fix it, while retaining Snap. The easiest and most reliable way to deal with it is to get rid of Snap altogether, and to install from Mozilla's PPA. Precisely because of the difficulties with upgrades.
So, yeah, theoretically non-technical users might run into the situation you describe. But you kind of forgetting that upgrade-induced problems is more of a Microsoft thing, where they force upgrades on their users and eventually break things. It's the Microsoft world where users constantly have to deal with broken updates. If you are a Linux user, you might just live happily with whatever you've installed 5+ years ago and just enjoy your life.
I am just waiting for the day we have an officially-supported Arch Linux Atomic distro based on ostree (pacman-ostree?)
I have been working on an immutable OS that uses squashfs instead and it seems to work better. The contract is tighter with squashfs, as you really _can't_ change the underlying squashfs stuff. Upgrades are easily scriptable and transparent on what they're trying to accomplish, too. The distribution is designed as a "meta" distribution with different flavors (deb, ubu, arc, fed, etc) that you can easily "swap" to just by changing the boot stuff, all configured to deliver the same kind of functionality (container host, mostly).
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer...
edit: there's a link in that document to https://github.com/containers/image/pull/902
New one on me, I had to search for its meaning. This seems to be a SUSE marketing term. But what I read seems to be some kind of immutable distribution with heavy focus on containers.
Good for SUSE, glad right now my distro is not going down that path and as far as I know there are no plans for that. But I am sure someday upstream may force it to.
When that happens, depending on how it plays out, off to OpenBSD full time, I use BSD now to test all development I do on Linux. I really like the simplicity of pledge(2) and unveil(2) plus the protections OpenBSD has by defaults. Testing on OpenBSD helped find some obscure bugs in a few of my objects.
Eg. I build a few projects myself. And sometimes I also need to debug them, after they are installed. Also, very frequently used programs, like Web browsers end up there.
So, if I had to use an immutable system, I would either not put anything useful in /usr, or would not use an immutable system at all.
This is, of course, not true for systems that are meant to be deployed and changed very infrequently, where stability of operation and ability to cleanly undo an upgrade are much more valuable than the convenience of changing whatever you need.
----
I think, a lot of such systems also very quickly earned a bad reputation because they also tried to ship with common applications for interactive use that don't work well (or at all) on such systems (eg. code editors). So, the first people to try such systems were programmers, who spend most of their time using the system in the code editor, and seeing how that doesn't work saw such a system as worthless.
And about the web browsers, aside from the fact that immutable distributions tend to ship one by default, can't you just install them via Flatpak?
If I put my binaries in the "immutable" place, it's no longer immutable.
I mean, if, say, I don't build my shell myself -- I'm also not going to modify it anyways. So, expending extra efforts on ensuring immutability is just making my system more complex for no reason. But, if I do build my shell myself, then immutability only gets in the way. There isn't a situation where I gain something tangible from immutability (again, as an individual user).
----
Actually, from my history, the most common thing I need to do in /usr is to create symlinks for various shared objects. Didn't even think about it at first.
If I install the borked shell into my $HOME then fixing it is as easy as removing the broken binary so I fall back on the underlying working shell.
That's the value of immutable /usr, having a reliable underlying fallback system which my fallible human self won't fuck up due to carelessness or hubris.
And yeah, I think most people only modify /usr to put library symlinks in for applications that have particular dependencies. But you can put those where ever as long as they're on your load path.
I dunno. I'm not afraid of breaking /usr. If I screw up, I'll fix it. I don't screw up often enough to have to also deal with setting up backups.
Being in the storage business, I have a sense of how hard it is to have functional / useful backups, how much you need to test that the backups will actually work, that they will do what you want them to do... I.e. if you think that setting up Snapper is going to solve your problems with bad installs, you probably didn't investigate the subject in depth. It covers but one of many potential failure scenarios. Anecdotally, one of my first experiences with immutable snapshots was with Btrfs, which... actually, I don't know what happened to it beside knowing it was a software error (the physical storage outlasted Btrfs by many years). So, once upon a reboot I discovered that Btrfs simply won't mount, and then I had a week-long process of trying to understand the failure, trying to restore from snapshot etc. And, eventually, I reformatted the disk with Ext4. The data wasn't salvageable at all (layered filesystem aren't your best friend if you want to recover data...).
It's really easier for me, individually to try and deal with the consequences than to have to set up and supervise a system that might help me if I screw up.
Again, this is all said from a perspective of individual usage. I have a different approach to computers that need to be used for business / organizations. There, I think, it's justified to spend the extra effort on backups, recovery protocols, data consistency etc.
So, to rephrase: I don't think that immutable /usr doesn't have value. It's just the effort for individual users isn't justified by the value it provides to them.
Aye, there's the rub: you're you: smart, handsome, successful. You're intelligent enough to know what you're doing or at least to figure out how to fix something if you do happen to make a mistake.
Conversely, I'm me: the average user. It's a miracle I can think (for a broad definition of think) and breathe at the same time. For the one time in a decade that my one brain cell overexerts itself and I try to do something 'clever' it's really helpful if the system can limit the amount of damage I cause. And I think that for the average pseudo-sentient troglodyte like myself it's better to have a system which is awkward to use but hard to break rather than something that gives enough rope.
It's kinda like the difference between a programming language with manual memory management and something like Rust (with the borrow checker) or Lisp (with garbage collection). For someone with a modicum of intelligence C is fine, but the majority of people are better off with a language that keeps the sharp objects locked safely (if you'll pardon the pun) away.
The issue is that most things are not containerized (or should I say namespaced) yet.
Yep and that's the problem, not talking about stuff that is in the container the running app never uses.
Imagine if you'd told us that in 30 years, applications would be linked statically... not merely with their libraries, but with the entire OS as a dependency!
Javascript "applications" aren't far from that are they? Copy of Chrome, copy of all modules...
And then they made Java ;)