Immutable desktops ?

[kc1di]

It seems like the catch word for now Is immutable. Fedora announced an immutable version of it's system. and now Looks like ubuntu may follow suit.

A Snap-based, containerized Ubuntu desktop could be offered in 2024

Ubuntu could join Fedora in offering an immutable desktop option.

arstechnica.com

 

[KGIII]

They've been working on that for a while. I should probably read the article before going on...

Yeah, they've had Core - which is for IoT devices. A desktop version might be pretty neat - perhaps kind of taking over the role that 'minimal install' used to hold.

 

[wendy-lebaron]

I'm going to repeat that VanillaOS have a good concept going on. However, it means /usr/local directory is officially dead. I would have to install that OS to see if that directory even exists. Some programs are going to be blocked from auto-updating if they also insist residing somewhere into /usr. I don't know that much about it. Compared to that scheme, Slackware looks so easy to wreck.

Sadly this "immutable" fever just means more memory. More RAM is going to be demanded for even simple applications, and nobody is going to get away with installing one of those Linux OS's with less than 64GB of total disk space. Maybe that threshold would be even higher.

I don't know, but this seems a logical step for Ubuntu so that Snaps are more widely accepted. They would certainly bank on curiosity and they could get plenty of feedback about it and work to refine the experience.

 

[sphen]

I have had bosses who were immutable. Everybody wished they would shut up so we could get back to work.

 

[KGIII]

just means more memory

No, that's not what it 'just' means. If it just meant more memory, there'd be no reason to do this.

 

[gvisoc]

I’ve been using Silverblue for a while and it’s a very interesting and user friendly concept.

 

[Leonardo_B]

It seems like the catch word for now Is immutable. Fedora announced an immutable version of it's system. and now Looks like ubuntu may follow suit.

Vanilla OS is Ubuntu with a immutable system already but it plans to move to Debian check it out if you like Vanilla Os

 

[pepdebian]

I'm going to repeat that VanillaOS have a good concept going on. However, it means /usr/local directory is officially dead. I would have to install that OS to see if that directory even exists. Some programs are going to be blocked from auto-updating if they also insist residing somewhere into /usr. I don't know that much about it. Compared to that scheme, Slackware looks so easy to wreck.

Sadly this "immutable" fever just means more memory. More RAM is going to be demanded for even simple applications, and nobody is going to get away with installing one of those Linux OS's with less than 64GB of total disk space. Maybe that threshold would be even higher.

I don't know, but this seems a logical step for Ubuntu so that Snaps are more widely accepted. They would certainly bank on curiosity and they could get plenty of feedback about it and work to refine the experience.

I agree with you, it does in some ways limit what you can do in terms of your system "ownership", in many scenarios immutable is probably a good thing but it just depends on the use case... I see it from a development perspective

Immutability in code does have value for example to pass an object to another function/method, you shouldn't have to worry about whether that object will have the same value after the function returns. It's easier to make immutable objects thread-safe. And it simplifies the implementation.

For me personally as a user though, I don't think an immutable OS is my cup of tea....for now...at least

 

[wizardfromoz]

@The Duck - your Post adds nothing so I have done nothing with it.

Do something other than just quote others, please.

Chris Turner
wizardfromoz

 

[camtaf]

It's not really new, various distros have been made up from compressed modules before; usually small ones that fitted & ran from memory at 'lightning speed'.....

Personally, I quite like this modular approach, programs can be added as & when needed, & then just deleted when done with, all dependencies usually taken care of either in the base module or in the module to be loaded.

 

[wendy-lebaron]

Personally, I quite like this modular approach, programs can be added as & when needed, & then just deleted when done with, all dependencies usually taken care of either in the base module or in the module to be loaded.

Ubuntu's approach will be different from Porteus, for example, but I have been wrong before.

 

[camtaf]

I was thinking along the lines of Tiny Core, SliTaz, Slax ,etc.

 

[MikeWalsh]

It's not really new, various distros have been made up from compressed modules before; usually small ones that fitted & ran from memory at 'lightning speed'.....

Personally, I quite like this modular approach, programs can be added as & when needed, & then just deleted when done with, all dependencies usually taken care of either in the base module or in the module to be loaded.

@camtaf :-

It's exactly the same approach Puppy takes. The entire system loads into a virtual RAMdisk from read-only files, so the 'base' system never changes (and can't be corrupted). Puppy's traditional SFS packages are loaded "on-the-fly" as needed, then unloaded again when finished with. The more modern range of Puppy-portables that I myself developed, with help from several community members, can all be run from a flash drive if required, a la Windows PortableApps.

Personal configuration changes are usually added-into what's known as the save-file or save-folder. However, it's become quite popular amongst our members to customize the system so it's exactly how you want it, then re-master the entire thing so that even your customizations become read-only.....and your Puppy loads in an expected, identical state at every boot.

--------------------------------------------------------------

This is where the Puppy-portables come in useful. They don't need to rely on having config files already present in the system; all config stuff is created & stored within the portable's directory by making use of the XDG Base Directory specification, setting a read-link for that directory, and making the directory itself its own $HOME. Thus, everything required is external to the base Puppy.....even additional dependencies, if needed, which are taken care of by specifying LD_LIBRARY_PATH to libs within the portable directory.

It all works rather nicely, if I'm honest.


Mike.

 

[Deleted member 111282]

I'm not trying to jump to conclusions when saying this, but I was reading this link that describes what an immutable distro is, and from how I interpreted it, it sounds like it becomes locked down in favor of making it more secure, reliable, and easier to maintain. As much as I like the thought behind the latter, it doesn't seem like you can really tinker with the distro and make it yours like you can with a traditional one, especially when it makes you update the entire system instead of allowing you to pick and choose which updates you want or don't. On top of that, I'd imagine how programmers learn their craft is by intentionally breaking a distro and then putting it back together, and this seems to rob them of that.

If anyone who's more experienced with this than I am, I'd really appreciate you explaining how I'm misunderstanding it

 

[gvisoc]

It’s neither locked down nor it restricts what you can do with it. With the tools it uses (e.g.: rpm-ostree for fedora) you can layer customisations on top of the base (publisher) image, reboot, and voilà. Those tools are based on git, indeed.

It’s only immutable during runtime.

Their main use case is to turn the OS into something more predictable.

The best way to understand them is to spin up a virtual machine and see how to do what you’re currently do in a mutable system.

 

[Deleted member 111282]

The best way to understand them is to spin up a virtual machine and see how to do what you’re currently do in a mutable system.

That makes more sense

 

[MikeRocor]

I was thinking along the lines of Tiny Core, SliTaz, Slax ,etc.

I haven't really done much distro hopping since I landed on Tiny Core, partly because of the way TC handles application software:

Applications are stored in "extensions" which are mountable read-only file systems (squashfs archives), so it just mounts the extension, then symlinks the files into the main filesystem (which lives in RAM) (*).

That does mean there's no handy way to update applications - you'd have to rebuild (or wait for the extension maintainer to rebuild) the extension, which is something that I personally don't care much about. It also means that the entire system is literally reinstalled every time you reboot.

(*) There is an option to copy, instead of symlink, some or all extensions into the main filesystem. That eats up a bunch of RAM, but allows you to remove the device from which the extensions were loaded.