Depending on your perspective, the vast number of Linux distributions do not appear to be so infinitely varied. Most distros are based on the filesystem hierarchy standard (FHS) [1], which stipulates that 13 relevant, known directories or corresponding symbolic links (e.g., /usr, /bin, /home) must be in the root directory. The package manager then usually distributes the files across the filesystem during package installation.

Other projects work differently and could be considered trendsetters for future Linux distributions. These are systems with a modified FHS, updates with rollback function, duplicate filesystems, apps in an app store, or containers and stateless systems. The techniques used are not necessarily new; sometimes they have been in BSD or Solaris for a long time or were influenced by other operating systems, such as NeXTStep [2], AtheOS [3], or BeOS [4]. However, in combination, they appear to be new paths for Linux distributions.

GoboLinux

If you limit your view to Linux distributions in the broadest sense, GoboLinux was the first distribution that took an entirely new approach to package management. Published for the first time in 2003, GoboLinux progressed steadily until 2008, but the distribution then disappeared into oblivion to rise again from the ashes: A new version was release in mid-2014 [5].

As the first system to break out of FHS, GoboLinux (Figure 1) arranged programs in their own directories below /Programs and did not distribute them across the entire filesystem in the traditional way. Instead of the usual directories /etc, /usr, or /var, a first glance at the GoboLinux root file tree shows the Data, Mount, Programs, System, and Users folders (Figure 2). The traditional view of the Linux file tree, which the specially developed kernel extension GoboHide hides, is mapped by symbolic links in /System/Index. However, each package is physically located with all its files in a separate directory.

Figure 1: The current version of GoboLinux relies on Enlightenment 18 as a desktop environment.

Figure 2: The usual suspects are missing from the GoboLinux root folder.

Installing a program therefore entails simply unpacking into a subdirectory of /Programs and final activation, which can be achieving by creating a symbolic link. As well as executable files, a package also contains information about dependencies at run time, the required user and group settings, the environmental variables, and configuration. The GoboLinux developers' mantra is: Our package manager is the filesystem.

According to the developers, this practice has several advantages. Besides allowing multiple versions of a program to be installed in parallel, they can also be executed at the same time. The different versions then are in directories like /Programs/Firefox/32 and /Programs/Firefox/33 or in /Programs/GCC/4.7.2-1 and /Programs/GCC/4.9.1-5. The developers point to daily handling of the system as another advantage. You can list all of the installed programs with ls /Programs, and then all the different versions using ls /Programs/<application>. Using

ls /Programs/Iceweasel/33

for example, outputs the contents of a program directory. This setup also makes dealing with dependencies easier.

A text file describes what a package depends on; checking its existence then simply requires a look in /Programs. This means that the system can be quickly returned to a functional state after a faulty package update. In doing so, GoboLinux does not need a central package database. Removing programs simply involves deleting the folder under /Programs. The GoboLinux Listener tool disposes of any Symlinks that are broken or no longer needed as a result.

Scripts and Compile are two important tools for GoboLinux. Scripts takes care of system administration, such as installing and removing packages, signing and verifying the GPG key, or checking dependencies.

The task of later installing programs that don't end up on the hard disk in the installation process rests on Compile. For this, it uses ready-made recipes [6], which, in the simplest case, comprise only two lines. Compile refers to the recipe to discover the URL of the Git repository or the source code and which methods can be used to build the code.

The recipe dictates whether a CMakefile or a Configure script exists, whether it's Python or Perl code, or whether SCons are used. As usual, the build process provides options. Compile focuses heavily on Gentoo's Portage [7]; it has, however, been adapted to the specific GoboLinux filesystem hierarchy.

The current release of GoboLinux 0.15 [8] relies on Kernel 3.14.2 and, initially, on Enlightenment 18 as a desktop environment. This includes a specially pre-configured ZSH as shell.

The program selection includes LibreOffice 4.2.3.3, Firefox 28.0, PulseAudio 5.0, SysV init 2.88dsf, and GCC 4.8.2. You can easily install many of the programs that are not supplied with the use of a recipe and the Compile script. This also includes proprietary applications, which GoboLinux does not preinstall as a general rule.

NixOS

The Nix [9] package manager and the NixOS distributions [10] based on it use an approach similar to GoboLinux, although with different methods in terms of the possibility of installing multiple versions of the application and consistent system updating. Other similarities include mixing of binary files and applications that need to be created from source code and a rollback option.

Together with other distributions, such as Fedora 17, NixOS has also aligned itself with the /usr Merge scheme [11]. Symbolic links guide the directories /bin, /sbin, and /usr/sbin to /usr/bin, so that all executable files exist in /usr/bin. NixOS even goes one step further and moves /lib, /lib32, and /lib64 to this position (Figure 3).

Figure 3: The NixOS modified filesystem hierarchy.

As a further deviation, the /opt directory is missing from NixOS, with /nix as the substitute. All installed applications are in its /store subdirectory, including all its files in their own subdirectories – GoboLinux also uses this principle.

NixOS uses complete descriptions for building the kernel, applications, and all other required packages. However, the descriptions do significantly more than GoboLinux recipes.

To set system specifications or control required functionalities, you modify the /etc/nixos/configuration.nix file. A specification for SSH is as simple as the example in Listing 1.

{
  boot.loader.grub.device = "/dev/sda";
  filesystems."/".device = "/dev/sda1";
  services.sshd.enable = true;
  services.openssh.permitRootLogin = "no";
}

Entering the nixos-rebuild switch command then fetches the SSH source code, compiles it, and writes the desired configuration to the appropriate places so that the SSH daemon runs by default from the next reboot. In contrast to conventional Linux systems, updates and configuration changes are all atomic: The system either completes the rebuild process successfully or not at all.

If everything works as it should, a new, working system exists without the possibility of an incorrect configuration option causing problems at the next system startup – unlike many conventional distributions. You can test larger changes parallel to the current system in a specially created virtual machine. Using

nixos-rebuild build-vm

starts a Qemu virtual machine with an image containing the changes.

The new system status then appears in the boot manager when you boot the system after an upgrade, along with the older snapshots (Figure 4). You can also roll back to the state before the last update using this command:

Figure 4: You can start the various stored NixOS snapshots via the boot manager.

nix-env --rollback

You can jump back to even older generations with

nix-env --switch-generation <n>

Removing the corresponding packages from the store once you have deleted one or more generations is as simple as:

nix-store --gc

These functions of the Nix package manager, which was created in 2003 within the framework of a university study by the University of Delft in The Netherlands, were implemented via a purely functional and declarative programming language written specifically for it. This purely functional programming method is different from imperative programming in that it understands functions in the mathematical sense of the word.

This allows fairly simple automated dependency management, the coexistence of multiple versions of a package, or of the same package with different parameters, and atomic updates, which automatically roll back to the last working state if an update fails.

Atomic upgrades do not leave the software in an inconsistent state at any time during the upgrade, as happens in many package managers for DEB or RPM. Updates are also non-destructive: This means they do not overwrite any old versions of the package, thus making it possible to roll back to an older version. A 160-bit cryptographic hash accompanies the package during its lifecycle and makes it uniquely identifiable (Figure 5).

Figure 5: NixOS uses the Nix store to store installed applications in their own directories.

Dependencies are resolved according to a hard-link-based model [12]. The system only removes a package that other packages in turn depend on, if no other packages reference it. New configurations of a package can be tested at run time in a virtual machine created specially for them without overwriting existing configurations. The disadvantage of atomic updates is that they increase disk space requirements because older versions are kept until you remove them manually.

The current version NixOS 14.4 is available as a Live CD for installation on 32-bit and 64-bit systems or as an appliance in OVA format for use in VirtualBox. The developers provide a NixOS instance for the Amazon EC2 cloud. The cost of a NixOS installation compares well in terms of time and knowledge required with an Arch Linux installation. The Nix package manager is also available for other distributions, such as Debian, FreeBSD, Fedora, Arch Linux, and even Mac OS X.

Bedrock: A Solid Foundation

If NixOS compares well against Arch Linux in terms of overhead, then installing Bedrock [13] comes close to setting up Linux From Scratch (LFS). Bedrock really dares to explore new territory, compared with the other distributions presented here. Bedrock, which is based on a relatively small, statically linked operating system core, aims to combine the advantages of different distributions in one system.

In practice, this approach means that, on the Bedrock core, different distributions and their applications can be operated simultaneously on one system with virtualization. Bedrock makes it possible, for example, to install and run the latest version of Firefox from Fedora and, at the same time, to launch a compiled version of the browser under Gentoo without D-Bus support.

Bedrock also supports the package management tools Apt, Yum, and Pacman known from Debian, Fedora, and Arch Linux.

All installed applications, no matter where they originate, think they are running on their native systems. All installed distributions conveniently share the home directory, so the same data is available to all program versions.

The Bedrock developers use two long-standing Linux techniques for these functions: changed roots (chroots) [14] and bind mounts [15]. Chroots are somewhere between containers and conventional virtualization, with the biggest difference being that chroots provide a certain amount of permeability. Bind mounts allow the interaction of files inside the chroots with files on the outside, whereas containers ensure strict data segregation.

Installing the current version Bedrock Linux 1.0beta1 "Hawky" may be well documented, but it overwhelms less savvy users because it is entirely console based.

You can create the basic system from the Bedrock Git repository starting with an existing Linux distribution. Afterward, Debootstrap is used to build a distribution of choice in the /bedrock/bedrock/clients/<Client Name> directory.

This step is followed by configuring the first client (i.e., a second distribution that you install parallel to the base system). Setting up Bedrock, along with installing Debian Sid and Fedora 21, took around four hours in our lab. The space required by Bedrock depends on the number of installed distributions, which should not be an impediment given today's hard disk prices.

In the Bedrock Linux 1.0beta2 "Nyla" version, at the end of 2014 or early 2015, the main developer Daniel (paradigm) Thau is planning to simplify the installation process. His plans for the future for Bedrock involve having installers for various distributions, which Bedrock then installs on another partition or hard disk on the guest system.

Uninstalling Bedrock should then be as easy as removing a guest distribution. The slides from one of his lectures at the Ohio Linux Fest [16] provide a quick overview of the Bedrock Linux principles.