Debian's dpkg and apt are both GPL2+. What's the reason they are reinventing the wheel here? Is there some kind of licence incompatibility that the GNU project cares about? Is there some kind of major architectural difference? Why is it important enough to fragment Free Software developers over?
I feel that this should be answered in an FAQ, but I can't find the answer anywhere.
In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection
Maybe that’s enough? (I don’t understand package managers.)
I'm not sure it's even a fork. It appears to plug a different backend/frontend into the nix structure, so it appears to be a "patch", for want of a better word. (at least that's what I gleaned from http://www.fdn.fr/~lcourtes/software/guile/guix-ghm-2012.201...)
The "unprivileged package management" is the important feature here from the GNU point of view. One of the philosophical underpinnings of the GNU project is empowering non-superusers as far as possible - that's why they've stuck with the microkernel design, too. The idea there is that non-superusers would be able to easily run their own filesystem or TCP stack, for example, since it's just a matter of running their own daemon.
Once you understand this, a lot of GNU's technical decisions make more sense.
Perhaps it doesnt matter, if this provides a large enough software base, then fedora, arch, gentoo etc would perhaps just write a guix->(dpkg|rpm|...) converter to keep their distribution up to date.
Not sure if it would be possible but moving work upstream where more detailed and in-depth knowledge is available might be a good thing.
with guix/nix you don't even care if they get adopted or not. you can use it in coexistence with any package manager.
very common scenario i come across few times a year: you get to work on an old CentOS/RedHat/Fedora box but you need to install latest package X which is only in next version of current distro. which would mean you need to upgrade or do a lot of manual work. with guix/nix you just install it without need to upgrade.
Does anyone still care that much about microkernels, which were the standard design for state-of-the-art OSes back in the 1980s?
Seems like research now is focused on VMs, which do have a current business use, just like they have for decades now.
The Hurd is, at least from the outside, a 1980s design that failed to catch on in the 1980s and is now a solution looking for a problem. At least the userspace intended to go with the Hurd proved to be high-quality and very widely usable.
Yes, people still care for microkernels, particularly in research, security, embedded systems. The developments didn't end in 1980 and are still going on now. What's interesting is that some of those kernels from the 1980s were architecturally superior to the commercial OSes used today. It's really a mistake to discount the technical advantages of these kernels due to lack of popularity.
The main problem with them is simply lack of manpower. Research usually means that older solutions are replaced with the new, which leads to a lot of wasted effort where those changes aren't backward compatible. There's also the huge effort to keep kernels up to date with hardware, and to port over the thousands of software packages that people typically uses in day-to-day activities.
That's perhaps the real advantage of the current popular kernels - they have a strong requirement for stability and introducing breaking changes is out of the question. It's a propagating effect too, due to the many layers of dependencies we have - modifying the lowest layer, the kernel, has the biggest overall effect on the entire operating system.
That's why the current VM (or chroot/jail/namespace) solutions are being pushed and researched - because they bring some of the advantages of the microkernel design to modern computers, but don't completely break everything. A graphical application in user space for example, shouldn't care whether it's running in a VM or on the metal, it only cares about it's dependencies.
>The Hurd is, at least from the outside, a 1980s design that failed to catch on in the 1980s and is now a solution looking for a problem.
The Hurd is still a problem, rather than a solution. It's original goal is by part a failure because of design problems in the Mach microkernel. There's attempts to put Hurd on other microkernels, which has pushed Hurd more into a research position, but there's certainly things to learn from the history of the project on how not to create an OS on a microkernel. It's also not the only project still running with a microkernel design (see HelenOS, Genode etc).
And it's not like the research is completely wasted even if these projects don't gain popularity - as some of their features make it into mainstream kernels. A good example is FUSE (Filesystem in userspace) on linux - which allows people to experiment with filesystems without hacking on the kernel or requiring additional privileges.
But whether a microkernel design will ever become mainstream is a different question. The sheer amount of work to port applications over makes it seem unlikely - although good design of open source software will make the effort significantly easier. It's unfortunate that we seem to be heading in the opposite direction though, with key players in the open source world pushing for a monotonous ecosystem around linux/systemd et al, even excluding working kernels like the BSDs.
This system works just as well for free software as for non-free. Downloading a binary blob from somewhere would be easy, just a few lines of code in the package description file.
I'm not one to declare other people's motivation, but it strikes me as very odd that there isn't a "So, here's what's irreparably wrong with dpkg/apt and rpm/yum".
there kind of is, if you read between the lines - their usp is the scheme interface, which provides a "proper" programming language with which to interact with the packaging system. they don't explicitly call that out as something wrong with nix, but it's clearly what they feel they do better.
I feel that this should be answered in an FAQ, but I can't find the answer anywhere.