Being declarative
The future is all wrapped up in a single text file?
Declarative configuration covers many areas and provides a method of defining something and then using some sort of automation to create the outcome. This sentence is deliberately vague as there’s a large number of tools that take some configuration and convert it to output.
The first example is Terraform, which allows virtual environments to be built from a textual configuration file. Terraform has support for a large number of environments, so virtual hardware can be provisioned in a wide range of platforms, spanning AWS, Azure, VirtualBox, VMWare and more.
The second example is Ansible, which allows devices to be configured in a certain way from a central server. When registering devices, they can be tagged, and incredibly complicated configuration can be built using a combination of tags that link to different configuration files. A single configuration definition can also apply to many devices and groups of devices
One powerful aspect of this sort of configuration process is that the files can be easily backed up and/ or shared. Should the worst happen and you end up recovering from backups, you can set up your declarative configuration tools and run them to configure either virtual hardware or operating systems.
NixOS is another OS that uses modern techniques to make the operating system as reliable and secure as possible. It handles things very differently and also uses a lot of the same techniques as the tools that can be used when using the Infrastructure as Code methodology. NixOS centres around the Nix package manager, which installs apps in a very different way from what we’re used to. Apps can be installed on a per user basis, or for every user. When installed, each app is stored in its own directory and multiple versions of the same app can be installed. Each directory contains all of the app’s dependencies and, again, multiple versions can be installed across the system. Apps installed or upgraded using this system are atomic, so the rest of the system is not broken if an upgrade or installation fails. Should a bug be found in a version of software, it can be rolled back, as the old version is not deleted straight away. Automatic updates are also easy to configure with the system. Nix can be installed on Linux distros as well as Mac OS and is also able to build or install packages from source or download and use prebuilt binaries. For small tools, source compilation wouldn’t take long, but imagine building your browser or window manager for each update that is released.
So, that’s Nix, but what is NixOS? The operating system uses Nix to not only build and install packages, but also to provide configurations to daemons, network configuration, package installation and more.
How does this work? Well, as we said, apps are all stored within their own directory in the Nix store. By default, this is in /nix/store. NixOS does not use a number of the usual directories you’d expect to see, such as /bin, /sbin, /lib and /usr, and accesses files from the Nix store instead. While there is an /etc directory, a lot of the files in there are just symbolic links (symlinks) to the files in the Nix store.
The benefits of a system such as NixOS are apparent, but this methodology must be maintained, as if you were to start installing software using other means, you would not be able to recover from a data issue, or set up a new device in exactly the same way. Learn more about NixOS at https://nixos.org.