dotfiles VS dotfiles

Not sure about central but just search dotfiles, config, or flake on GitHub and filter by nix language. Most dotfiles are a sort of “distro” as nix let’s you configure everything from scratch in a central way. Eg my personal dotfiles are an abstracted layer of NixOS/home manager. This can be seen honestly in a lot of popular configs. Eg my WireGuard module turns high level options into automatic configs (see: module).

What’s powerful about nix is the language IMO. I was able to build an automatic WireGuard setup[1] with tagging that automatically works on each new machine thanks to the ability to do config as code. Just provide some basic config for each machine and the code turns it into an interface with peers.

The issue to me isn’t the language persay (it’s really a tiny surface area language, see the built in/lib functions [2]) but the tooling built around packaging is a hodgepodge mess of semi-documented workarounds (with Nixpkgs blessed ways vs used libraries) and is extremely difficult to approach and understand.

[1]: https://github.com/jordanisaacs/dotfiles

Not entirely sure what you mean by policies. But you can use rycee’s buildFirefoxXpiAddon. All you need is the xpi. See: https://github.com/jordanisaacs/dotfiles/blob/master/modules/users/graphical/applications/firefox.nix for some manual packages.

As a heads up setting up gnome-keyring is an adventure in and of itself when not using GNOME which from the sounds of it you are not. It took me a month of on and off trial and error to finally quash the last of its bugs. You can search around my dotfiles where I have it working but the solutions are all over the place (modules/system/gnome/default.nix, modules/users/graphical/shared.nix, and modules/users/graphical/wayland.nix).

I’ll just add on, I use functions in my nix file to make configs (iso, home manager, nixos),: function folder. With this logic you can create basic other hosts. How they are used in used in flake.nix

I am using this repo as a guide. I created a module which has the bootloader and filesystems configuration, and here I would like to conditionally load the qemu guest configuration, based on a configured attr. When you install NixOS in a qemu vm, this import is automatically added by nixos-generate-config to /etc/nixos/hardware-configuration.nix like so:

> And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...)

I agree that the name is bad and has always been bad. I wonder what they were thinking. But the syntax of the Nix language is not based on Haskell. It would be better if it were, but the Nix syntax is actually based on trying to twist a functional language into looking like a Unix-style configuration file. It's horrible, and conceptually big details like "this is a function" is hidden in very subtle syntax (a single colon). The liberal use of semicolons and the use of space-separated lists is another concession to looking like a config file. I feel Nix would have been better if it didn't try to cater to older conventions in this way. Sometimes the old ways are just bad. Incidentally, one of the big advantages of Guix (a Nix fork/derivative) is that it uses Scheme as its declaration/configuration language.

I switched to Nix some years ago on my desktop system. While I was initially quite frustrated at lots of the paper cuts - particularly the byzantine design of Nixpkgs itself which is built around manual programming with fixed-point combinators - I was carried through by two things:

1) I was intellectually convinced that the basic premise was sound.

2) Getting a basic desktop system running doesn't require you to understand all the complexity. NixOS works really well out of the box with its standard settings, and making basic configuration changes and adding/removing packages doesn't require you to know anything about the Nix language or the design of Nixpkgs.

Not much later I was able to do pretty radical things like changing the version of LLVM used by Mesa on my system, to work around a defect in AMDs GPU drivers[0]. I have no idea how I would do something like that on Debian. Even better, when this workaround later became unnecessary, I just removed the pertinent parts from my configuration file, and it was like it was never there. My system is fully declarative and not soiled by the remnants of previous hacks.

[0]: https://github.com/athas/dotfiles/blob/d495aeb85fe38569eb212...