10 ms·

Purely Functional Linux with NixOS [video]

169 points by begriffs 10y ago

awqrre 10y ago
In a CAD world, that would be like parametric drafting?
- Ericson2314 10y ago
  I'm going to take a wild guess: yes :)
- SSLy 10y ago
  Yeah, more or less.
- agumonkey 10y ago
  does that imply live/realtime recomputing ?
sdegutis 10y ago
> where multiple versions of the same library or application can live in harmony How does NixOS solve the diamond dependency problem?
- geofft 10y ago
  I think in practice, I have far less trouble with the actual diamond dependency problem - binary A requires libraries B and C, which depend on two different versions of D - than the boring version - system A runs binaries B and C, which depend on two different versions of D. NixOS solves the latter.
- corysama 10y ago
  If you are asking about a single application depending on conflicting libraries such that it can't be built at all, I don't think NixOS can solve that. What it can do is have multiple conflicting libraries installed simultaneously and individual applications can choose which completely-defined environment they want to run in.
- smallnamespace 10y ago
  It's largely mitigated by allowing multiple versions. Imagine A depends on B and C, which both depend on D. The diamond dependency usually pops up when B and C need different versions of D. But in this case, Nix allows you to simply install another version of B or C such that they can share D. This doesn't help you if there's no set of A ... D that are jointly consistent, but then you would've been SOL anyway.
- ambrop7 10y ago
  Normally you end up only a single version of a library needed in the scope of one application. E.g. application A depends on libraries B and C and both of these depend on the same version of library D. And there is no problem as long as this is the case, the exact same library will be used. If for some reason B and C depend on different versions of a library, then things may go wrong, e.g. one package may end up inadvertently using an incorrect version of a dependency. Nix cannot solve this problem because it originates from the OS/compiler design (same sonames, same symbol names). Consider that with respect to libraries, Nix mostly just wraps the compiler to add needed -L flags and also sets RPATH in shared libs and executables so that needed shared libs are found at runtime. If an application effectively depends on different versions of one library with the same soname, the dynamic linker will still use just one of the available ones. What Nix does allow you to do is to isolate packages from one another. You can have one application using only one version of library D, and another application using only a different version of library D. I should note that it's somehow hard to get to this situation, because the Nix packages collection (nixpkgs) doesn't keep too many versions of packages. Typically for minor upgrades the library is just bumped, and when you rebuild the final application all references to that library will be up to date. You can only realistically get issues if the application ends up depending on different major versions which are both maintained in nixpkgs but are not designed to work together in the same application.
  - nine_k 10y ago
    I suspect that the same binary cannot realistically depend on two different versions of a library. I can imagine that package A may have two binaries, one depending on a library B version 1.1, and another, on B 1.2 Does NixOS allow to have both B-1.1 and B-1.2 installed, and A's different binaries to load the correct different versions of the library from B-1.1 and B-1.2?
    - ambrop7 10y ago
      Well yes strictly speaking, the same binary. But in practice with Nix's default library resolution logic (the mentioned compiler wrapping) you will probably also have problems trying to build binaries in one package using version of a library (see note [1]). That is, I think you'd have to do some "hacking" to fix the issue, or separate the binaries into different packages (and maybe create a new package that "assembles" all the binaries by creating symlinks to them). > Does NixOS allow to have both B-1.1 and B-1.2 installed, and A's different binaries to load the correct different versions of the library from B-1.1 and B-1.2? Yes, well actually, the thing is that typically you only "install" (into a user environment) final applications (A) that you need not libraries, so the libraries (B) can be considered to not really be installed, just available (somewhere in /nix/store) and referenced correctly (e.g. by RPATH). [1] When you declare a dependency in a package specification by putting it into buildInputs, the compiler wrapper will automatically add an -L<store_path>/lib so that linking with just -l will find the library. With multiple versions of a library in buildInputs, that becomes a problem.
themartorana 10y ago
Anyone using NixOS as a server in production? We're on FreeBSD now but I think Linux in our stack is inevitable (many servers, like Aerospike, are Linux only). There's always Ubuntu, but this looks lovely. I've had my eye on it for a personal Linux workstation but haven't heard anything about it as a server.
- teh 10y ago
  We run a fleet. Happy to answer questions here or shoot us a mail at team@wearewizards.io if it's sensitive.
  - tikhonj 10y ago
    Do you have a blog post about it or something? I don't have specific questions, I'd just love to see how Nix looks in production.
    - teh 10y ago
      No high level overview, just a fairly specific (and sadly slightly out of date) one here: https://blog.wearewizards.io/how-to-use-nixops-in-a-team https://blog.wearewizards.io/how-to-use-nixops-in-a-team It's still Linux but a lot of common problems go away. E.g. if you remove a user from your config then it's removed on the server (as opposed to Ansible). Or: Because you have a dependency DAG all services that need restarting after a change are known (no more Chef notifies :restart). Or: No more apt-get dist-upgrade. You can have a single package depend on an entirely new version of your OS and keep the old OS in place (except for the kernel version of course).
  - viraptor 10y ago
    How's the binary security on NixOS these days? The official information I find are... worrying. Specifically: a) security updates are the same as all the other updates and may take days to get to you, do runtime replacements manually yourself (https://nixos.org/wiki/Security_Updates https://nixos.org/wiki/Security_Updates) and b) next to no hardening during compilation (https://nixos.org/wiki/Hardened_NixOS https://nixos.org/wiki/Hardened_NixOS)
paxcoder 10y ago
GNU/Linux distribution with revertible package management. EDIT: I believe that my description is more accurate and if I am wrong I would like to be corrected. But I'd appreciate if you didn't downvote me simply because I use the term "GNU/Linux". I don't downvote you if you use the kernel's name for the entire OS. Thanks.
davexunit 10y ago
See also GNU Guix. https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/
- inquisitiveio 10y ago
  Which is also worth mentioning, builds part of its package management on top of nix https://www.gnu.org/software/guix/about/ https://www.gnu.org/software/guix/about/
- paxcoder 10y ago
  Would be nice if someone could update the previous NixOS vs GuixSD discussion: https://news.ycombinator.com/item?id=8246338 https://news.ycombinator.com/item?id=8246338
- wanda 10y ago
  In a similar vein is Intel's Clear Linux[0] https://clearlinux.org/ https://clearlinux.org/
  - codemac 10y ago
    Clear Linux is much more focused on the "containers as VMs" direction than nix or guix are (Use the $PATH instead of containers, no virtualization of network cards etc).
k__ 10y ago
I think NixOS is the future, but there needs to be more time put into UX. Distros like Ubuntu are still much easier to get running and this scares many people away :/
- zzzcpan 10y ago
  And it's unusable on small VMs, it takes like almost a gig of ram to install something and lots of time to figure out how to edit some config if it doesn't have an option for your needs. So, yeah, if they want users - they need to work on that.
  - SwellJoe 10y ago
    That's interesting, and not something I'd noticed (I have a 2GB NixOS VM for tinkering with it). That makes NixOS far less attractive for the things I was think it would be a natural for: containers. Because containers need to be reproducible, and because the current crop of container management and deployment tools are really messy, NixOS seems like a natural fit for building containers (maybe for hosting them, too, eventually). But, if it's not possible to custom build tiny containers on demand without needing a ton of memory, the power of it becomes less fun. I'm visualizing a system whereby you spin up custom environments based on need (with exactly and only the packages and config you need for the specific task, at hand), on demand, in a distributed environment. That'd be harder if the resources to spin up are very high. apt and yum both can consume a lot of memory when installing large lists of packages, but 1GB is pretty far out, and you can work around it by installing a small number of packages at a time. Which slows it down, but allows installation to work on even very small systems (like 128MB, or even smaller, if you've got a little swap).
    - chriswarbo 10y ago
      > NixOS seems like a natural fit for building containers (maybe for hosting them, too, eventually) NixOS has support for hosting containers, which share the Nix store with the host, so they're presumably pretty lightweight. I've tried running NixOS in VMs, using Nix on Ubuntu, orchestrating things with NixOps, etc. and found that it's much more painful than just installing NixOS on the bare metal and managing everything via /etc/nixos/configuration.nix
corysama 10y ago
My Linux experience so far has been limited to ls, cd and vi. From the outside, package management has always seemed to me like a huge mess. But, I've been starting to learn Nix recently and I really like it. I can add, remove, test, screw up, change my mind, whatever without stress.
- SwellJoe 10y ago
  "From the outside, package management has always seemed to me like a huge mess." Compared to what?! There's no OS that has historically had better (or even close to as good) package management as Linux, either in the form of apt-get/dpkg or yum/RPM. Nix is probably better, on a couple of dimensions, but to suggest it was a mess before...well, I just wonder what you could be comparing to that would be better?
  - Artlav 10y ago
    Perhaps it's about expecting to have program locality? I.e. you download a zip file, you unpack it into a directory, and here is your entire program. Right there, in that directory, not splattered around the filesystem by the package manager. That's the way it's done on Windows, anyway.
    - johncolanduoni 10y ago
      Perhaps for the newer Windows platforms (e.g. UWP) but Win32 installers have definitely been known to put things all over your system.
      - Artlav 10y ago
        Yeah, that's the reason why i have a "got installer? not worth using" pre-filter for Windows software. Not sure how things are these days, but i'm talking about the Win 9x to Win 7 days.
        yiyus 10y ago
qwertyuiop924 10y ago
Am I the only one who thought Guix did this better? Maybe it's just my freakish and unnatural love of parenthesis. Or my hatred of learning new configuration syntaxes (I just want to install packges, dammit! Yes, I enjoy learning new languages, but I need to get this machine up and running, and I don't want to learn your new programming language to do that)
- sorpaas 10y ago
  What I really worry about is my nonfree wireless driver and Nvidia driver, which doesn't seem to be available on Guix.
  - Slackwise 10y ago
    Well, you can specify extra packages using $GUIX_PACKAGE_PATH, and I've seen a few custom repos, such as this: https://github.com/genenetwork/guix-bioinformatics https://github.com/genenetwork/guix-bioinformatics and https://github.com/Ecogenomics/ace-guix https://github.com/Ecogenomics/ace-guix I'm not sure how easy it is to maintain a system with extra packages like this, but it'd be nice to be able to use an "overlay" repo as you can in Gentoo for personal/custom packages. Would love to ping davexunit to see if he can elaborate, because I don't see any specific way to add repositories from the documentation.
    - davexunit 10y ago
      There's no such thing as a repository in Guix. Using GUIX_PACKAGE_PATH is the closest thing, conceptually.
      - Slackwise 10y ago
        Ahh, well, then it appears I have to manage a directory of packages myself, as well as any dependencies outside of the Guix store, right? Would be nice to just have a secondary source, as I do with MELPA for Emacs, or overlays for Gentoo. Is something similar/comparable planned to be added? Orrr should someone step forward and volunteer to add it as a feature...?
fizzbatter 10y ago
I love the idea of NixOS, but overall i think i need to wait for it to be a bit more user friendly. The number of times i was completely perplexed when i tried to use this as my home server was.. well, numerous. Awesome idea, and the rollbacks were great, but i kept having to write my own packages and it was all a bit too confusing to do that constantly.
qwerty12653 10y ago
I really want to like NixOS, but there's a serious lack of examples of how to deploy common web infrastructure with it, and that's bitten me the few times I've tried to play with it. For example, our stack is nginx, uwsgi, django, elasticsearch, and postgres. Installing most of the pieces seemed relatively straightforward(though required a fair bit of searching through the nixpkgs source), but it's honestly pretty unclear how to install our actual django app. Currently we just clone the repo to the server and point uwsgi to the relevant uwsgi.py file, but it doesn't seem like there's a good way to do that in NixOS. I'd love to hear that I'm wrong here, but again, the lack of decent example documentation is really the single biggest issue I have with NixOS. The rest of the documentation seems to be improving slowly but steadily.
- thinkmoore 10y ago
  You might be interested in checking out Habitat from Chef, which uses many similar ideas: habitat.sh
  - rokgarbas 10y ago
    as nixos user i looked at habitat and the thing that i will never switch to habitat is that environments are not (build) reproducible. basically habitat is more like docker where it snapshots "successful" build and you use that input for further building. what i loved about habitat is the supervisor part. i there is a way to use habitat's supervisor with nix. then you get best of both tools. until then i'll just have to stick to python's supervisord.
dominotw 10y ago
so could this replace docker as distribution format? cgroups and namespaces can be use independently of docker.
- benley 10y ago
  Not exactly ... but you can certainly use Nix to build docker images, which is very convenient.
transfire 10y ago
It's very cool what Nix has managed to accomplish. Unfortunately, after studying it I've started to think the solution is overwrought and might be more trouble than the problem is solves, or as I like to say, "with solutions like that who needs problems?" I think it boils down to these points from the summary: > Thus the same package can coexist on the system with multiple configurations. That we have to worry about multiple static compilations of a package hits a deeper problem that Nix can't fix. Namely that there really shouldn't be any need for static install configurations. So the only static differentiation that should be necessary is version. > The derivation is a string in key-value format which will ultimately be hashed and which can refer to objects in the Nix store So why create a whole new "expression" language just to generate these? Developers work with key-value formats all the time (e.g. YAML, JSON). The whole functional language thing seems almost like a slight of hand when you realize this is the end result.

169 points by begriffs 10y ago

awqrre 10y ago

In a CAD world, that would be like parametric drafting?

Ericson2314 10y ago
I'm going to take a wild guess: yes :)
SSLy 10y ago
Yeah, more or less.
agumonkey 10y ago
does that imply live/realtime recomputing ?

sdegutis 10y ago

> where multiple versions of the same library or application can live in harmony How does NixOS solve the diamond dependency problem?

geofft 10y ago
I think in practice, I have far less trouble with the actual diamond dependency problem - binary A requires libraries B and C, which depend on two different versions of D - than the boring version - system A runs binaries B and C, which depend on two different versions of D. NixOS solves the latter.
corysama 10y ago
If you are asking about a single application depending on conflicting libraries such that it can't be built at all, I don't think NixOS can solve that. What it can do is have multiple conflicting libraries installed simultaneously and individual applications can choose which completely-defined environment they want to run in.
smallnamespace 10y ago
It's largely mitigated by allowing multiple versions. Imagine A depends on B and C, which both depend on D. The diamond dependency usually pops up when B and C need different versions of D. But in this case, Nix allows you to simply install another version of B or C such that they can share D. This doesn't help you if there's no set of A ... D that are jointly consistent, but then you would've been SOL anyway.
ambrop7 10y ago
Normally you end up only a single version of a library needed in the scope of one application. E.g. application A depends on libraries B and C and both of these depend on the same version of library D. And there is no problem as long as this is the case, the exact same library will be used. If for some reason B and C depend on different versions of a library, then things may go wrong, e.g. one package may end up inadvertently using an incorrect version of a dependency. Nix cannot solve this problem because it originates from the OS/compiler design (same sonames, same symbol names). Consider that with respect to libraries, Nix mostly just wraps the compiler to add needed -L flags and also sets RPATH in shared libs and executables so that needed shared libs are found at runtime. If an application effectively depends on different versions of one library with the same soname, the dynamic linker will still use just one of the available ones. What Nix does allow you to do is to isolate packages from one another. You can have one application using only one version of library D, and another application using only a different version of library D. I should note that it's somehow hard to get to this situation, because the Nix packages collection (nixpkgs) doesn't keep too many versions of packages. Typically for minor upgrades the library is just bumped, and when you rebuild the final application all references to that library will be up to date. You can only realistically get issues if the application ends up depending on different major versions which are both maintained in nixpkgs but are not designed to work together in the same application.
- nine_k 10y ago
  I suspect that the same binary cannot realistically depend on two different versions of a library. I can imagine that package A may have two binaries, one depending on a library B version 1.1, and another, on B 1.2 Does NixOS allow to have both B-1.1 and B-1.2 installed, and A's different binaries to load the correct different versions of the library from B-1.1 and B-1.2?
  - ambrop7 10y ago
    Well yes strictly speaking, the same binary. But in practice with Nix's default library resolution logic (the mentioned compiler wrapping) you will probably also have problems trying to build binaries in one package using version of a library (see note [1]). That is, I think you'd have to do some "hacking" to fix the issue, or separate the binaries into different packages (and maybe create a new package that "assembles" all the binaries by creating symlinks to them). > Does NixOS allow to have both B-1.1 and B-1.2 installed, and A's different binaries to load the correct different versions of the library from B-1.1 and B-1.2? Yes, well actually, the thing is that typically you only "install" (into a user environment) final applications (A) that you need not libraries, so the libraries (B) can be considered to not really be installed, just available (somewhere in /nix/store) and referenced correctly (e.g. by RPATH). [1] When you declare a dependency in a package specification by putting it into buildInputs, the compiler wrapper will automatically add an -L<store_path>/lib so that linking with just -l will find the library. With multiple versions of a library in buildInputs, that becomes a problem.

themartorana 10y ago

Anyone using NixOS as a server in production? We're on FreeBSD now but I think Linux in our stack is inevitable (many servers, like Aerospike, are Linux only). There's always Ubuntu, but this looks lovely. I've had my eye on it for a personal Linux workstation but haven't heard anything about it as a server.

teh 10y ago
We run a fleet. Happy to answer questions here or shoot us a mail at team@wearewizards.io if it's sensitive.
- tikhonj 10y ago
  Do you have a blog post about it or something? I don't have specific questions, I'd just love to see how Nix looks in production.
  - teh 10y ago
    No high level overview, just a fairly specific (and sadly slightly out of date) one here: https://blog.wearewizards.io/how-to-use-nixops-in-a-team https://blog.wearewizards.io/how-to-use-nixops-in-a-team It's still Linux but a lot of common problems go away. E.g. if you remove a user from your config then it's removed on the server (as opposed to Ansible). Or: Because you have a dependency DAG all services that need restarting after a change are known (no more Chef notifies :restart). Or: No more apt-get dist-upgrade. You can have a single package depend on an entirely new version of your OS and keep the old OS in place (except for the kernel version of course).
- viraptor 10y ago
  How's the binary security on NixOS these days? The official information I find are... worrying. Specifically: a) security updates are the same as all the other updates and may take days to get to you, do runtime replacements manually yourself (https://nixos.org/wiki/Security_Updates https://nixos.org/wiki/Security_Updates) and b) next to no hardening during compilation (https://nixos.org/wiki/Hardened_NixOS https://nixos.org/wiki/Hardened_NixOS)

paxcoder 10y ago

GNU/Linux distribution with revertible package management. EDIT: I believe that my description is more accurate and if I am wrong I would like to be corrected. But I'd appreciate if you didn't downvote me simply because I use the term "GNU/Linux". I don't downvote you if you use the kernel's name for the entire OS. Thanks.

davexunit 10y ago

See also GNU Guix. https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/

inquisitiveio 10y ago
Which is also worth mentioning, builds part of its package management on top of nix https://www.gnu.org/software/guix/about/ https://www.gnu.org/software/guix/about/
paxcoder 10y ago
Would be nice if someone could update the previous NixOS vs GuixSD discussion: https://news.ycombinator.com/item?id=8246338 https://news.ycombinator.com/item?id=8246338
wanda 10y ago
In a similar vein is Intel's Clear Linux[0] https://clearlinux.org/ https://clearlinux.org/
- codemac 10y ago
  Clear Linux is much more focused on the "containers as VMs" direction than nix or guix are (Use the $PATH instead of containers, no virtualization of network cards etc).

k__ 10y ago

I think NixOS is the future, but there needs to be more time put into UX. Distros like Ubuntu are still much easier to get running and this scares many people away :/

zzzcpan 10y ago
And it's unusable on small VMs, it takes like almost a gig of ram to install something and lots of time to figure out how to edit some config if it doesn't have an option for your needs. So, yeah, if they want users - they need to work on that.
- SwellJoe 10y ago
  That's interesting, and not something I'd noticed (I have a 2GB NixOS VM for tinkering with it). That makes NixOS far less attractive for the things I was think it would be a natural for: containers. Because containers need to be reproducible, and because the current crop of container management and deployment tools are really messy, NixOS seems like a natural fit for building containers (maybe for hosting them, too, eventually). But, if it's not possible to custom build tiny containers on demand without needing a ton of memory, the power of it becomes less fun. I'm visualizing a system whereby you spin up custom environments based on need (with exactly and only the packages and config you need for the specific task, at hand), on demand, in a distributed environment. That'd be harder if the resources to spin up are very high. apt and yum both can consume a lot of memory when installing large lists of packages, but 1GB is pretty far out, and you can work around it by installing a small number of packages at a time. Which slows it down, but allows installation to work on even very small systems (like 128MB, or even smaller, if you've got a little swap).
  - chriswarbo 10y ago
    > NixOS seems like a natural fit for building containers (maybe for hosting them, too, eventually) NixOS has support for hosting containers, which share the Nix store with the host, so they're presumably pretty lightweight. I've tried running NixOS in VMs, using Nix on Ubuntu, orchestrating things with NixOps, etc. and found that it's much more painful than just installing NixOS on the bare metal and managing everything via /etc/nixos/configuration.nix

corysama 10y ago

My Linux experience so far has been limited to ls, cd and vi. From the outside, package management has always seemed to me like a huge mess. But, I've been starting to learn Nix recently and I really like it. I can add, remove, test, screw up, change my mind, whatever without stress.

SwellJoe 10y ago
"From the outside, package management has always seemed to me like a huge mess." Compared to what?! There's no OS that has historically had better (or even close to as good) package management as Linux, either in the form of apt-get/dpkg or yum/RPM. Nix is probably better, on a couple of dimensions, but to suggest it was a mess before...well, I just wonder what you could be comparing to that would be better?
- Artlav 10y ago
  Perhaps it's about expecting to have program locality? I.e. you download a zip file, you unpack it into a directory, and here is your entire program. Right there, in that directory, not splattered around the filesystem by the package manager. That's the way it's done on Windows, anyway.
  - johncolanduoni 10y ago
    Perhaps for the newer Windows platforms (e.g. UWP) but Win32 installers have definitely been known to put things all over your system.
    - Artlav 10y ago
      Yeah, that's the reason why i have a "got installer? not worth using" pre-filter for Windows software. Not sure how things are these days, but i'm talking about the Win 9x to Win 7 days.
      - yiyus 10y ago

qwertyuiop924 10y ago

Am I the only one who thought Guix did this better? Maybe it's just my freakish and unnatural love of parenthesis. Or my hatred of learning new configuration syntaxes (I just want to install packges, dammit! Yes, I enjoy learning new languages, but I need to get this machine up and running, and I don't want to learn your new programming language to do that)

sorpaas 10y ago
What I really worry about is my nonfree wireless driver and Nvidia driver, which doesn't seem to be available on Guix.
- Slackwise 10y ago
  Well, you can specify extra packages using $GUIX_PACKAGE_PATH, and I've seen a few custom repos, such as this: https://github.com/genenetwork/guix-bioinformatics https://github.com/genenetwork/guix-bioinformatics and https://github.com/Ecogenomics/ace-guix https://github.com/Ecogenomics/ace-guix I'm not sure how easy it is to maintain a system with extra packages like this, but it'd be nice to be able to use an "overlay" repo as you can in Gentoo for personal/custom packages. Would love to ping davexunit to see if he can elaborate, because I don't see any specific way to add repositories from the documentation.
  - davexunit 10y ago
    There's no such thing as a repository in Guix. Using GUIX_PACKAGE_PATH is the closest thing, conceptually.
    - Slackwise 10y ago
      Ahh, well, then it appears I have to manage a directory of packages myself, as well as any dependencies outside of the Guix store, right? Would be nice to just have a secondary source, as I do with MELPA for Emacs, or overlays for Gentoo. Is something similar/comparable planned to be added? Orrr should someone step forward and volunteer to add it as a feature...?

fizzbatter 10y ago

I love the idea of NixOS, but overall i think i need to wait for it to be a bit more user friendly. The number of times i was completely perplexed when i tried to use this as my home server was.. well, numerous. Awesome idea, and the rollbacks were great, but i kept having to write my own packages and it was all a bit too confusing to do that constantly.

qwerty12653 10y ago

I really want to like NixOS, but there's a serious lack of examples of how to deploy common web infrastructure with it, and that's bitten me the few times I've tried to play with it. For example, our stack is nginx, uwsgi, django, elasticsearch, and postgres. Installing most of the pieces seemed relatively straightforward(though required a fair bit of searching through the nixpkgs source), but it's honestly pretty unclear how to install our actual django app. Currently we just clone the repo to the server and point uwsgi to the relevant uwsgi.py file, but it doesn't seem like there's a good way to do that in NixOS. I'd love to hear that I'm wrong here, but again, the lack of decent example documentation is really the single biggest issue I have with NixOS. The rest of the documentation seems to be improving slowly but steadily.

thinkmoore 10y ago
You might be interested in checking out Habitat from Chef, which uses many similar ideas: habitat.sh
- rokgarbas 10y ago
  as nixos user i looked at habitat and the thing that i will never switch to habitat is that environments are not (build) reproducible. basically habitat is more like docker where it snapshots "successful" build and you use that input for further building. what i loved about habitat is the supervisor part. i there is a way to use habitat's supervisor with nix. then you get best of both tools. until then i'll just have to stick to python's supervisord.

dominotw 10y ago

so could this replace docker as distribution format? cgroups and namespaces can be use independently of docker.

benley 10y ago
Not exactly ... but you can certainly use Nix to build docker images, which is very convenient.

transfire 10y ago

It's very cool what Nix has managed to accomplish. Unfortunately, after studying it I've started to think the solution is overwrought and might be more trouble than the problem is solves, or as I like to say, "with solutions like that who needs problems?" I think it boils down to these points from the summary: > Thus the same package can coexist on the system with multiple configurations. That we have to worry about multiple static compilations of a package hits a deeper problem that Nix can't fix. Namely that there really shouldn't be any need for static install configurations. So the only static differentiation that should be necessary is version. > The derivation is a string in key-value format which will ultimately be hashed and which can refer to objects in the Nix store So why create a whole new "expression" language just to generate these? Developers work with key-value formats all the time (e.g. YAML, JSON). The whole functional language thing seems almost like a slight of hand when you realize this is the end result.