I'm surprised immutable systems aren't more popular.
Back in the Knoppix days it was first a novelty, and then a blessing
that you had to boot from a CD-ROM, because it led to one amazing
outcome:
Less tinkering.
Or rather - it split use from tinkering.
Systems today are designed around the principles of deferral and
volatility. You can add or change anything at any time. The user has
absolute freedom to tinker, but also the vendor of always-connected
products has endless possibilities to update. The result is a mess of
dissatisfaction and half-bakery. Nothing is ever finished or fully
right. It also, maybe paradoxically, leads to systems that feel less
under your control.
Systems like TinyCore and Live CD distros take a different approach
that the OS is finished. You have two choices, take it or leave it.
Unless you are prepared to cross a non-trivial barrier to remix and
update the non-volatile image, you are forced to just use what you
have. That leads to more productivity because you adapt to the tool
rather than constantly adapting the tool to you.
I like TinyCore because it's looking to a middle ground of baking
immutable systems at key stage points and keeping changes separate
from the immutable core. I can change the core if I want to, but
rarely.
I see that as a separate prospect than "appliance platforms" like
Android and a PhoneOS onto which you can only load "apps".
What ideas and favourite solutions do other's have for using
immutability, or not liking it?
I helped write parallelknoppix when I was an undergrad - our university's 2nd cluster ended up being a bunch of laptops with broken displays running it. Took me a whole summer.
Then the next semester I am denied the ability to take a parallel computing class because it was for graduate students only and the prof. would not accept a waiver even though the class was being taught on the cluster me and a buddy built.
That I still had root on.
So I added a script that would renice the prof.'s jobs to be as slow as possible.
This is so typical German (I say that as German). It has changed quite a bit fortunately, but German professors are so often sticklers to the rules "aus Prinzip" (for a matter of principle).
> I'm surprised immutable systems aren't more popular.
They once were, before the internet made software updates "easy". There was a time when software was released (and often embedded without any option for upgrade/modification).
But immutable (mostly correct and reliable) software is more expensive and takes longer to develop, so it is out of fashion. Instead we now push out alpha quality MVPs and depend on updates to resolve known and unknown unaddressed issues as well as promised by not delivered features.
To be a little fair to developers, the user expectations these days are 10x or more greater than they were pre-internet-update days. After all, we now carry "supercomputer" devices in our pockets which also make phone calls, and we expect features and integrations which previously were not even imagined.
Even cars are now becoming update dependent for features and bug fixes. This is approaching a breaking point, I think. It will likely happen; there will be regulation and/or revolt; there will be a return to write-once approaches.
I idly wonder how long it will be before an OS could be "done". OS is proven to be free of security exploits, applications run entirely isolated permissions (network, disk, etc), and any remaining performance gains are incremental and optional.
I'd like to think it's possible, but sadly we don't even have the tooling to begin to correctly understand the problem in software let alone the unsafe hardware interactions.
Does macOS count? There are large chunks of the system that are impenetrable in real-world use. For example, in order to install the `yabai` window manager, here's what you need to do on your system:
If part of your program's installation process is "reboot into recovery mode", I feel like you're working with an OS that isn't quite as malleable as we sometimes are led to believe it is. :D
(btw I use `yabai` and it is totally worth doing all these things...I wouldn't set it to auto-update, and I review every release carefully, but so far so good. It's a great WM for macOS!)
Fedora Silverblue certainly seems popular here. I use it regularly and it’s been solid. I’m not sure how many people use Silverblue, but I recommend evaluating it!
I have been tempted recently to install Fedora Silverblue for trying it a daily driver in a spare computer I have at home, however, I read in many forums people having to implement some nasty workarounds for common things I use (e.g Docker/Podman). Perhaps in a near future when I have more time.
Technically you can install whatever you want the traditional way by "layering" it on your base image. I.e. just do a `rpm-otree install <package>` instead of `dnf install <package>` then reboot.
The hard/fun part is just figuring out a way to install and use the software you want without doing that, since that kind of defeats the purpose of using silverblue in the first place. In most cases, you can use a flatpak, a toolbox, or a container.
However, if you can't figure it out, there's no real harm in giving up and layering whatever you want.
> I'm surprised immutable systems aren't more popular.
Well technically near every router and embedded device is "immutable", with usually only config partition being changed, and firmware update being just re-loading whole image.
Core of macos itself is immutable and won't let you even add kernel modules or enable/disable system services, and IIRC it lives on a separate partition that is R/O.
> I'm surprised immutable systems aren't more popular.
Sadly, because they inherently make it so hard to keep up to date with the latest version of proprietary software like nVidia. Or they don't provide support over a wide range of (desktop and embedded) architectures.
Often the best choice you can make is the distro that has most users, so you are sure that it will get the attention and support from third parties.
That's exactly how I run my daily driver, my system is read-only, and I use overlayfs to put a read-write layer on top stored in RAM. This way all changes get removed every time I close the computer.
For my own files I have a partition which I use exclusively for data.
When I want to make changes to the system I have a boot option to disable overlayfs which I use once every few months for updates.
It depends, for most local apps you just have to log-in once while in upgrade mode (read-write on base system and overlayfs disabled), then the cookies will persist indefinitely and you'll be logged-in whenever you boot your computer in read-only mode.
For websites the cookies tend to expire once every few months so I'll boot back to upgrade mode and refresh my log-ins everywhere at once every few months at the same time as I install my system updates.
You can also selectively copy some software's local data to your persistent read-write disk partition and create a symbolic link in the original directory, that way this particular piece of software will be white-listed in a sense and always writable. But I haven't needed to do that.
My only issue has been google which has a weird cookie implementation, it throws cookie-mismatch errors all the time so I have to delete them and relog-in every day. If it were a big issue I'd make my firefox profile always writable as described above but I don't use google much.
My take on why they aren't more popular is that they are difficult to produce. Packer works, but it's slow and the artifacts it produces are bloated. I've been dreaming up a better tool for a while now that would make it possible to build images much faster regardless of whether you're on macOS/Windows/Linux. The hope is that it would be good enough to replace mutable systems managed with configuration management. Not really ready for use yet though.
Fedora Silverblue is probably one of our favorite Linux distributions nowadays. It was also our first experience with GNOME Wayland and we don't regret it.
I have found IODD 2531 (there are likely others) to be super-useful for that sort of a thing.
It presents an ISO (using the rocker on the side as a selector) from its HDD as a bootable CDROM target, and still exposes the HDD/SSD as a separate target.
So, it is possible to boot what is an RO OS image, and use the HDD/SSD target as an overlay, but because it is not flash memory, the wear issue is far less of a problem.
And, since it is presenting ISO images as boot targets, it is possible to (relatively) easily test upgrades while keeping the overlays separate.
Immutable doesn’t mean no updates. It just means that the user can’t change the system, and also doesn’t have to. An immutable System can have updates every night, as long as they are compatible.
It’s a bit like iOS and android, the system is the same on all devices of the same model, there are just different configurations and different apps.
It's as immutable as burning a new bootable LiveCD every time you update except that the images are kept on the HD for convenience and speed. Once booted, files stay pristine until the next reboot.
Everybody got scared from Windows XP having to reboot twice per day and wait 10 minutes just to change your display resolution or install some Windows Update security patches. Updating display drivers without restart, was back then announced as a major feature of Windows Vista.
Funny because now, that's how both Android and iOS behave, with the difference that OS updates only come every other month and AB partitions making the installation process perceived as fast as only rebooting.
> That leads to more productivity because you adapt to the tool rather than constantly adapting the tool to you.
This is just vastly untrue.
A bespoke tool will always be more productive than a one-size-fits-most tool, and thankfully with development tools the work/time of fitting your tool is marginal to the hours you work with it, and the effort is heavily front-loaded. After a few years you have a solid setup that only requires tiny amounts of polishing every few hundred hours.
The paradox of choice is real. A well configured bespoke tool may be more efficient, but if it’s hard to reach a configuration that you like, then a non configurable tool that has well selected choices may be more efficient simply because it eliminates the time, energy and mental effort spent on configuring and thinking of configuring the tool, and trying to get comfortable with the various configurations you may tinker the tool into.
So the real correct answer to whether bespoke or pre-configured tools are more efficient is “it depends”.
> A bespoke tool will always be more productive than a one-size-fits-most tool
Others have noted the FOMO/paradox of choice issue, so I’ll list another: multi-context environments. I work in a highly collaborative environment where I need to share tools and sometimes whole machines. I rarely get to use the same configuration for any particular task. So bespoke, to me and many of my colleagues, means more stuff to learn. Standard options and configurations mean much higher levels of productivity.
Short version is that MacOS made it so root cannot modify certain files without rebooting, disabling security and then booting to change those files. It can also stage changes to reload on boot, so for example, when you get a new version of the Zoom client, you actually have to reboot to make the camera permission go into effect. It's probably safer, but as a user, having to reboot just to turn on the camera is... MS Vista like...
I've been running the latest version of macOS and I've never had to reboot to enable camera permissions for any app. I haven't had to do it on fresh install or upgrade. The only thing I've had to do is close the app and open it again after giving it camera permission on first install. Subsequent updates seem to keep that permission enabled...
"I'm surprised immutable systems aren't more popular."
In the security world, an immutable system is an unpatchable system. If a 0-day is found in the system image, you can't fix it, you have to get a new image going. This causes wasted personnel-hours, wasted money, and some times wasted hardware if the image happens to be on a ROM-type of data storage. I've seen immutable systems on WORM HDDs. The people running those types of systems quickly got tired of having to do hardware replacements for every patch.
You are misunderstanding what immutable infrastructure is. You don't buy some SSD with a preinstalled OS and use it as it is for 10 years.
The point is in not making changes on the fly on live systems. You are perfectly able (and encouraged) to deploy new nodes with updated software and roll over the old nodes.
That's popular, but that's not an immutable OS we're talking about that's just a hypervisor. Routers also work like that, but we're clearly not talking about them.
Back in the Knoppix days it was first a novelty, and then a blessing that you had to boot from a CD-ROM, because it led to one amazing outcome:
Less tinkering.
Or rather - it split use from tinkering.
Systems today are designed around the principles of deferral and volatility. You can add or change anything at any time. The user has absolute freedom to tinker, but also the vendor of always-connected products has endless possibilities to update. The result is a mess of dissatisfaction and half-bakery. Nothing is ever finished or fully right. It also, maybe paradoxically, leads to systems that feel less under your control.
Systems like TinyCore and Live CD distros take a different approach that the OS is finished. You have two choices, take it or leave it.
Unless you are prepared to cross a non-trivial barrier to remix and update the non-volatile image, you are forced to just use what you have. That leads to more productivity because you adapt to the tool rather than constantly adapting the tool to you.
I like TinyCore because it's looking to a middle ground of baking immutable systems at key stage points and keeping changes separate from the immutable core. I can change the core if I want to, but rarely.
I see that as a separate prospect than "appliance platforms" like Android and a PhoneOS onto which you can only load "apps".
What ideas and favourite solutions do other's have for using immutability, or not liking it?