Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to Immutable Linux Systems

dataswamp.org

Post reply on HN
Print view View original

31–40 of 164 posts

Re: Introduction to Immutable Linux Systems

#31

Post by hx8 »

softirq wrote: post #7

Been 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 symbolic link with the Ubuntu name that points to the Fedora rpm managed library. Instead, to get it to work I forked the script, got it to build locally, made it look for either library name, ran local test cases, submitted the code as a PR upstream, etc etc etc. It took something that would normally cost me 1 line of shell to fix to something that took 90 minutes.

Re: Introduction to Immutable Linux Systems

#32

Post by NavinF »

Zuiii wrote: post #16

The 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-letter-iv...

> it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.

Re: Introduction to Immutable Linux Systems

#34

Post by edrxty »

It's interesting to watch these immutable images being adopted in the wider computing community. This has been a thing forever in the embedded world with Yocto/Peta Linux/Buildroot images. The image is a usually a straight disk image and is read-only in operation. This doesn't inherently fix all the insecure IOT stuff as you usually need some way to reimage the device with updates and it takes at least some skill to do the bootloader signature verification right. It does help though as well as keep things deterministic.

Re: Introduction to Immutable Linux Systems

#35

Post by bandrami »

Zuiii wrote: post #16

The 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.

Re: Introduction to Immutable Linux Systems

#36

Post by bandrami »

ggm wrote: post #28

If you ran root on ZFS with a single mount / form, and snapshotted it immediately after install, would that count as "immutable" in this logic?

If you did it before and after every system alteration, I'd count that. That's tedious and error-prone to do by hand, though, so you'd want a set of tools to do it automatically. At which point you've invented a new immutable distro.

Re: Introduction to Immutable Linux Systems

#37

Post by gettodachoppa »

fbdab103 wrote: post #25

Relatedly, does anyone know if the security guarantees around distrobox have gotten any stronger? Last I looked, they promised nothing, but curious if there has been any movement there. I would love if there was a seamless way to launch a distrobox os with a separate user home that could not touch my host system. Likely a Real Hard Problem, but even some isolation would probably be an improvement of running everythin…

Last I looked at Distrobox, DNS didn't work on Ubuntu LTS or Debian Bookworm. It was literally useless.

How can anyone adopt an unpolished hobby project that only seems to be tested on the dev's Arch box is beyond me.

Re: Introduction to Immutable Linux Systems

#38

Post by Ferret7446 »

edrxty wrote: post #34

It's interesting to watch these immutable images being adopted in the wider computing community. This has been a thing forever in the embedded world with Yocto/Peta Linux/Buildroot images. The image is a usually a straight disk image and is read-only in operation. This doesn't inherently fix all the insecure IOT stuff as you usually need some way to reimage the device with updates and it takes at least some skill to…

It has not been possible/practical to use immutable system images until recent advances like ostree/flatpak/systemd-homed.

We didn't "just discover" some secret only known to the embedded community, lots of people have been working toward this exact goal for a long time, because we already knew for a long time that it has a lot of advantages.

Re: Introduction to Immutable Linux Systems

#39

Post by dfee »

NavinF wrote: post #32
Zuiii wrote: post #16

The 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…

Great link. However, I don’t know how Joel could see a newcomer can challenge an incumbent, short of reimplementing all features.

Certainly, Google Sheets didn’t do that. Nor has airtable (valuation considerations aside, it has seen some adoption).

In a new category, or a new market, there is no benchmark. So that’s the east case. But sometimes new products do displace old products, and sometimes just by distribution or pricing at the cost of features.

So how do you reconcile that, Joel?!

Post reply on HN