Maybe in that type of environment if it’s a commercial enterprise. There are the bigger players out there that maybe have the resources to make that happen such as Fedora (Red Hat) or OpenSuse etc.
As an end user i don’t see myself having an interest in it. I can see it in the Educational, institutional, commercial environments but it may not be for everyone.
How much disk space is dedicated to implement an immutable system?
There is (at least one) old-school method that requires about 15 to 25/30 GB (size depends on installed packages). (Partition/mount swapping)
There is also another old-school method for semi-immutable that requires no extra disk space. (remount ro/rw on updates/system maintenance)
Ok. So it does make sense to you, you just don’t like it. That’s a big difference than what you originally said. If you look at who is really in on it, it’s Fedora which is basically Red Hat testing, and openSUSE’s micro.
It doesn’t make any sense from an Arch stand point, although the steam deck is quite compelling. But, most people are here because they want exactly their computer and are willing to make it. Red Hat especially is all commercial. And quite profitable. To have something you can control like that would be incredible.
Commercial stuff is simplicity and get work done.
Immutable systems make sense when using unstable (rolling, etc.) distros, for professional reasons, or when the system administrator is not a System Administrator (regular users, with no time or will to learn).
Yes …along those lines.
dang. i was not bothered about immutability anyway not falling for the hype. however, for my real world needs, all my customers are using wi*dows. wondering if i could load up a small application which has everything pre-configured and depolyed like docker. this is including arch + terminal + python script.
another way is host an application like chroot, virtualenv with python capablities, however with a guarantee that the distro cannot be written on to. there will be some cases in the future which works on a server client model. though whoever starts first will be a server and client as well.
client who logs in second and later will all be clients.
my head is spinning on the possibilities.
I completely understand Red Hat and Suse embracing this, as already said, for commercial use in enterprise environments you need something that employers won’t break.
At work, we use Fedora and it simply works without the hassle.
Even though I’m flattered that this project was included in their manual, since we’re not the top dogs in the Linux universe, I also have difficulties seeing the benefits of its real-world use case for Arch, this distro, or any Arch-based distro for that matter. The use of it kind of defeats the nature of those distros. Arch is just not ideal for enterprise purposes, in my opinion, it will remain the distro for tinkerers and people who are interested in the technical aspects of computing.
even after so much rant from ChatGPT, the difference between readonly and immutable OS is not clear.
Creating an immutable operating system and a read-only operating system are two different approaches with distinct characteristics. Here's an explanation of each:
1. Immutable Operating System:
An immutable operating system is designed to be unchangeable or non-modifiable once it is deployed or booted. The key characteristics of an immutable OS are:
a. Immutable State: The OS is created in a state that cannot be altered. It is typically built as a read-only image or snapshot, which means that any changes made to the OS during runtime are not persisted. This approach ensures that the OS remains consistent and free from unauthorized modifications.
b. Enhanced Security: By preventing modifications to the OS, an immutable system can enhance security. Since the OS cannot be tampered with, it is more resistant to malware, unauthorized configuration changes, and other potential security threats.
c. Easy Rollback and Recovery: Since the OS image is read-only, it is possible to roll back to a previous known-good state by simply reverting to an earlier snapshot. This feature simplifies recovery from system failures or compromised environments.
d. Limited Customization: Immutable OSs are typically designed with limited customization options. Users cannot make permanent changes to the OS configuration or install additional software unless they create a new customized image.
2. Read-only Operating System:
A read-only operating system is an OS where the underlying storage media or file system is set to read-only mode. In this approach:
a. Read-only File System: The file system used by the operating system is mounted in a read-only mode, which means that no modifications can be made to the files or the system configuration once it is booted.
b. Enhanced Security: Similar to an immutable OS, a read-only OS offers improved security by preventing unauthorized modifications to the system. It helps protect against malware infections and reduces the risk of accidental or intentional tampering.
c. Limited Flexibility: Since the file system is read-only, users have limited flexibility to customize the operating system or install additional software. Any changes made during runtime, such as user data or configuration changes, may need to be stored externally or in a separate read-write partition.
d. Updates and Patches: Keeping the OS up to date with security patches and software updates can be challenging with a read-only OS. It typically requires a mechanism for applying updates without modifying the read-only file system, such as using a separate overlay file system or applying patches on top of the read-only image.
In summary, an immutable OS is created with the intent of being unchangeable, ensuring consistency, security, and simplified recovery, while a read-only OS restricts modifications to the underlying file system, providing enhanced security but with limited customization options and update mechanisms.
What’s not clear ?
I think it’s clear… Read only allows some modifications in an overlay, the other not.
It’s ChatGPT so at least half is going to be wrong or made up.
Personally, I would like a happy medium. Think “system restore” but nothing overly aggressive as snapshots.
As a home user, I want the newest software and I want to install software, sometimes outside a repo or package manager. I want to edit some cool config file somewhere and improve upon the stock install of either an app or the operating system.
But I also want to “restore” (recover) if something terribly goes wrong, without the whole system being imaged or useless things being snapped too. The last time I tried using snapshots, I watched hard drive space quickly become a premium and I also watched my system appear to be more resource intense as it “snapped” for every, single, minor, and insignificant change.
I like seeing people think outside the box, and this development does that. But I think it would have been a good idea to look for that happy medium too.
But os as eos in total with desktoo making immutable lol. base install immutable… But rest is snap or flatpak would be more preferably you stil can update the desktop itself…,as base install as minimum
But on a point pointless lol
Probably because there isn’t any real difference between those two concepts.
There are differences between implementations, but the concepts are identical.
Still think this is one Shinny Shinny New New thing that should NEVER become standard. It’s like still using AOL or Ubuntu after you’ve been on linux for a year or more.