Feature: System Administration

Nix fixes dependency hell on all Linux distributions

A next-generation package manager called Nix provides a simple distribution-independent method for deploying a binary or source package on different flavours of Linux, including Ubuntu, Debian, SUSE, Fedora, and Red Hat. Even better, Nix does not interfere with existing package managers. Unlike existing package managers, Nix allows different versions of software to live side by side, and permits sane rollbacks of software upgrades. Nix is a useful system administration tool for heterogeneous environments and developers who write software supported on different libraries, compilers, or interpreters.

Why provide yet another package manager? Because current package managers fall short in the upgrade cycle. Everyone gets burnt by software dependencies, at some point. In particular, with a major release of any given distribution, many people choose not to upgrade until it is time to do a fresh install. With Nix, upgrades are always safe: they don't overwrite previously installed packages. This means previous versions will continue to work, and you can easily roll back.

Nix started as an academic project at Utrecht University in the Netherlands. The name is tongue in cheek; in Dutch it means "nothing."

All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible.

Suppose you upgrade Firefox, and your package manager decides that you need a newer version of GTK as well. If the new GTK is not quite backward-compatible, then other applications on your system might suddenly break. In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one, because Unix programs tend to have many external dependencies.

Also, destructive upgrades make it hard to undo, or roll back, an upgrade. Unless you or your package manager makes a backup of all the files that got replaced, you cannot easily undo an upgrade.

Finally, while the package manager is busy overwriting all the files that belong to a package, your system is temporarily in an inconsistent state in which a package may or may not work properly. Hit the power switch on your computer halfway through your next OS upgrade and see if the system will still boot properly!

Usually, an upgrade of a package will make the older version disappear. Sometimes a package manager allows a few versions next to each other -- say gcc-3.4 and gcc-4.3. However, this only works if the packager has arranged for this by making sure that the two versions install to different paths. What if you want to test gcc-4.0.3 without disrupting your system? Or if you want to test software using different compiler, library, or interpreter versions and combinations? What if you want to try the latest beta version of an application without risking your existing installation?

Then there is the problem of multi-distribution support. Developers and systems administrators have no way of knowing what combinations of kernel, libraries, and packages a user is running. When a user tries to install some software and complains about a missing library, you can suggest he try to find the appropriate packages, but you have not tested them in the same combination of dependencies. You can ask him to build from source, but he may not be using appropriate versions of libraries and compiler. Even if you are lucky enough to work for an institution that standardizes on a single distribution, you may find users' libraries are outdated and do not support the software you want to deploy.

Existing package managers do well enough in furnishing stable systems because they depend on a long period of testing by a lot of people. However, when users need more recent software, because of a bug or some missing functionality, they turn to so-called "testing" or even "unstable" packages, which often come with a range of dependencies that also get updated on the users' systems, potentially introducing instabilities in other software that depends on those components.

Nix has a more graceful approach that lets different versions of software coexist. Rather than installing packages in global locations such as /usr, it instead stores each package in its own directory under /nix/store. The top-level directory for each package contains a cryptographic hash based on all the inputs used to build the package. That creates a unique identifier such that multiple versions of a package don't interfere with each other, and different packages on your system can use different versions of some dependency without causing a conflict. This means that you can atomically upgrade and roll back packages.

Getting started with Nix

Ironically, the best way to install Nix is to fetch and compile it from source using the normal ./configure ; make ; make install commands, as root, as this will work for any system, including Mac OS X and the BSDs. You'll need a standard GNU g++ build environment and curl installed to bootstrap Nix. Once Nix is installed it no longer depends on those tools. Nix stores packages and some metadata under the directory /nix, so make sure there is enough space there. If / doesn't have enough space, either use a special partition for /nix , or bind-mount /nix to a filesystem that has 5 to 50GB of space available. You should also add the file /usr/local/etc/profile.d/nix.sh to your bashrc file. It sets up some environment variables (like $PATH) that Nix needs in order to work properly.

Once Nix itself is installed, you can start using it to install software. You can get Nix Packages (Nixpkgs), a large collection of packages for Nix, by downloading it from the Nix Web site or checking it out from its Subversion repository. However, the easiest way to use it is to subscribe to the Nixpkgs channel, which is just a way to distribute the latest version of Nixpkgs automatically to users:

Nixpkgs consists of a large set of Nix expressions, which are Nix's language for describing how packages are built, similar to Gentoo ebuilds. Nix is essentially a source-based package manager, like Portage, but Nix will automatically download precompiled binaries of packages if it can locate them by their hash values. The Nixpkgs channel contains a lot of precompiled binaries, which speeds up package installation significantly.

Once nix-channel has downloaded Nixpkgs, you can see what packages are available. The nix-env tool acts much like yum and apt-get. You can see a list of packages by running nix-env -qa '*', or to list all the packages named Firefox, nix-env -qa firefox. That should return a list like:

Installing a package with dependencies

To see the power of Nix, let's say you want to install Firefox 2, with all its dependencies and a bunch of plugins, such as Flash, without overwriting anything on your existing system. Just type nix-env -i firefox-2.0.0.17-with-plugins and Nix downloads and compiles these packages. Even though firefox-2.0.0.17-with-plugins is not available precompiled in the channel, most of its dependencies are. Nix will download binaries where possible, and compile from source otherwise. Firefox has lots of dependencies, from the GNU C library to GTK. Your distro will already have most of these, but Nix installs its own copies to make sure that you get exactly the right versions and that they don't interfere with rest of your system. After all, nowadays, why not sacrifice a bit of disk space to get predictability?

So now you should be able to run the Firefox you just downloaded by simply typing firefox on the command line. (You may need to set the FONTCONFIG_FILE environment variable to /etc/fonts/fonts.conf to make sure it can find your system's fonts.)

Now let's try upgrading to Firefox 3, either with the command nix-env -i firefox-3.0.4-with-plugins, or nix-env -u firefox, which would have made Nix pick the latest version. After this, you should have Firefox 3 installed, but the old Firefox is not gone -- it has not been overwritten. The two versions automatically end up in different paths:

You can see from this why packages do not interfere with each other. You can run either version of Firefox cleanly from the above paths.

Outside of Nix, you can still use the installed packages on your native system. The Nix packages are extra and independent.

Profiles

One can invoke a program directly from its path, or by adding paths to the system's search paths, but the long path names obviously make this ugly. That is why nix-env automatically generates trees of symlinks to the installed packages automatically. To make this work, you would have in your $PATH something like ~/.nix-profile/bin, which points at one of these trees of symlinks. This is incidentally how Nix can do atomic upgrades and rollbacks: it just generates a new tree of symlinks to the new packages, then flips ~/.nix-profile to point at the new one.

You can have more than one of these trees of symlinks, or profiles, each containing different activated packages. This lets you set up a profile for a specific version of any application within a profile. For instance, you could set up a profile to try out the latest version of Firefox by entering the command:

nix-env --profile my-firefox-test -i firefox-3.0.4-with-plugins

then running ./my-firefox-test/bin/firefox (which is a symlink to the actual location of Firefox 3 in /nix/store) -- it won't affect your 'normal' Firefox in ~/.nix-profile/bin.

Rollback

Since installing Firefox 3 did not overwrite the old Firefox 2, it is straightforward to roll back changes. If you want to go back to Firefox 2, all you need to do is say nix-env --rollback to return to the previous situation.

Of course, you'll probably want to get rid of old versions eventually. If you are sure you do not need to roll back any more, you can say nix-collect-garbage -d to delete all unneeded packages from the system -- in this case Firefox 2 and any dependencies that are not used by some other (still enabled) package.

Creating your own packages

Finally, Nix comes with a domain-specific language for writing package descriptions. This functional yet straightforward language provides an elegant way of providing and maintaining packages with their assorted dependencies. A package for PHP with dependencies, looks like:

This Nix expression requires libxml2, among other packages, and allows a choice of SQL back ends on installation. Nix expressions come with a large number of commands for package definition, which usually makes package descriptions compact and easy to understand. At build time the environment is clean and isolated from all other libraries, so dependencies always have to be included explicitly. A missing dependency will always be detected, which is a great feature for software developers.

The ability to pass options to the package configuration allows for flexible package management. For instance, you could build a package with GUI support on desktops and without GUI support on servers. Stripped-down versions of software and even documentation are feasible with Nix. More complex examples can be found in the package source tree.

Conclusion

With Nix, you can use a rock-solid and stable distribution like Debian stable or Red Hat Enterprise Linux as a foundation. When you need to deploy recent software, not provided by the distribution, Nix provides support for multiple versions, complete dependencies, and rollback. Nix allows you to escape dependency hell by creating a predictable system for software managment.

Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 78.32.219.25]
on December 22, 2008 08:22 PM

This is just completely stupid. Debian hasn't had "Dependency hell" since apt was created. That's around the start of most of my time with Linux, which something like over 14 years now. If people want to keep using RPM or some similar package tool, getting dependency hell, and then reinventing the wheel, that's their problem. As far as debian-and-derivative users are concerned, the issue doesn't exist, and so we're hardly going to be convinced by solutions to something that doesn't need fixed.

As for installing different libs with every package... that's insane. It amounts to installing a xen virtual server for every package, which no one in their right mind considers viable for a simple desktop machine with potentially thousands of programs installed (yes, on debian, easily, I know redhat users are more limited ;). Creating a new OS install for each program is hardly a solution. Also, again, with debian, the few rare problems that this MIGHT fix are easily solved.

What we REALLY need is a package manager like debian's in every way, except for:

d) Auto-choosing and configuration of packages by FEATURES, not name. So if I say I want to use a database with object-orientation and a python dbapi interface, having previously said I want smtp mail services, it should uninstall mysql, install postgresql, uninstall my mailserver that doesn't support postgresql, install a mailserver that does use it, and configure it using the abstracted mail config I set in the network directory.

e) and, well, a few more things too. But god... stop solving things that are already solved, and work on a next-gen distro please. I mean, I'd be happy with even a distro that had decent package management and encouraged network-wide PKI (with your mailserver setup, database server setup, ssh setup, etc.) as standard.

Re: Nix fixes dependency hell on all Linux distributions

Posted by: Samuel Fogh
on December 22, 2008 09:09 PM

You are right if you talk about packages from your distributions repositories (packages built for your distribution and release), because the way packagers solve a dependency problem (new version of library not being backwards compatible) is to support both the old and the new version of the library or to patch the software if it's a simple fix. The real problems exists for third party "package" maintainers, a problem LSB tries to solve in a clumsy and short sighted manner. This package manager tries a different approach to the problem. I don't know about you guys, but I'm not going to be happy if UT2K4 stops working because some library version gets kicked for being deprecated. A solution to the problem could be a secondary package manager supporting any possible version of a library.

Re: Nix fixes dependency hell on all Linux distributions

yum is arguably equal to or better than apt-get... but let's not debate that. A lot of the issues have to do with the quality of packages and the deps put within them. Regarding repository size, check out DAG, rpm fusion, and/or EPEL for RHEL and you'll see it isn't so bad really.

Ok, now... your comments are ALMOST true with regards to Debian but you completely overlooked the solid argument made by the author in the article... what if you want something way newer than your distro currently offers? What if you want multiple versions? What if you want easy rollback? Seems like it is providing a slew of new features to me.

Regarding your comment about Nix being similar to creating a Xen virtual machine... I disagree. You can loose the benefits of shared libraries... but it isn't full machine virtualization... it is application virtualization... which is much lighter-weight than full machine virtualization. There was a pretty cool product called "thin-stall" that used this concept... install the app and everything needed to run it... and be independent. I believe thin-stall was for Windows apps and used Wine... but VMware bought it up... and it costs a fortune... so I doubt anyone is actually using it. :) Anyway, Nix is not a full machine but just an app. Now very heavy applications might require a lot of deps and memory for multiple versions of libraries to be in memory... but run of the mill applications shouldn't be that bad. It'd be a way to go back in time and compare OpenOffice.org 1.x, 2.x and 3.x on the same system without having to go the full-blown distro route. I would assume it'd let you go with something ancient just as it lets you go with something bleeding edge?!?

Now having said that, I do agree with the other features you recommend adding. Good job. I'm a big containers person and I'd like to see a package manager be able to build a container out of a package as well... so add that to the list.

Re(1): Nix fixes dependency hell on all Linux distributions

The problem is, the added packages are really NOT integrated with your existing system, and other packages (except those installed with Nix) can't use them by default. You will then have to remember which packages are installed with which package manager.

There is usually a reason why the distro has version XYZ of a particular program, which you will have to install as well if it is needed as a dependency inside the distro.

Re: Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 76.64.2.45]
on December 23, 2008 04:05 AM

It's not stupid, because the maintainers are the ones doing all of the incredibly hard work to resolve the dependencies for you behind the scenes. Nix takes an automated approach to dependency management that pretty much obsoletes the majority of the work maintainers must do. That's a GOOD thing, because it frees them up for more productive things which can only improve the progress of Linux and open source (not to mention all of the valuable VOLUNTEER time they're WASTING because of managing this crap).

Re: Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 66.17.143.99]
on December 23, 2008 06:42 AM

>> This is just completely stupid. Debian hasn't had "Dependency hell" since apt was created.

That's correct; Debian, by itself, doesn't suffer dependency hell. In your world perhaps Debian, and nothing but Debian, is sufficient. Among developers and other advanced users, however, things aren't as simple.

Perhaps you need a modified version of glibc. Some people need exotic versions of compilers to build embedded systems. Some people must regression test many versions of the same software; for instance app X must be tested with 10 difference versions of libfoo. Other people wish to continue using a old program that relies on features that have been deprecated in newer versions of certain dependencies.

Apt and its ilk solve only the simple use case. Your ignorance of anything other than the simple use case doesn't make efforts to solve the harder cases stupid.

Other examples of attempts to solve the same problem are found at NetBSD (pkgsrc, which supports multi-version packages, uses indirection via symlinks very much like NIX, and builds independently of the host OS) and at Microsoft (.NET via shared, multi-version assemblies). Consider your own ignorance before declaring this or that "stupid".

Re: Nix fixes dependency hell on all Linux distributions

I don't like the Nix approach, but the problems they mention are very real, major issues on GNU/Linux systems. Just because you are happy with the selections and versions of Debian packages and never want anything else, doesn't mean everyone else is like you. Debian's package management isn't any different from RPM, technically anyway. It's just that Debian maintainers are more disciplined. Still, you are locked into a set of certain versions of certain packages compiles with certain options chosen by them. It's open source and you can grab a tarball or alternate packages--which many people end up having to do at some point--and it won't be a fun experience.

A nice world is where you can just grab a package where the requirements are simply things like minimum kernel version, minimum memory, disk space, a network connection, etc. install and expect it works and doesn't break anything. Telling everyone to use Debian wouldn't solve that problem, even if they did... and it'd introduce other problems like, the difficulty of just installing Debian and the notoriously hostile to noobs Debian community.

The whole idea of each version of each distribution having its own special, package hierarchy was a seriously wrong turn for GNU/Linux as a whole. If it isn't the single biggest thing holding back widespread adoption of GNU/Linux, it certain is at least one brick wall on that path. To put this even simpler, people need to be able to buy or download a package and say, "Oh, yeah.. It's for Linux and I have Linux.", install and expect it works.

Re: Nix fixes dependency hell on all Linux distributions

Typical arrogance of a debian fanatic. Well, I assume he is a debian fanboy because he so vehemently defends debian's policy.

Please, before I even argue, fix your distribution's problem of splitting every package in 100 different parts and then send these guys complaining
on the ruby mailing list about it. For it is your distribution's arrogant stance that "we dont have any problem" that is the real problem in the first
case.

> As for installing different libs with every package... that's insane.
As is the idiotic debian solution to versioned binaries. What the heck is ruby1.8 ? It is a symlink to the binary ruby.

I laugh at these incompetent solutions. Why do you REQUIRE to have versioned binaries at all? And do you apply these
standards consistently? If one wants to use versioning, then versioning directories is the way to go.

> with debian, the few rare problems that this MIGHT fix are easily solved.
Yeah, typical debian attitude - we are perfect. We have no problem. Therefor nothing needs be fixed ...

But you know what is funny? Debian creates its own little niche, similar to the other big distributions.
These distributions become more and more incompatible to each other. You cant just easily mix
a .rpm with a .deb. Things will break soon.

This is not entirely debians fault alone, but it is the attitude such as above which spits onto users.

> a) Package manager gateways for closed systems like cpan, ctan, pear, etc
And another typical debian arrogance. Do you remember how python developers were annoyed
that debian crippled the default python install years ago by outfactoring required packages of python
standard install? I think it was setuptools or eggs, some thing that a "typical" python developer required.

A similar thing happened with ruby, and also with ruby gems. This is such a bullshit attitude, it makes me not
sad - it makes me very angry. And whenever I see "reasons" for such a solution repeated I will destroy them.

> b) Standardised, network-wide deployment and configuration (including hierarchical config and lockdown for EVERY tool/app on the system) by policies set in a directory like LDAP.

Dont give me the bullshit of the FHS and LSB. The whole notion of splitting packages and files everywhere is the wrong idea.

Apple has got it better than debian. Why? Because they arent governed by a bunch of monkeys in the first place.

Another useless dependency. Why need a user rely on these in the first place? I thought debian is so super secure.

> d) Auto-choosing and configuration of packages by FEATURES, not name.

Here, I actually find myself agreeing with you. However you go to the extent of UNINSTALLING something. I wonder if
debian apt/dpkg provides an easy way for this. I do not think so (and if it does, tell me how, so I can comment.)

> top solving things that are already solved, and work on a next-gen distro please.
I am not working on nix, or coding etc... I am just sympathetic for their cause.

Debian??

Have you tried installing a binary package of KDE4 on Debian Etch? I guess not.... Or try getting xorg 1.5 on Etch, equal fun.... I have done it, and ended up with a system where I could no longer compile packages because of a mix of glibc, libc and gcc that was not balanced. So I had to choose either moving to Sid entirely, or stay with a half broken system.

Nix gives loads of overhead, but it is at least an effort to combine a stable base and up to date desktop packages... Debian has a fine package manager, but unless you want to mix versions, you will soon find yourself wanting more recent versions of packages.

I myself would have preferred more effort on Autopackage, but Nix is a fine attempt to unify platforms. If it means that software providers can now issue Linux versions without having to bother for dependencies, that is a big pluse...

No, Unix does NOT have anything like "DLL hell"

"In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one,"

No, it is not.

In Linux (and most if not all Unixes) packages can specify to the installers whether they want just the latest version of a library. or a specific version, or anything later than a specified version. Different versions can coexist, and links are used so that to get the latest version, you don't have to know its version number.

In Windows on the other hand (at least up to NT; I haven't used Windows since then) the DLL specification is broken. If a DLL has already been loaded into memory, that's the version that will get used. So if you try to run 2 apps concurrently that want different versions of the same DLL, one of them is guaranteed to break. That's DLL hell. What happens depends on the order in which apps are started.

Nix fixes dependency hell on all Linux distributions

Nix is just one of many tools that is trying to address a shortcoming in the way that software is currently packaged for Linux; it's true that if you stick to the stuff in your distro's repositories, then you don't get "dependency hell", or (for those less inclined to gross melodrama) dependency conflicts. If you want to install a piece of software that requires dependencies your distro cannot provide (such as a newer version of glibc), you typically need to install statically compiled versions of the software.

Which means that you either need to hope someone statically compiled software for your OS, or you need to do it yourself. Nix et al are just providing an easier mechanism for this.

There's been a lot of griping about the "big freeze" model of development (q.v. Beranger' s big rant that lit up the blogosphere last week), things like Nix present an alternative to that model. GoboLinux is another project trying to do something like this, from what I understand.

Whether you agree with this approach or not, it solves a problem for some users. Time will tell if it's a good idea.

whoops

"Your distro will already have most of these, but Nix installs its own copies to make sure that you get exactly the right versions and that they don't interfere with rest of your system."

I was thinking it sounded ok (although not really necessary) until I got to that line. At which point I remembered all the DLL hell I used to have in Winblows... which starts with each app installing it's own.

And it installs everything in it's own /nix directory? So let's just start adding more new non-standard paths to Linux, and then insist on all packages using that? It's bad enough that KDE apps all want /opt, Gnome apps all want /usr and everything else uses /usr/local. Don't need even more.

Nix fixes dependency hell on all Linux distributions

From what I understand, this seems to be an ideal, distro-agnostic, package manager. Isn't this what we have been looking for? A way to consolidate all efforts into packaging across distros? (I may be misunderstanding nix concept, but I don't think I am.) I guess the question remains: why nix?

Why can't you just install apt on a fedora, or install yum on ubuntu? They all install into the base system, and therefore, mix and merge in a very ugly way. I guess you could set up apt or yum to install in its own directory to mimic nix. I don't know how that would work, but bet it is harder than simply that.

Obviously, this isn't the solution to all problems. Nothing is. But it is not hard to imagine that you could have a base install of any distro with its own package manager For example, use apt with ubuntu, and upgrade base apps and entire system with apt. However, for the majority of optional packages, you can install via nix, and upgrade the packages accordingly. This way, you could share package building across all distros, yet still have various distros with their own unique package managers and bundled apps. This could also be possibly cross platform with BSD, Opensolaris depending upon the package. Some packages can recompile cleanly across the unixes, but I don't know which ones. Sure I'm making it easier than it probably is, but this seems like a really positive thing.

Two words, names rather.

Re: Two words, names rather.

Posted by: Teilo
on December 23, 2008 01:44 AM

Give me a frickin' break! I've used Gentoo for many years. I KNOW how bad it gets when you want to do upgrades, unless you are constantly spending time staying on the cutting edge. Portage is exactly the wrong solution. How many times have you run revdep-rebuild? How many times, in the process, has this failed and left your system broken? How many times have your builds failed somewhere in the middle, and left you cursing, searching forums, and bug reports for a solution? Done a Perl upgrade recently? Python? Updated from Apache 2.0 to 2.2? Do the words "package >=XYZ is blocking package ABC-123-r13" mean anything to you? Ever wanted to install an ebuild that needed a new version of Portage, that needed a new version of Bash, that would not install because it was bloody blocked by the old version of Bash?

Gentoo is the worst possible example you could have named. In Gentoo, the entire bloody OS is a moving target all the time.

I stuck with Gentoo for a lot of years. I still love the sorry little bugger, like I love my senile, toothless, cursing grandpa. But you are out of your fracking mind if you think Portage is the solution to our packaging ills. All my new server builds are using the latest Ubuntu LTS, and let me tell you, my life has become so much easier after making that decision.
[Modified by: Teilo on December 22, 2008 10:24 PM]

Re(1): Two words, names rather.

Posted by: Fletch
on December 23, 2008 11:01 AM

I agree that Gentoo has its own set of issues when concerning portage ("hey I told it to do an upgrade but now I have these errors preventing such and such ebuild from running"), and that's really Q&A on Gentoo's devs to address, but do not say Portage is exactly the wrong solution. Portage is a very excellent solution, and while I don't think it is the greatest end user solution (as people who want to use packages are not interested in the notion of compiling), I do think that it could be used to generate channels for binary package building of libraries and apps to get the features (as mentioned earlier in this thread) that users want so that users can download the apps and libs tailored to their needs. Yes there are issues where "ebuild such and such is blocking such and such" in Gentoo, but I guess the same things exist within alot of package management. What Portage does do nicely is have the notion of "slots" allowing libraries and apps to live side by side. I note your reference of having to search forums for help in Gentoo, but I think your bias has blinded your total reason because if any user here states he or she never has to use forums/help for his or her operating system of choice would lead me to believe he or she is lying.

I think that Gentoo would be a good idea for all distros to use as the LSB as the way development should go... a development tool so to speak. But then the idea behind all of these operating systems we are listing is that we have choice in using what we want. When facing new users, I usually point them in the way of Ubuntu, as I want them to have a starting good user experience. People that have specific development needs, I point them in the way of Gentoo.

Getting back to the point, if Nix isn't your cup of tea, then simply don't use it. I certainly give it credit for doing what the authors attempt to accomplish, and perhaps it might have a good use in environments where different development groups exist and need different versions of libraries. I'm not really a fan of this, but this is simply the reality of what it is. Anyway, I'm going to investigate it and see if it can fill a need that certain users I support use.

Oh, and one more thing: while I recognize your life has become easier using Ubuntu, my life would be a rotting chaotic pit of hell if I had to use that on a daily basis for the kind of work I do, and it would be extremely confining. I think Ubuntu is a fantastic operating system as it his brought ease of use to numerous users who do not have alot of demands out of their operating system other than being a platform to launch their apps. However, for tweakers and power users, it just isn't the flexible animal that Gentoo is (and you are certainly entitled to disagree with me here as we are simply arguing chocolate is better than vanilla (and vice versa)), but noting that an anonymous poster tried saying Gentoo (and really Portage) solves all problems rather than discuss it (and is the real culprit in this thread), I figured I would straighten his and your nonsense out.

Re(2): Two words, names rather.

Posted by: Teilo
on December 23, 2008 05:59 PM

I have no problem whatsoever with Nix. I didn't say a word about Nix. You should read more carefully.

If I were intending on building a tweaked out system, I would still choose Gentoo. Gentoo is a tweaker's wet dream. But how many servers need this? Almost none, given that most servers need one or more of the following: Web, Mail, Samba/NFS, Database, various scripting languages. It does not make sense. The marginal speed improvement you will get in most server scenarios are more than negated by the hassle which Gentoo imposes on the Admin. In those cases where you DO need the bleeding edge, you almost never need it for the whole system. Need to generate -march specific code? Fine. Do it on a package-by-package basis where it makes sense. But saying, "If you need speed, you need Gentoo" is just wrong.

Blaming this on the devs vs. Portage is a meaningless distinction. When an ebuild doesn't work, what bloody difference does it make whether the devs or Portage is to blame? In the end, all it really means is that I cannot install a package. An OS is more than it's core technology. It is also the developers who build on it. To talk of the superiority of Portage when the devs are constantly breaking the dependency tree is to turn your OS into a Platonic kingdom (look it up).

And as for your note about using the help forums: I have never, not once, had a package install fail on Ubuntu. 15 server installs later, everything just plain works. In Gentoo, simple packages fail all the time.

So, that comes to the point of my original response: Gentoo/Portage is absolutely the wrong answer for a universal packaging system for all the reasons I cited. I'm sorry if you think that is my "nonsense" but I work in the real world, with real deadlines and budgets and bosses breathing down my neck. The words, "I'm sorry, sir, but the critical security upgrade for Apache didn't work last night. I found the fix on the Gentoo forums, but it will take me another few hours to rebuild all the packages that got broken" won't cut it here.

Not any more. There are ~x86 versions of Portage which handle this automatically. There are other Portage Tree package managers that do the same.

"Ever wanted to install an ebuild that needed a new version of Portage, that needed a new version of Bash..."

No. Never. How the hell did you get in that situation? Did you start an install last week on a 1.4 LiveCD?

"In Gentoo, the entire bloody OS is a moving target all the time."

That's *kinda* the whole point of the distro. However, you can leave your system in a pretty stable state. I have Gentoo boxes which haven't had anything other than Portage upgrades and security fixes applied to them in *YEARS*. If you don't do an 'emerge world', then you're not forced to upgrade *anything*.

Re(2): Two words, names rather.

Look - every one of your responses is besides the point. And by the way, way to go on the stereotypical response, "But there's a fix in the beta version!!!".

Go back to the post I'm responding to: Portage is about the worst solution to package management woes that Nix addresses, that you could possibly imagine. You fail to get what real business deal with, evidently.

"You can leave your system in a pretty stable state. I have Gentoo boxes which haven't had anything other than Portage upgrades and security fixes applied to them in *YEARS*."

Liar. If it were years, you would be dealing with the nightmare of Portage and security updates requiring new versions of key system components, requiring a rebuild of many other apps. Yeah. Deny it. Go ahead, fanboy. Gentoo rox0rz. If it duzn't work for U U R st00pidz.

Two Different Words

Re: Two Different Words

Posted by: Fletch
on December 23, 2008 11:04 AM

Same issues. I've seen Live Upgrade brings systems to a halt breaking them before. Perhaps it could be a user issue, but on the same token, I can just as easily reference how horrible Solaris manages the install of these packages via CLI on how HORRIBLE this experience is. If you are using a frame buffer, it goes rather well, but to manage the installs of the initial app list one wants, their dependency checker and installation menu makes dselect look good at times.

Nix fixes dependency hell on all Linux distributions

Yes debs, and rpms work great... because alot of package managers are putting in alot of hard work to make it so. People are saying apt works better than yum, which is true in some ways and false in others.
This solutions solves all issues with any other package manager, and the only drawback if that old dependencies which are no longer used will waste space, but since space is relatively cheap why not waste it?
Although, a secondary Package Manager, no thanks, I'd rather rely on the man hours of diligent package managers. When I see a distro based on Nix I will no doubt give it a good go though.

Nix fixes dependency hell on all Linux distributions

Nix is THE next-generation package management software, period. If you don't understand HOW and WHY it works this way, just shut up, and listen (you can't make any alternative suggestions that are worth something, anyway).

You know, there are times, when you should remain silent just not to show your ignorance.

Re: Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 66.81.33.19]
on December 23, 2008 07:57 AM

Well, you may know nix, but you sure don't know open-source. This whole discussion of which package manager is better to install binary packages is idiotic in an open-source world. Slackware has it right; provide a solid development environment by default, a set of tools to make building packages from source fast and easy, and take care of your own dependencies.

Re(1): Nix fixes dependency hell on all Linux distributions

Posted by: Fletch
on December 23, 2008 11:07 AM

I think all of us should stop assuming ignorance, tom foolery and the like. I think everyone posting here has his or her credit in the intellectual space in Linux, but should rather discuss rather than state "oh what I have is better than what you have"

Zero Install

Zero Install (http://0install.net/) shares some of the interesting properties of nix, but has other features (http://0install.net/matrix.html) like allowing end-users to install packages. Having two package managers bothers me, even though I in effect do that already with stow for certain (mostly cpan) packages.

Autopackage solves this problem better..

Autopackage enables you to choose where to install, but searches to see if you have each dependency and install only if not already there. Also, it doesn't use any non-LSB compliant directories (like /nix) or cryptographic anything weird like that. It's also been around a while. I think it's the best solution so far.. It has very easy to use tools for both packaging and installing (GUI or text).

The problems that remain with it are that there is no way to know what make-options were used in compiling dependencies and thus, re-using existing dependencies will sometimes break software. If I weren't already so busy with projects, do to things to improve Autopackage:
(1) with each library dependency, add a like-named file containing its make options with the extension to identify it, as such.. (e.g. liboss.so together with liboss.mk (text file containing make options and compiler version))
The underlying distribution doesn't do this, but every additional dependency could and should.
(2) build a client-server packager where the client determines what additional dependencies need to be downloaded then tells the server so it can download only what the individual system actually needs.
While autopackage can package up every possible dependency for you, it'll make for an unnecessarilly large download. So, unless the package has few or no dependencies or is shipped on CD, this kind of enhancement could do away with the last complaint I can think of (after enhancement #1).

Re: Autopackage solves this problem better..

Posted by: Fletch
on December 23, 2008 11:13 AM

True, but you could simply use ldd with grep for most situations to understand what is there. Noting if you know what you are looking for, it would be easy to make some sort of front end to do that so that you could re package what you needed to get the features you want. This is an interesting tool as well.

Re: Zero Install

Posted by: Fletch
on December 23, 2008 11:09 AM

Hmm, that may not be a bad idea. However, for a system engineer supporting the host, it would mean that he or she would have to dig through user directories to understand why apps are installed and where problems occur. But then, I don't know where it allows end users to install applications. This really is interesting, but if we are talking about installing services (web servers, application stacks), I don't think that would be a good fit in an enterprise role. This too is worth checking out.

Platform-less Poverty

"It's very sad to see that the Linux world is still stuck with this crap and still attempting to create the Yet Another Ultimate Package Manager because they're incapable of defining a platform."

This is about the only sensible thing anyone here (incl. the article) has said.

There also needs to be some discussion of who the audience is for any given packaging approach. Repositories and apt/yum are fine for trained sysadmin and dedicated tinkerer types. But they leave any would-be ISVs (learn that term and love it, folks) without any clear idea of of the software landscape occupied by their would-be target users... i.e. this nebulous 'Linux' thing lacks a stable platform where the app developer and end-user can meet (and where the developer can provide formal tech support without getting hopelessly bogged down in variability between distros).

I like Google Android for this reason: Its a true platform (containing Linux) that gives the user interface and programming interface equal weight. ISVs know they can confidently develop for it, using the supplied SDK as a reference/starting point, and also be able to lead the users through a predictable environment (i.e. provide effective support).

Note that TFA didn't even mention LSB. That should be impossible in an article about a new package manager for a particular platform. But the community here (geeks and other die-hards) just don't get it, and don't want to think about PC platforms, which are mainly commitments made by OSes to end-users and app developers that allow the two groups to use the system together without being managed by the OS vendor.

In short, these people get the personal computer concept even less than the purveyors of commercial Unix did.

If NIX is the primarly package manager

If NIX or something like that is the primary pakage manager you don't really have to waste a lot of space. If the pacakge manger only installs a different version of dependency if needed.

So for the standard package of the distro you will basically have a single version of all the package. But say you are installing a new version of firefox .. now if the gtk version is valid for the few version (exact or in the range) it will just install firefox. If a newer version of gtk is needed then it will install that .. and if another new package needed this new gtk .. that will get it automatically.

now one problem though is whether a hash can make the comparison of same version difficult. I would rather have all the options in building the package stored .. not just the hash and for dependency you define the options thats releveant to you .. (most cases very few .. like optimization flag don't matter in most cases) ..

This problem was solved with DOS

With DOS, everything was unzipped into its own directory, and the program could be restored to a backup computer merely by copying it over.

I've been making a living in computing since before you were born, before paper tape, with punch cards.

The Windows registry and DLL hell have their worst features expressed in these dependency problems, and it's why the Linux Desktop will never happen. Just how do you *recover* a crashed system?

A business is looking for effective solutions that are simple. Linux is even more complicated than Vista. Posted on Mac Tiger, I'm a Development Director for a nonprofit who uses SAMBA to tie together a herd of XP, 98, DOS(yes it's still needed) and Mac computers.

Re: This problem was solved with DOS

Sure it was. But comparing DOS with a multiuser and multitasking OS as Unix, Linux og Vista is like comparing apples and oranges. Remember I was running Desqview in DOS with a bulletin board system in the late 80's. The right thing to do is to ask yourself why OS today stores files like it does.

Linux is not complicated when you understand the basic logic in the system. It's only a matter of knowledge. And you can also like in DOS backup and restore files by copy in Linux too. So it's easy to create a backup of the system with only the basic tools from the OS itself. Try that in Vista or XP and you soon get the issue with locked files and then need some special backup tool.

I think the LSB standard should formulate a need package manager which in turn could ble implemented both in apt and yum with a common standard fileformat for packages. Then after a while the distros will be starting looking more and more alike in the basic system. Nix for me is a like a draft. Apt works good enough in Ubuntu.

Get off my lawn!

Posted by: Anonymous
[ip: 208.38.27.131]
on January 06, 2009 07:36 PM

DOS was single-tasking, single-user, had no inbuilt security mechanisms whatsoever, struggled to use more than 640K of RAM, had no hardware abstraction model and no standard method to implement reusable components. There was no dependency problem to solve!

Ah, those were the good old days...when every single app not only got put in its own self-contained directory. Of course, if you got a new printer and had 5 different applications that used a printer you might have to copy in 5 different "drivers" into 5 different directories, but that's OK. If you got one of those snazzy new "Vee Gee Aye" cards you needed to make sure all your apps supported it, as each accessed the hardware directly instead of through a standard interface, but that's OK too, because who needs graphics when you have such a "wonderful" command line interface and "advanced" scripting language to make those powerful "bat files"?

Heck, sounds too complex to me. I think CP/M had it solved. There was no graphics to speak of, unless you had a dazzler card or something..then you had ONE graphics app...to make pretty pictures...and that was it! No confusing directory tree either--just one nice, flat directory of files--and if you wanted to get fancy you could divide it into USER areas. You could only have what---15 of them, so you didn't need to know names...just put your WORDSTAR files in USER 0, DBASE files in USER 1 and so on, and take a sharpie and write the whole contents of the disk on the vast expanse of the 8 inch floppy dust jacket! Forget about that fancy ZCPR shell too--with all those advanced features like named directories and password protection of files you need a degree it's so complex..gimme the good ol' CCP shell any time!

Times have changed old man. All them young 'uns gotta have their Interweb, and you have to have security if you make it so all computers can talk to one another and so many people can use one computer. They all gotta have their "gooey" screens with little pictures and arrow pointers and mice. They all want "three dee" in their video games (all we had is Pong and we liked it dammit!). These newfangled computers have scads of peripherals to hook in and everyone wants dozens of applications installed, and these whippersnappers have the gall to expect ALL their toys to work with ALL their software! The nerve of them! That's why we have hardware abstraction and drivers that are reusable and *depended on* by multiple applications. With so many apps, and the expectation that they can all run at the same time within the confines of system memory, it made sense to come up with a way to share code in a standard way instead of having everything using different code (or copies of the same code) that do the same thing. Hence ANOTHER dependency after drivers--the shared library.

"Dependency hell" was CREATED out of that demand for "solutions that are simple". DOS computers just didn't do that much--they were solutions to simple problems. When the "problems" (expectations placed on PCs) grew in scope the "DOS way" became unwieldy. Nowadays ALL popular apps use graphics so they ALL need graphics drivers--thus they ALL now depend upon one standard set of shared libraries to handle graphics. Nowadays ALL computers support multiple user accounts and access control, so now they depend on a set of shared libraries and mechanisms for authentication and access control. Sure, it created the problem of "dependency hell" but can you imagine if your video card still needed separate code or "drivers" for EACH APPLICATION that used graphics on your computer? That'd be nuts!

I think this "nix" thing doesn't fix anything--It is a workaround that avoids shared components altogether (in a nonstandard way at that) instead of making shared component management work better. Sure, hard drives and RAM are cheap, but what about efficiency and application interoperability? I don't want to fill my drives with multiple copies of slightly different builds or versions of libraries--I want that space for my data thank you. The headline "Nix solves dependency hell" is catchy but it is untrue--it is merely a tool for *avoiding* the problem, at the expense of the advantages of shared components. As a stopgap to try the odd "black sheep" software it is fine, but it is not optimal as a "solution" that one could, for example, base an entire Linux-based OS distribution upon.

Also, the problem isn't really that bad anymore. Both RPM and DEB based OSes have repositories and package management tools like YUM and apt-get that track dependencies well and even manage updates with ease. If you are content with what is offered within the supported repositories you actually have a software management system notably superior to what Vista offers! And to you Debian fanboys out there--we are in the 21st century. Other package management schemes have caught up, and the devils in the details are either so minor or so technical in nature that Joe User doesn't give a damn...APT/DEB AND YUM/RPM BOTH WORK JUST FINE. Normal users are tired of such VHS/Beta battles, and with Linux we can accommodate both.

The SOLUTION isn't what NIX does, which is try to bring back elements of those DOS days. We need to refine what is out there to allow for cross-distribution compatibility in repositories and packages. LSB has made a valiant effort at trying to be a real solution but it is not a complete solution, as it focuses a bit too much on the dependencies themselves. There are means within package managers of all kinds to determine what package provides library/file 'x' and what packages depend on such a file, and executable headers could include version or build information and what not. There needs to be a distribution-neutral way to handle such "depends-upon" and "provided by" information. It might not eliminate the problem, but it would greatly reduce it, such that a Mandriva user could grab Fedora packages, or whatever.

Remember, "simple solutions" mean simple to USE. Building solutions that are truly simple for users can be tricky and require work. Otherwise, we'd be content with CP/M.

Re: Get off my lawn!

Posted by: Anonymous
[ip: 76.95.137.53]
on January 06, 2009 08:21 PM

NIX solves some very real problems for people that are using Enterprise Linux distros. Maybe you're running webservers on RHEL4? Maybe you're not excited about having to maintain your own software library/repository for all the newer versions of software you need for that use case than what is provided by the vendor. It's a major time sink and pain to have to build and test everything by hand (configure --prefix=/foo/bar-2.0.24 -execprefix=... && make && sudo make install). With a solution like this one, which is basically ports or Gentoo for on top of your distro, it does most of the heavy lifting for you. Disk space is cheap. Time is not.

Re: Security headache?

Posted by: Anonymous
[ip: 123.49.42.65]
on December 23, 2008 10:45 AM

and how it is not now. .. when debian or enterprise distro's will have two years old version of libs which needs to be packaged. It may happen now that a distro or package dev may update the dependency to refect the new updated (patched) lib and you can safely install it getting the fix whereas right now you may not be able to cause that update breaks something in your distro and it will take them a long time to fix the issue .. or backport the patch.

If you talk about the developer of the package who is fixing the bug .. and needing to apply it in every version of the package .. that can happen now all the same cause distro's are using different version (mostly not the latest) but thas mostly taken care of by distro maintainers.

Yes there are troubles on how exactly you manage the whole dependency since you can now have so many different combination .. version,patched .. but thats something every distro, maintainer already manages in their head .. I guess this would force everyone to be a bit formal or at least thats what my understanding is.

Re(1): Security headache?

Posted by: Anonymous
[ip: 132.79.7.16]
on December 24, 2008 02:23 PM

In Debian the answer is simple and easy: When the update is made available, port it to the Debian stable version of the lib, patch the source, remake the package (simple rebuilding of an existing package is pretty simple), bump the version so that it is now "higher" than the previous one, deploy the updated package to your own internal update servers. The next time that your Debian stable box looks for updates (you do have this on an automatic schedule, right?) it finds a new package, installs it, and is done. Since the depends are 99% likely to be the same nothing breaks.

Or wait for Debain maintainers to do the work for you and copy the package down.

This is just one more reason to keep all of your servers running the same distribution.

Re: Security headache?

Posted by: Fletch
on December 23, 2008 11:14 AM

Sure. It would be no different then noting what libraries/apps you have installed regardless how they are installed, and updating those that need security based updates. But again, in package land, this is much more trivial.

Nix fixes dependency hell on all Linux distributions

It's not POSIX-compliant but it could sit very nicely alongside a POSIX-compliant system as a platform for installing otherwise incompatible software. Sounds really flexible.

My concern is; is it too flexible? Could it become a vector for trojans? What will stop vital system components being substituted to create back doors? Will it have its own repository or allow any package to specify anything?

If a system were built from scratch using this it wouldn't be GNU, but a new OS using GNU and possibly other *nix components assembled in a new way. Would that be secure? The present model with packagers working very hard just to keep things working is very time-wasting, but it also provides control over what goes into a distribution. Would that control be lost to the point that the resulting OS would soon become a giant botnet?

These are huge issues to address. If they can be, then maybe this has a great future.

epkg?

Posted by: Anonymous
[ip: 24.131.41.49]
on December 23, 2008 01:54 PM

Nix sounds like epkg redone without the tgz source. Can anyone comment on the differences between epkg and nix besides the obvious?
- epkg doesn't download binaries
- nix doesn't create a pkg that includes the platform in the name

Nix fixes dependency hell on all Linux distributions

Gobo meets Autopackage?

Nix sounds intriguing, but at the end of reading this article I couldn't help but think someone tried to combine the concepts of Gobo Linux and Autopackage. Both are very nice projects, that never got the attention they deserve...so I'm a little pessimistic about Nix ever taking off itself.

The problem is in the Linux community we generally find 2 types of users: A. Thinks he/she knows so much about anything and everything, that there's no need to change the things they spent so much time learning to deal with already; B. Average Joe users who don't know anything about how their system works and why new ideas like this are necessary. Then we have a rare third type, who sees a project like this (or once again Gobo or Autopackage too) tries to help promote it, uses it as much as they can, then after a year or two gives up because the vast majority of users either don't know or don't care, and the new and exciting project fades into obscurity.

Maybe I'm wrong...but after 5 years in the Linux/open-source world this happens way too often...

The major problem is capturing dependencies, software needs to work together

Nix sounds interesting, but the really hard work is getting a large number of package maintainers to work together to make software follow rules so it can inter-operate. Debian's breakthrough was its policy that lays out rules that software packages (and its community of package maintainers) should follow. A really nice thing that apt does is support disjunctive dependency rules and the idea of virtual packages.

What is important for installing packages is capturing dependencies, satisfying them, and idempotency in the installation scripts. I don't want to have to find out myself that such and such a library is incompatible with firefox, nor do I want to have 400 slightly different versions of glibc installed on my system. What I want is Debian/testing, that is packages that have gone for two weeks without anyone filing major bugs against them and a consistent set of packages that work together.

Sure Debian could be better, but I think it's mostly about changing the policy document and improving the package building tools so that for the 90% case the tools just do the right thing for you. The thing that I don't like at present is that software starts when you install it and there's no way to turn that off. That makes doing installs into chroots to be later run on virtual machines difficult. It's not so easily solved.

The other thing in Debian is there isn't an easy way to create packages that do configuration for you. Lighttpd for instance gives you a vanilla install, but it would be nice to have a package that configures lighttpd in a particular way for you, e.g. sets it up users with home directories and installs a wiki or some such. Some thought is needed to setup packages to support plugin packages well.

Re: The major problem is capturing dependencies, software needs to work together

Posted by: Anonymous
[ip: 132.79.7.16]
on December 24, 2008 02:18 PM

And just as Debian has contributed something to the field, so has Nix. What Nix contributes, in its own horrifyingly unmaintainable way, is the idea of non-destructive updates. If you could combine that non-destructiveness, guaranteeing that unrelated things don't break by not disturbing them, with Debian's policies you might have something useful. It would make dependency resolution simpler if you never encountered "trying to remove foo so I can install foo2, but bar relies on foo" - just copy, version it, update your side and leave bar with a legacy environment. Some details would need to be worked out, like whether and how to flag orphaned environments for examination by the admin, some way to be sure that multiple copies of things are not kept unnecessarily, etc..

I think Nix, while not a solution itself, is a valuable contribution to the effort.

Nix fixes dependency hell on all Linux distributions

So how do you install your own packages from source. If thinks life in some obscure /nix subdirectory I'd imaging there must be some serious LDFLAGS/INCLUDES juggling going on. This really sounds worse than using something than any other package managing system.

Slackware is still best - no dependencies

Posted by: Anonymous
[ip: 130.208.84.4]
on December 24, 2008 11:05 AM

Well I still like Slackware the most, no dependencies and packages are simple tarballs with doinst.sh scripts, easy to make yourself when building your own. Slackpkg gives you some of yum/apt-get features if you want.

Duplication

While Nix has a somewhat novel approach to the problem their answer still leaves something to be desired.

1) Source-based
I know it can do binary, too, but as the article states it was intended for source-based installation and inherits all of the problems involved with that.

2) Duplication
As with the age-old debate about the merits of OS X style app bundles, what do you do about duplicated libraries (and other things)? Sure it's *useful* to have two different versions of Firefox, but now I also must have two copies of flash, two copies of each and every extensions I installed (and I must update them independently!). Multiply this out by a dozen programs and you start to encounter real pain.

Perhaps something similar to Nix which can also inter-relate things that are the same would be a viable solution. Imagine a kind of copy-on-write style of operation: As long as two apps rely on a particular version of a particular lib, one copy of the lib serves both apps. When one app is upgraded the 'new' app relies on a new version of the lib, the 'old' copy of that app relies on the old version, and the other app relies on the old version. When the other app updates to now rely on the new version, it re-points to the existing copy of the lib that was pulled by the first app. Basically, resolve dependencies as usual but, using Nix, don't break other things and smartly consolidate to the smallest set of files possible.

It would be hellishly difficult, I'm sure. You'd also really want some way to single instance configuration, where that makes sense, and make it version specific, where that makes sense.

One thing which I think would go a long way towards improving the situation: allow apps to link to libs by declaring a required set of exported symbols and not necessarily a specific version. Perhaps update the soname to include information about the compile time options that were used on the lib.

Nix fixes dependency hell on all Linux distributions

lol GOBOLINUX. I can run different versions of the same software. I can uninstall simply by deleting the file. Similar to how Mac OS X is run. All applications are in the Apps folder. Simple. Logical. Separated. Clean.
Good thing other linuces are getting closer. This kind of reminds me of Mac OS vs. Windows 1.0 -Windows XP. How every version of Windows is like Mac '85. Until Gobolinux's method is adopted by every Linux as the de facto standard, then Linux will always be a hobbyist platform with no chance for desktop acceptance.

Re: Nix fixes dependency hell on all Linux distributions

Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 65.33.222.2]
on December 24, 2008 07:23 PM

Most of the comments on this page are very ignorant. I've been using Nix and NixOS (the accompanying operating system which /does/ exist) for the last six months as my primary computing environment. Admittedly, the article does not explain the full power and underlying semantics of the system. Before judging the entire system with platitudes checkout the actual Nix documentation. There are /significant/ advantages and drawbacks to the system - neither of which seem to be adequately addressed here.

Nix fixes dependency hell on all Linux distributions

It is impossible to write a short article that does NIX justice - linux.com allows short articles only. I agree people really interested in the concepts ought to dig into the white paper(s) on NIX. In particular the functional language approach for expressions is of great interest and simplifies managing complex packages greatly. NIX is more than a simple answer to dependency hell and includes a full-blown distribution named NIXOS.

The article was written from a single use case perspective: it gives a great answer to a real problem for both developers and system administrators alike with regard to dependencies. In response to some comments above: I have been (and still am) an ardent Debian user. However, NIX saves the day when it comes to complex dependencies. I think packagers should consider a Nix-like approach to make systems more predictable and provide true roll-back on upgrades. The technology is here. Debian does not do proper roll-backs, nor Slackware nor any other main stream packager.

And for those who can't wait - Nix works in all environments, including the BSD flavours. Even better: the learning curve isn't steep at all. We hope people will find this article useful when they hit mentioned infamous conflicts. You can consider yourself lucky if you are unconcerned.

Nix fixes dependency hell on all Linux distributions

What ?! Debian doesn't have dependency hell ?! Bullshit!
Debian's dependency hell shows up in the very fact they can't even release in a predictable schedule.
Furthemore, Debian does not differentiate between "base" system and "userland" software (such as *BSDs do). Therefore, even your kernel package might be accidentally uninstalled - and this HAS happened - see the paper:

Nix fixes dependency hell on all Linux distributions

I downloaded and run nixos iso in VirtualBox.. After running nix-env -qa firefox, I get an error saying:

error: while evaluating the attribute 'config' at '/etc/nixos/nixos/system/system.nix', line 18
while evaluating the function at '/etc/nixos/nixpkgs/pkgs/lib/default.nix', line 448:
..
..
getting status of '/etc/nixos/configuration.nix': No such file or directory

Downloading NIXOS now to see if it has wings

Aside from being a possible escape from the clutches of corporate-lockdown (M$use/Comical/RadHad/etc)
or package-lockout (the rpm x apt religious wars),
it appears to have some real potential.

Imagine loading this thing up once and never needing to upgrade_X_install another distro ever again?
System upgrades would be incremental adjustments
rather than the entire-operating-system-and-dataset-gambling ritual
we endure every time we get tempted by the
latest and greatest new distro release (complete with errata and 'known-issues' klingons)
That is a staggering thought....
.>:<.
============================================
from a NIXOS discussion elsewhere we see this clarification

> Someone who tried Nix from the Linux.com article:
>
> I downloaded and run nixos iso in VirtualBox.. After running nix-env -qa firefox, I get an error saying:
>
> error: while evaluating the attribute 'config' at '/etc/nixos/nixos/system/system.nix', line 18
> while evaluating the function at '/etc/nixos/nixpkgs/pkgs/lib/default.nix', line 448:
> ..
> ..
> getting status of '/etc/nixos/configuration.nix': No such file or directory

?? Wow.

I guess you know what /etc/nixos/configuration.nix is about?
It does contain the configuration of the system.
I've never tried running nix-env -i from the booted cd so I don't know
wether it's even supported?

The default way to install nixos is mounting the target partition on
/mnt and create configuration.nix on the mount point
(/mnt/nixos/configuration.nix).
But this is all described herehttp://nixos.org/releases/nixos/unstable/manual/ (Or on ctrl alt F10 or so).

Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 198.140.183.1]
on January 05, 2009 09:12 PM

A word from the non-technical end-user. All modern package managers seem to work quite well, are simple to use, and avoid "dependency hell". The problem arises when one's needs or wants transcend the limits of the approved repositories and methods of installation. Then there is the temptation for the unknowing to try to compile from source, interconvert deb and rpm with alien, etc, which may cause breakage of the system.

I know this is heretical, but I think in the long-term something like PCBDS's PBI system is the best bet for newcomers. I know it lacks the elegance and sophistication of the package managers, and I understand that the notion of multiple, redundant versions of libraries (packages) is wasteful. However, PBIs cannot break the system, do not dependent on the continued care and maintainance of repos, do not require sophisticated package management systems, and are easy to install and simple to uninstall.

I doubt the *nixes will make much headway in terms of market share, until such time as one can point a browser at a popular software download site, download any package, click on it and have it install into any "distro" (even if the current package manager system is more logical, more efficent, "better").

Re: Nix fixes dependency hell on all Linux distributions

Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 192.168.1.150]
on January 14, 2009 05:39 PM

Hmm.. I'm a little bothered by the inclusion of FreeBSD's ports in this mess, as I don't really see how that's true. Perhaps FreeBSD (binary) packages could suffer from this, but the ports system compiles from source. Portupgrade is also an extremely powerful tool, used as portupgrade -arR there is theoretically zero chance of having dependency issues as it will take care of both dependencies and programs/libraries which depend upon it. If your worried about core OS libraries, which are typically pretty stable, force a recompile of everything after an OS update and you got yourself covered. I am in no way claiming my solution is the best, I just know what works for me and as far as my job is concerned, that is all that matters.

Re: Nix fixes dependency hell on all Linux distributions

Posted by: Anonymous
[ip: 70.74.186.82]
on January 16, 2009 05:13 AM

I say this as a BSD user and fan: portupgrade sucks. I've seen it get stuck on circular dependencies more than a few times, and on large upgrades using portupgrade -arR, it's not unusual for me to have to go to the machine, manually upgrade (or outright remove) a dependency, and restart the upgrade process several times. The situation is a little better if you tell portupgrade to use binary packages where available, but it's not much better and FreeBSD's binary packages tend to be pretty out of date compared to what's in the ports tree.

The BSD's have their own advantages and reasons for using them, but portupgrade is NOT one of them. I'll take it over portage any day of the week, though. That shit is heinous.