this post was submitted on 14 Feb 2024
101 points (97.2% liked)
Linux
48328 readers
761 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
In this comparison, the devil is in the detail.
With Ansible, you have an initial condition onto which you add additional state through automatically executed steps dictated by you until you (hopefully) arrive at a target state. This all happens through modification of one set of state; each step receives the state of the previous step, modifies it and passes the entire state onto the next step. The end result is not only dependant on your declared steps but also the initial state. A failure in any step means you're left in an inconsistent state which is especially critical for the case of updating an existing state which is the most common thing to do to a Linux system.
In NixOS, you describe the desired target state and the NixOS modules then turn that description into compartmentalised bits of independent state. These are then cheaply and generically combined into a "bundle"; wrapping them into one big "generation" that contains your entire target state.
Your running system state is not modified at any point in this process. It is fully independent, no matter what the desired system is supposed to be. It is so independent in fact that you could do this "realisation" of the NixOS system on any other system of the same platform that has Nix installed without any information about the state of the system it's intended to be deployed on.
This "bundle" then contains a generic script which applies the pre-generated state to your actual system in a step that is as close to atomic as possible.
A good example for this are packages in your PATH. Rather than sequentially placing the binaries into the
/usr/bin/directory as a package manager would when instructed by ansible to install a set of packages, NixOS merely replaces thebinsymlink with one that points at an entirely new pre-generated directory which contains the desired packages' binaries (well, symlinks to them for efficiency). There cannot possibly be an in-between state where only some of the binaries exist; it's all or nothing. (This concept applies to all parts that make up a Linux system of course, not just binaries in the PATH. I just chose that as an easy to understand example.)By this property, your root filesystem no longer contains any operating system configuration state. You could wipe it and NixOS would not care. In fact, many NixOS users do that on every boot or even use a
tmpfsfor/.(Immutability is a property that NixOS gains almost by accident; that's not its primary goal.)
Very good explanation. It's an often overlooked property of NixOS and why I often feel like Nix on other systems is an okay way to get packages but you're missing out on all the good stuff you get through the modules, like losing 95% of what makes the concept good.
I don't think NixOS is the best possible solution to the problem, but it's the only original distribution that even tries to tackle it instead of just working around it.
Well, apart of GUIX of course ;)
It's sort of a conceptual fork of Nix but the actual implementation is all original.
I thought so too but learned recently that Guix system is nix under the hood, basically translates everything, so it's more than a conceptual fork though obviously some more work went into it than your average Ubuntu fork.
https://guix.gnu.org/en/about/
They used to use the nix-daemon to realise derivations but that too was replaced original software at some point I believe. Everything else has been guix own tooling for a long time.
They still use the same derivation file format (.drv) and the basic concepts are the same ("conceptual fork"), so you could theoretically be able to realise a derivation produced by guix using nix-daemon/nix-store but that's about it as far as similarities go.
If you don't believe me, go take a look at the source code. I promise you won't find a single line of C++ in it, only a ton of parenthesis ;))))