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.
That particular Xkcd comic has been posted 79 times in the past year or so† and has quickly become a cliché. The authors' stated goals are to make a "purely functional" and "practical 100% free" package manager.†† They don't mention competition, proliferation, or winning market share. A vague hope of consistency and cohesion accompanying the announcement of a program "approaching its first alpha release" isn't a rallying cry. I think they made this announcement simply so that people interested in this sort of thing might take a look.
Unfortunately, I could only process the first 1000 entire list of ~1500 results because the API refused queries with start > 900. I have sort of a bad conscience because I'm polluting future queries by posting the top 10 list above, but I think I can live with it.
Hearing a disturbance, the master programmer went into the novice's cubicle.
"Curse these personal computers!" cried the novice in anger, "To make them do anything I must use three or even four editing programs. Sometimes I get so confused that I erase entire files. This is truly intolerable!"
The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.
The novice thought for a moment. "I will design a new editing program," he said, "a program that will replace all these others."
Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised. "What did you do that for?" exclaimed the novice.
"I have no wish to learn another editing program," said the master.
It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me:
* Why utilize scheme? It's declaritive utilize a markup like yaml, don't go off the deep end because you can.
* Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS.
* Parse the config files for options, it's easy cmake, autocrap, etc all have parsable formatting this way you don't need to mess with adding build time options.
* Parse the source for dependencies, there are lots of white papers of people doing this and beating human made spec files.
* Utilize machine learning for classification of options, dependency resolution (utilizing previous data).
If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening.
Why not scheme? It's liberally licensed and already has mind-share. It's a simple, no fuzz language with little obfuscating magic and great expressive power.
It allows you to build your solutions as bare-bones as you like or go on full architect should you need to. Sounds like just what the doctor ordered.
> when you give people a fully featured language to fool around with, things you could never imagine can start happening.
Maybe a package manager is not the best place to have that flexibility? (I noticed this seems to support "unprivileged package management", but still...)
You break the idea of a declarative package by doing this you can have side effects that modify or mess with anything. This means I cannot update a package reliably when it's updated because it may or may not change something.
Almost any programming language can be declarative, the problem is it allows logic as well as having a whole programming language installed instead of a simple parser.
Packages are mostly just declarations of how you want a package to be built/installed, but sometimes they require additional logic or computation. Using python would require a separate file format to put definitions into (e.g, YAML), and those definitions would need a rigid schema and versioning system. Some existing package managers take this approach, but what happens when you need a feature that doesn't exist in the declarative schema? You would need to extend the YAML format and bump the version numbers to allow your new features.
On the other hand, a LISP does not need a distinction between a declarative format and the computation language itself - it does both in a consistent syntax. (Homoiconicity is the term). It makes it much simpler to mix your declarations and computations, alleviating much of the need for a rigid specification on package definitions.
If you look at places where the former system is used, you'll find they usually age pretty quickly - or have many version increments because the original design omitted features people wanted in their package definitions. In effect, this leads to standards proliferation, because people invent new systems when the existing ones don't do what they need. Rather than trying to second guess the features people might need, it can be easier to just give them the ability to add them when they want.
A recent example of the former system is this project from GNOME: https://live.gnome.org/BuilDj. If you look at what it's trying to do, it really just wants to reinvent makefiles in YAML. A clear example of NIH, which will fail because as soon as someone needs to do something which their YAML schema doesn't support, it's a useless tool.
That's actually a great point - something I didn't think of when I suggested python since I don't know scheme :D
Maybe this is reason enough to learn scheme soon.
For practical considerations would you still choose scheme, or would you try and see if some massaging of python can get you the desired results - purely because of the simplicity and adoption rate of the language?
Like I've repeatedly said, as far as LISPs go, scheme is very simplistic and friendly. For things like this, basically a DSL for package-definitions (or other declarative data-formats), a simple LISP like scheme seems pretty optimal.
I see no reason not to look into it. It should take you less than 5 minutes to get started in a repl.
I suspect the fact there's GNU Guile, an entirely in-house Scheme ecosystem, has a lot to do with it. Use Python and be beholden to the Python community (outsiders!) Use JSON (as someone else suggested) and be beholden to the Javascript/JSON community (outsiders! oh and that awful JSON license!) etc.
I use WebOS in two devices (a pre2 and a touchpad) every day and am pretty happy about it. I think Enyo rocks and is available everywhere and that WebOS is more user friendly than iOS and Android.
Guix & Nix
~~~~~~~~~~
Nix is really two things: a package build tool, implemented by a library
and daemon, and a special-purpose programming language. Guix relies on
the former, but uses Scheme as a replacement for the latter.
Technically, Guix makes remote procedure calls to the ‘nix-worker’
daemon to perform operations on the store. At the lowest level, Nix
“derivations” represent promises of a build, stored in ‘.drv’ files in
the store. Guix produces such derivations, which are then interpreted
by the daemon to perform the build. Thus, Guix derivations can use
derivations produced by Nix (and vice versa); in Guix, the cheat code is
the ‘nixpkgs-derivation’ procedure. :-)
With Nix and the Nixpkgs distribution, package composition happens at
the Nix language level, but builders are usually written in Bash.
Conversely, Guix encourages the use of Scheme for both package
composition and builders.
Can someone explain what benefits do I get for using this rather than the package manager offered by my distribution? And do you need root access to install guix? Because if you do then
> unprivileged package management
seems quite, well, useless imho. If on the other hand everything in guix lives in the userland, I can see myself using it in the servers I don't have root-access to..
It does feel a bit like it can become a platform independent alternative to something like Cygwin. Along the lines of ActiveState perl, but a whole GNU environment instead.
Both GNU Guix and Nix seem like excellent steps forward in bringing sanity to package management. Does anyone know if puppet, chef, salt and similar configuration management tools were inspired by these projects? At a cursory glance, e.g., there are some striking similarities in the DSLs of NixOS and Puppet.
Ever tried to build distribution packages? If it works for you, doesn't mean it works everywhere. Slight errors in the dependency specifications of a package may make it fail if you have wrongly versioned/missing libraries etc. It's often very difficult to verify that package dependencies are 100% correct. Sometimes package builds are not reproducable, as autoconf doesn't care about the build dependencies you defined but just adds any dependency it can auto-detect at compile-time. So you have to double-test your package when build on a build server etc. etc.
AFAIU the Nix package manager fixes that by trying to assure bit-for-bit matching dependant packages are present by making every package version a hash of the installed files, hashed with the hash of all dependencies (similar somehow to how the filesystem/history data are managed in Git, BTW).
The Nix package builder (named hydra) on the other hand makes sure that builds are performed in complete isolation via enhanced chroots, so that every build is 100% reproducible. It locks the build process down so much that it can't even access the network nor would the process be able to observe varying host names. [1]
This is why they call it a "purely functional" build system. As in purely functional programming: there's no state at all. Inputs completely define the output.
Now Guix sits on top of Nix and somehow attempts to make its features available on a higher level via a Scheme API (Nix uses its own language for package dependency and build descriptions)
I haven't used Nix before, just read about it, but having suffered through writing complex package build recipies for OpenWrt, I very much appreciate the approach.
Does it need to? It's for hackers, not for every user. If you're bored and feel like hacking on something, this might interest you. If it doesn't, Mr. Ludovic is not trying to force you to use it.
For me, some of its features, specially non-privileged user package management, are interesting. I'm not so much interested in the distribution at the moment, more in the package manager. I imagine there aren't many supported packages yet, so it's a matter of writing scripts... eventually it can become a distribution. Not for everyone.
But I still see no problem in more package managers being out there - any one has a problem with yum / apt being two different package managers? Why is yet another package manager is a bad thing?
I principle you are right. However in practice there is a sane point where there are so many competing solutions that you have to question why people don't spend their time improving existing solutions instead of adding to the fragmentation.
I highly recommend reading over some of the Nix papers -- what the author is doing is totally divergent from nearly every other package manager in a way that's either insane or brilliant (I don't personally know enough to judge). I saw his talk at a software upgrades workshop, and it was pretty impressive.
Sometimes you can't just improve an existing solution. It may be fundamentally different from what you intend to do (both technically and philosophically).
Yet another package manager? :)
I've yet to see something that does a better job than http://paludis.exherbo.org/
And that is not to say Paludis couldn't be improved. But I don't get why people devote time to the community to work on stuff that has been thoroughly solved.
The Linux community needed this around 15 years ago when Windows 98 came out. Now we've got .deb and .rpm which do the job perfectly well. It's even better nowadays, as well, since their existence is effectively hidden from the user thanks to package managers.
I don't think package management is a solved problem. Most distributions fail at the simple task of installing multiple versions of the same package alongside each other. Also, lackluster dependency management (you install library X, it wants to install mail server Y and database Z).
There are many approaches that one would mistake as being "reinventing the wheel":
1. FreeBSD ports system is barebones, but incredibly simple and transparent.
2. Arch Linux's PKGBUILD recipes are also simple and, at times, a much better alternative to binary packages.
3. Gobo Linux (http://www.gobolinux.org) solved binary packaging the right way by having each package in it's own tree. It's approach is similar to OS X, which also gets this right.
"you install library X, it wants to install mail server Y and database Z)"
Almost exactly what happened when I installed nmh. Wasn't at all obvious from the dependency list that I'd get qmail, didn't pay attention to the warning prompt and said Y, ...
Bonus, I have a bunch of new system accounts in my Display Manager's login screen. Bleah. Fortunately my scorched-earth reinstall is coming up, so I just leave them there to make it easier to hate what happened.
you can rollback on debian? you can install packages as user on RedHat? i moved away from it just because things like .deb and .rpm don't do the job all the way
"do the job perfectly well" is a bad way of saying what I was thinking: "for the most part, they work pretty well for the average user" which is true.
They don't cover all edge cases perfectly. But for a user who is new to Linux and wants to install some software, it's better than what we've got on any other OS except ones with dedicated and closed app stores.
Ironically, this Guix thing would be perfect... for Windows.
Right now, I have to maintain my own list of GnuWin32 installers (wget coreutils cygutils diffutils findutils grep gzip less patch sed tar unzip) retrieved from sf.net, with a 30 lines batch script to deploy them, plus a powershell command to retrieve wget as the first step.
nix (and potentially guix) is working on windows, at least from what i heard. probably there are some issues with existing packages since nobody really pays much attention to windows but if somebody cared this could improved a lot.
Well there is already nixpkgs which has existed for a while with core features that I saw mentioned. I would be happy if there was increased interest in both and their feature set.
I feel that this should be answered in an FAQ, but I can't find the answer anywhere.