Show your list of packages or shut the fuck up already.

I’m the only one talking to you. You’ve convinced nobody else that you’re even worth speaking to. Honestly, you sound like the weenie who tried to publish that bootlicking pro-military letter. Wanna go be the second person to sign it? You certainly aren’t doing anything worthwhile with your time here on Lemmy.

You claim you have a list of packages, but you’ve revealed none of them. This is somewhere between the angry politician waving a list of enemies and the dishonest teenager claiming to have a romantic partner in terms of convincing me. Look, you have the time to write something like fifty Lemmy comments per month; I think that you can write the twenty or thirty lines of Nix required to build your pet package. It’s a shitty carpenter who blames their power tools and a shitty scientist who makes empirical claims without evidence.

The nixpkgs community has been operating and maintaining nixpkgs-update since 2018. Earlier in the thread, you were shown the infamous Repology graph; it’s also linked from the nixpkgs-update documentation. We already have a concerted plan to offer the freshest ports tree in the world and are executing on it. If your particular pet package isn’t available, then contribute it yourself and the bot will ensure that it stays fresh and updated.

I use the community impermanence flake instead of ZFS or btrfs. It’s still fairly nice; I actually like knowing that stuff like ~/.cache doesn’t persist anywhere on disk, even in snapshots. It does require a lot of careful thought, like e.g. which parts of the persistent disk need to be backed up locally.

Do it yourself. Contributing to nixpkgs is easy, especially for updating packages.

Search the manual for support32Bit configuration options, like hardware.opengl.support32Bit, hardware.pulseaudio.support32Bit, or services.pipewire.alsa.support32Bit. Any 32-bit games, as well as Steam itself, will need these to get their GL and PA/ALSA libraries set up properly.

You may also want to look up what programs.nix-ld.enable does, although I hear that there’s a better harness builtin as of NixOS 24.05.

All that said, everything Just Worked when I last tried. I haven’t run Steam in a while, though. I do use Retroarch and OBS without problems, though, streaming PS4 speedruns to Youtube or Peertube, and that all works out-of-box.

It’s the other way around. Nix sucks. (Guix sucks too.) However, every other build system I’ve used, as well as every other package manager and every other distro, sucks more.

You’re doing fine. Slow down. Forget “installation”; it’s not a concept Nix uses. If jumping directly to NixOS is overwhelming, it might be easier to go back to Arch, Ubuntu, or something else you know and are comfortable with, and use Nix from a familiar distro; build up idioms for working with your preferred tools, development environments, and configuration. When you’re ready, you can try NixOS again, and hopefully it will make more sense.

nix-env must evaluate all of nixpkgs and the reference implementation of Nix is not very fast. It’s not a big mystery, although it appears that a rewrite of Nix will be required to improve it.

The flake exports look like outputs.nixosConfigurations.joker, each one matching a hostname. There’s a poorly-documented feature of nixos-rebuild where you can point it at a flake with --flake and it will try to use the configuration matching the current hostname. So, I make the flake available on each machine and customize it using the hostname. One flake, a dozen machines. Works well enough for a homelab but would not work for a large cloud deployment.

Oh, right, monoids! Yes, you understand correctly.

A monoid is a collection of objects that has some sort of addition and zero. (Depending on your maths background, it might equivalently have some sort of multiplication and unit.) Addition must be associative, and addition with zero must not have any effect. Monoids let us think of a system as built from a sequence of operations; each operation adds to the system, preparing its state incrementally.

Sometimes monoids are commutative, which means that the order of additions is irrelevant to the result. Commutative monoids let us think of a system as built from a collection of operations without worrying about the order in which those operations are applied.

NixOS modules (and HM modules, etc.) are commutative monoids. The zero is {}. The module system lets options declare their own monoids which ride along, like my example of allowedTCPPorts. Because we can combine sets of port numbers (with set union) and get more sets, we can factor a set of ports into many smaller subsets and put each one in their own file. Here’s my shortest module, for an internal Docker registry, docker-registry.nix:

{
  networking.firewall.allowedTCPPorts = [ 5000 ];
  services.dockerRegistry = {
    enable = true;
    enableGarbageCollect = true;
  };
}

I’m adding some code snippets from my homelab’s flake. Minor details are changed. Note how I have a core.nix and also separate files for adding Avahi (zeroconf) and SSH, and for fixing bufferbloat. I could have them as one file, but it’s easier to come back to them after several years this way. (bufferbloat.nix was last changed in December 2021, for example.)

I know that some of this code style probably seems weird. Think of it as heavily inspired by Puppet, Chef, Ansible, HCL, etc.; when we are configuring a system, it is very very nice to be able to comment out a single line at a time.

    commonModules = {
      imports = [
        nixpkgs.nixosModules.notDetected
        ./avahi.nix
        ./bufferbloat.nix
        ./core.nix
        ./ssh.nix
      ];
      nix.registry.nixpkgs.flake = self.inputs.nixpkgs;
      nixpkgs.config.packageOverrides = pkgs: {
        mumble = pkgs.mumble.override {
          pulseSupport = true;
        };
      };
      users.users.corbin = {
        isNormalUser = true;
        extraGroups = [ "wheel" ]; # Enable ‘sudo’ for the user.
      };
    };

      joker = nixpkgs.lib.nixosSystem {
        inherit system;
        modules = [
          commonModules
          ./joker/configuration.nix
          ./gl.nix
          ./sound.nix
          ./wifi.nix
          ./xserver.nix
        ];
      };

At scale, you’ll appreciate explicitly spelling out your imports. I currently have 23 importable files, of which two are mutually incompatible (headless vs. Xorg). I don’t want a glob over these files because no machine can have all of them; indeed, most machines only have like five imports from the list.

What might be more interesting to you is a common collection of modules which must be imported everywhere. To achieve this, I explicitly declare a commonModules at the top of my flake and reuse it in each machine definition. Another approach might be a common.nix module which recursively contains the common modules as its own imports.

Finally, it doesn’t “defeat[] the point of separating” expressions into multiple files to avoid globbing over them. Because NixOS/HM modules are monoidal, they often factor nicely. When you have a dozen different services, you could stuff all of them into one file with one networking.firewall.allowedTCPPorts if you wanted, or you could put each service into its own file and let each module bring its own port to the combined configuration. The latter is easier at scale; I have nine modules declaring TCP ports and five machine-specific TCP ports as well, and it would be a pain to put all of them in one location.

The NixOS community is forked on a regular basis. So is the nixpkgs community. The focus here is on control of CppNix, e.g. blocking the autotools-to-meson PR.

It’s pretty easy to have opinions that the mods and Foundation don’t like. Be polite and you’ll be fine. Also, don’t be like Jon, who thinks “polite” means smiling through gritted teeth and being passive-aggressive.