4 ms·

We were running nix in production and it was an absolute mess While the language is declarative your configuration is scattered, debuggers are absent, and you'

• ris 3y ago
  > you're ultimately interacting with a a layer on top of what the original package was designed to do This is fundamentally necessary, because the "original package" (for some value of "package") doesn't care about anything else on the system apart from getting itself running using whatever arbitrary configuration scheme / fs layout / daemon management happens to please the upstream author.
• rgoulter 3y ago
  > While the language is declarative your configuration is scattered... I think it's worth being more precise here. With a NixOS system, the configuration and services can all be declared from a single starting point. (Which is a benefit you'd get from NixOS, or maybe Ansible). With NixOS' modules, the options used to configure services can be set from any nix file, which may be annoying (but IME is more likely to be a help than a hindrance). The actual configuration files used by running services will be in some not-obvious-to-find directory. > ...you're ultimately interacting with a a layer on top of what the original package was designed to do. This makes it hard to figure the system out, how to debug, and occasionally support... Yeah; when something doesn't go well with Nix / NixOS, you may need to understand any/all of what the Nix code is doing, what the package/service you're describing is trying to do, and how it runs in Linux.