I started using SuSE in 2002, and it was my go-to distro for personal purposes until 2022. At that time I made the leap To NixOS. It feels now I made the right choice. SuSE always felt stable and predictable, but I never really grokked the community and what priorities steered its roadmap. Also it was quite common that software I wanted to use wasn't packaged. As much as I liked it, it was right to part ways. If it wasn't for NixOS, I am very unsure what I would do now.
My understanding is that SuSE is the Fedora of SLES, and SLES is what Dell tries to put on some of its storage appliances. This is a kind of appliance that doesn't go to individual consumers though, so, you might have never encountered it.
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.)
I'm generally afraid of major changes and this one has the potential to massively affect me. I've jumped through several distributions over the years - red hat back when it wasn't enterprise, ubuntu, then fedora, then debian, then eventually ended up with OpenSUSE back in ~2017 and I fell in love with it. It's been my daily driver ever since - work, home and laptop. I still run debian on all my servers at my home lab but for a daily driver, OpenSUSE ticked all my boxes: you can get almost anything to run on it, even if it's not officially supported, flexible, frequent updates and all the good stuff. The only downside has been dealing with Nvidia (quadro's specifically) but that applies to pretty much any distro. I'm really hoping I won't have to jump trains again. Time will tell I guess
If you ever end up jumping ships again, maybe it's time to try a distribution that don't make too many choices for you, so you can remain with the software stack you're comfortable with? I'd say Arch would be my first pick for that, but there is obviously many others that fit that label too.
I'm all for this change!
I think the immutable OS is the way to go for most people.
And I've been using Tumbleweed for a long time and I'm excited for Slowroll to get... "rolling", so that I can jump over to that.
One thing that confuses me though is how Leap now sounds like another Aeon or Kalpa version, so why does it need to exist?
Immutable OS is not a good choice for individual users. For servers that don't see much interactive use / don't need frequent opportunistic installs or updates / don't need various ad hoc assembled applications to share data, and value stability of the system over its usability -- it's good.
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..
Yeah, I guess, I'm falling behind the times. I've never used, nor have I ever met anyone using Chrome OS or Steam OS. What are they for?
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 don't see the point of ostree personally. It's overly complicated for what it's trying to do (immutable base).
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).
OSTree is moving to using OCI images, which removes a large amount of complexity in its current form. On top of using composefs, this will make it impossible to change the underlying files manually without causing the file to be invalidated.
Yeah I do not like it as well. Especially since redhat tried to force it on users of CoreOS Container Linux, with a completely new os without any upgrade path and half the features. Forking base worked at the beginning , but was painful and broke sometimes. I migrated all coreos machines to flatcarlinux which was a fork of coreos and was bought by Microsoft and is still maintained by them. What a strange world. (I was a big fan of back than and used centos/fedora heavily. I dropped everything in favor of Debian/tumbleweed/manjora and almalinux(centos migrated))
I think flatcar uses squashfs
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.
Newer versions of SteamOS is essentially that, although it does focus on the gaming/multimedia use-case rather than general desktop usage, but it does the general desktop usage part just fine too.
'Immutable' distributions suffer from bad branding, the only thing that's immutable is /usr, so it's far less terrible than the name makes it seem. Loading and blacklisting modules, modifying grub configuration, changing sysctl settings,... all of those things work fine. But people see 'immutable' and think 'oh, I can't change my fan speed', 'oh, I can't disable the annoying PC speaker beep', and so on. I don't know how the branding could be improved, but I do think that better branding would help getting people invested.
Even just immutable /usr is still bad for individual users.
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.
If I put my binaries in a place other than the "immutable" one, what's the point in having the immutable place if I don't use it?
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 build a shell, unwittingly fuck up the build configuration, and make install it into /usr; then fixing it will be... well it'd be easy because I have Snapper set up so I can just roll back a snapshot, but if I didn't have that fixing the system could be quite annoying.
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.
> 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.
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.
eh, in a couple of years the recommended practice would probably be to keep /usr as minimal as possible, and install stuff to /opt. Then we'll have come around full circle. \s
In the mid-90s, dynamic/shared objects were the new hotness on SunOS.
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!
> 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 of course, they put java in a container. an os statically linked to what's practically another os, statically linked to the application itself. (I consider containers to be a form of static linking)
I've been moving my Leap stuff to Slowroll. It does well so far and I don't have to worry about this ALP thing. The immutable stuff sounds interesting but it's just not for me at this point in time.
Clicked on the link and remembered that yes, this stupid site uses Cloudflare to apparently block all Indian IPs, even for static articles like this one. Encountered it a couple of years back & forgot.
