While indeed written a while ago, I found the article well-written and bringing up reasonable points.
- The installer apparently needs more than 1.25 GB of RAM. That seems surprising, I wonder if we could improve that.
- bitlbee-mastodon has since been packaged in nixpkgs, weeslack hasn’t. It’s unfortunate they ran into problems trying to package things, but hard to learn from without more details.
- The issue that example from the nix manual doesn’t actually work is still open, might be worth a look.
- The manual conflates ‘just packaging’ and ‘packaging for contributing to nixpkgs’. I think it might actually be good to focus on the ‘nixpkgs’ scenario, as it’s easy to use a fork of the nixpkgs, and packaging like that provides a nice smooth path into eventually actually contributing your packages.
-
nix-shelldocumentation: I agree we can do better there (I think things have improved somewhat but could improve more). - “
nix-shellpolluting the working directory and carrying state between build attempts” sounds weird, not sure what was going on there.
The author closes with 2 issues they expected to have, but acknowledges that since they didn’t get seriously into using NixOS this is mostly speculation. It’s still interesting to look at those issues because they say something about first impressions (perhaps even before people try NixOS).
- nixpkgs derivations generating configuration files: nixpkgs puts a ‘layer’ between the way you configure your system and the actual configuration files - for example, to configure grub you now potentially have to learn both the nixpkgs-level options, the actual grub configuration format, and how those fit together. I was also concerned about this when I first read about NixOS, but in practice it has never been a problem for me.
- The Nix language being a custom DSL. While it’s true that this causes additional work and things like debugging and tool support are not great, it seems to work out well. Using a general-purpose language would have advantages, but also disadvantages.