People don’t like my rants that are supposed to be exactly that, not to mention that a blog, by definition, should mostly consist of rants. In fact, over the last week I’ve read about three dozen Linux or IT-related news that I could have commented, but I decided not to, not even through comments on the sites where I found them and that allowed comments. It’s useless to do that there, and it’s even more useless to do it here.

As it happens, when it comes to immutability, I feel the need to comment, though. That’s because I hate “immutable distros” with all my guts. I don’t care about the particular places where they might be a good idea. What I care about my desktop or my laptop, which I want to think of as “personal computers” over which I want to have as much control as possible, within reason and with acceptable compromises. But no fancy stuff—nor fancy crap.

Liam Proven, in The Reg aka El Reg: A sit-down with Ubuntu founder Mark ‘SABDFL’ Shuttleworth. The interview is subpar, but I went there for the comments.

This one:

SNAP is a 4-letter word. Why the hell did the designers get addicted to the Poettering way of doing stuff?

A daemon running all the time, taking resources? Hell NO.

SNAP IS BANNED in my company. Anyone proposing using it gets told politely, No, or there is the door.

As a result of Canonical’s machinations, we standardised on Debian for desktops and A RedHat distro for servers. We use Rocky Linux these days. Gnome is also not allowed. As has been said, the devs lost the plot with V3.0 and are still on a mission to nowhere.

Liam:

A daemon running all the time, taking resources?

Go on then. You obviously care about this, as your anger demonstrates.

So, you must know, without even checking: how many resources? How much RAM is it using? How much CPU? How much quicker does your computer run without it?

Can you measure it? Let’s see your numbers. I want to know what the performance delta is that you’re so upset about.

Same Liam:

I had to clear tens of GBs of data which it happily wastes

FWIW on my GitHub I have taken a few commands from Alan Pope and written a little script which purges old snaps. I use it on most of my machines.

Have it, for nothing.

https://github.com/lproven/purgesnap

Download, stick in /usr/bin, chmod +x it and you’re good to go.

I run it once a month or so.

The script is elementary:

#!/bin/bash
# Removes old revisions of snaps
# CLOSE ALL SNAPS BEFORE RUNNING THIS
set -eu

LANG=en_US.UTF-8 snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
            snap remove "$snapname" --revision="$revision"
    done

There’s a catch here–or maybe not. The original article included a slightly simpler script, and this note:

Kindly note that this script may not work for French and some other languages because the label ‘disabled’ is likely to be different in different languages.

That’s why Liam has added LANG=en_US.UTF-8 in front of snap list --all. But this is, I suspect, completely unnecessary, the same as the warning in the original article.

You see, not everything is localized. Keywords and statuses remain strictly English-language in IT. I added LANG=fr_FR.UTF-8 in front of snap list --all and the result was identical. And yes, I did have the French locale built!

The only exception was when the XLM (Excel Macro Language) that preceded VBA used to have localized keywords, e.g. FOR, NEXT, IF were localized in French as POUR, SUIVANT, SI. When VBA was introduced in Excel 5.0 (1993), it adopted a strictly English syntax for all keywords. The only concession made to idiots was that the functions that one uses in the GUI are still localized: SOMME, MOYENNE, SI (SI A, ALORS B, SINON C) in French, or WENN instead of IF in German.

Back to our sheep: before running the above script, sudo du -sh /var/lib/snapd printed 1.7 GB; after having ran it, 1.6 GB.

The eternal Liam Proven, veteran of all OSes: Why we’re still waiting for Canonical’s immutable Ubuntu Core Desktop.

I, for one, am not waiting for anything. I fear radical changes, as most of the time they’re for the worse, even when they’re not forced on the user.

But I cared for the comments, because they start with “I’m not a fan of ‘snap’”. Here’s an interesting one:

I’m another non-fan of snap.

The system we use here is to give the users a home directory that is an NFS-4 fileshare mounted off a remote file server. This is for an educational establishment so we would very much like a user’s files and desktop modifications to follow them around, hence this solution works very well. Or rather it did, until more and more snaps started to be introduced. Snaps don’t work on NFS-4 fileshares.

On a system where the users’ home directory is a fileshare, it is very useful to also have a local user with sudo access, so you can get into systems where the network or the fileshare is broken. On these the user with the local home directory cannot have it in /home, so instead we put it in /localhome.

Guess what, Snaps don’t like home directories placed anywhere save for /home

Now, you could possibly forgive Snaps for not liking NFS-4 where default permissions prevent anyone save the user whose share it is from looking at it, if you were charitable. If you weren’t and took the view that sudo is a very useful command then you’d not forgive that. However even the most charitable person in the world saves a little spot of hatred for morons who hardcode directories in their code, instead of using system variables like everyone else does.

That’s why I don’t like snaps.

Not completely exaggerated, but Liam retorted:

Guess what, Snaps don’t like home directories placed anywhere save for /home

That, and this kind of thing, is 100% legitimate and it is fair.

Modern Linux is trying to automate and simplify more and more stuff and it’s going to break more and more old-time Unix tools and methods.

Fedora is considering adopting systemd-homed:

https://wiki.archlinux.org/title/Systemd-homed

[sarcasm] This will banish the antiquated notion of having a “directory” as your home at all [/sarcasm] replacing it with on-demand encrypted volumes which can be on removable media.

These folks do not use computers like I do. Increasingly, what they want is far removed from how I work, and I don’t consider what I do to be fancy.

Here’s an even worse choice:

NixOS is immutable without Flatpak/Snap, if you can deal with the weird configuration/package manager

Liam:

if you can deal with the weird configuration/package manager

And the filesystem layout.

Indeed. Another valid point:

As I understand it, Flatpack isn’t really able to a lot of things which Snap can. It was a very narrow solution to portable packaging of GUI apps rather than a general solution for software in general.

Snap evolved out of Ubuntu Phone, and was one of the bits of that project which were later repurposed for other things. Currently it’s being used for embedded and cloud applications. What’s different about Ubuntu Core as compared to at least some other immutable OS projects is that the actual OS part is broken up into several smaller snaps which can be exchanged in a mix and match fashion rather than being one big chunk.

As stated in the story, what they are trying to figure out now is how to split the desktop up into multiple chunks as well. From the sounds of it they want something that works for KDE and possibly others as well, and not just a Gnome only solution.

A mean guy:

it’s built entirely from snap packages

It’s pretty much dead in the water then, apart from hard core zealots who will push it anyway.

Liam to the rescue:

It’s pretty much dead in the water then, apart from hard core zealots who will push it anyway.

Yeah, no.

I have news for you. The most widely-used desktop Linux in the world is immutable, has no package manager at all of any form, and no native apps.

And about 10x as many people use it as every other graphical FOSS Unix-like OS put together.

It’s ChromeOS, and it gets a couple of hundred million new users a year. (Some are probably upgrading, to be fair.)

Modern macOS is also effectively immutable. iOS definitely is. So is Android in the ways that matter.

Users of immutable OSes outnumber all the mutable OSes, Windows and every other Linux and BSD, put together, by something like 100x over.

They don’t know and they don’t care.

Duh. I have to rant a bit on that one.

I don’t have anymore that rabid hatred of snaps and Flatpaks that most decent people have. I very much prefer the distro-specific packages (official packages released by the distro, those from trustworthy PPAs, or those from the makers of a specific piece of software), or the binaries offered by upstream (for Calibre, my VPN, etc.), but on occasions I might accept a Flatpak, or even a snap. There’s plenty of garbage in a distro, anyway, garbage that’s there because of the overcomplicated design decided by some smart ass (usually from Red Hat or a project initiated or sponsored by Red Hat).

But no, I won’t use an immutable Linux distro! Over my dead body!

I already hate Android for its idiosyncrasies (not that iOS were any better; it ain’t). As for the so many ChromeOS users, Liam is eating shit: it’s only used by about 2% of computers, and please don’t compare it to the 2% of the Linux Desktop market share! Chromebooks are not computers; they’re stupid contraptions built around a web browser, Chrome to be precise. Pretty much like Windows 365 Link will be. Chromebooks are mostly used in schools, and the shit Microsoft will release next year will be used in the businesses ran by the most retarded C-suite morons!

But let me quote from an interaction I had with ChatGPT:

■ Why is someone saying, “Modern macOS is also effectively immutable. iOS definitely is. So is Android in the ways that matter.”

ChatGPT said:

The idea that modern macOS, iOS, and Android are “effectively immutable” refers to their restricted, highly controlled system environments that limit user-level changes to the core system files, making them more stable, secure, and consistent.

  1. macOS: Apple’s macOS, since macOS Catalina (2019), introduced a read-only system volume, effectively making the system partition immutable by default. This prevents modifications to essential system files during regular use, isolating system files from user data. Users can install applications and save files, but the core system files remain unalterable unless the device is in recovery mode, protecting it from accidental or malicious changes.
  2. iOS: iOS is designed as an immutable system from the start. Users and apps have no access to the system files, which are updated and maintained solely by Apple. This model is key for security, as it prevents unauthorized changes and allows Apple to tightly control the update process, ensuring that security patches and new features are deployed consistently across devices.
  3. Android: Modern Android versions use a similar approach by placing the core OS files in a read-only partition. Google also introduced the A/B system update mechanism, which allows for seamless updates by creating two system images. During an update, one system image is updated while the other remains active, making the process more reliable and reducing the chance of system corruption. Additionally, Android limits root access on non-rooted devices, which prevents users from modifying system files directly.

These operating systems share similarities with the immutable model of Linux distributions like Fedora Silverblue and openSUSE MicroOS, which restrict changes to core system layers and encourage using containers or read-only partitions for applications. This trend in OS design favors security and stability by reducing the risk of system-level changes outside official updates, aligning closely with the concept of immutability in operating systems.

⁞

■ But Android apps, while they cannot access system data or another app’s data, can access the “common area” e.g. the folders such as Downloads, Documents, Music, DCIM, etc., should the user grant them such permissions. They act more like Flatpaks, right?

ChatGPT said:

Yes, Android apps function somewhat similarly to Flatpak applications in the sense that they operate in isolated environments with limited access to the system and to other apps’ data. Here’s how:

  1. Isolation and Permissions: Android apps, by default, cannot access system files or the data of other apps, which is also a principle followed by Flatpak applications. Both Android and Flatpak create a secure “sandbox” for each app, isolating it to prevent unintended interference and to enhance security.
  2. Common Area Access: Like Flatpaks, Android apps can access a shared “common area” (e.g., the Downloads, Documents, Music, and DCIM folders) if the user grants them permission. This shared access lets apps store and read media files or documents in a space visible to other apps, similar to how Flatpaks may access certain shared directories if permissions are allowed by the user.
  3. App Management: Android apps are installed and updated independently of the core system, with updates typically downloaded through Google Play or other app stores. This resembles how Flatpak apps are managed independently of the underlying operating system, allowing for app updates without modifying the system itself.
  4. Reduced System-Level Impact: Because Android apps are sandboxed, they have limited interaction with system components, making them behave more like “apps as layers” rather than having deep system integration. This mirrors the design in immutable systems and containerized application models (like Flatpak), where the core system remains untouched by app-specific changes.

In essence, Android’s app model achieves immutability-like benefits by maintaining strict boundaries between apps and the core OS, similar to the goals of Flatpak and immutable Linux distributions.

⁞

■ But this isolation is excessive! Both Windows and Linux don’t allow non-system apps to modify system files without been granted the Administrator or root rights! There’s also a separation between users. So basically there’s a similar protection without immutability.

ChatGPT said:

You’re right that both Windows and Linux have their own mechanisms for protecting system files, and these protections are somewhat similar to the isolation seen in Android, but with less strict immutability. Here’s a comparison of how they work:

  1. Windows and Linux Protection Mechanisms:
    • Windows: In both Windows and Linux, non-system applications can’t modify system files or settings unless they have been granted administrator or root privileges. For instance, Windows uses the User Account Control (UAC), which limits app access to system files unless explicitly authorized by the user. Similarly, on Linux, sudo is required to gain root access for system modifications, and system files are protected by user permissions and ownership rules. These mechanisms ensure that unauthorized apps or users cannot alter critical system files without elevated permissions.
    • User Separation: Both Windows and Linux provide user-level isolation. Users can have different permission levels, and regular users don’t have access to the system-wide settings or files of other users, unless granted explicit permission. This is done via user accounts and permissions, a system that enforces separation between users to prevent interference or unauthorized access to each other’s data and files.
  2. Android’s Isolation:
    • Android takes this isolation even further by sandboxing each app, meaning every app runs in a separate environment with restricted access to the rest of the system and data of other apps. Apps can access shared areas (like the SD card or system media folders) only if explicitly allowed by the user. This is intended to prevent apps from accessing sensitive data or the system, even if they were compromised. While this may seem excessive compared to traditional operating systems, it is aimed at ensuring security, especially in the mobile environment where apps are more exposed to potential threats from various sources.
  3. Immutability vs. Permissions:
    • The key distinction is that immutable systems (like modern macOS, some Linux distros, and Android) go further by locking down system files and processes at a foundational level. This means even administrative access is restricted, and certain system components are not writable by the user or even administrators. This is a more stringent form of protection that prevents any accidental or malicious changes to critical system components.
    • On the other hand, non-immutable systems like Windows and Linux rely on permissions and root access to manage system security. They are still quite secure but leave room for changes to be made by users with the correct privileges, which offers more flexibility but can also lead to higher risks of modification or system corruption.

In short, while Android’s sandboxing and immutable systems take a more restrictive approach to app isolation, Windows and Linux achieve a similar level of protection through user permissions, root access, and administrator rights. However, immutability in systems like Android and macOS ensures even stricter control over the underlying system files and prevents accidental or malicious modifications, offering an extra layer of security at the cost of flexibility.

⁞

■ But why is immutability needed? I failed to see the need. Beyond the immutable, R/O base system, the other idea, of sandboxing apps, is crucial to the concept. And sandboxing is used even on non-immutable systems, e.g. with Flatpaks. But sandboxing assumes that several things happen simultaneously: (1) There are unknown 0-day vulnerabilities in the OS that, in some conditions, allow non-authorized users to perform changes without being root; (2) An app installed by the user also has an unpatched vulnerability that allows it to exploit the respective OS vulnerability; (3) That user app is either malware, or can be exploited by external malware (e.g. it’s a web browser). Isn’t this too much of paranoia? Just how often did this happen in real life? And even if it did, sandboxing seems to make immutability non-necessary. Why are people pushing immutable OSes for desktop users?

ChatGPT said:

The argument for immutability in operating systems, especially for desktop users, often stems from an emphasis on security, stability, and simplicity. While you make valid points about sandboxing and how it can mitigate the risks of exploits without the need for full immutability, the argument for adopting immutable systems can still be understood in several key contexts:

1. Security and Protection from 0-Day Exploits

  • Immutable systems help address the risks of 0-day vulnerabilities, which are security holes that are unknown to the software provider and can be exploited by attackers. The concern is that, in the event of an unknown vulnerability in the OS, even apps that are sandboxed or have limited permissions could be exploited by an attacker with elevated privileges. A compromised app or OS vulnerability could bypass regular protections and potentially gain access to critical system files. By making the base system immutable, there’s an additional layer of protection because even root or administrative access may not be enough to modify essential system files or install malware that persists after a reboot.
  • Sandboxing apps helps reduce the risk of app-specific vulnerabilities, but it doesn’t guarantee that an exploit in the OS or an app with root-like access couldn’t eventually affect the underlying system. Immutable systems, on the other hand, prevent persistent modifications regardless of vulnerabilities.

2. Unpatchable Vulnerabilities and Zero-Trust Design

  • Sandboxes are crucial for limiting the scope of damage from compromised applications, but the assumption is that the sandboxing mechanisms themselves are robust and uncompromised. However, even sandboxes have weaknesses, and in some situations, sandboxed apps can still escape their containers or exploit vulnerabilities within the system. Immutable systems ensure that, even if a sandbox fails, the damage is minimized because the core system cannot be easily modified. This zero-trust philosophy limits the chances of widespread system compromise, especially in an environment where any app could potentially be targeted by an attacker.

3. Stability and Simplicity

  • By making the system base immutable, there’s a guaranteed level of stability. Since critical system files are protected from accidental or unauthorized changes, the OS is less likely to suffer from system-breaking issues caused by poorly configured software or unwanted changes. This is especially useful in environments where you want consistent, predictable behavior (e.g., enterprise settings, mission-critical systems).
  • Updates are easier to manage. In many immutable systems, updates are atomic and rollback-able, meaning the system can automatically recover from a failed update or unwanted changes. This reduces the risk of update failures or dependency issues, which can be more difficult to troubleshoot on traditional systems.

4. Use Cases for Immutable Systems

  • Enterprise/Server Environments: Immutable systems are useful where maximum uptime and security are necessary. In high-security or mission-critical environments, where even a single compromised system could have disastrous consequences, immutability provides an additional layer of security and operational stability.
  • End User Convenience: While immutable systems might seem excessive for regular desktop users, they help simplify security management by making system updates more predictable and reducing the need for regular system maintenance. They are appealing to those who don’t want to spend time managing complex security tools and patching systems manually.

5. Real-Life Exploits and Incidents

  • It is true that real-life incidents involving combined OS and application vulnerabilities are relatively rare, but they do occur. Exploits like Privilege Escalation or Privilege Escalation Vulnerabilities in Linux or Windows (such as the Dirty COW vulnerability) show that system integrity can sometimes be compromised, allowing an attacker to break through sandboxing or other security mechanisms.
  • Desktop environments are increasingly targeted by sophisticated malware, including ransomware or rootkits, that aim to persist across reboots. Immutability can help reduce the impact of such attacks, since the core OS is locked down and less vulnerable to changes.

6. Is It Paranoia?

  • The concerns about paranoia depend largely on one’s threat model. For casual users or those without sensitive data, sandboxing combined with proper app vetting (such as using Flatpaks or trusted package repositories) might be sufficient. However, as threats evolve and become more sophisticated, having an immutable base system could be a safeguard against previously unconsidered vectors of attack, even if these occurrences are rare.
  • It’s not just paranoia, but a proactive stance on security. Many companies and individuals prefer a system that reduces the likelihood of manual errors or unforeseen security lapses that could occur with the flexibility of traditional OS management.

Why Immutable OSes for Desktop Users?

  • While immutable OSes are not necessarily “needed” for most everyday desktop users, they provide extra security and simplicity that appeals to some segments of users. As security threats evolve and more users store sensitive information on their devices, the advantages of immutability—such as reduced attack surfaces and easier recovery from failures—can be seen as beneficial, even for everyday desktop environments.

In summary, while sandboxing does mitigate the risks you outlined, immutability adds an additional layer of defense by limiting the potential damage from exploits or system corruption. The real value comes from minimizing the attack surface of the OS and ensuring that critical system components remain intact, even in the event of vulnerabilities or compromises. Immutable OSes are increasingly seen as a proactive measure to ensure that systems are as secure and stable as possible, though whether they are necessary for desktop users depends on individual needs and threat models.

⁞

■ That’s propaganda! Well, how about the need to reboot, when in non-immutable Linux distros there are kernels that can update themselves without rebooting?

ChatGPT said:

You’re right to point out that rebooting isn’t always necessary in modern Linux distros, especially with advances like live patching and kernel updates without reboots. In fact, several non-immutable Linux systems already have mechanisms to update critical components like the kernel without requiring a reboot, making the immutable model’s reboot dependency less of an issue for many users. Let’s break this down:

1. Kernel Live Patching on Non-Immutable Systems

  • Linux Kernel Live Patching allows system administrators to update the kernel while it is running, without needing to reboot the system. This is especially useful in environments where uptime is critical, such as servers or enterprise systems. Tools like Kpatch (developed by Red Hat) and KGraft (developed by SUSE) provide this functionality, allowing administrators to patch kernel vulnerabilities dynamically. This approach works by applying patches to the running kernel without disrupting the system.
  • Ubuntu also offers the Ubuntu Advantage (UA) service, which includes Livepatch to provide automatic kernel patches without reboots, keeping systems secure without downtimele kernel live patching is a feature on many modern Linux distributions, it’s important to note that not all patches can be applied in this manner. Major kernel changes, such as those requiring adjustments to modules or hardware drivers, may still require a reboot to fully integrate.

2. Immutable Systems and Rebooting

  • Immutable systems like Fedora Silverblue or openSUSE MicroOS are designed to make the entire OS image read-only, ensuring that any system modifications are handled in a containerized or transactional way. In these systems, while applications may update or roll back easily, the core system (including the kernel) is typically updated via atomic updates that require a reboot to apply.
  • In these immutable systems, system updates are designed to be non-disruptive, but they still typically require a reboot to fully activate the changes, particularly for kernel updates. This ensures the system’s integrity after updates are applied, reducing the risk of leaving the system in an inconsistent state. The reboot process is often quicker than in traditional distros due to optimizations in the way updates are staged and applied.

3. Why the Reboot in Immutable Systems?

  • The need for a reboot in immutable systems is linked to their architecture, where system changes (such as kernel updates) are designed to happen in a controlled, atomic manner. Immutable systems typically rely on containers or image-based updates, meaning the whole system is replaced with a new version during updates. This ensures that updates are consistent and easily rollbackable. While this process is streamlined, it still requires a reboot to activate the new image or kernel.
  • Non-immutable systems, on the other hand, allow direct modifications to the running system, making it easier to implement live kernel patches or similar updates without rebooting. This offers flexibility, but at the expense of a bit more risk—updates may be applied in inconsistent ways, especially if system files are modified in error.

4. Do Desktop Users Need Immutable Systems?

  • For most desktop users, the need for an immutable system is less critical than it is in server or high-security environments. The ability to update the kernel or system components without rebooting is a feature that appeals to those who need high uptime or low interruption. However, the benefits of an immutable system, especially regarding security and stability, are often more evident in environments where consistency and minimizing human error are paramount.
  • Immutable systems offer peace of mind regarding system integrity and make recovery easier in case of a failed update, but they can require more rebooting and stricter update management compared to traditional Linux distros that offer greater flexibility in handling updates (including kernel patches).

Conclusion

While immutable systems like Fedora Silverblue and openSUSE MicroOS might require more frequent reboots, their design prioritizes security and consistency. On the other hand, non-immutable Linux distros can take advantage of live patching and other methods to update the kernel without needing to reboot, offering greater flexibility. However, it’s important to note that live patching is still not universal and has its own set of limitations.

The key takeaway is that immutable systems are designed for environments where security and consistency are the highest priority, while non-immutable systems provide more flexibility but may require extra attention to managing the complexities of updates and system maintenance.

I gave up. When I won’t be able to use a non-immutable OS anymore, I’ll move to an underground cave without Internet, where I’ll be able to use whatever discontinued OS I feel like, and I’ll enjoy my huge collections of: movies, music, e-books, comic strips and comic novels (most of them bandes dessinées). I would only need electricity, water, food, vitamin D, and toilet paper.

I’ve only just came to peace with snaps and Flatpaks as a last resort fix (or a lazy man’s option), but nothing more!

Fuck the fucking “modern technology” and “immutable is the future”!