NixOS Usage Experience

Disclaimer: This translated content is generated by a large language model.

Recently, I replaced the hard drive in my laptop and switched to the NixOS system. This article will first share the process of installing and configuring the system and my experience using it, followed by some of my thoughts on declarative configuration systems and containerization technologies.

 

Comparison with Old Linux Distributions

My first exposure to a Linux distribution was CentOS, which I installed directly on VMware. After a few days of trying it out, I gave up because I wasn't familiar with many Linux commands. The first Linux distribution I installed on a physical machine was Fedora, where I set up a dual-boot system with Windows and Fedora. Fedora felt relatively beautiful and modern to me, but I wasn't very proficient with the rpm package manager at the time, and after one upgrade, I couldn't find the old grub boot entry, so I only used it for two or three months. After that, I used the Manjaro distribution for a longer period. As a member of the Arch family, Manjaro uses rolling updates and, combined with the KDE desktop, offered a rich configuration experience.

Besides these distributions used on personal computers and desktop environments, I have also used Ubuntu and Debian in configurations provided by cloud service providers, as well as Alpine Linux in container environments. Ubuntu and Debian are quite mature and stable systems, but I don't think they are very suitable for configuration on my personal computer, especially Ubuntu's SNAP package management system. I also tried installing Alpine Linux on a USB drive, but this system was also difficult to configure; it feels more suited for use within containers.

After using Manjaro for over four years, I also encountered quite a few problems. First, there was the issue of dual-boot and hard drive space. During the old installation process, to be compatible with Windows, I divided the disk into three partitions: Linux, Windows, and data. The data partition used NTFS, thus lacking permission control and some Unix file attributes. Such file partitioning made expansion and backup difficult, especially after major system updates. The second problem was about the desktop management system. The old Manjaro used the KDE desktop, but I configured dwm as my window manager. The result was that I was unfamiliar with X11 and KDE packages, installing a bunch of bloated software. And when I wanted to switch to a Wayland compositor, I didn't know how to go about it (although KDE updates later provided a Wayland session option, I still didn't know how to configure it). The third set of problems lay in the configuration files under the home directory. Aside from Emacs and a few other programs for which I specifically maintained configurations, the configuration files for various other programs, big and small, were haphazardly placed under the home directory, making them difficult to organize.

A common solution is to use declarative distributions, such as NixOS and Guix. Guix is a GNU project; they have always wanted to promote their Hurd kernel, though Linux is also an option currently. Guix uses Scheme as its configuration language and Shepherd to configure system services, replacing systemd. Overall, I feel that the Nix and systemd ecosystem is more mature, so I chose NixOS as my new Linux distribution. In terms of hardware, I plan to partition the entire hard drive into one EFI and one Btrfs. I intend to migrate the old Manjaro to a Btrfs subvolume, also creating a dual-boot system. However, I will not migrate the old Windows (in recent years, Microsoft and Windows' various designs and marketing have given developers and open-source software no reason to choose them outside of gaming). Regarding desktop issues, I decided to use a new Wayland compositor and the Sway window manager (I realized that tiling window managers can also be richly configured to achieve high efficiency). For configurations under the home directory, I decided to manage them using Nix flakes combined with home-manager. However, for Emacs and a few other pieces of software, I will configure them directly using symlinks and copying, as I realized Emacs itself has an elegant functional configuration solution.

Installation and Configuration Process

First, regarding hardware configuration and disk partitioning, I began by preparing a Nix configuration repository controlled by Git. After booting into the system using a Live image, I used Btrfs to create partitions, set up the network, and then generated the hardware configuration. The next step was configuring home-manager and some common software, including Sway, Emacs, SSH, Podman, Alacritty, Chromium, etc. So far, the configuration has taken considerable effort, but most of the desired effects have been achieved. A minor hassle is that some software options are missing (either in unstable or not available), requiring me to write configuration files myself and place them in specific folders.

NixOS Reproducibility and Devcontainers

Ultimately, I haven't used this reproducibility feature much; I feel I'm still in the early stages of use, and many configurations are the simplest possible to get running. Later, if I want to experiment with new features, I will likely configure them more often using a combination of snapshots and Git repositories.

In fact, while using NixOS, I also thought about the devcontainers I had configured previously. Simply put, devcontainers leverage containerization technologies like Docker, using a Dockerfile or some script files to configure an environment. Then, a configured VSCode or other editor accesses this containerized environment via SSH for development. The advantages of such configurations are the ability to develop in an isolated environment and good integration with Git or GitHub workflows (e.g., GitHub Codespaces). The drawbacks are that the VSCode plugin is proprietary, and the package size is somewhat large. I had previously learned that Nix also has some applications in containerization, capable of minimizing image size and fixing versions, but I truly don't know its applications in devcontainers. On the other hand, Nix's toolchain also allows development without Docker, directly using nix develop within a folder.

Overall, I don't think complete reproducibility is necessary for all aspects, especially for some personal configuration applications, such as my Emacs configuration and Rime input method dictionary. I also don't think it's a good idea to use Nix alone on other personal computers. Under MacOS, some configurations might conflict with Apple's security policies, and other Linux distributions differ from Nix in various aspects (for example, the FHS followed by many Linux distributions is not entirely the same as Nix). What I'm more optimistic about is how this reproducibility can meet my needs for stable use and experimenting with new features, and on the other hand, using this centralized configuration to manage computing resources.