How would you approach making immutable live-cd like Linux? No persistence at all, just boot it and run some app - think some kind of presentation panel which shows predefined program/URL. Ideally net booted to avoid having storage at all.
Introduction to Immutable Linux Systems
61–70 of 164 posts
Re: Introduction to Immutable Linux Systems
#62The problem I had with flatpak and the immutable approach in general is that I can't modify them in ways that aren't supported by the developer. For example, I use decsync to sync my calandars but as far as I can tell, it's impossible to add the decsync plugin to the evolution flatpak. Until these immutable systems support the stacking of custom overlay filesystems as a first class feature^1, people will continue to…
> add the decsync plugin to the evolution flatpak This sort of thing is very common with GUI software on Linux. Outside of this bubble, most software comes with batteries included. Eg Solidworks never makes me download optional dependencies, but FreeCAD made me do it literally every 15 minutes as I move to the next step in a CAD/CAM/sim/render workflow. Also see https://www.joelonsoftware.com/2001/03/23/strategy-lett…
Outside of this bubble, you see vim plugins, VSCode plugins, JetBrains IDE plugins… Photoshop plugins, Premiere plugins…
Re: Introduction to Immutable Linux Systems
#63The initramfs-overlay package became a trivial install with OverlayFS being accepted into the kernel a few years back.
This meant the mess systemd created each boot, could be dropped into the ram-drive with zero impact on the OS image. Effectively turning any Debian based system into a read-only OS backing image, but retaining the ability to boot into a normal writable system with a single boot flag.
This trick is a lot less finicky these days. =)
Re: Introduction to Immutable Linux Systems
#64What 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 wa…
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.
Re: Introduction to Immutable Linux Systems
#65What 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 wa…
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.
Re: Introduction to Immutable Linux Systems
#66The problem I had with flatpak and the immutable approach in general is that I can't modify them in ways that aren't supported by the developer. For example, I use decsync to sync my calandars but as far as I can tell, it's impossible to add the decsync plugin to the evolution flatpak. Until these immutable systems support the stacking of custom overlay filesystems as a first class feature^1, people will continue to…
You can add plugins to applications in flatpak; package these plugins as extensions.
How it is done can be seen with OBS: flathub has several OBS plugins available (com.obsproject.Studio.Plugin.*).
Re: Introduction to Immutable Linux Systems
#67While I am glad Silverblue is on this list, not having Fedora CoreOS on it too is a shame. FCOS is an amazing OS to run in production and it has come a very long way since the CoreOS acquisition. I find that FCOS is a good middle ground of being usable and easy to learn while still being immutable compared to Nix. The FCOS devs introduced a new feature called CoreOS Layering which lets you define your system in a Doc…
Thanks for making this tool and showing how to get started with the layering!
Do you have any thoughts you’d like to share on flatcar as the other project with CoreOS lineage?
As for me my main difficulties have been figuring out what to do with these projects in a bare metal environment. Building VM images is cool, but much of the time I want to do things like install to an existing drive or even onto a ZFS pool underneath.
Re: Introduction to Immutable Linux Systems
#68Is anyone running diskless Alpine in production? It seems optimal to me but extremely uncommon.
In the past I’ve tried running a small USB drive in rented bare metal w/ diskless alpine, but the machine seemed to reboot randomly IIRC.
Re: Introduction to Immutable Linux Systems
#69> 4.1. Pros § > 4.1.1 you can roll back changes if something went wrong. > 4.1.2 transactional-updates allows you to keep the system running correctly during packages changes. Last time I needed to roll back was OpenSSL in Ubuntu 18.04 and that was on one system. I don think I've ever had a problem that 4.1.2 solves. I don't want to have yet another Linux OS to solve a problem that happens once a decade. If I wanted…
I agree.
Just like Wayland, they're pushing it for other reasons (breaking existing stuff, locking you in to the GNOME desktop, etc), and using spurious reasons to promote it.
Re: Introduction to Immutable Linux Systems
#70> immutability is a lie, many parts of the systems are mutable, although I don't know how to describe this family with a different word (transactional something?). In the case of Nix, it sounds like it's more focused on reproduce-ability? It sounds like I should be able to take the Nix configuration file, plop it on another computer, and get the same system (except, perhaps, for /home). Some of the others sound more…
"Immutable" is a strange term for this:
* system upgrades aren't done on the live system
* packages changes are applied on the next boot
* you can roll back a change
That's a atomic transaction, like a database. Although having to shut down the system to do a commit is a bit much.
Microsoft put atomic transactions into their file system years ago, but file system transactions were never used much. You'd like to have an install system where all changes commit all at once, and if anything goes wrong during install, nothing commits and you roll back to the previous state. In theory a transactional file system could do that. In practice, there's probably too much other non file systems state involved.