The amazing thing is that the whole set up of your linux machine is encaptulated in one declarative text file (that you can put in version control). Give it a try by installing it using VirtualBox: https://nixos.org/wiki/Installing_NixOS_in_a_VirtualBox_gues.... You can log in (demo/demo in the 14.10 vm) and play around, essentially be editing `/etc/nixos/configuration.nix`.
I recommend trying the configuration of an experienced user. Here's the result of a simple search on github:
https://github.com/sitano/configuration.nix
https://github.com/Hinidu/configuration.nix
https://github.com/garbas/nixos-configuration
You can also get started very easily using a ec2 tiny instance (free tier): https://nixos.org/wiki/NixOS_on_Amazon_EC2
It looks like Guix provides a significantly more expressive interface with Scheme than Nixos does with Nix expressions. IIRC, there's also better integration with the system (Nixos auto-generates plenty of bash), which will surely accelerate development / debugging.
Does anyone here have Guix experience to share?
Installing the full OS is for the brave at the moment, but we'd certainly like you to give it a try if you have the machine/VM to spare. If you do, please let us know what you liked/disliked, what worked and what blew up. There's no guided installer, but it's not too hard to get running in most cases. Partition disks, write system config, run something like 'guix system init config.scm /mnt/my-new-root-partition/' and reboot.
Since becoming one of the core developers, I have been working on a tool called 'guix environment' that can be used for creating reproducible development environments for software projects. I was happy to discover that the core part of Guix contains all the features needed to write tools that could replace things like Vagrant and (once we have container support) Docker. It's just a matter of writing the proper frontend.
I hope you'll give Guix a try sometime. :)
About half a year ago I ran into problems with updating and did not have the time to fix it (stuff simply did not build - I did not try the --with-source trick).
I hope that a reinstall with the new version fixes that.
What sold it to me was that when the system breaks during update, everything is still in a working state. → http://draketo.de/light/english/install-gnu-guix-03 My son once found the power-connector of my Gentoo box while I was running updates and hit the pretty red glowing button. It took me three days to recover the system…
But in general I have no idea what I'm doing with it. Just trying it out and it's mostly working for me.
Anyone to share their experiences?
(Migrating from Arch to NixOS at the moment, but thought maybe I'd detour a bit and try Guix.)
So lots and lots of compilation (on build farms at least), and lots of bandwidth usage. Though something like ccache can help with the compilation, and binary diffs could help with the bandwidth.
Immutable data structures in FP are probably a good analogy.
Edit: argh, this was supposed to be a reply to the question about the disadvantages of the purely functional package managers specifically, not the OS in general.
Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change.
jabberwork-1.2
jabberwock.core-1.6
jabberwock.apache.interface-0.3
jabberwock-1.3
jabberwock.core-1.6
jabberwock.apache-interface-0.4
Instead of having to update all the hefty ".core" modules, you could get away with only updating the hopefully lighter launchers / library loaders and the specific interface code being updated.That's also true for software I'm packaging. Certain ecosystems just really love to load configuration files and write log files relative to the binary path which breaks in nixos because all packages live on a read-only mount (looking at you ruby, cargo from rust will also be fun).
Lastly there's just not the same number of contributors yet so you're going to have more of the small issues that get fixed and reported by the armies of users that e.g. Ubuntu has.
I'm saying all this as an incredibly happy user. I can think of few technologies that have given me as much leverage as nixos in recent years.
As a fairly new developer I don't find the learning curve to be steep. The configuration language is a Scheme DSL and is a lot simpler to my brain than spec files or Debian-style directories.
Where stuff lives in the filesystem becomes largely irrelevant because you can treat the store as a blackbox cache. What matters is only the stuff in ~/.guix-profile/, which is very tidy and only contains the software you installed to your profile.
In many cases situations like this can be fixed by setting environment variables, but in some cases more patching is required to make this work properly.
EDIT: I don't consider this a serious disadvantage, though. It is not unusual for packagers to patch software in other distributions. (I dare you to check out spec files for popular RPMs.) It's just something a package maintainer has to think about under some circumstances.
I should also note that I'm surprised at how little patching is required for most software (besides the common shebang patching).
2. It creates guix-specific users for building purposes.
There really isn't much bad to say about guix. You can even switch to it without giving up on your old package manager. That way, even point 1. isn't an issue. Of course, 2. isn't really an issue in itself; `cat /etc/passwd` already contains a lot of users whose purpose I know little about.
The project develops, at the same time, GNU GSD (Guix System Distribution), a GNU operating system.
GNU GSD is an avant-garde GNU system utilizing Guix as its package manager, and the similarly Guile/Scheme based dmd as its init system.
I probably will one day, but not right now.
But: I'm not sure you're doing your work any justice by labelling it "avant-garde". I think you risk looking "weird" or more dangerous than you need to and might detract people from looking into it.
What negative connotations do you think this has among hackers?
apt-get allows at most one version of a package to be installed at a time; if you want two versions, you need to ask the maintainers to split the package into two. Guix doesn't suffer this problem; packages are given an ID based on a hash of their contents and dependencies, so two versions will happily sit side-by-side. An "update" is treated more like installing a separate package.
If two applications depend on two different versions of some library, you can't install both applications. In Guix you can, since each can use the version it needs.
apt-get affects the whole system. All users are affected by a change; if some other user installs/removes/updates a package, you have to just deal with it. In Guix, every user gets a "profile" package, which can depend on anything they like. Installing/removing/updating packages just creates a new version of your profile, with its dependencies added/removed/changed according to what you asked for.
apt-get is stateful: the contents of /usr, /etc, etc. are changed as packages are installed/removed. Guix is immutable: packages live in their own read-only directories, so nothing can break them after installation.
apt-get can't roll back: packages can't be down-graded, all kinds of actions are taken by pre/post install scripts which can't be undone, etc. Since Guix is immutable, "rolling back" just means going back to the old selection of packages; ie. installing the old version of the profile package.
This is still true in Nix (and Guix I assume), although there are facilities for overriding, say, just the source tarball (to a different version) without needing to create a whole new Nix package (and worst case, creating a whole new Nix package is an order of magnitude easier than creating a Debian package in my experience).
In the "nixpkgs" set of packages, a few packages come in multiple versions (gcc, autotools come to mind), but most are only available in a single version.
Of course, once you've managed to install package-version-1, even as nixpkgs moves to version 2, 3, and so on, your version 1 can remain installed forever if you wish, and nothing can swap out the libpng, or libc or whatever it may depend on, since as you say all these can live side-by-side with other versions of themselves.
I've also found that the increasing entropy caused by stateful alternatives (e.g. apt-get) eventually becomes impossible to manage. This is entirely due to hidden state that grows in complexity over time. Eventually, things break in a way that nobody on StackOverflow has seen before, and you're SOL. In the declarative world, everything specific to your setup is required to be defined upfront, in one central place. This provides you with a much better chance of understanding your system as it evolves.
(Your account name makes me think you've appreciated functional programming data structures at some point. In not surprisingly, the benefits of immutability and declarative style in programming languages seem to carry over to configuration management.)
- apt-get, yum, pacman and "traditional" package managers deal with _transition of your system_: _please install this packet_, _please remove this packet_
- nix and guix deal with _state of your system_: _please make sure that the final state is thus_.
This brings easy reproducibility of a system (if you have the recipe, you can have a another machine be an _exact_ copy) and de-entanglement (no more managing conflicting dependencies, no more dangling files). If I were to draw parallel, it would be like this:
- "traditional" package managers are like jQuery: you pick some DOM node / some package, and modify it / update it. After some time you don't know anymore who modified this DOM node, who needs it, ... things become hard to track
- nix and guix are like React: you specify the state you want in a single place (or rather in a definite place) and React/nix maps that definition into your final product
Here's a long blog post that goes into more detail: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansibl...
With guix gsd and nixos, the package manager is the configuration manager. The package manager is not just package manager, its not just apt-get, it is also puppet/chef/salt, and a distribution-maker or manager. I believe with guix you could make your own distribution (software collection) in the same descriptive language as making packages. You cant do that with apt or any debian tools.
* you can describe a tree of dependencies using any version of the package you want, and can easily rollback to a previous tree if an update broke it
* because you describe a tree of packages, you're actually describing the complete state of the system, there's no leftovers from previous installations which make it work by chance
* as a result you can easily partially alter (and rollback) or move nix configurations from one machine to the next
Essentially nix (and guix?) merges package management and configuration management in a stateless and declarative, easily audited and customised, manner.
Suppose one has a resource for file in Puppet
file "blah" do source "yada" end
if you erase that resource, the file still stays there. With Nix/Guix anything not defined in configuration isn't present at all on system.
Another feature : one can install, for example, different versions of Python/PyPy/etc locally using the same package manager. Local and system-wide package share the same underlying files and don't interfere.
Rollbacks, very easy way to restore system packages/configs to previous working state.
I tried using Guix to deploy to the cluster in Karlsruhe (more than a year ago) but back then it was still missing most of the libraries I needed. When you finished making it work for your cluster, that could be a pretty good base for many other people, too.
vboxmanage convertfromraw ~/Downloads/gsd-usb-install-0.8.1.i686-linux gsd-install.vdi --format vdi
The resulting VDI file can then be attached to a VirtualBox machine as a primary IDE disk. Be sure to enable PAE/NX in the System settings.