This is all based on 2-3 hours with a virtual appliance version of the OS running in VirtualBox, and minimal reading of the documentation.
There aren't a lot of standards in Linux, but those few there are, NixOS seems determined to break. Their model is different and interesting, but wasteful of space (keeping multiple versions of software around, not just as root but also per-user) and making itself a security issue waiting to happen with old software versions. On the plus side, the package manager (which seems to be the centre of the OS) did complex manipulations (like changing the PATH) seamlessly.
- I was running the OS in a VirtualBox VM (encouraged by them: they provide appliance packages)
- disclaimer (I haven't researched this much)
- based around the philosophy of the Nix Package Manager
- always consistent, able to install multiple versions of any package
- users can install their own packages, and setting the PATH is how they choose which applications and versions are active
- the default window manager is KDE: I don't like the current menu system much, even once you get used to its non-obvious behaviours, I think it would be slower to use than a more standard menu ...
- what do you do first as a VirtualBox user? You try to install the VirtualBox Linux Additions
- ... which fails: line 402: /bin/rm: No such file
- there is an "rm" and it is on the path, but it's in /run/current-system/sw/bin/rm
- so ... copy VBoxLinuxAdditions.run to /root/ and edit it:
- vim VBoxLinuxAdditions.run : vim: command not found
- okay, fine: "vi VBoxLinuxAdditions.run" : vi: command not found
- WTF?!: this is a 838MB compressed system complete with KDE, and they didn't include the POSIX standard editor?
- list available packages: nix-env -qa: this is fairly slow, and has a huge output that's piped to less - it also doesn't tell you anything beyond name-version, no description
- nix-env -qas (supposed to give me status) took a very long time and then coughed hundreds of errors (can't show them because I couldn't cut-and-paste without the VBox tools ...)
- install with nix-env -i vim-7.4.410 (version number is not required)
- vim defaults to full vi-compatibility, why?
- there is no gvim, although there are many vim packages
- bzip2 is also not installed, hello? ... installed
- installs that are run as root install to /root/.nix-profile/bin/<binary-name>
- but VBoxLinuxAdditions.run checksums itself and barfs if there are changes, so I can't install
- "xterm" seems to ignore the ~/.Xdefaults and ~/.Xresources files: I was unable to permanently set foreground and background colours, something I've relied on for over a decade
- so ... in /bin/ I did a ln -s $(which rm) and same for bzip2
- and now VBoxLinuxAdditions.run fails on not being able to find a single standard library path (it checks a bunch, including (it claims) the LSB standard)
- so at every turn they've managed to avoid using standards ...
- after all that - Nix does provide a VirtualBox-GuestAdditions package ... but it's for 4.3.24 and I've just installed VBox 4.3.26
- nix-env -i VirtualBox-GuestAdditions caused a massive flurry of downloads including gmake, the VBox-Additions ISO, and a brand new Linux Kernel (source, 3.19-rc7) ... started to compile stuff, but eventually barfed on configuring the kernel (I ran that as user ... kernel-as-root probably wouldn't work, not even with Nix - odd it even tried when a kernel was a dep)
- failed as root as well
- one of the comments in the nix package manager manual said "if it starts downloading and compiling, something went wrong" - which I don't think is strictly true, there's a reason - but this didn't end well
- current "uname -a" is 3.14.34 etc.
- root installs go to /root/.nix-profile which is a soft link to /nix/var/nix/profiles/default (this dir is on the user's PATH)
- user "demo" installs go to /home/demo/.nix-profile, a soft link to a user specific folder - although oddly not in the user's tree: /nix/var/nix/profiles/per-user/demo/profile
- user level nix-env -i <package> will happily install something already installed at the root level, and the user's version precedes the root version on the path. So much for system-wide security fixes
- if I were a user on a multi-user system, this would be an interesting idea ... but how many multi-user systems are there left in the world? And the idea of keeping multiple versions around, before we even start counting the drive space occupied by user's versions of the same software ...
- the whole OS strikes me as a security issue waiting to happen