“NixOS is a Linux distribution based on Nix, a purely functional package management system. NixOS is an experiment to see if we can build an operating system in which software packages, configuration files, boot scripts and the like are all managed in a purely functional way, that is, they are all built by deterministic functions and they never change after they have been built.”
From their web site, I think it’s not a real project. Is it a joke?
I don’t think it is. I’m downloading the x64 image right now and looking through the rest of the site, the system sounds very interesting.
Gonna give it a run and report back.
I hope we aren’t going to get a lot of April fools stories. The problem with April fools stories is that they live just as long in the search engines as any other stories, and continue to cause confusion all year long, for years to come.
It’s one thing to have to hassle with them on Apr 1. It’s quite another when you are desperately searching for the solution to a problem on New Years Eve, come across a promising article, and then notice the date, hopefully before you have wasted much time on it.
I think this is a real project, though. Albeit a rather odd one.
Edited 2007-04-01 16:48
This is a real project from the looks of it. Many of the entries on the Wiki are from well before April.
Not only that, some of the research papers released have way too much valid material to be a fake:
http://nix.cs.uu.nl/docs/papers.html
“While NixOS is not really suitable for production use, it already works quite well as a server OS. (We don’t really have a useful X server configuration yet, so it’s not very useful as a desktop OS right now.)”
And you can download it, too.
Sever OS and no GUI. MMM kay.
it says on here http://nix.cs.uu.nl/index.html that there are packages for gnome, x, and compiz.
Multi-user package management — any user can install software through the same mechanisms that the administrator uses. This is not the case for most package managers such as RPM.
(sarcasm on)
Yeah. Because letting any jackhole who walks up to the box install software has worked out so well in the Windows world. That’s gotta be a winner.
(sarcasm off)
Anyways it does have some interesting concepts in it’s design.
Yeah. Because letting any jackhole who walks up to the box install software has worked out so well in the Windows world. That’s gotta be a winner.
Depends on what you want from the box. You’re falling in the classical trap of merging the server and desktop worlds. On a server I would not like everybody to be able to install stuff, hell, I want to control even who runs stuff.
But on a desktop it’s quite the opposite. If daughter Jane has an account on the family home computer and she can pull off installing a piece of software, she should be able to go ahead and do that. The only thing I want the OS to do is to ensure she will mess up as little as possible of the rest of the system (other user accounts/system files etc.) That’s where Windows fails and the Mac does not, and one reason why the Mac is such a fabled desktop computer.
Security is pretty much sensibly covered with today’s Linux. Confort on the desktop is not, no matter how much we kid ourselves. It cannot be, as long as it still has 30-odd-years old legacy ties to UNIX. The FHS is a wonderful thing, but completely outdated in today’s day and age. Too bad extremely few are able to challenge the status quo on this one.
Edited 2007-04-02 10:28
Well, for a change, it’s really nice to have a package manager and system scripts that have are functional, since we all know that on other distros they just take up valuable disk space
/nix/store/r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1/
I like the name, very functional
and very visual 
That’s why the term “function languages” might work better…
Yes, the *stupid* idea of putting the key before the name of the package almost made me think that it was a joke..
If you really want to put a key in the directory name, put it *after* the package name!
firefox-2.0.0.1-r8vvq9kq18pz08v249h8my6r9vs7s0n3 would be more more sensible, it would :
1) be much more readable since left-to-right readers would just ignore the end of the string.
2) group together different version of the same package when you list the content of a directory.
3) the auto-completion would work much better..
*Sigh*, the one who designed this key-package schema don’t think about the users..
Well, we do *try* to think about the users, since we use it ourselves 😉
In practice, it doesn’t really matter whether the symbolic package name is at the start or the end, since you’re not supposed to access packages by listing the contents of the Nix store. Rather, packages are installed in “profiles”, which are just symlinks to the installed packages. For instance, your Firefox might be /nix/var/nix/profiles/default/bin/firefox or /nix/var/nix/profiles/per-user/bob/bin/firefox, which would be a symlink to /nix/store/hash…-firefox-2.0.0.1/bin/firefox. And those profiles are what you have in your $PATH. If users actually had to deal with those nasty store paths directly, it wouldn’t really matter if the hash came first or last – it would suck in either case.
In fact, we could omit the symbolic name altogether and everything would still work fine from an end-user perspective, but it would make debugging packages (like understanding build errors) a lot harder.
Incidentally, the tab completion argument for me works out exactly the other way around: if you get (say) a build error relating to r8vvq9kq18pz08v249h8my6r9vs7s0n3-firefox-2.0.0.1 and you want to inspect the contents of that directory, then you only have to type the first few characters of the hash and press tab to get the whole path. Anyway, it’s a bit subjective 🙂
Downloaded and mounted the x64 image in VMWare. The installation works a bit like any source based distro in that you have to partition your disk with fdisk, then initialize the partition(s) with the appropriate filesystem.
I partitioned the drive with one swap partition, sda1, and my root partition, sda2. mkfs.ext3 /dev/sda2, mkswap /dev/sda1, swapon /dev/sda1 and finally mount /dev/sda2 /mnt.
Next, you need to tell the system it’s basic parameters with a file called configuration.nix. What I did was, instead of creating one from scratch, I copied /etc/nixos/nixos/configuration/examples/basic.nix to /etc/nixos/configuration.nix, edited the file with nano, set the correct parameter for grub, swap and root and ran nixos-install (all this information I got from the docs, founs at http://nix.cs.uu.nl/dist/nix/nixos-unstable-latest/manual/ )
Currently, it’s downloading some packages and patches. Hopefully I’ll have an update later.
So far, so good 😉
Update: I screwed up the install by not adding a very simple line. In the configuration.nix file, between the device identifier and the mount point, inpute the following line:
fsType = “ext3”; (or whatever fs you chose)
I tried fixing it by hand but gave up after 10 minutes (OK, OK, I’m lazy! It’s sunday! 😉
Still didn’t work. Looks like a long read through the docs for me. Gonna install arch before though!
I was wondering why anyone would want a fictional operating system, and then I re-read the headline.
“””
I was wondering why anyone would want a fictional operating system,
“””
Rumor has it that the system kernel is written almost entirely in INTERCAL, with just a smattering of asm. 😉
Not to say that a fictional OS is pure fiction… just think of GNU/HURD
What a relief! I’m tired of the rest of those dysfunctional Linux distros.
Just reading through the papers and it seems very interesting. Imagine installing/upgrading/downgrading software without dependancies problems. Imagine as a software developer you don’t have to waste hours trying to get your app in every distro.
Add security etc on top and you might get a fine stable system.
I truly hope this thing gets adopted.
I’ve just installed it and tried it out. Here’s my take (comparison with Zero Install from http://0install.net):
Nix is a “purely functional” package manager. It is purely functional in the sense that each version of a package has its own directory. As with Zero Install, “upgrading” creates a new directory for the new version, rather than modifying the existing one. Unlike Zero Install, however, whether a package is installed affects the behaviour of the system. For example, running “firefox” when Firefox isn’t installed produces an error in Nix, whereas in Zero Install it will install Firefox first if missing and then continue. In other words, installation has side-effects in Nix.
Additional feeds (e.g. for pre-built binaries) can be registed using “nix-channel –add”, which appears to work much like “0launch –feed”, although each channel can contain binaries for multiple packages.
Each version of a package has a digest, which includes all build dependencies (e.g. the version of the compiler used), just as it does in Zero Install (for packages built using 0compile, at least).
One difference between Nix and Zero Install is that Nix treats configurations as packages. Changing your configuration is like “upgrading” your configuration package to a new version. Rolling back a change is like reverting to a previous version. Zero Install doesn’t generally handle configuration settings, preferring to let the user use subversion for that, but it’s an interesting idea.
Building a Nix package involves creating a “Nix expression” in a (custom) functional language. The expression fills the same role as a Zero Install source feed (it says where to download the source, what its digest is, what the build dependencies are, and how to build it).
While Zero Install is mainly targeted at adding additional packages to an existing system, Nix aims to manage the whole system (although it installs cleanly alongside your existing package manager). Nix packages have short names (like “perl”) not full URIs, and thus it appears to assume a centrally-controlled repository. Nix does not currently appear to sign the channel files.
Can mutually untrusting users share packages safely? The manual says “A setuid installation should only by used if the users in the Nix group are mutually trusted, since any user in that group has the ability to change anything in the Nix store”, which sounds like a “No”, whereas Zero Install support this: http://0install.net/sharing.html
How are channels secured? I had a look at a MANIFEST file, but didn’t see any kind of signature. I was never prompted about keys, etc.
Are packages namespaced? Dependencies seem to have short names (like “perl”). Presumably there’s a central authority that assigns names?
I’ve only had a brief look though, but it’s good to see more people developing systems like this. Corrections welcome!
Edited 2007-04-01 20:17
Tom, I voted this up, brilliant review, wanted to vote it up some more!
A lot of good ideas there. Lets hope major distros take note.
This surely looks great.
Rollback, multiple versions.
Ubuntu should look here for inspiration.
I’ve installed the OS yesterday and tried it for two hours or so, so I don’t say that my opinion has most insight. Apart from the fact that the OS still needs some maturity, there is what I’ve found out.
To manage your OS configuration, you have to edit a central configuration file in /etc/nixos/configuration.nix. It’s yet another configuration format with hashed and tables. Once the changes are done, you use `nixos-rebuild` to apply the changes. You can choose to apply the changes directly, after reboot or only provide a boot option. The new configuration will be added into the grub menu, so that you can choose on what configuration you want to boot. In other linux OSes, you only get extra entries after kernel upgrades. This is an interesting option.
While trying to install the OS, I had to edit that central configuration file multiple times to get the syntax right. Apparently the parser is not very robust because some lines require a ; at the end, but not all. I won’t go into the detail, since it’s an implementation matter, but the backtrace was pretty useful.
You also use that file to enable various services. For example, you can enable apache by adding “httpd = { enable = yes; }”. You also have keys to choose the process’s user, hostname, etc.. But, for example, vhosts are not supported. The problem I see here, is that every software that runs as a service must be supported by the configuration framework. I don’t know how much work it is, but it seems a lot to me. Imagine all the configuration generators that you need for a complete system ! Just to fully support apache it already seems complicated.
On the user side, you have all the nix-* commands. They are used to build per-user packages. For example, if you need subversions, you’ll use `nix-env -i subversion`. The package gets downloaded and compiled (if necessary?). All those packages are located in a complicated path that I don’t remember. Binaries and such are then symlinked into your “user-configuration” package that is also in a complicated path. In the end, you’ll have lots of long paths in your env and lots of symlinks.
Once the package are adapted to the system, package dependencies seems to work pretty well, as you can have multiple versions of the same package installed without affecting the system. In the fact, that problem becomes trivial and you don’t have to rely on SLOTS or other “hacks” like in other distros.
The downside, from what I have seen, is that you need more work than for example in Gentoo or Arch to package your software. You only have “sh” in the /bin folder, so you have to make sure to not use absolute paths. After having installed firefox, I had to edit it’s launch script to remove absolute references to /bin/env and /bin/ls for example. I don’t know if it’s a goot thing(TM) but it surely needs more work to get packages working correctly.
So the system looks really interesting and I’ll surely come back once they support the madwifi drivers. I’m not sure that this approach is the best but at least it’s really original.
Cheers,
zimbatm
I wonder how a merge of this, GoboLinux and Ubuntu would end up?
Just imagine, multiple versions from Nix, readable directory names from GoboLinux and the simplicity of Ubuntu. That would be great!