mirror of
https://github.com/foo-dogsquared/wiki.git
synced 2025-01-30 22:57:59 +00:00
3.3 KiB
3.3 KiB
NixOS
- an operating system that uses Nix package manager as the core component to build a whole operating system; this make NixOS as an image-based operating system similar to roam:Fedora Silverblue, roam:MicroOS, and roam:Endless OS
- despite being mentioned to the aforementioned image-based operating systems, it isn't an immutable system; NixOS itself is not immutable as you can still interact with the system just like with traditional Linux-based OS; most of the system is set up by the package manager which does have an inherent property of being immutable but this doesn't make NixOS an immutable system
- most of the workflow and ecosystem comes from the central repository for any Nix-related system: roam:nixpkgs; it is where most of the roam:NixOS modules come from
-
it isn't really like the traditional Linux distros that you'll see as it has made decisions that can majorly affect how you daily-drive the system
- the Filesystem Hierarchy Standard (FHS) is nowhere to be found;
there is only the
/bin/shand/usr/bin/envwhich is there for convenience purposes which is nice if you rely on some scripts - the absence of the FHS alone has some implications; one of them is the inability to run precompiled binaries (including AppImages which rely on system libraries) since most of them rely on the files that are expected to be present in the traditional distros like Debian and Fedora
- because of the non-existent FHS, you have to compile and/or create a derivation for that project; workarounds exists for certain situations like AppImages and programs that expects a system with FHS but you still have to create a Nix package for it
- the Filesystem Hierarchy Standard (FHS) is nowhere to be found;
there is only the
Benefits of NixOS
- one of the nicest advantage of Nix-based systems is having hermetic builds; this means that configurations are made only from the package manager; with Nix being the way it is, all of its files come from the Nix store which contains unique versions of different packages and inputs (derivations); in practice, configuration are applied by building it first by the package manager then symlinking the output from the store to various points in the filesystem;
-
coming from the sysadmin perspective, hermetic builds means it has mitigations against configuration drifts;
- in roam:Ansible, configurations are applied by processes which can leave files behind; while it can keep track of changes and processes are usually idempotent, Ansible doesn't deal with removed changes which means manual intervention and a potential configuration drift; in short, Ansible looks more of a task runner than a configuration framework
- in Nix-based systems, configurations are built and then applied over the system by the package manager as an atomic update; having the configuration seen as one output by the package manager means removed changes are not much of a problem since they are part of another output which can be reapplied if those changes are needed additionally, Nix keeps track of the configurations through generations