NixOS and the Linux distribution as a “channel”

I am currently installing and setting up NixOS, a GNU-Linux distribution that lets you configure your system and install apps using a configuration file. The configuration/installation is written in a language of its own called Nix, which is a pure functional language (PFL). If this sounds scary, don’t worry. It’s basically a configuration file with a few quirks. They have an installation and configuration manual, but it is missing large chunks of vital information for new users to configure their system, such as mounting NTFS drives at bootup with non-privileged user access.

Fortunately, they have a GitHub page, where I have been submitting issue reports, but many of their developers are over-attached to outdated ways of doing things, so there are petty fights about default settings that really should be changed for the benefit of new users. There is a pervasive problem in the open source community where existing contributors refuse to make quality of life changes to improve the software experience for would-be contributors, on the basis of some obscure and technically incorrect rationale. For example, the allowUnfree = true setting is off by default, which prevents the user from installing any program, like VSCode, that has a non-free license, and any non-free library that another program relies on. (Link to my issue & someone else’s earlier issue).

So, getting creative, I have come up with a way to satisfy both camps, allowing the minority of fanatical developers to satisfy their niche needs without affecting the rest of the normal users. The idea is presented below:

Config generator templates

From GitHub

Usability enhancement

When setting up NixOS, the config generator should have templates for different use cases, like end-user, server, etc. These would store appropriate defaults, such as allowUnfree = true for normal humans, while letting the superstitious/inflexible developers who can’t stand that feature to initialize their systems with allowUnfree = false.

This problem and solution are a subset of a larger problem and solution: #55924

Curated package channels

From GitHub

Basis

I want to install a set of items that are commonly installed on KDE desktop environments, such as a calculator, text editor, and more. Typically, the user agrees to this set of software when they choose their distribution. In a sense, distributions are just curated collections of software. This should actually be done on top of a base system (NixOS/Archlinux/etc), and users should not need to change distros just to get a system that is optimized for Digital Audio production or Video production or Office Workstation use or a Server environment.

Idea

Software packages that make sense together should be offered in curated “streams” or “channels”. Yes, I know “channels” currently means something different. The current concept of software channels should be renamed to “software sources” (aka “repositories”).

Isn’t this the same as a meta-package? Why or why not?

The current meaning of “meta-packages” is similar to what the new “channels” means. “Channels” borrows the nomenclature from popular software and services like music websites and video websites that users are familiar with. Similar to those services, when you tune into these software channels, you will be subject to the curator’s choices about what is appropriate and what makes sense together. This requires a distinction between basic meta-packages and the new idea of channels. The software in a basic meta-package is whatever is dictated by the project’s developers and what they choose to release as a complete project. On the other hand, channels contain packages that depend on each other for an overall subjective experience for the end-user.

Browsing channels

Channels should be listed and browsed separately from the basic packages. These are completely different things with different purposes. Do not mix them together.

Why is this NixOS’s problem and not KDE’s or GNOME’s?

In a sense, these “channels” should be a feature within the Desktop Environment itself, but it has to be implemented at the level of the package manager, so the KDE/GNOME developers will never be able to implement this themselves.