5 ms·

Honestly, I have to say I'm in two minds about NixOS. Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused

Honestly, I have to say I'm in two minds about NixOS. Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity. Its a bit like messing around with the buzz-word-of-the-day Kubernetes compared to just getting the job done with a good old fashioned VM. Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS. Also, sometimes its nice to have the warm fuzzy feeling of using a software vendor's supported package build on a supported OS (e.g I'd rather run a package from the official Postgres repo then mess around getting Postgres working on NixOS).

jaemoe 6y ago
Yup! I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them). As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.
- ris 6y ago
  It's a shame to me how docker has come to be seen as "the usual software", as it's really just another layer of duck tape which uses OS features to pretend that arbitrary build processes are "reproducible" (when actually the way most Dockerfiles are written, they are most certainly not). As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.
  - throwaway894345 6y ago
    Docker’s build process sucks, but that’s not the point of Docker—the point is that it’s a standard image format for containers which allows for orchestrators like Kubernetes to exist without caring about the internal details of any given container (e.g., what language it uses). It does pretty well in that regard, and you can even use Nix to build Docker images. Nix’s value proposition is reproducible builds, and while it does reproducibly build software, writing those definitions is incredibly hard (though the difficulty varies widely from package to package).
    - ris 6y ago
      No, I absolutely acknowledge the value of a "docker image" as, essentially, an interchange format. But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.
      - throwaway894345 6y ago
        Unfortunately today there aren’t many better options. Building images with Nix is great in theory (as Nix in general is great in theory), but it implies packaging one’s own app with Nix which is an enormous burden in most cases. There are other projects emerging that give us better image build systems than Docker, but none are well-tested at this point such that their tradeoffs are understood. This is a real pain point in the ecosystem, and it will be interesting to see how it resolves.
        ris 6y ago
        > packaging one’s own app with Nix which is an enormous burden in most cases I have not found this at all tbh.
        throwaway894345 6y ago
        I’ve tried this personally, and we attempted it as a team professionally and in both cases the juice was deemed not worth the squeeze. In particular, we were constantly packaging low-level transitive dependencies for C projects, and ultimately you had to not only know how to build your own package, but also any package for your entire dependency tree. If your dependency tree doesn’t involve any C dependencies (or if Nix definitions already exist for them) then you probably won’t run into so many issues (which is likely to be the case for Go, Haskell, etc—languages that don’t have a heavy emphasis on C dependencies and probably those that can be statically linked) but for Python, Node, etc you will probably have problems. None of this is to speak about the dearth of documentation or the difficulty using nixpkgs as a reference.
        6y ago
swinglock 6y ago
> 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.
diggan 6y ago
I'm running NixOS in a VM, trying to evaluate if it's worth switching from Arch to NixOS before making the leap. > possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components. What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work. With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up. Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.
- jaemoe 6y ago
  I too was using Arch before and a friend convinced me to do the leap and I don't really regret it. One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.
  - eepp 6y ago
    how do you break Arch so bad these days? last major issue I had was when everything moved from /bin to /usr/bin.
    - jaemoe 6y ago
      The issue wasn't the system broke, in fact, my system was doing pretty much alright. The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions. I was tired of tinkering to get everything to work as I wanted.
exo762 6y ago
> failures caused by adding the extra layer of abstraction and complexity I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.

jaemoe 6y ago

Yup! I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them). As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.

ris 6y ago
It's a shame to me how docker has come to be seen as "the usual software", as it's really just another layer of duck tape which uses OS features to pretend that arbitrary build processes are "reproducible" (when actually the way most Dockerfiles are written, they are most certainly not). As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.
- throwaway894345 6y ago
  Docker’s build process sucks, but that’s not the point of Docker—the point is that it’s a standard image format for containers which allows for orchestrators like Kubernetes to exist without caring about the internal details of any given container (e.g., what language it uses). It does pretty well in that regard, and you can even use Nix to build Docker images. Nix’s value proposition is reproducible builds, and while it does reproducibly build software, writing those definitions is incredibly hard (though the difficulty varies widely from package to package).
  - ris 6y ago
    No, I absolutely acknowledge the value of a "docker image" as, essentially, an interchange format. But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.
    - throwaway894345 6y ago
      Unfortunately today there aren’t many better options. Building images with Nix is great in theory (as Nix in general is great in theory), but it implies packaging one’s own app with Nix which is an enormous burden in most cases. There are other projects emerging that give us better image build systems than Docker, but none are well-tested at this point such that their tradeoffs are understood. This is a real pain point in the ecosystem, and it will be interesting to see how it resolves.
      - ris 6y ago
        > packaging one’s own app with Nix which is an enormous burden in most cases I have not found this at all tbh.
        throwaway894345 6y ago
        I’ve tried this personally, and we attempted it as a team professionally and in both cases the juice was deemed not worth the squeeze. In particular, we were constantly packaging low-level transitive dependencies for C projects, and ultimately you had to not only know how to build your own package, but also any package for your entire dependency tree. If your dependency tree doesn’t involve any C dependencies (or if Nix definitions already exist for them) then you probably won’t run into so many issues (which is likely to be the case for Go, Haskell, etc—languages that don’t have a heavy emphasis on C dependencies and probably those that can be statically linked) but for Python, Node, etc you will probably have problems. None of this is to speak about the dearth of documentation or the difficulty using nixpkgs as a reference.
        6y ago

swinglock 6y ago

> 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.

diggan 6y ago

I'm running NixOS in a VM, trying to evaluate if it's worth switching from Arch to NixOS before making the leap. > possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components. What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work. With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up. Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.

jaemoe 6y ago
I too was using Arch before and a friend convinced me to do the leap and I don't really regret it. One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.
- eepp 6y ago
  how do you break Arch so bad these days? last major issue I had was when everything moved from /bin to /usr/bin.
  - jaemoe 6y ago
    The issue wasn't the system broke, in fact, my system was doing pretty much alright. The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions. I was tired of tinkering to get everything to work as I wanted.

exo762 6y ago

> failures caused by adding the extra layer of abstraction and complexity I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.