top | item 3968298

(no title)

edolstra | 14 years ago

In NixOS (the Linux distribution based on Nix [1]) we use the functional approach for managing all the "static" parts of the system, i.e. packages, but also most configuration files in /etc - these get build by Nix functions in much the same way as packages. This is good since it means that (say) a rollback of the system will cause it to revert to a consistent combination of packages and configuration files. (So you don't get an Apache httpd.conf that refers to some feature that doesn't exist in the Apache you just rolled back to.)

However, when it comes to stateful stuff such as user data or databases, the funtional approach indeed doesn't really apply very well. NixOS manages state in an imperative manner in the same way as every other distribution. (For instance, NixOS uses Upstart jobs to create/update state.) That means that a rollback of your system won't rollback (say) your PostgreSQL database, unless somebody made the Upstart job of PostgreSQL do that. So when it comes to state, NixOS isn't better than other distributions, but it's not worse either ;-)

[1] http://nixos.org/, http://www.st.ewi.tudelft.nl/~dolstra/pubs/nixos-icfp2008-fi...

discuss

order

moonboots|14 years ago

Thanks for the response. I agree that some functionality currently handled by package managers is hairy, even for other package managers. To some extent, I don't think this functionality should be managed by package managers. It would hurt usability because the user would need to set up configuration files, hook the package into the init/upstart system, and fix breakages across updates. On the other hand, I've never been a fan of running 'sudo apt-get install apache2' on a development machine and exposing a public port and running an application I don't always need every time I boot up.

nwmcsween|14 years ago

The problem with the nix package manager that I see is it doesn't integrate into a hierarchy of any kind thus no partitioning of data. Also the nix language is very obtuse and domain specific(which is a good thing as well as bad). I plan on creating a meta package manager that is functional but allows output of arbitrary formats such as rpm, deb, etc. I also think integration is a separate but just as important aspect and hope to use mruby, rspec and augeas(or something else as it seems the parsing format is yet another NIH wheel).