===
On NixOS, you do not need to be root to install software. In addition to the system-wide ‘profile’ (set of installed packages), all user have their own profile in which they can install packages. Nix allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure. Users cannot install setuid binaries.
===
Requirement to be administrator to install software is the root of all evils in managing OS.
As far as keeping everything in a special location (/nix or whatever), this reminds me SCO OpenServer 5: they had all the files somewhere in /var; /bin, /sbin and everything else were just symlinks. It did not work all that well.
Some of the ideas seen in NixOS can also be seen in the Image Packaging System (Atomic Upgrades, Reliable Upgrades) project: https://java.net/projects/ips/pages/Home
Disclaimer: I'm also one of the IPS authors, so I agree with some of NixOS' ideas :-)
I read one article and skimmed the other under "Background reading" but I could not spot what the core philosophy or mechanic of how you are producing atomic and reliable upgrades.
I try to stay abreast of package systems which have the same or close feature set as nix. If you have a moment to explain the core mechanic or a reference it would be much appreciated.
The future you describe is the distant past for many of us.
We've been using chroot, FreeBSD jails, Solaris Containers, and similar technologies for many years now. Combined with the basic functionality of UNIX and UNIX-like systems, we can quite safely isolate users, apps and data, but without the overhead and inconvenience of heavy-weight virtualization techniques. Even then, these techniques are quite new relative to what's been available to mainframe users for many decades.
Sure, nixos is very forgiving to experiment with because you can easily rollback to a pervious configuration. Modify a library and something stops working fixing it is as simple as `nix-env --rollback` for a user package and `nixos-rebuild --rollback` if something was changed with the system configuration a restart may be needed if some systems are touched but it has not happened often and when it is needed it is specified.
I enjoy how easy it is to set up different profiles with different sets of libraries/compilers for development.
It has made it worth while to try out old libraries that only work on old compilers. It also made it easier for me to test against the HEAD of the complier repo for testing forward compatibility or new compiler features.
Since everything is nicely encapsulated once I have an environment working on my laptop I can use `nix-copy-closure` to move it to another remote server. `Nixops` a more recent offering just renamed from `charon` also allows for deterministic building of ec2 instances.
took me a while to figure out. nix-env -qa * | grep "package you are looking for"
nix-env -i "package"
need to add different channels if you are grabbing packages from places other than nix-pkgs.
I had a hard time, getting some haskell packages to work, because nixos symlinks all the binaries, and there was some encryption library dependency, hard coded in a cabal file, and it was a headache/ gave up.
Eelco also provides a pathelf utility for modifiying dynamic linker in elf files, I haven't used it.
I'm on ubuntu again but I can't remember why. Oh ya, I couldn't get Blackberry's SDK working on nixos. Anything that doesn't go through nix-pkgs, will take some work. I didn't get to the point where I was writing nix-expressions.
Other than that it works fairly well (in a VM), and you don't need to wait for it to compile all the packages like with Gentoo: if the build server has a binary then it will download that.
The way they install multiple versions of applications and manage the dependencies reminds me of GoboLinux. I like the direction of this. Really like how they named everything though in Gobo.
I remember playing with Gobo several years back. Although renaming system directories makes it a bit more approachable to newcomers, it also makes it less language independent and less recognizable to the users who typically need to use it (sys admins and such).
However, the general idea of installing things in a self-contained directory was fantastic, and I'm happy to see another operating system trying something similar. I used to use PC-BSD regularly, whose package manager also does this:
I tried this distro 2 times since I heard of this rootless package administration. I give up because of poor documentation in both situations.
I would love to see this approach in arch or gentoo (without the butthurt of slots)
That is too bad it has worked fairly well on vmware for me. I have also enjoyed using the nix package manager on my macbook as well.
The documentation can be lite on examples but it is very forgiving distribution to experiment with and I do not see to bump in to corner cases as often as I have on other linux flavors/package manager.
Having installed NixOS over a year ago, I was really impressed with the package manager. It's wonderful to be able to have multiple versions of GCC, haskell, etc side by side, so you can debug some of the reasons why your program works in one user's version/environment but not the other's. The actual papers are an interesting read as well.
I've long suspected that something like this was the logical end point. Ever since I found myself writing a Puppet manifest that created an Upstart entry.
Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc".
Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL".
Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system.
Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy.
Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other.
Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.
Nix is an experimental Research OS exploring what you can do with a pure functional package manager. This is interesting. You are probably being downvoted because your comment looks like a poor attempt to cash in on the "What linux needs is another..." meme for some easy karma.
But let's take you at face value. Maybe you were serious in your assertion.
While Ubuntu, Debian, Fedor, Gentoo, and many other distros use very mature, robust and all around awesome package managers I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons.
Nix fixes exactly this problem while still maintaining many of the same benefits as the other package manager. So maybe Linux does need another package manager.
Or at least it needs people willing to play around with solving issues in the current package managers in a "research" setting perhaps?
[+] [-] foohbarbaz|13 years ago|reply
=== On NixOS, you do not need to be root to install software. In addition to the system-wide ‘profile’ (set of installed packages), all user have their own profile in which they can install packages. Nix allows multiple versions of a package to coexist, so different users can have different versions of the same package installed in their respective profiles. If two users install the same version of a package, only one copy will be built or downloaded, and Nix’s security model ensures that this is secure. Users cannot install setuid binaries. ===
Requirement to be administrator to install software is the root of all evils in managing OS.
As far as keeping everything in a special location (/nix or whatever), this reminds me SCO OpenServer 5: they had all the files somewhere in /var; /bin, /sbin and everything else were just symlinks. It did not work all that well.
[+] [-] dEnigma|13 years ago|reply
Pun intended? ;)
[+] [-] alcidesfonseca|13 years ago|reply
[+] [-] gnoway|13 years ago|reply
[+] [-] binarycrusader|13 years ago|reply
Disclaimer: I'm also one of the IPS authors, so I agree with some of NixOS' ideas :-)
[+] [-] davorak|13 years ago|reply
I try to stay abreast of package systems which have the same or close feature set as nix. If you have a moment to explain the core mechanic or a reference it would be much appreciated.
[+] [-] noonespecial|13 years ago|reply
[+] [-] PommeDeTerre|13 years ago|reply
We've been using chroot, FreeBSD jails, Solaris Containers, and similar technologies for many years now. Combined with the basic functionality of UNIX and UNIX-like systems, we can quite safely isolate users, apps and data, but without the overhead and inconvenience of heavy-weight virtualization techniques. Even then, these techniques are quite new relative to what's been available to mainframe users for many decades.
[+] [-] skrebbel|13 years ago|reply
[+] [-] laurentoget|13 years ago|reply
this talk by Eelco is a good introduction for hacker types. And the motivation is at the beginning of the talk.
[+] [-] yowmamasita|13 years ago|reply
[+] [-] aphexairlines|13 years ago|reply
Here's another example that's not public, and not really a distro, but... http://stackoverflow.com/questions/3380795/what-does-amazon-...
[+] [-] lholden|13 years ago|reply
[+] [-] drdaeman|13 years ago|reply
[+] [-] GigabyteCoin|13 years ago|reply
Does anybody have any experience/testaments to post about this OS?
[+] [-] davorak|13 years ago|reply
I enjoy how easy it is to set up different profiles with different sets of libraries/compilers for development.
It has made it worth while to try out old libraries that only work on old compilers. It also made it easier for me to test against the HEAD of the complier repo for testing forward compatibility or new compiler features.
Since everything is nicely encapsulated once I have an environment working on my laptop I can use `nix-copy-closure` to move it to another remote server. `Nixops` a more recent offering just renamed from `charon` also allows for deterministic building of ec2 instances.
[+] [-] jrn|13 years ago|reply
need to add different channels if you are grabbing packages from places other than nix-pkgs.
I had a hard time, getting some haskell packages to work, because nixos symlinks all the binaries, and there was some encryption library dependency, hard coded in a cabal file, and it was a headache/ gave up.
Eelco also provides a pathelf utility for modifiying dynamic linker in elf files, I haven't used it.
I'm on ubuntu again but I can't remember why. Oh ya, I couldn't get Blackberry's SDK working on nixos. Anything that doesn't go through nix-pkgs, will take some work. I didn't get to the point where I was writing nix-expressions.
[+] [-] edwintorok|13 years ago|reply
Other than that it works fairly well (in a VM), and you don't need to wait for it to compile all the packages like with Gentoo: if the build server has a binary then it will download that.
[+] [-] ztzg|13 years ago|reply
http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00034....
It shares concepts and some bits with NixOS, but replaces the configuration language with Guile, an implementation of Scheme.
[+] [-] snowpalmer|13 years ago|reply
http://wiki.gobolinux.org/index.php?title=The_GoboLinux_File...
[+] [-] gw|13 years ago|reply
However, the general idea of installing things in a self-contained directory was fantastic, and I'm happy to see another operating system trying something similar. I used to use PC-BSD regularly, whose package manager also does this:
http://www.pcbsd.org/en/package-management/
[+] [-] oakaz|13 years ago|reply
[+] [-] vdm|13 years ago|reply
http://www.listbox.com/member/archive/182179/2013/05/sort/ti...
[+] [-] brini|13 years ago|reply
http://lists.debian.org/debian-devel/2008/12/msg01027.html
[+] [-] cwp|13 years ago|reply
[+] [-] gfxmonk|13 years ago|reply
[+] [-] topbanana|13 years ago|reply
[+] [-] davorak|13 years ago|reply
Package A could depending on glibc-2.13 and package b could depend on glibc-2.17. No conflicts would because by both running at the same time.
[+] [-] qznc|13 years ago|reply
[+] [-] davorak|13 years ago|reply
[+] [-] durbatuluk|13 years ago|reply
[+] [-] davorak|13 years ago|reply
The documentation can be lite on examples but it is very forgiving distribution to experiment with and I do not see to bump in to corner cases as often as I have on other linux flavors/package manager.
[+] [-] yarou|13 years ago|reply
[+] [-] subprotocol|13 years ago|reply
[+] [-] jacques_chester|13 years ago|reply
Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc".
Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL".
Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system.
Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy.
Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other.
Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.
[+] [-] drivebyacct2|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] denysonique|13 years ago|reply
[+] [-] vitno|13 years ago|reply
[+] [-] durbatuluk|13 years ago|reply
[+] [-] mbell|13 years ago|reply
[+] [-] zaphar|13 years ago|reply
But let's take you at face value. Maybe you were serious in your assertion.
While Ubuntu, Debian, Fedor, Gentoo, and many other distros use very mature, robust and all around awesome package managers I still run into issues where a package is uninstallable because of some other package that it depends on is pinned, or the wrong version, or any number of other reasons.
Nix fixes exactly this problem while still maintaining many of the same benefits as the other package manager. So maybe Linux does need another package manager.
Or at least it needs people willing to play around with solving issues in the current package managers in a "research" setting perhaps?
[+] [-] noonespecial|13 years ago|reply
[+] [-] banachtarski|13 years ago|reply