Is 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.
Introduction to Immutable Linux Systems
81–90 of 164 posts
Re: Introduction to Immutable Linux Systems
#82It's so light, you can spin up VMs, one for a mail-server, one for a database, one for a firewall/router, each in a couple of seconds.
Tinycore is itself immutable, so you add a vdisk with a "package" and some config, mark it read-only, and job done. A single Virsh script handles the startup and shutdown of "services" - each being a Tinycore instance. Fun, and robust so far, but not sure if I'd put it into anyone's production just yet.
Re: Introduction to Immutable Linux Systems
#83Been using Fedora Silverblue since its release and it's absolutely the future. ostree is what everyone should be using.
Re: Introduction to Immutable Linux Systems
#84Fully statically linked.
Re: Introduction to Immutable Linux Systems
#85Depending on the implementation, a system may offer more features. But this list is what a Linux distribution should have to be labelled "immutable" at the moment."
Immutable. I do not think it means what you think it means.
Re: Introduction to Immutable Linux Systems
#86What 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…
Re: Introduction to Immutable Linux Systems
#87Earlier quoted context omitted.
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.
How is it different from what you call “layering”?
Legit question, just trying to understand why you feel it’s an advantage.
Re: Introduction to Immutable Linux Systems
#88Been using Fedora Silverblue since its release and it's absolutely the future. ostree is what everyone should be using.
I found Silverblue to not be flexible enough for my person computers. Maybe I use Linux in a hacky way, not having write access to /usr or /bin or other folders drove me crazy about once every two weeks. For example, I was using a script written by an ubuntu user that was looking for a library with the name/location ubuntu puts it in. Fedora uses a different name for the library. My instinct here is to create a symbo…
How do you keep track of your custom modifications to /usr or /bin without using the package manager? Do you record them somewhere for reference?
Re: Introduction to Immutable Linux Systems
#89Earlier quoted context omitted.
I found Silverblue to not be flexible enough for my person computers. Maybe I use Linux in a hacky way, not having write access to /usr or /bin or other folders drove me crazy about once every two weeks. For example, I was using a script written by an ubuntu user that was looking for a library with the name/location ubuntu puts it in. Fedora uses a different name for the library. My instinct here is to create a symbo…
There are 3 ways to get what you want more easily: 1. With Fedora Silverblue 39 the most straightforward way is to add a Dockerfile layer just which makes your changes directly to the base image. 2. You can also create your own RPM and make the changes there. 3. Best is to actually run your script in an Ubuntu container (distrobox, toolbx, or podman).
Does that put the onus on you to rebuild container image in order to receive system updates?
Re: Introduction to Immutable Linux Systems
#90The 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…
> stacking of custom overlay filesystems as a first class feature At that point why not just use a mutable system? This reminds me of how a decade ago everybody rushed to move to nosql and then immediately reinvented schemae in their projects.
Compare Haskell: both Haskell and C support both mutable variables and constant ones. But the ecosystems and idioms are very different.