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?
Case in point: I had to upgrade some Debian VM's with Postgres 9.0 to Wheezy with Postgres 9.1 a while ago. They were messy combinations of mostly Etch + parts of Lenny and Squeeze, as a legacy of rushed upgrades. And while upgrading Debian version by version mostly runs smoothly with apt-get, there are some very nasty gotchas:
- You always need to upgrade apt and dpkg step by step, as if you're careless, you'll leave your system with an apt and dpkg that can't install most of the following upgrades, including the next available version of itself due to external dependencies on packages that are only available in a format your current version of dpkg/apt does not support. You then need to downgrade. Problem is you then run into utter dependency hell. Generally the solution is to --force-all install an older version of dpkg from /var/cache/apt/archives, then update and try again.
- If you're not very careful with the apt sources when doing a Postgres upgrade, you risk having Debian install 9.1 and remove Postgres 9.0. Problem is, if it removes 9.0, you can't run pg_upgradecluster, because that requires the old Postgres to exist and be running. Now, reverting is suddenly a big problem unless you add the Postgres teams own Debian repository.
This isn't particularly a criticism of Debian (though I dislike the fact that dpkg and apt-get have external dependencies - if there's anything that should be built statically, it's a package manager) - if you do things carefully, and step by step, things will work fine and you "only" need to learn a couple of rules of thumb (First, always make sure to upgrade version by version, apt-get update, apt-get install dpkg apt). These are hairy edge cases... But they'd be so much less of a problem with easy rollback and/or ability to pull in multiple versions easily.
> 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.
I ran in to this problem quite often when trying out science or numerical libraries and is one of the reasons I run mostly on nixos now.
I think this comment from jacques_chester [1] does an excellent job at explaining why it is important to break free from this mindset periodically. It is all about busting out of local maxima in the efficiency of our tools.
Local maxima, exactly. We often lose sight of how and why we are at a particular maxima and assume that the current layering is the only acceptable layering.
But sometimes it's just accidents, or was just the shortest path to a working system, or lots of little local solutions that agglomerated into larger global solutions.
Every once in a while punching through the old layers is useful. Not always. Sometimes. Having a sense of history makes this easier ... and harder.
Sometimes the outcome is so stunningly obviously better that everyone slaps their foreheads and wonders how it could have been any other way.
Other times ... well, other times we all spend our workdays arguing about it on HN.
Why doesn't it need any more fragmentation? Your argument is begging the question. Personally I think people are better off with 50 kinds of spaghetti sauce.
Improve in what way? This puts any design change off the table forever. I don't see anything wrong with a rethink, as long as it's motivated. Maybe the motivation has not been well-stated - but maybe you haven't made it any clearer that dpkg or rpm are the optimal package managers (barring a few little 'improvement' patches here or there).
Just blasting the project in the most generic terms is avoiding the necessary thinking about what the goals should be and what are good ways of achieving them.
