9 ms·

NixOps – Declarative cloud provisioning and deployment with NixOS

248 points by mrkgnao 9y ago

djsumdog 9y ago
Seems neat, better than Terraform, although limited to just nix and a few providers. Hopefully that will grow. I've been working on a provisioning tool myself. Provisioning is hard, and supporting multiple APIs can be really difficult.
- arianvanp 9y ago
  The `none` provider works for any servers that has an ssh connection. I use it myself to maintain my server on vultr.com . It has been pretty neat!
  - 616c 9y ago
    So put on a Nix overlay on your Linux/Unix flavor of choice like people have done with pkgsrc in and outside the NetBSD community?
    - arianvanp 9y ago
      No. Vultr supports custom ISO's. And I uploaded the nixos image to my account
    - FrozenCow 9y ago
      I don't know how NetBSD handles this, but for any provider that doesn't allow you to use custom ISO's or ipxe, you can use [nixos-in-place](https://github.com/jeaye/nixos-in-place https://github.com/jeaye/nixos-in-place). I've used it before. It isn't ideal, but it gets the job done.
  - dhess 9y ago
    FYI, there's a WIP PR for Vultr backend support in NixOps. https://github.com/NixOS/nixops/pull/634 https://github.com/NixOS/nixops/pull/634 I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my personal branch. Now everything is working great.
    - disassembler 9y ago
      I'm the author of that PR. I apologize for the forced usage of btrfs. This was one of my first delves into the nix language, and I literally copied the digital ocean backend and changed the API calls (and the d.o had a hardcoded filesystem and I wanted btrfs and didn't know how at the time to move that into the configuration level). After the 17.09 release of NixOS is completed, I'll put some focus back in that PR and hopefully get it merged upstream.
      - dhess 9y ago
        No need to apologize. It works great for my needs and it was easy enough just to hack your hack :)
- mbrock 9y ago
  I don't really see Nix as a limitation. It has a good claim to being a universal system configuration tool. Or how do you mean it's limited?
  - matt4077 9y ago
    When I last tried it about 6 months ago it seemed to be a complete mess. I failed to get any recent ruby gems installed. There were dozens of different articles describing how to work with package repositories, and all of them seemed to be outdated by varying degrees. I also got the feeling that nix had more of a focus on desktop systems, for whatever reason.
    - tinco 9y ago
      I use it as a system level configuration tool, and then use Docker for the application level. This is not how the NixOS sees itself ideally, but in my experience their ideology does not map well to the reality of application deployment. So what I do is have all system level tools installed using NixOS: the OS, logging, systemd, Docker, sshd and so on. Then I have my applications built as Docker containers and provision them as systemd units also configured by NixOS files.
      - matt4077 9y ago
        That sounds reasonable, but it kinda makes me question NixOS' value proposition. It seems that any one of the current distributions works well as a generic base for containers. There are probably lots of systems running standard Linux packages with more complex configurations (i.e. Mailservers, maybe databases, proxies etc) where I could imagine it being useful? Or maybe their desktop work makes more sense than I thought–my desktop environment is much more customised than any server, and I've never tried if the setup scripts I try to maintain actually work.
        tinco 9y ago
        I don't think any operating system at this moment does well as a base for containers. At least not from the box, and as soon as you have to customise the OS you need tooling like Puppet/Chef/Salt to make your customizations reproducible. And that's the exact value proposition of NixOS, it's not only reproducible, the OS will be a complete reflection of your Nix specifications from the ground up. I feel NixOS definitely gets some stuff wrong, and I hope at some point it gets some good competition. Mainly because the Nix language looks a bit awkward to me, and also because I don't fully get their package management situation. But the idea of having the operating system be configured from a specification is just a level up from old fashioned linux distros.
zeisss 9y ago
Is there good explanation anywhere of the syntax of those files? I tried getting into nix multiple times and was always put off by the lack of understandability of this.
- lallysingh 9y ago
  The syntax is, by far, the most painful part. Change the drop-down to Nix then click on the manual. The website is hard to navigate in that way.
- k__ 9y ago
  https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55 https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c5...
- zimbatm 9y ago
  Nix is a bit like JSON + functions. An object (called attrset in nix): { a = 3; b = 4; } A list: [ 1 2 3 4 ]; A string: "hello" A multi-line string: '' multine string '' This defines a lambda with two arguments: a: b: a + b; It's possible to pattern-match arguments. This accepts an attrset with keys a and b, and maps them to local variables: { a, b }: a + b; There are some variations around that like `{ a ? 3 }:` `{ a }@attrs:` and `{ a, ... }` One special type is the path, which has it's own literal that starts with `./` To load a file, the `import` keyword is being used. In most cases the whole file is a big lambda function, which gets returned by the import. Once you know that you can start reading nixpkgs and learn about the building blocks to constructs packages.
  - FrozenCow 9y ago
    Also, for convenience, nested objects/attrsets can be shortened. For instance: { a = { b = { c = 3; }; }; } can be shortened to: { a.b.c = 3; } This is used quite often in NixOS system configuration files. There you'll find lines like: services.openssh.enable = true; For a list of all system configuration options that NixOS supports by default see (NixOS options)[https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html].
pierrebeaucamp 9y ago
I would love if someone could compare NixOps with BOSH.
- djvdorp 9y ago
  That would be interesting indeed!
- jacques_chester 9y ago
  I haven't done much Nix, but I do peek over the fence now and then because I (and others) wonder about applying it to buildpacks and/or OCI layer construction. I do a lot more BOSH, since I work at Pivotal. So these remarks are probably wrong. However, from my ignorant viewpoint: The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-good states. BOSH does this at the whole-machine level. You get a stemcell (fixed target), you get releases (fixed configuration of software) and you get deployments (fixed mappings from releases into running systems). When you make a change, you redeploy. BOSH recompiles any changed release packages and then rolls them out across the fleet, starting with canaries. BOSH lets you define the number of VMs, networks and whatnot; I'm not sure if NixOps does. Treating components as replaceable is the main point of departure from previous generations of configuration management, which largely evolved out of a world in which the mission was "make this single machine look right, starting from an unknown state". NixOps appears to do something similar. I'm unclear as to whether it operates at the whole-machine level (à la BOSH) or whether it can perform transformations within an existing machine. The latter would, obviously, be a lot faster than replacing VMs wholesale. That said, whole-machine replacement does have one accidental benefit: it's ruthless. You very quickly encounter the one-in-a-million edge cases for running services because BOSH will quite unmercifully steamroll VMs during a deploy. Any stateful distributed services that aren't ready to have running machines yanked from under them at short notice will quickly reveal themselves. You'd be surprised how many systems that advertise themselves as tolerant to random machine loss ... er ... aren't. Not sure much how I can go into this, but some distributed systems do much more poorly than the stuff on the tin suggests, even after substantial engineering on our part to try and prop them up. Disclosure: I work for Pivotal, so I use BOSH sometimes in my dayjob. But I'm by no means a capable operator or BOSH expert.
zbentley 9y ago
Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very oriented towards provisioning machine instances rather than provisioning behavior across networks or multi-machine services, which is something that Puppet really excels at. What features does this offer in addition to ones that Puppet provides? That said, I've been getting tired of Puppet recently for some unrelated reasons, so I'll definitely give this a try.
- zimbatm 9y ago
  NixOS is the system configuration layer and closer to puppet in solo mode. With a single (or multiple) nix file(s) it's possible to configure a machine and it's services entirely. NixOps is the cloud configuration layer, it provisions cloud resources and uploads NixOS configuration to the machines. It's closer to terraform in that regard. It also has a state file (currently sqlite3) and uses a push model to propagate configuration changes. What's missing right now is a third option where an agent is installed on the machines for a more dynamic configuration of the cluster as a whole. This role will probably be filled by Kubernetes or Nomad.
  - wmertens 9y ago
    Note that with nixops, you can pass variables to the whole deployment configuration, and as such, your deployment is "dynamic" if you reconfigure it often enough :) Here's a deployment of mesos where you can specify how many slaves and masters you want: https://github.com/wmertens/nixops-mesos https://github.com/wmertens/nixops-mesos
- phunehehe0 9y ago
  > Other than integration with the rest of the Nix/NixOS ecosystem Nix/NixOS is the big deal actually. NixOps is just icing on the cake. A NixOS installation is configured by building/copying over a system profile, and then activating it. With just NixOS, you edit a configuration file on the server, then run a command that will build a system profile from that configuration and activate it. With NixOps, you have configuration files on your workstation, and run commands to build the system profiles, copy it to the servers, and activate them. Of course you can do all of this without NixOps. It just makes certain things easier. Puppet and others can do all of this, too. However state transition tend to be the weakest link (e.g. tell Puppet to provision a brand new server vs one that has run some other stuff, how sure are you that the resulting systems are the same?). Nix/NixOS takes care of that (most of the time anyway -- there are still things like data migrations that applications have to take care of).
mrkgnao 9y ago
In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS). Currently, this works best for Haskell, for which there is a sizeable amount (relatively speaking) of Nix tooling available. This is largely because a lot of Nix(OS) users also use Haskell, perhaps because lend themselves to very similar modes of "declarative" thinking. This is a thorough, excellent guide on how to develop Haskell projects with Nix, including managing non-Haskell dependencies (zlib, SDL, ncurses, and so on): https://github.com/Gabriel439/haskell-nix/ https://github.com/Gabriel439/haskell-nix/ I only started using NixOS about a month ago, and it's fantastic. The best part is that binary caches are available for almost everything, so the hitherto-painful step where one compiles Haskell dependencies locally has been completely eliminated. The best way I can describe how I work now is "Python virtualenvs, but for everything at once and just so much better". PS. Gabriel Gonzalez is, in general, someone who makes great documenation. Check out the tutorial for his stream-processing library Pipes: the ASCII art alone is awesome :) https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-Tutorial.html https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-T...
- arianvanp 9y ago
  Gabriel also has a great blog http://www.haskellforall.com/ http://www.haskellforall.com/ Basically the kind of person I would love to buy a beer any time because he does so much great work. on topic: The binary caches are great. For work I'm currently evaluating https://github.com/typeable/stackage2nix https://github.com/typeable/stackage2nix and https://github.com/input-output-hk/stack2nix https://github.com/input-output-hk/stack2nix to generate nix expressions from our haskell stack projects. And then push the build artifacts to a shared cache. Such that nobody has to ever compile a dependency twice. Because nothing sucks more than starting your day watching the compiler churn away at compiling after version bumps, to then also see a collegue go to the same pain all over again.
- Ixiaus 9y ago
  We use NixOS in production in our product, for our cloud services, and for some development environments. We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects. It's an incredible tool. NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to decouple system specification from system deployment. So I wrote a tool that handles performing the same system deployment operations that NixOps does for you and you can simply pipe the nix path result from nix-build to it. We use terraform to specify and manage the cloud resources.
j_s 9y ago
Can anyone comment on whether or not Nix is 100% reproducible? To the best of my limited understanding, it is not.
- catern 9y ago
  Nix doesn't guarantee bit-for-bit reproducibility: That is, two different builds of a Nix package may not produce bit-identical output. (They probably will, because of all the sandboxing, but nothing prevents an arbitrary package from generating random numbers at build time.) Certainly Nix makes it a lot easier to get reproducibility in practice, though.
- plesiv 9y ago
  It is not. In this talk [1] Eelco Dolstra touches upon that a bit also. [1] https://www.youtube.com/watch?v=QvH5qU1qBXY&feature=youtu.be https://www.youtube.com/watch?v=QvH5qU1qBXY&feature=youtu.be
thomastjeffery 9y ago
NixOS makes a great OS for personal/workstation use, too. With NixOS, my system is always 100% clean, and never broken. I can install packages in my home directory without root. Best of all, whenever I want to write any code, I can use nix-shell to make the toolchain and dependencies temporarily available to a self-contained shell. No more cluttering my system with libfoobar-dev for a quick build, and forgetting why.

248 points by mrkgnao 9y ago

Seems neat, better than Terraform, although limited to just nix and a few providers. Hopefully that will grow. I've been working on a provisioning tool myself. Provisioning is hard, and supporting multiple APIs can be really difficult.

arianvanp 9y ago
The `none` provider works for any servers that has an ssh connection. I use it myself to maintain my server on vultr.com . It has been pretty neat!
- 616c 9y ago
  So put on a Nix overlay on your Linux/Unix flavor of choice like people have done with pkgsrc in and outside the NetBSD community?
  - arianvanp 9y ago
    No. Vultr supports custom ISO's. And I uploaded the nixos image to my account
  - FrozenCow 9y ago
    I don't know how NetBSD handles this, but for any provider that doesn't allow you to use custom ISO's or ipxe, you can use [nixos-in-place](https://github.com/jeaye/nixos-in-place https://github.com/jeaye/nixos-in-place). I've used it before. It isn't ideal, but it gets the job done.
- dhess 9y ago
  FYI, there's a WIP PR for Vultr backend support in NixOps. https://github.com/NixOS/nixops/pull/634 https://github.com/NixOS/nixops/pull/634 I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my personal branch. Now everything is working great.
  - disassembler 9y ago
    I'm the author of that PR. I apologize for the forced usage of btrfs. This was one of my first delves into the nix language, and I literally copied the digital ocean backend and changed the API calls (and the d.o had a hardcoded filesystem and I wanted btrfs and didn't know how at the time to move that into the configuration level). After the 17.09 release of NixOS is completed, I'll put some focus back in that PR and hopefully get it merged upstream.
    - dhess 9y ago
      No need to apologize. It works great for my needs and it was easy enough just to hack your hack :)
mbrock 9y ago
I don't really see Nix as a limitation. It has a good claim to being a universal system configuration tool. Or how do you mean it's limited?
- matt4077 9y ago
  When I last tried it about 6 months ago it seemed to be a complete mess. I failed to get any recent ruby gems installed. There were dozens of different articles describing how to work with package repositories, and all of them seemed to be outdated by varying degrees. I also got the feeling that nix had more of a focus on desktop systems, for whatever reason.
  - tinco 9y ago
    I use it as a system level configuration tool, and then use Docker for the application level. This is not how the NixOS sees itself ideally, but in my experience their ideology does not map well to the reality of application deployment. So what I do is have all system level tools installed using NixOS: the OS, logging, systemd, Docker, sshd and so on. Then I have my applications built as Docker containers and provision them as systemd units also configured by NixOS files.
    - matt4077 9y ago
      That sounds reasonable, but it kinda makes me question NixOS' value proposition. It seems that any one of the current distributions works well as a generic base for containers. There are probably lots of systems running standard Linux packages with more complex configurations (i.e. Mailservers, maybe databases, proxies etc) where I could imagine it being useful? Or maybe their desktop work makes more sense than I thought–my desktop environment is much more customised than any server, and I've never tried if the setup scripts I try to maintain actually work.
      - tinco 9y ago
        I don't think any operating system at this moment does well as a base for containers. At least not from the box, and as soon as you have to customise the OS you need tooling like Puppet/Chef/Salt to make your customizations reproducible. And that's the exact value proposition of NixOS, it's not only reproducible, the OS will be a complete reflection of your Nix specifications from the ground up. I feel NixOS definitely gets some stuff wrong, and I hope at some point it gets some good competition. Mainly because the Nix language looks a bit awkward to me, and also because I don't fully get their package management situation. But the idea of having the operating system be configured from a specification is just a level up from old fashioned linux distros.

zeisss 9y ago

Is there good explanation anywhere of the syntax of those files? I tried getting into nix multiple times and was always put off by the lack of understandability of this.

lallysingh 9y ago
The syntax is, by far, the most painful part. Change the drop-down to Nix then click on the manual. The website is hard to navigate in that way.
k__ 9y ago
https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55 https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c5...
zimbatm 9y ago
Nix is a bit like JSON + functions. An object (called attrset in nix): { a = 3; b = 4; } A list: [ 1 2 3 4 ]; A string: "hello" A multi-line string: '' multine string '' This defines a lambda with two arguments: a: b: a + b; It's possible to pattern-match arguments. This accepts an attrset with keys a and b, and maps them to local variables: { a, b }: a + b; There are some variations around that like `{ a ? 3 }:` `{ a }@attrs:` and `{ a, ... }` One special type is the path, which has it's own literal that starts with `./` To load a file, the `import` keyword is being used. In most cases the whole file is a big lambda function, which gets returned by the import. Once you know that you can start reading nixpkgs and learn about the building blocks to constructs packages.
- FrozenCow 9y ago
  Also, for convenience, nested objects/attrsets can be shortened. For instance: { a = { b = { c = 3; }; }; } can be shortened to: { a.b.c = 3; } This is used quite often in NixOS system configuration files. There you'll find lines like: services.openssh.enable = true; For a list of all system configuration options that NixOS supports by default see (NixOS options)[https://nixos.org/nixos/options.html https://nixos.org/nixos/options.html].

pierrebeaucamp 9y ago

I would love if someone could compare NixOps with BOSH.

djvdorp 9y ago
That would be interesting indeed!
jacques_chester 9y ago
I haven't done much Nix, but I do peek over the fence now and then because I (and others) wonder about applying it to buildpacks and/or OCI layer construction. I do a lot more BOSH, since I work at Pivotal. So these remarks are probably wrong. However, from my ignorant viewpoint: The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-good states. BOSH does this at the whole-machine level. You get a stemcell (fixed target), you get releases (fixed configuration of software) and you get deployments (fixed mappings from releases into running systems). When you make a change, you redeploy. BOSH recompiles any changed release packages and then rolls them out across the fleet, starting with canaries. BOSH lets you define the number of VMs, networks and whatnot; I'm not sure if NixOps does. Treating components as replaceable is the main point of departure from previous generations of configuration management, which largely evolved out of a world in which the mission was "make this single machine look right, starting from an unknown state". NixOps appears to do something similar. I'm unclear as to whether it operates at the whole-machine level (à la BOSH) or whether it can perform transformations within an existing machine. The latter would, obviously, be a lot faster than replacing VMs wholesale. That said, whole-machine replacement does have one accidental benefit: it's ruthless. You very quickly encounter the one-in-a-million edge cases for running services because BOSH will quite unmercifully steamroll VMs during a deploy. Any stateful distributed services that aren't ready to have running machines yanked from under them at short notice will quickly reveal themselves. You'd be surprised how many systems that advertise themselves as tolerant to random machine loss ... er ... aren't. Not sure much how I can go into this, but some distributed systems do much more poorly than the stuff on the tin suggests, even after substantial engineering on our part to try and prop them up. Disclosure: I work for Pivotal, so I use BOSH sometimes in my dayjob. But I'm by no means a capable operator or BOSH expert.

zbentley 9y ago

Other than integration with the rest of the Nix/NixOS ecosystem, how is NixOps different from Puppet? Reading briefly through the examples, it seems very oriented towards provisioning machine instances rather than provisioning behavior across networks or multi-machine services, which is something that Puppet really excels at. What features does this offer in addition to ones that Puppet provides? That said, I've been getting tired of Puppet recently for some unrelated reasons, so I'll definitely give this a try.

zimbatm 9y ago
NixOS is the system configuration layer and closer to puppet in solo mode. With a single (or multiple) nix file(s) it's possible to configure a machine and it's services entirely. NixOps is the cloud configuration layer, it provisions cloud resources and uploads NixOS configuration to the machines. It's closer to terraform in that regard. It also has a state file (currently sqlite3) and uses a push model to propagate configuration changes. What's missing right now is a third option where an agent is installed on the machines for a more dynamic configuration of the cluster as a whole. This role will probably be filled by Kubernetes or Nomad.
- wmertens 9y ago
  Note that with nixops, you can pass variables to the whole deployment configuration, and as such, your deployment is "dynamic" if you reconfigure it often enough :) Here's a deployment of mesos where you can specify how many slaves and masters you want: https://github.com/wmertens/nixops-mesos https://github.com/wmertens/nixops-mesos
phunehehe0 9y ago
> Other than integration with the rest of the Nix/NixOS ecosystem Nix/NixOS is the big deal actually. NixOps is just icing on the cake. A NixOS installation is configured by building/copying over a system profile, and then activating it. With just NixOS, you edit a configuration file on the server, then run a command that will build a system profile from that configuration and activate it. With NixOps, you have configuration files on your workstation, and run commands to build the system profiles, copy it to the servers, and activate them. Of course you can do all of this without NixOps. It just makes certain things easier. Puppet and others can do all of this, too. However state transition tend to be the weakest link (e.g. tell Puppet to provision a brand new server vs one that has run some other stuff, how sure are you that the resulting systems are the same?). Nix/NixOS takes care of that (most of the time anyway -- there are still things like data migrations that applications have to take care of).

mrkgnao 9y ago

In view of some replies downthread: yes, application-level management is entirely possible with Nix(OS). Currently, this works best for Haskell, for which there is a sizeable amount (relatively speaking) of Nix tooling available. This is largely because a lot of Nix(OS) users also use Haskell, perhaps because lend themselves to very similar modes of "declarative" thinking. This is a thorough, excellent guide on how to develop Haskell projects with Nix, including managing non-Haskell dependencies (zlib, SDL, ncurses, and so on): https://github.com/Gabriel439/haskell-nix/ https://github.com/Gabriel439/haskell-nix/ I only started using NixOS about a month ago, and it's fantastic. The best part is that binary caches are available for almost everything, so the hitherto-painful step where one compiles Haskell dependencies locally has been completely eliminated. The best way I can describe how I work now is "Python virtualenvs, but for everything at once and just so much better". PS. Gabriel Gonzalez is, in general, someone who makes great documenation. Check out the tutorial for his stream-processing library Pipes: the ASCII art alone is awesome :) https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-Tutorial.html https://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-T...

arianvanp 9y ago
Gabriel also has a great blog http://www.haskellforall.com/ http://www.haskellforall.com/ Basically the kind of person I would love to buy a beer any time because he does so much great work. on topic: The binary caches are great. For work I'm currently evaluating https://github.com/typeable/stackage2nix https://github.com/typeable/stackage2nix and https://github.com/input-output-hk/stack2nix https://github.com/input-output-hk/stack2nix to generate nix expressions from our haskell stack projects. And then push the build artifacts to a shared cache. Such that nobody has to ever compile a dependency twice. Because nothing sucks more than starting your day watching the compiler churn away at compiling after version bumps, to then also see a collegue go to the same pain all over again.
Ixiaus 9y ago
We use NixOS in production in our product, for our cloud services, and for some development environments. We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects. It's an incredible tool. NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to decouple system specification from system deployment. So I wrote a tool that handles performing the same system deployment operations that NixOps does for you and you can simply pipe the nix path result from nix-build to it. We use terraform to specify and manage the cloud resources.

j_s 9y ago

Can anyone comment on whether or not Nix is 100% reproducible? To the best of my limited understanding, it is not.

catern 9y ago
Nix doesn't guarantee bit-for-bit reproducibility: That is, two different builds of a Nix package may not produce bit-identical output. (They probably will, because of all the sandboxing, but nothing prevents an arbitrary package from generating random numbers at build time.) Certainly Nix makes it a lot easier to get reproducibility in practice, though.
plesiv 9y ago
It is not. In this talk [1] Eelco Dolstra touches upon that a bit also. [1] https://www.youtube.com/watch?v=QvH5qU1qBXY&feature=youtu.be https://www.youtube.com/watch?v=QvH5qU1qBXY&feature=youtu.be

thomastjeffery 9y ago

NixOS makes a great OS for personal/workstation use, too. With NixOS, my system is always 100% clean, and never broken. I can install packages in my home directory without root. Best of all, whenever I want to write any code, I can use nix-shell to make the toolchain and dependencies temporarily available to a self-contained shell. No more cluttering my system with libfoobar-dev for a quick build, and forgetting why.