What these sort of introductions to immutable always fail to consider is the other side of the coin, image-based. I'm working on https://universal-blue.org/ along with many people much more skilled than me. We build OCI container images on top of vanilla Fedora Silverblue & many other editions with different desktops. Those images can then be booted to (or rather rebased to) using rpm-ostree. This is a more robust way of extending the system than layering, and the same changes can be easily benefited or inherited from by anyone. You can even make your own image really easily!
I think that VanillaOS and SUSE are working on similar things, but we're not an OS project, just a downstream from Fedora. Fedora's full support is underway but with what's already working perfectly our methods are already IME some of the most robust and easy ways of delivering Nvidia drivers for example.
Tangential, but I had my mind blown in about 2009 by a big hypervisor running Windows remote desktop hosts. I believe it was Citrix.
The VMs booted from images. The image and the mutable differencing disks were entirely in RAM (although user profiles were on spinning rust). A desktop host for 25 users would boot to accepting remote logins in about 4 seconds.
If you Google it, it's a pretty common phrase referring to magnetic disk as opposed to SSD. Could even be applied to drum, I suppose, if you could still find any...
I would go so far as to say this is the standard informal/slang way to distinguish rotating magnetic media from optical/solid-state media, and off the cuff I'd say it has been since the advent of consumer optical media about 30 years ago.
I'm not, but I appreciate your confidence in asserting so.
Finding evidence of that term being used has no bearing on how widespread that term was. Just because you've encountered it doesn't mean it is as widespread as you seem to assume.
You remind me of people I would meet in one state, who would use certain slang or have certain customs particular to that state and insisted it was a USA wide custom, despite having never left their state.
I very quickly get the impression you are one of those "need to have the last word" types, so I won't be responding to you further.
100% relevant and I was going to point it out to you myself.
It is OK to not know stuff. It is not OK to argue that because you didn't know something lots of other people do, that the thing is is obscure or nonstandard or weird.
Just because you've been exposed to that term does'nt mean it's as widespread as you seem to think it is.
You remind me of people I would meet in one state, who would use certain slang or have certain customs particular to that state and insisted it was a USA wide custom, despite having never left their state.
I very quickly get the impression you are one of those "need to have the last word" types, so I won't be responding to you further.
I'm confused, isn't Fedora Silverblue also image-based? I thought the default installation doesn't use layering, and that layering only comes when you want to install extra RPM packages.
Yes, Fedora Silverblue is image-based. We just use extending those stock images as an alternative to layering and easy way of shipping the same system configuration to many people.
An OCI image is pretty simple, yes, so is the sort of image that is in an OSTree repository. The difference is that when using `rpm-ostree` packages installed with `rpm-ostree install` are "layered" on top of the base image, while packages in the "base image" (be it OCI or OSTree) are part of the system and thus not "layered".
Adding packages in an image has the benefit of pseudo-reproducability (have the same image on multiple computers) and the added robustness of your base system being built elsewhere daily. Your computer just pulls the diffs. For example, there have been issues with rpmfusion on Fedora that ublue users completely avoided. Codecs & other essential rpmfusion packages are included in the images, and the rpmfusion repository is removed after they are installed. This way, if something package-related breaks it breaks at the image build stage, and an ordinary user wont even notice it before it is fixed.
The most noticeable benefit IMO, though, is being able to ship the same changes on top of a base image every day for multiple machines. This is not only packages, but for example udev rules, and other QoL things like our `justfile`s, configuration for https://just.systems/ that has some useful scripts for adding the kargs necesarry for Nvidia drivers to work and `just update` for updating the system, flatpaks & distroboxes.
I see that UBlue uses Github actions to rebuild the images regularly to roll in package updates. Who foots the bill? Are the images also served from Github? Does Github charge for egress? What happens when a lot of users want to download the same image?
Github free tier served us well. For a while we had a paid tier for GH orgs to get better builders, but now I think we use https://buildjet.com/. I'm not too familiar with this aspect, though.
I think the bills are paid by Jorge (the kind of "founder" of the project), at least I think so, though some of the other top members with jobs in the Linux/Cloud world might be helping. Donation paths and such have been considered, but the bills aren't too huge so nothing has been rushed in.
For the registry, GHCR serves us entirely for free. No egress costs, no ingress costs, nothing. No plans to change providers, and I don't think they have plans to raise pricing either. We could probably find an alternative host pretty easily, though, through the cloud contacts and knowledge some of the devs here have.
I think that VanillaOS and SUSE are working on similar things, but we're not an OS project, just a downstream from Fedora. Fedora's full support is underway but with what's already working perfectly our methods are already IME some of the most robust and easy ways of delivering Nvidia drivers for example.