After daily driving NixOS and the Nix pm for almost three years, it feels like it’ll be simplified by entities external to the project. It’s still in that academic phase (don’t do this/that) and needs software engineering asap.

That usually involves reducing boilerplate ruthlessly while generalizing/capturing fundamental uses cases (setting implicit best current practices). It’s reminiscent of lxc just before docker arrived for the masses.

btw this blog is served to you by NixOS :-)

Surely typing/saying the below Alpine command to install Firefox is way easier than who knows what multi–stage process other operating systems require.

apk add firefox

Google’s search box (rather tongue in cheek) is the most popular command line interface in use today. With NLP, installing and running firefox would just be a phrase equivalent that compiles to:

firefox

On NixOS, we can already do stuff like that. Of course, NixOS lacks a translation/encapsulation layer for imperative to declarative specification — so user friendliness suffers dramatically.

It’s kinda odd being able to remember what things were like before Docker appeared. Docker is the software developer’s take on creating a Linux distribution. It’s useful, but the indirection of containers and pinning can be deadly. Avoiding unnecessary indirection is advantageous.

I’m just now realizing that there might be a schism within the Nix/NixOS ecosystem/community on old versus new interfaces. If that’s remotely true, then somewhere, a great holy war is at play. Here’s an article summary of the old versus the new interface that I stumbled upon recently.

This blog is really really good for robust usage of Nix/NixOS. I stumble upon it every so often. Another excellent blog is “How to Learn Nix” which explores in excruciating detail the painful parts of nix and its documentation. Discovered that one recently.

What’s funny about the NixOS/GNU Guix design is that it tricks developers into writing their own system packages. That would never happen on other Linux distributions. I’m slowly favoring Guix though, since the new nix flake interface couples too tightly with git.

I’m very tempted to stick GNU Guix somewhere in my main workflow — Guile Scheme looks interesting. I’m sorta curious as to why people like Lisp languages so much. The plan is to read the reference manual. (yeah… right)

My knowledge of the functional ecosystem is mostly diddly, but maybe there’s a way to speed it up? Ignore all module and package imports and piece together a minimal evaluation perhaps?

{ ... }:

{
  imports = [
    <nixpkgs/nixos/modules/programs/git.nix>
    <nixpkgs/nixos/modules/security/auditd.nix>
    <nixpkgs/nixos/modules/services/databases/postgresql.nix>
  ];

  nixpkgs.overlays = [
    (_: pkgs: {
      cpio = pkgs.callPackage <nixpkgs/pkgs/tools/archivers/cpio/default.nix> { };
    })
  ];
}

If that goes anywhere, maybe that’s an article, but I’m fairly certain someone must have tried something like this already.

The peculiar thing about the nix ecosystem, is that the easiest way I’ve been able to convince someone to try nix is to first show nix-env. Then apply the idea of declarative package management. Not too long after that they’re on NixOS or using nix flakes, and have catapulted far past my own knowledge of nix.

Only recently did I discover that in the wider ecosystem, using nix-env is a big no-no — that’s sort of interesting.