5 ms·

> Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Hav

> Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Having used NixOS for more than a week, I have the same but opposite feeling. If you don't mind the hyperbole, NixOS is a solution, Salt and similar as a substitute is duct tape. :)

jsjohnst 6y ago
Salt/Chef/Puppet/Ansible/etc are generally “good enough” tools and work for many needs, but over time cruft will inevitably happen (unless you frequently start from a clean base image). NixOS tries to avoid that by making it difficult to accidentally do a one-off outside your tooling and/or install things that unintentionally (or intentionally) stomp on other installed things in your system.
- ris 6y ago
  Having worked with these tools, in comparison Salt/Chef/Puppet/Ansible are a collection of footcannons wrapped in the guise of a solution. The entire idea of trying to manage a fleet of stateful OS installations and stay on top of it all once it gains the slightest hint of complexity is a fallacy.
- kohlerm 6y ago
  I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git. Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.
  - jsjohnst 6y ago
    > Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments. I agree, but your and my definition of “good enough” is not the same as everyone else’s. These tools wouldn’t be as heavily used if folks didn’t feel they solved a problem they had.
    - kohlerm 6y ago
      They used to solve some problems in a way that was good enough at that time. Nowadays setting up services, where you have to take care of avoiding port conflicts, is much easier with container technology. Modifying config files in the users directory is in my experience a pain because chef was not designed to do that. You have to do all kind of workarounds to get permissions right. Just using Chef for abstracting from which package manager you use also does not fully work because package names can be different between Linux flavors. Chef also requires a ruby installation, which itself is a problematic large dependency which might conflict with another ruby version on the system. Update: trying to install the same package in different versions at the same time is also a pain.

jsjohnst 6y ago

Salt/Chef/Puppet/Ansible/etc are generally “good enough” tools and work for many needs, but over time cruft will inevitably happen (unless you frequently start from a clean base image). NixOS tries to avoid that by making it difficult to accidentally do a one-off outside your tooling and/or install things that unintentionally (or intentionally) stomp on other installed things in your system.

ris 6y ago
Having worked with these tools, in comparison Salt/Chef/Puppet/Ansible are a collection of footcannons wrapped in the guise of a solution. The entire idea of trying to manage a fleet of stateful OS installations and stay on top of it all once it gains the slightest hint of complexity is a fallacy.
kohlerm 6y ago
I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git. Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.
- jsjohnst 6y ago
  > Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments. I agree, but your and my definition of “good enough” is not the same as everyone else’s. These tools wouldn’t be as heavily used if folks didn’t feel they solved a problem they had.
  - kohlerm 6y ago
    They used to solve some problems in a way that was good enough at that time. Nowadays setting up services, where you have to take care of avoiding port conflicts, is much easier with container technology. Modifying config files in the users directory is in my experience a pain because chef was not designed to do that. You have to do all kind of workarounds to get permissions right. Just using Chef for abstracting from which package manager you use also does not fully work because package names can be different between Linux flavors. Chef also requires a ruby installation, which itself is a problematic large dependency which might conflict with another ruby version on the system. Update: trying to install the same package in different versions at the same time is also a pain.