4 ms·

Well, he does mention in the first few paragraphs that "it gets you out of the notion of doing anything manually". The clue here is that Nix systems are meant t

by sparkie 12y ago

Well, he does mention in the first few paragraphs that "it gets you out of the notion of doing anything manually". The clue here is that Nix systems are meant to be configured only via Nix expressions. Any junk you throw onto the filesystem manually is not part of the concerns of the rest of Nix, because the software packaged by Nix can't even see that junk (when building software or using a nix environment) - it can only see the dependencies specified in the package definitions. The packaged definitions are what matters, because those are the part you redeploy to other systems. Any system is welcome to add it's own entropy, put it's own junk on - but when you want reproducibility, you do it by specifying how to get that reproducibility in your nix expressions.

otterley 12y ago
One could argue the same for any package-oriented system, from Red Hat to Solaris to Debian/Ubuntu ("only use packages"). The reality is quite different, and it's always been different. I'm unaware of any environment that's used packages for every aspect of system management, and Nix isn't going to change that. Moreover, there's nothing stopping a Nix package author from writing a post-install script that causes state changes to be made out of bounds. The package manager isn't going to notice, and it's not going to clean it up at deinstallation time.
- sparkie 12y ago
  I think you misunderstand the architecture of Nix. Every package in Nix gets put into an immutable /nix/store. Packages are identified by a hash of their contents, so a small mutation of any package definition gives it a new identity, and thus, a separate package derivation. Every package in the store has exact dependencies - they reference the hashes of other packages only. When a package is built with Nix, only the directories for these packages are exposed to the chrooted environment in which the build occurs - so it is simply not possible for some randomly added junk in the filesystem to make it's way into a nix-defined package. Contrast this to building software on another machine, where I might depend on "glibc" version "1.0". The combination these two values hardly represents a unique identity, as I could make any random package that fits those requirements. It's much more difficult for me to create a package which results in an hash collision though. One thing that makes the other systems so unreliable is the presence of multiple repositories. If you were going to deploy packages from a single repository, then you can do careful planning in such a way that packages do not have any collisions. Assuming no user mutates the directories under control of the package manager, such system will also be effectively reproducible. Current mainstream distros work surprisingly well because they basically use this model, where a default repository provides most users needs. These distros quickly break down when you start adding third-party repositories which bundle alternative compilations of the same software that sits in the "official" one. Basing packages from hashes (identity), rather than names and numbers, and making sure all of the files for each package is held in an isolated directory ensures that collisions won't happen, even if two different repositories provide the same software name and number, they are represented by different hashes, and will be treated as distinct pieces of software.
  - retr0h 12y ago
    I like the architecture of Nix, and believe there are many benefits to it's packaging model. However, I am not a huge fan of the syntax[1], and rather use a template engine I am quite familiar with (like jinja). I'll continue to follow and learn more about Nix, but anxiously awaiting my epiphany. [1] https://github.com/NixOS/nixpkgs/blob/1a504e3fb72fab10799cf07ba8eaa942bb7e585b/nixos/modules/services/web-servers/apache-httpd/default.nix https://github.com/NixOS/nixpkgs/blob/1a504e3fb72fab10799cf0...
    - fineIllregister 12y ago
      If you like Scheme, GNU Guix is based on Nix but uses a DSL in Guile. http://www.gnu.org/software/guix/ http://www.gnu.org/software/guix/
    - cwp 12y ago
      Yeah, problem with nix is that it's different. The nix language is a lazy-functional DSL, which takes a bit of effort to learn. The thing is, "better" does imply "different." The syntax is weird and difficult, but it's the linchpin of the whole system. It's much, much better than your typical packaging system and worth the effort to learn it.
    - gfxmonk 12y ago
      Do you wish nix's syntax were more like jinja? Or do you actually want to use jinja with nix somehow? I don't really know what the latter would mean, since nix is a programming language and jinja is a (string-based) template system.
  - xorcist 12y ago
    So, what do you do when you have to install a new patch level release of said glibc? Rebuild every single component on the system? I take it configuration of the packages needs to go in nix as well? So what do you do when there is, for example, a change of upstream smtp?
- vertex-four 12y ago
  Nix doesn't have post-install scripts. (NixOS sort-of does, as its global "activation script".) In any case, nothing can force you to do anything - only give you tools to work in the right direction. Nix gives you tools for dealing with the concept of an immutable system - there's very few other working tools that do the same. Perhaps it can't possibly get all of it right - database setup and schemas, for example - but that's alright, you can use other tools to deal with them! (There's certainly a glut of schema management tools that would fit right into a Nix system.)
  - tel 12y ago
    I'd be interested to hear of any recommendations for schema management software which works on principles similar to Nix.
    - vertex-four 12y ago
      In general, you could integrate a tool like Alembic into a NixOS system, by having your NixOS configuration copy your migration files to a persistent directory in the activation script, and running the relevant command to get to a certain revision of your schema specified in your NixOS configuration. That way, you always have all the scripts in a persistent directory to roll back without having to keep them in your git repository until some undefined point in time, and it's tied in reasonably well. However, NixOS doesn't handle multi-system upgrades very well on its own - for example, you need to have some external way of dealing with "we need to upgrade the schema before restarting the application servers one at a time". I think that's a whole project on its own, and something that almost everything seems to do on an ad-hoc basis (Salt excluded).
      - cwp 12y ago
        This is just what I do. I don't use Alembic, but I've got a really simple tool that handles migrations. The tool, along with its sequence of migrations is deployed along with the app. The systemd service for Postgres runs the tool after the database is up. Because the service definition has my migration tool as a dependency, it gets rebuilt when the tool is updated. That causes Postgres to get restarted and the tool to get run IFF there are new migrations. The nix configuration is parameterized, so that in dev or staging environments, the database is completely rebuilt and loaded with test data on each deploy, but in production, we just apply migrations. With Nixops, this works even on a multi-system deployment. The full deployment typically takes several minutes, but most of that time is in installing the updated packages, which doesn't interrupt the running system. Once everything is installed, the cut-over only takes a second or two. Eventually, I'll have enough traffic to warrant more careful orchestration of the cut-over, but for now it's fine.

by sparkie 12y ago

otterley 12y ago

One could argue the same for any package-oriented system, from Red Hat to Solaris to Debian/Ubuntu ("only use packages"). The reality is quite different, and it's always been different. I'm unaware of any environment that's used packages for every aspect of system management, and Nix isn't going to change that. Moreover, there's nothing stopping a Nix package author from writing a post-install script that causes state changes to be made out of bounds. The package manager isn't going to notice, and it's not going to clean it up at deinstallation time.

sparkie 12y ago
I think you misunderstand the architecture of Nix. Every package in Nix gets put into an immutable /nix/store. Packages are identified by a hash of their contents, so a small mutation of any package definition gives it a new identity, and thus, a separate package derivation. Every package in the store has exact dependencies - they reference the hashes of other packages only. When a package is built with Nix, only the directories for these packages are exposed to the chrooted environment in which the build occurs - so it is simply not possible for some randomly added junk in the filesystem to make it's way into a nix-defined package. Contrast this to building software on another machine, where I might depend on "glibc" version "1.0". The combination these two values hardly represents a unique identity, as I could make any random package that fits those requirements. It's much more difficult for me to create a package which results in an hash collision though. One thing that makes the other systems so unreliable is the presence of multiple repositories. If you were going to deploy packages from a single repository, then you can do careful planning in such a way that packages do not have any collisions. Assuming no user mutates the directories under control of the package manager, such system will also be effectively reproducible. Current mainstream distros work surprisingly well because they basically use this model, where a default repository provides most users needs. These distros quickly break down when you start adding third-party repositories which bundle alternative compilations of the same software that sits in the "official" one. Basing packages from hashes (identity), rather than names and numbers, and making sure all of the files for each package is held in an isolated directory ensures that collisions won't happen, even if two different repositories provide the same software name and number, they are represented by different hashes, and will be treated as distinct pieces of software.
- retr0h 12y ago
  I like the architecture of Nix, and believe there are many benefits to it's packaging model. However, I am not a huge fan of the syntax[1], and rather use a template engine I am quite familiar with (like jinja). I'll continue to follow and learn more about Nix, but anxiously awaiting my epiphany. [1] https://github.com/NixOS/nixpkgs/blob/1a504e3fb72fab10799cf07ba8eaa942bb7e585b/nixos/modules/services/web-servers/apache-httpd/default.nix https://github.com/NixOS/nixpkgs/blob/1a504e3fb72fab10799cf0...
  - fineIllregister 12y ago
    If you like Scheme, GNU Guix is based on Nix but uses a DSL in Guile. http://www.gnu.org/software/guix/ http://www.gnu.org/software/guix/
  - cwp 12y ago
    Yeah, problem with nix is that it's different. The nix language is a lazy-functional DSL, which takes a bit of effort to learn. The thing is, "better" does imply "different." The syntax is weird and difficult, but it's the linchpin of the whole system. It's much, much better than your typical packaging system and worth the effort to learn it.
  - gfxmonk 12y ago
    Do you wish nix's syntax were more like jinja? Or do you actually want to use jinja with nix somehow? I don't really know what the latter would mean, since nix is a programming language and jinja is a (string-based) template system.
- xorcist 12y ago
  So, what do you do when you have to install a new patch level release of said glibc? Rebuild every single component on the system? I take it configuration of the packages needs to go in nix as well? So what do you do when there is, for example, a change of upstream smtp?
vertex-four 12y ago
Nix doesn't have post-install scripts. (NixOS sort-of does, as its global "activation script".) In any case, nothing can force you to do anything - only give you tools to work in the right direction. Nix gives you tools for dealing with the concept of an immutable system - there's very few other working tools that do the same. Perhaps it can't possibly get all of it right - database setup and schemas, for example - but that's alright, you can use other tools to deal with them! (There's certainly a glut of schema management tools that would fit right into a Nix system.)
- tel 12y ago
  I'd be interested to hear of any recommendations for schema management software which works on principles similar to Nix.
  - vertex-four 12y ago
    In general, you could integrate a tool like Alembic into a NixOS system, by having your NixOS configuration copy your migration files to a persistent directory in the activation script, and running the relevant command to get to a certain revision of your schema specified in your NixOS configuration. That way, you always have all the scripts in a persistent directory to roll back without having to keep them in your git repository until some undefined point in time, and it's tied in reasonably well. However, NixOS doesn't handle multi-system upgrades very well on its own - for example, you need to have some external way of dealing with "we need to upgrade the schema before restarting the application servers one at a time". I think that's a whole project on its own, and something that almost everything seems to do on an ad-hoc basis (Salt excluded).
    - cwp 12y ago
      This is just what I do. I don't use Alembic, but I've got a really simple tool that handles migrations. The tool, along with its sequence of migrations is deployed along with the app. The systemd service for Postgres runs the tool after the database is up. Because the service definition has my migration tool as a dependency, it gets rebuilt when the tool is updated. That causes Postgres to get restarted and the tool to get run IFF there are new migrations. The nix configuration is parameterized, so that in dev or staging environments, the database is completely rebuilt and loaded with test data on each deploy, but in production, we just apply migrations. With Nixops, this works even on a multi-system deployment. The full deployment typically takes several minutes, but most of that time is in installing the updated packages, which doesn't interrupt the running system. Once everything is installed, the cut-over only takes a second or two. Eventually, I'll have enough traffic to warrant more careful orchestration of the cut-over, but for now it's fine.