The All Systems Go! conference happened last week in Berlin, devoted to systemd / container / image-building topics. Several cool talks focused on immutable distributions: their usages and virtues, particularly NixOS. NixOS is the foremost immutable, reproducable, and atomically upgradable Linux distribution, and a powerful building block for building easily deployable services.
Andreas Herrmann, the first Bazel community expert, talked about the value of a reproducible build of your software and the merits of using an immutable distribution like Nix to make your builds better. Xe Iaso's talk on writing your own NixOS modules for your own build dependencies to ensure your software is reproducable. Lots more talks, but mostly systemd-related: check out the list of talks and the recordings!
All Systems Go 2023 will feature Lennart Poettering talking about Unified Kernel Images along with talks on encrypted Btrfs sub-volumes, Linux security, BPF filtering, soft reboots, Linux and TPMs, systemd-repart, mkosi, and Microsoft talking about their image-based Linux deployments on Azure, among other topics.
Related: The Future of Linux: Exploring Immutable Distributions
Related Stories
Arthur T Knackerbracket has processed the following story:
If you're a Linux enthusiast, you've likely come across terms like "immutable distribution", "OS3", or "image-based operating system". These concepts have been gaining traction in the Linux community, sparking curiosity about their significance. In this article, we'll delve into the world of immutable distributions, exploring how they work, their advantages, potential drawbacks, and whether they truly represent the future of the Linux desktop.
An immutable Linux distribution is a unique breed of operating system designed to be read-only and resistant to easy modification once installed. The fundamental idea behind these distributions is to restrict user and superuser access to system files and directories, ensuring that most changes are temporary and erased upon reboot. This approach has earned them the moniker "immutable."
When updates are applied to the system, they don't modify the existing installation. Instead, they create a new system image that becomes the active one upon the next reboot. While this might initially seem limiting, immutable distributions implement workarounds to ensure users can still customize their computing environment.
Immutable distributions offer robust security benefits. Since users and third-party programs can't readily modify the core system, the risk of viruses, Trojans, ransomware, and other malware compromising system files and directories is significantly reduced. Even if an attacker gains access to the system, their ability to write or modify system components is limited.
Immutable distributions are highly reliable. Users are less likely to accidentally break their systems or encounter issues caused by third-party software modifications. Unlike conventional distributions, there's no risk of running into dependency conflicts or unintentionally destructive commands.
Maintenance is streamlined with immutable distributions. Updates are only applied after a reboot, eliminating the risk of breaking the system while it's running. This approach also minimizes the chances of encountering dependency-related problems during updates.
One significant challenge with immutable distributions is installing applications, as traditional package management systems typically require write access to the system. Immutable distributions address this issue using various methods:
Many immutable distributions embrace universal packaging formats like Flatpaks, Snaps, and AppImages. These formats don't need full system access and bring their dependencies, making them ideal for installation on immutable systems.
Some distributions allow users to install packages in a dedicated layer separate from the immutable base system. These layered packages persist across reboots and are included in the updated system image, providing a way to install drivers, libraries, and applications not available as universal packages.
(Score: 4, Insightful) by DrkShadow on Saturday September 23 2023, @05:43AM (2 children)
That's not "immutable distributions". That's immutable application packages. Like a deb archive. Except it goes further: the whole OS is within the archive. That's just app packaging, that's just containers.
Behold: The Future of Linux is Upon Us! (I think we've seen before where this will go...
(Score: 2) by turgid on Saturday September 23 2023, @09:26AM
It gets worse.
and Microsoft talking about their image-based Linux deployments on Azure
These are truly End Times.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Saturday September 23 2023, @04:56PM
Most people/organizations don't care that much if ransomware encrypts/mangles their system files. They care that ransomware encrypted their data. Assuming not all of it is backed up.
There are probably thousands of copies of those system files on the internet if not more, if they want them they can get more easily.
Not so for their data.
if you use VM stuff you can set stuff up so you can rollback to known snapshots. Your data could be on a different drive that's not affected by the rollback and backed up on a regular basis.
(Score: 4, Insightful) by Rich on Saturday September 23 2023, @02:26PM (8 children)
Never heard of it. Quick look shows a completely hipster conformant web stack with everything from the typical tablet-friendly home page to a forum-conduct policing team, and a shitload of stuff in between. There are a few rough edges, like the "weekly" newsletter being far from weekly. The main person is one dutch guy, Eelco Dolstra, who does Nix since 20 years and had his PhD over it in that time. Still, maintaining such a niche thing with such a broad presence over 20 years is a hell lot of effort and someone's got to pay for it. It's a bit of a mystery where that comes from.
On a technical level, let me quote the Wiki "while NixOS does have an /etc directory to keep system-wide configuration files, most files in that directory are symlinks to generated files in /nix/store, such as /nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config. Not using global directories such as /bin is part of what allows multiple versions of a package to coexist.". Holy cow, pathnames like these already ruin our lives from Mac package storage to Firefox profiles, and I'd rather stay very away from them. I'll dismiss it as "dead end path" here. The clean approach would have been to do a transactioning and versioning file system as backing store with a liberal amount of union mounting sprinkled on.
In general, the complexity of the dependencies of a modern OS with all the stuff demanded by people putting layer upon layer upon layer doesn't go away when you hide parts of it some fashion. Quite the contrary, and with one big single dpkg tree one at least has a remaining chance to see what's going on in the big picture. I'll assert that it's easier to just sort out any problems in there than to juggle with multiple trees (although I do understand, for example, but don't really approve, where python venvs come from).
Next.
(Score: 2) by GloomMower on Saturday September 23 2023, @05:14PM (7 children)
I think you are missing a big part of the point of systems like NixOS, and why what you are talking about isn't a big deal. One of the ideas is the entire system is defined by one config file, that includes system configuration normally in /etc. The idea is you can bring up the exact same system with just having your nix.conf. So you shouldn't be changing anything in /etc, you should modify your nix.conf and then update nix to follow that config.
I also believe what nix is doing is a lot more efficient than versioning file systems as it holds and uses per-package snapshot of packages based on hash instead of say snapshots of the entire file system.
You can follow where the money is coming and going by looking at the NixOS board meeting minutes and financial summaries.
https://discourse.nixos.org/c/dev/nixos-foundation/47 [nixos.org]
I'm not saying it is for you. I have not even used it much myself, it just seemed like something that has a lot of promise and I've been looking into.
(Score: 4, Informative) by turgid on Saturday September 23 2023, @08:50PM (4 children)
One of the ideas is the entire system is defined by one config file, that includes system configuration normally in /etc.
That's going to be a heck of a very big config file. There are good reasons why /etc is full of separate files. Monoliths are bad.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by GloomMower on Saturday September 23 2023, @11:39PM (3 children)
You can split it up if you want to, but fine... single nix configuration, not single nix config file.
(Score: 2) by turgid on Sunday September 24 2023, @08:21AM (2 children)
So we already have our configuration in /etc. Why do we need another one? It'll be a different syntax, less precise and another layer of obfuscation. What if I just need to tweak something in /etc? Do I need to do the super configuration too? How do I keep them in sync? Do I need to guess what changes to put in the super configuration to get the changes in /etc?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by GloomMower on Sunday September 24 2023, @01:36PM (1 child)
I'm not a nix expert, not even really yet a user. I think it is something you might need to try to see if you see any potential for it, for yourself.
You can search for the configuration parameters here.
https://search.nixos.org/options [nixos.org]
About having to make config changes in two places. The idea isn't you put it in two places, you never change it in /etc directly, you should just put it in the super configuration, and then run a nix command to apply your changes (nix-rebuild i think). Tweak the super configuration, no big deal. Go back to previuos config, no big deal.
Same for packages. Want a package installed, put it in the config. Ever wish you can like undo a apt upgrade? In nix if you have it right, you can just load up a previous revision of your config and it is like the upgrade never happened.
Yeah you don't have to like it. It is an way(or attempt) to get a reproducible system exactly the way you want it. If you need to undo a change, edit the configuration and it isn't dirtied by the previous one (extra packages or whatever). If that is something that interests you, it might be worth checking out, if not that is okay.
It has been a while since I managed large number of servers, but during that time I was trying to get a cfengine type system going (I believe that project or idea turned into ansible). Nix seems more like my style in defining the system. I can also see it useful for my desktop or workstation. If I ever want to switch hardware, just copy my nix configuration and home over and it is the way I want it in minutes. Or even the same hardware, just updates, it can be more of a truly rolling package system without the frear of everything breaking and I can't go back.
From their docs:
"if you provide the same inputs, the same version of Nixpkgs and the same /etc/nixos/configuration.nix you will get the exact same system state."
(Score: 2) by turgid on Sunday September 24 2023, @03:19PM
It sounds like a load of over-engineered rubbish by people who don't understand Unix or have a vested interest in making it obfuscated and over-complicated. I've been using Slackware since the mid 90s. I've worked with many other distros and real Unix (Solaris). Thank goodness for Slackware. While everyone else is going crazy, Pat keeps on keeping on.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Rich on Sunday September 24 2023, @11:43AM (1 child)
Well, the financial disclosure looks solid for some "established grassroots" operation. And with the track record of their maintainer, I think the whole structure is the manifestation of his life of research. Even if the site looks more like it was done by salespeople than researchers. One can never be sure if the drive behind technologies on Linux that move away from classic maintenance isn't there for more nefarious purposes. (E.g. Mono, which was seriously well done at a low level when it came out, yet suspiciously lacked Debugger and WinForms to make it useful without being tied in to Windows...)
But still for "image" based OSs, I don't think I could buy into their approach. The way Apple does it on recent OS releases ("sealed" binary hash tree) would be somewhat interesting for an immutable base system if the end user would be in control of the hardware signing root (not just SIP/seal off). Then you could mix & match and make sure you'll end up with exactly what needs to be reproduced at runtime. Alas, the standard file hierarchy is a bit in the way of doing that easily (i.e. rather than having /etc/9123jjnshxauanw-ssl.config, you'd have /build-9123jjnshxauanw/openssl/etc/ssl.config) and then build your immutable runtime from these blocks E.g. the clients would always expect openssl at /Library/Packages/openssl/bin/openssl and you could flip that out for some legacy use case. Whether there should be exposed /Library/Packages/openssl- variants is debatable, because with security requirements, patches HAVE to go in everywhere. It's probably ok where two branches are actively maintained.
(Score: 2) by GloomMower on Sunday September 24 2023, @01:43PM
It probably isn't for everyone. If I understand your comment, it seems you like more of a large encompassing disk snapshot approach and it is fine to like it that way better.
I kind of also understand where you are coming from, and why you might want it that way from previous experience. Just a small for examples: In ubuntu its packages and apt repos, ppa, get deleted, moved and are not available over time (support ends for that version). I think in Nix their goal is for that not to happen or there is a more reasonable workaround.
In Nix the configuration file is the snapshot.