> Not that: enterprises and other businesses know someone will handle their problems now and later with Red Hat, SUSE, and Ubuntu. Is there assurance of that for Nix?
No. For this reason alone nothing big is about to happen. Some consulting shops might prescribe this, or may just use it internally. Other places I know its in deployment they have an employee whose a power user or contributor who probably evangelized it in the first place.
> So the whole distro is separate from Linux itself in terms that it could work on a BSD or Windows just replacing some OS-specific modules?
I am much more familiar with nixpkgs (the packages themselves, suitable for single-user install on top of some distro) proper, but let me take a shot. Nix is like a way better version or puppet/ansible/etc in that virtually all the work is done not in nix but in the nix expression themselves. This is true for both nixpkgs and nixos. The most interesting thing that Nix does is the sandboxing, and must of that I think could be done as support code in the nix expression language except then it would be easier to subvert.
They way nixos is structed (topological sort on deps is)
The purpose of the module system is the key to understanding nixos vs nixpkgs. Nixpkgs is just software to build: you can build as much as you want, as many versions of a thing as you want (nix doesn't even disambiguate between 2 packages vs 2 versions of the same package). Since it's just building software, there is no services or long running software or state really, other than nix itself.
Now that's all great, but a distro inevitably involves more state / finite resources. Only one process gets to be PID 1, only so many port files, etc. Nix doesn't want to deal with all this itself, so it largely just spits out /etc files. In rarer cases there are deliberately impure "packages" that may run some commands to set up something (e.g. the "package" that builds /etc itself.)
The module system allows one to write configuration modules (duh!) that (a) declare a few options (b) do a few things based on those options. Those "things" include delegating to other modules. Now the key point is the config options are safely combined so that syntactically conflicting configuration is caught -- we have conceptually a "partial monoid" of configurations. e.g. `{ a = [ "b" ]; }` (+) `{ a = [ "c" ]; }` => `{ a = [ "b" "c" ]; }`, `{ a = "foo"; }` (+) `{ a = "bar"; }` => error. This means one can use config itself to model finite resources (modules can also assert on config so one can e.g. ensure list is a set).
Because nixpkgs is one ginormous repo, its very easy to refactor and add abstractions. So on any system that Nix will one, one can just add more layer to bluntly abstract over non-portabilities. Not exactly glamorous, but it works. And people do use nixpkgs on FreeBSD and illumos at atleast, so I am sure it runs there. [Few users + our shitty CI practices means that is prone to bitrot, cygwin once worked years ago IIUC]. I don't know if Nix knows about jails or zones yet, but there is plain chroot "sandboxing", or even none at all, for more portability.
> Good to know it's not dependent on systemd, though, for uptake reasons.
For example, there was some talk about smudging the nixpkgs--nixos divide so that single-user-install nix users on MacOS could use the module system to define services. That would naturally involve abstracting over init as no systemd on Darwin!
> "mechanisms from policy"
Ah, that was the phrase I was forgetting :)
> Btw, are you a NixOS developer or did "we" mean something else?
The "we" is really just group membership psychology at work :). I don't have repo privileges or anything but contribute odds and ends. Currently working on better cross-compiling abstractions in nixpkgs ...because is anything ever designed with cross-compiling in mind from day one?!
No. For this reason alone nothing big is about to happen. Some consulting shops might prescribe this, or may just use it internally. Other places I know its in deployment they have an employee whose a power user or contributor who probably evangelized it in the first place.
> So the whole distro is separate from Linux itself in terms that it could work on a BSD or Windows just replacing some OS-specific modules?
I am much more familiar with nixpkgs (the packages themselves, suitable for single-user install on top of some distro) proper, but let me take a shot. Nix is like a way better version or puppet/ansible/etc in that virtually all the work is done not in nix but in the nix expression themselves. This is true for both nixpkgs and nixos. The most interesting thing that Nix does is the sandboxing, and must of that I think could be done as support code in the nix expression language except then it would be easier to subvert.
They way nixos is structed (topological sort on deps is)
1. library of mainly FP prelude functions and few fix-point combinators, https://github.com/NixOS/nixpkgs/tree/master/lib
2. Nixpkgs itself https://github.com/NixOS/nixpkgs/tree/master/pkgs
3. NixOS module system: maybe https://github.com/NixOS/nixpkgs/blob/master/lib/modules.nix ?
4. NixOS itself https://github.com/NixOS/nixpkgs/tree/master/nixos
The purpose of the module system is the key to understanding nixos vs nixpkgs. Nixpkgs is just software to build: you can build as much as you want, as many versions of a thing as you want (nix doesn't even disambiguate between 2 packages vs 2 versions of the same package). Since it's just building software, there is no services or long running software or state really, other than nix itself.
Now that's all great, but a distro inevitably involves more state / finite resources. Only one process gets to be PID 1, only so many port files, etc. Nix doesn't want to deal with all this itself, so it largely just spits out /etc files. In rarer cases there are deliberately impure "packages" that may run some commands to set up something (e.g. the "package" that builds /etc itself.)
The module system allows one to write configuration modules (duh!) that (a) declare a few options (b) do a few things based on those options. Those "things" include delegating to other modules. Now the key point is the config options are safely combined so that syntactically conflicting configuration is caught -- we have conceptually a "partial monoid" of configurations. e.g. `{ a = [ "b" ]; }` (+) `{ a = [ "c" ]; }` => `{ a = [ "b" "c" ]; }`, `{ a = "foo"; }` (+) `{ a = "bar"; }` => error. This means one can use config itself to model finite resources (modules can also assert on config so one can e.g. ensure list is a set).
Because nixpkgs is one ginormous repo, its very easy to refactor and add abstractions. So on any system that Nix will one, one can just add more layer to bluntly abstract over non-portabilities. Not exactly glamorous, but it works. And people do use nixpkgs on FreeBSD and illumos at atleast, so I am sure it runs there. [Few users + our shitty CI practices means that is prone to bitrot, cygwin once worked years ago IIUC]. I don't know if Nix knows about jails or zones yet, but there is plain chroot "sandboxing", or even none at all, for more portability.
> There a link describing that in more detail?
I'm not sure what's best for NixOS (the above is my own memory from spending enough time on IRC, etc), but http://lethalman.blogspot.com/2014/07/nix-pill-1-why-you-sho... is a great blog series introducing nix itself.
> Good to know it's not dependent on systemd, though, for uptake reasons.
For example, there was some talk about smudging the nixpkgs--nixos divide so that single-user-install nix users on MacOS could use the module system to define services. That would naturally involve abstracting over init as no systemd on Darwin!
> "mechanisms from policy"
Ah, that was the phrase I was forgetting :)
> Btw, are you a NixOS developer or did "we" mean something else?
The "we" is really just group membership psychology at work :). I don't have repo privileges or anything but contribute odds and ends. Currently working on better cross-compiling abstractions in nixpkgs ...because is anything ever designed with cross-compiling in mind from day one?!