I wouldn’t call it coding. It’s more about writing configurations. You have to provide a list of packages you need and some configuration for them like configuring default desktop environment. I recommend searching for dotfiles repos with configuration.nix on github to get an idea.

As someone elase said, it’s not really coding but more like writing a configuration. If you need an example (I’m using AMD so there will be some changes required) you can check out my own config at https://gitlab.com/theshatterstone/nix-conf

Edit: Also, the note on shebangs applies to all scripts within NixOS.

nvidia-open-dkms usually doesn’t break when updating.

Daily use isn’t difficult IME. NixOS is just so nice once it’s working. It’s ridiculously easy to understand your system & how it’s set up (it’s all in your config). Nothing changes between updates that you don’t know about. You never have to merge configurations from upstream. It’s trivial to try something new without changing your system overall. Rollbacks are amazing. It’s easy to configure a new machine, to keep multiple machines synchronized (same packages & versions & even users & dotfiles). I have automatic updates enabled so I get a new system when I reboot, and if I don’t like an update I can just revert seamlessly. It basically works like an appliance: I don’t have to think about the way it’s set up unless I disagree with the defaults, and in that case I can change them. You can always override things, even down to applying patches to source code (though obviously that then requires re-compiling). It’s like if you took the stability of Debian, the up-to-date nature and huge repo of Arch & the AUR, and the configurability of Gentoo and mashed them all together.

The hard bits are packaging new programs and making “modules”. You can pretty much always configure a program by just writing the config file options in a Nix string block, e.g. I’ve got the following in my home-manager config for my ~/.xkbrc:

  home.file.".config/kxkbrc" = {
    text = ''
      [$Version]
      update_info=kxkb_variants.upd:split-variants

      [Layout]
      DisplayNames=
      LayoutList=us
      LayoutLoopCount=-1
      Model=pc86
      Options=terminate:ctrl_alt_bksp,compose:rctrl
      ResetOldOptions=true
      SwitchMode=Global
      Use=true
      VariantList=colemak
    '';
  };

Modules would let that be a Nix expression, e.g. looking like

programs.xkeyboard = {
  layout = "us";
  variant = "colemak";
  model = "pc86";
  options = {
    terminate = "ctrl_alt_bksp";
    compose = "rctrl";
  };
  resetOldOptions = true;
};

but that requires writing an expression in Nix that converts the Nix syntax into whatever syntax the config file needs to be. That means learning a lot more Nix. Packaging programs also requires learning more Nix, and particularly how Nixpkgs builders work.

That said, the documentation is shitty, the error messages are shitty, Flakes are massively easier to work with but still “experimental” and lots of the docs & examples online are for pre-flakes, while nixpkgs is enormous it doesn’t have everything, and IDE support for Nix shell environments is lacking (have to use VS Code or a terminal-based editor like nvim).

Nix is sort of like democracy. Democracy is the worst form of government, except for all the others. Nix is the worst way to manage an OS, except for all the others. It’s shitty, but it’s shitty in different ways and those mostly end up making day-to-day operations easier.

guix pull && guix upgrade is still a bit slow, but I never thought excessively slow (definitely slower than xbps, pacman, and probably apt too).

I guess I never thought much about it because of rollbacks, so it’s safe enough to just cron.

GNU Shepherd! Written and configurable entirely in Guile Scheme, just like Guix itself.

Snapshots require btrfs though, don’t they?

As far as AUR is concerned, one should be fair. The things that are offered in AUR can be problematic in general. No matter if you use vanilla Arch or a distribution based on Arch. Because not everyone who offers something in the AUR cares about updates in a timely manner or at all.

There is definitely a reason why https://lists.archlinux.org/archives/list/[email protected]/ exists. Just as there is a reason why there is a general warning about the AUR (https://wiki.archlinux.org/title/Arch_User_Repository).

With Manjaro, I rather see the problem that the team responsible for it apparently does not learn from its mistakes, so that, for example, the SSL certificate of the website has not been renewed several times (https://web.archive.org/web/20230706060943/https://manjarno.snorlax.sh/). That may not be a big problem in itself, but if even such little things go wrong, then I personally cannot trust an entire distribution.

Not sure what constitutes a lot, but definitely had AUR software. Generally only for things that were not otherwise available