toolchain.md

Towards a Nixified Social Operating System

A Strategy Proposal for the Nix Ecosystem

The Nix Ecosystem has a wonderful diversity of tools, some of which are arcane enough to take years to discover. Nixpkgs also has an impressive diversity of packages and modules; discovering what you need and integrating it into a configured stack takes time and effort.

I think it is safe to say most of us like the extensible nature of Nixified systems; we appreciate the resulting diversity of platforms which can be built on the solid foundations Nix provides. What if we start considering the Nix Ecosystem as a sort of social operating system where we exchange configurations and the culture of how to use them, allowing us to deploy systems rapidly for very diverse usecases.

This proposal tries to lean into this idea, to pursue it such a strategy to its conclusion.

This proposal has five spearpoints:

• A: NixEcosystem streamlining Nix branding to facilitate autogeneration and extensibility
• B: NixToolchain expanding the unified command-line interface to the broader ecosystem
• C: NixStacks preconfigured composite modules for a configuration sharing culture
• D: NixKit strategic boilerplate for community network infrastructure

A: NixEcosystem - Streamlined Nix Branding

New Harmonized Names, Refreshed Logos & Extensible Branding

This proposal pitches a hardline naming convention for Nix tooling, which can then be leveraged to streamline the command line tooling of the whole Nix Ecosystem.

Changes:

1. Revert Hydra's name to NixFarm
2. Rename Disnix as NixSrv (or maybe something else; the import part is the Nix-prefix)
3. Colors adjusted to be fresher and more modern
4. A distinct yet clean font and modern font selected
5. Font Awesome icons distinguish the element visually from the rest

We could relatively easily make a script / simple web app for generating such logos automatically, given a text and choice of icon; this means we can easily extend the brand to embrace new projects in the ecosystem.

B: NixToolchain - the Nix Ecosystem in a Bottle

Extending the new unified CLI to the wider ecosystem

The unified Nix Toolchain would come with only the core components but allow enabling various submodules, doing stuff equivalent to nix install <submodule>. The coupling here is in interface only: the projects for each subcommand can exist in seperate repos and be imported if installed.

The hope is to move towards a situation where we can have an imperative-declarative mapping. The user could then use imperative commands and inspect the declarative expression of the new configuration.

0. NixCore

• nix build
• nix store

1. NixOS

• nix os

2. NixOps

• nix ops

3. Nixpkgs

• nix pkgs

• nix chan

4. NixDSL

• nix repl
• nix lang

5. NixServ

• nix serv

6. NixFarm

• nix farm

7. NixStack

• nix stack

8. NixUtils

• nix shell
• nix search
• nix find
• nix stats
• nix wiki
• nix man
• nix help

9. Notable missing stuff

• User management: the state of Nix User Profile (NixUP) is unclear at the moment.
• Installation: with various installers around like the bootable iso, nixos-infect, etc. a consolidated installer is left for later consideration.
• Enviornments: ditto?

C: NixStacks - Community Composite Modules

Preconfigured multi-service modules with a higher-level interface

Sometimes we want to share more than mere packages and service modules: we want to share stacks. We can use configuration templates for this, but it would be nice to have an abstraction designed for the purpose. A stack abstraction would include some bundled services, typically with some preconfigured integration, and some user supplied configuration through a simplified interface. These stacks would be shared in Nixpkgs, and once installed one could imperatively and declaratively add and remove packages and services to them and toggle various options.

We could have something like

nixpkgs/nixos/modules/stacks/username/datascience/default.nix

and then

stacks.username.datascience.enable = true;

The namespacing is there to address the 'opinionation' of Nixpkgs by a stack mechanism; this way stacks are defered to other repositories on GitHub (or elsewhere). This would encourage a culture of diverse solutions being shared under the single configuration DSL.

I think putting this in Nixpkgs could be very nice for new comers: they could follow a simple tutorial and very quickly have a full stack up and running. Eventually if and when some Nix language changes would take place, we could even consider distinguishing service modules from stack modules explicitly.

D: NixKit - Boilerplate Stacks for the Community

Making Federated Network Deployment a Breeze

If we coordinate some work on creating nice standard stacks for the community, we could have something like:

• NixBase: some very basic tools which are handy for any system to have
• NixDev: general development tools like VCS, IDEs and optional language specific extensions
• NixNet: client and server tools for federated communication protocols
• NixPub: publication tools for editing, typesetting, drawing and publication
• NixData: data science tools for NLP, ML, statistics and other analytics

These would allow people to easily deploy federated educational networks, and could be of great social value to a wide variety of communities, especially once we make simplified GUI configuration panels.