I have been using NixOS for a year and a half. It is conceptually different from other Linuxes, and is notoriously difficult to explain. Unfortunately, the strange concepts and ugly configuration language mask an underlying simplicity which I think is superior to the traditional approach to Linux system design. I will try, in this article, to explain a few of these concepts, and how they relate to a development problem caused by the fundamental design of traditional Linux.
The problem with the FHS
The Filesystem Hierarchy Standard seems to be a basic part of Linux. Indeed, it is one of the first things everyone learns about when starting to use Linux, though they are usually unaware that it is the FHS. The FHS simply defines where different types of files should be located: executable files in /bin or /usr/bin, libraries in /lib, configurations in /etc, and so on. Most people assume this to be a fundamental aspect of Linux, but it is not.
On a Linux system, everything is a file, and files can be located anywhere, in any directory. As long as you know where your executables are, and they know where their libraries are, everything can be in one directory, or split across multiple paths. Linux doesn’t care.
On the other hand, in an ecosystem in which code is widely shared among projects, the arbitrary placement of various components made life difficult, so, early on in the life of Linux, a group of people proposed a standard (firstly the FSSTND, followed by FHS) which defined locations for the various types of files, a proposal which was quickly adopted by just about everybody.
The problem with this approach is its hierarchical tree structure. It would appear an obvious way to organize files, but it is by nature limiting. in modern programming, multiple versions of programming languages and libraries are necessary, not all of which are compatible. With only one /lib directory, only one /usr/bin directory, etc. how do you manage multiple versions of all the packages? A program might be dependent on a specific version of Python, while another program might require another. In development, this is particularly problematic, as version bumps can break programs, so version consistency is crucial. But on any given Linux system, ensuring such consistency is effectively impossible.
There is an entirely different approach, an organizational structure unfamiliar to many: a graph.
Keep reading with a 7-day free trial
Subscribe to biscotty's Workshop to keep reading this post and get 7 days of free access to the full post archives.