4 ms·

Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization

Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!

seniorivn 5y ago
most people who have claim to be unix experts and cannot grasp nix are usually just don't like functional languages those who do, say that it's a great idea, but implementation is a bit hacky and not well documented
- temptemptemp111 5y ago
  The first sentence is false - unless we cannot find anyone who both likes functional languages and does not like NixOS... Which is quite easy to do. Then you say the only reason they could state for not liking it is the "hacky implementation" and bad documentation. Sure...
kohlerm 5y ago
One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
- temptemptemp111 5y ago
  You say Docker is overkill when scratch images are extremely minimal - and you're comparing using containers to rewriting the entire host OS (which isn't even done yet in NixOS case)? Overkill is rewriting the host OS continually until everyone who was previously familiar with it has no clue how to use it anymore. That is just hiding complexity, it isn't simplifying it. A package manager in a good distro can install / maintain "different compilers." You can use Debian to create Docker images in a reproducible way too. NixOS isn't more reproducible or especially reproducible when compared to a distro that has also accomplished reproducibility... It merely mixes up config management code down to the bottom of your OS, thus requiring an OS/distro rewrite (which still isn't close to being done). It is shifting complexity from one place to another, like Oobleck in Dr. Seuss. You can also do OS imaging & snapshots in a distro-independent way using Darch, and then boot from those images in your bootloader. No need for NixOS there either; so what does this solve other than a massive bikeshedding project when engineers should be focusing on what is useful?
chriswarbo 5y ago
> Docker, lxc, VMs, and now NixOS? NixOS came out in 2003. For context, that's when Xen came out. LXC came out in 2008; KVM (Linux's built-in VM support) came out in 2007; Docker came out in 2014.
- temptemptemp111 5y ago
  I didn't mean they were chronological in their release. I meant that they are being pitched for the same use-cases. And overlapping use cases. For example, take the NixOS snapshot functionality vs the Darch + basically any distro snapshot functionality. One reinvents the OS unnecessarily to accomplish the same thing. Same for the rest of NixOS functionality... Like a configuration management project that didn't set constraints.
chriswarbo 5y ago
> How many containerization concepts do we need? Nix and NixOS aren't containers (or VMs, etc.). > If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. The basic concept of Nix is (a) use the `--prefix` argument of ./configure scripts to keep things apart, and (b) use the `PATH` end var to choose what we want to run. In comparison, containers are much more recent, require more invasive changes (i.e. support from the kernel), etc. Personally, I like using containers to run binaries. Putting a whole Linux/Busybox installation inside one seems to defeat the point though...
- temptemptemp111 5y ago
  Yes I realize this... People are using different words often when trying to accomplish the same thing and thus confusing themselves. For example, how many people are using configuration management like chef inside of Docker images? Too many, clearly! How much developer time is being burnt unnecessarily with NixOS? I just don't see what would count as engineering evidence that NixOS is simplifying complexity instead of hiding it.

seniorivn 5y ago

most people who have claim to be unix experts and cannot grasp nix are usually just don't like functional languages those who do, say that it's a great idea, but implementation is a bit hacky and not well documented

temptemptemp111 5y ago
The first sentence is false - unless we cannot find anyone who both likes functional languages and does not like NixOS... Which is quite easy to do. Then you say the only reason they could state for not liking it is the "hacky implementation" and bad documentation. Sure...

kohlerm 5y ago

One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.

temptemptemp111 5y ago
You say Docker is overkill when scratch images are extremely minimal - and you're comparing using containers to rewriting the entire host OS (which isn't even done yet in NixOS case)? Overkill is rewriting the host OS continually until everyone who was previously familiar with it has no clue how to use it anymore. That is just hiding complexity, it isn't simplifying it. A package manager in a good distro can install / maintain "different compilers." You can use Debian to create Docker images in a reproducible way too. NixOS isn't more reproducible or especially reproducible when compared to a distro that has also accomplished reproducibility... It merely mixes up config management code down to the bottom of your OS, thus requiring an OS/distro rewrite (which still isn't close to being done). It is shifting complexity from one place to another, like Oobleck in Dr. Seuss. You can also do OS imaging & snapshots in a distro-independent way using Darch, and then boot from those images in your bootloader. No need for NixOS there either; so what does this solve other than a massive bikeshedding project when engineers should be focusing on what is useful?

chriswarbo 5y ago

> Docker, lxc, VMs, and now NixOS? NixOS came out in 2003. For context, that's when Xen came out. LXC came out in 2008; KVM (Linux's built-in VM support) came out in 2007; Docker came out in 2014.

temptemptemp111 5y ago
I didn't mean they were chronological in their release. I meant that they are being pitched for the same use-cases. And overlapping use cases. For example, take the NixOS snapshot functionality vs the Darch + basically any distro snapshot functionality. One reinvents the OS unnecessarily to accomplish the same thing. Same for the rest of NixOS functionality... Like a configuration management project that didn't set constraints.

chriswarbo 5y ago

> How many containerization concepts do we need? Nix and NixOS aren't containers (or VMs, etc.). > If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. The basic concept of Nix is (a) use the `--prefix` argument of ./configure scripts to keep things apart, and (b) use the `PATH` end var to choose what we want to run. In comparison, containers are much more recent, require more invasive changes (i.e. support from the kernel), etc. Personally, I like using containers to run binaries. Putting a whole Linux/Busybox installation inside one seems to defeat the point though...

temptemptemp111 5y ago
Yes I realize this... People are using different words often when trying to accomplish the same thing and thus confusing themselves. For example, how many people are using configuration management like chef inside of Docker images? Too many, clearly! How much developer time is being burnt unnecessarily with NixOS? I just don't see what would count as engineering evidence that NixOS is simplifying complexity instead of hiding it.