nixpkgs

).

ckage manager ecosystems, e.g. cabal/hackage for Haskell packages. Results are cached locally (packages are only built once, until they get garbage collected) and remotely (if a build server has already built a package, you can fetch it from there instead). For development environments, you can write a Nix package for your project then run the 'nix-shell' command to enter its build environment (i.e. all dependencies available, environment variables set, etc.)

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?!

rbage`) are very nice additions. Apart from these features, the fact that it doesn't chown `/usr/local/` to my user is a big plus. Nix will also not linking anything not explicitly installed by user to their profile (e.g. if package A has B as dependency, B won't be linked until user actually choose to install it, which is then managed separately from B that were explicitly installed as A's dependency). That said, I've since revert back to Homebrew because there are few packages broken that are crucial to what I'm working on. Creating and fixing package is not too hard (I did with aria2c), although time didn't allow me to do it back then. I would love to try to switch to Nix again sometimes. People in ##nix-darwin are super-nice, also! :-) [1]: https://github.com/NixOS/nixpkgs/pull/15029 [2]: https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell...