NixOS: The last word in Armagetron hosting

[numinit]

Oh boy I wish this comment was on the first page...

I love the idea NixOS. I also hate the idea. If you limit yourself solely to single-file config like that, you're somewhat locked-in to a given ecosystem. That's not really linux - but at the same time, there are some very useful fundamentals here. Package managers could use stateful restore functionality, for example. Grub could do with saving the previous configuration and presenting it as an option if the primary config fails to boot.

I think there are still major escape hatches. For example, you can run the steam runtime and all its games just fine, due to some clever chroot hackery that mostly "just works" and makes your NixOS system look like Debian to anything you're running on. That and nix-ld help with running non-Nix packaged binaries hugely. But, yeah, if you want to, say, run the vscode server, you have to enable that first.

For appliances, it's amazing, especially if you have a ton of boxes to deploy. Upgrades are seamless and you don't have to think about them nearly as much as dist-upgrade.

Yeah, for someone who loves total and direct control over their system, NixOS is a bad choice. It's the law of leaky abstractions that can strike. You're writing some configuration, and some not entirely clear process creates a different configuration, which some other program then uses. Worst case, you have to debug TWO things, the program you want to configure, what its configuration file should be, and then how to get to that configuration using the single configuration language.

On a related note, there have been pushes across nixpkgs to expose more knobs that reduce abstraction leaks. It's why services.armagetronad.<server>.settings is a thing. Instead of writing a config file out as a string, you can just provide an attrset that ends up calling a function inside the module that generates one. nixpkgs hasn't always been this way, you used to need to just stick config snippets everywhere. While you still kind of do and there will always be abstraction leaks with Linux to some extent, and nixpkgs will never be anywhere close to perfect, that is why you see things like the extraConfig string options meant to tack on things to (for example) nginx's complicated config. On the other hand, since Armagetron's config format was simple enough, I didn't need to add that at all.

Overriding the "nice defaults" also usually works with enough hackery, which has allowed me to stay. I came from a highly tweaked Arch setup prior to using NixOS, and don't always love the defaults, but can override them when I want with package overrides, overlays, and such. Weirdly it's made my usual process of tweaking my systems like crazy easier, because I can reproduce all the tweaks everywhere with the right homebrew NixOS modules. So maybe give it a chance. That's actually why it's become the perfect OS for me, I have been trying to get the incremental cost of deploying extra boxes down without using something like Ansible which just runs scripts on a "normal" OS and doesn't offer nearly the benefit Nix does.

Here's a great example. For Armagetron in particular, I always used to build custom servers back in the late 2000s. So I had to learn how autotools and such worked. I thought the move to Docker in general for the tech industry was a huge shame, because it's slapping a bunch of entire Linux systems together from prebuilds, pretty much. Things were no longer hackable at the package level. I always used to just change --prefix to test multiple dedicated servers! But now with nixpkgs the prefix doesn't really matter. stdenv automatically sets it to something unique and calls make install for most derivations, which sticks everything in $out. (Check out the build logs for the latest Armagetron on nixpkgs, it may be pretty informative.)

But, say I wanted to change the "reasonable defaults" to add a configuration flag (say, --enable-memmanager, which btw may crash - see previous upthread discussion for why I removed it). I'd use overrideAttrs to do so and just overlay it to make my changes apply systemwide.

Code: Select all

nixpkgs.overlays = [
  (final: prev: with final; {
    armagetronad = prev.armagetronad.overrideAttrs (old: {
      configureFlags = old.configureFlags ++ [ "--enable-memmanager" ];
    });
  })
];
environment.systemPackages = with pkgs; [ armagetronad ];

And that's it. Now I've got a bespoke Armagetron.

Or I could change the source entirely too, to fetch from gitlab:

Code: Select all

nixpkgs.overlays = [
  (final: prev: with final; {
    armagetronad = prev.armagetronad.overrideAttrs (old: {
      src = fetchFromGitLab {
        owner = "armagetronad";
        repo = "armagetronad";
        rev = "<git sha or tag here>";
        hash = ""; # leave empty and the fetcher will tell you what the hash should have been (starting with sha256-)
      };
      configureFlags = old.configureFlags ++ [ "--enable-memmanager" ];
    });
  })
];
environment.systemPackages = with pkgs; [ armagetronad ];

Or I could grab the derivation and mess with it:

Code: Select all

nixpkgs.overlays = [
  (final: prev: with final; {
    armagetronad = callPackage ./my-armagetronad.nix {};
  })
];

Or I could just change it in the dedicated server config for the service:

Code: Select all

services.armagetronad.servers.custom-server = {
  enable = true;
  package = pkgs.callPackage ./my-armagetronad.nix { dedicatedServer = true; };
};

And so on, and so forth. This is insanely powerful stuff and comparing it directly to normal Linux distros does it a disservice sometimes.

BTW, 0.2.9.2.3 just hit unstable.

[Z-Man]

Heh, I'm looking forward to the day where I understand all of that