Okay the title is a very lame pun. But in this post I’d like to argument a bit more my reasons for not liking the Hurd project, at least in the way it is still being developed nowadays, which I announced on Identi.ca yesterday. This might sound quite strange coming from the guy who dedicated time and soul to Gentoo/FreeBSD.
First of all let’s put into context what Hurd is nowadays: it is not something viable, or usable. Twenty (20!) years after its original inception, Hurd is still nothing that you’d think of using on your desktop, or your server — nor should you, I guess. The class of operating system this belongs to is the same as Gentoo/FreeBSD, Debian’s GNU/kFreeBSD , Haiku, Plan9 and so on, a toy project. Or if you want to make it sound less childish, a research project, but I prefer the shorter version.
But while there are so many toy projects operating systems, I’m singling out Hurd, and there two main reasons for my feeling; they can be considered mostly personal, non-technical opinion, but I’ll stand by them.
First of all, most other toy systems have given us steady improvements in different areas; take Plan9 for instance: ten years older than Hurd, but recently Linux gained access to paravirtualized filesystems, based on what? On the Plan9 protocols. Good research going — even though it does seem tremendously silly when you look into it for the first time. And even though I was sceptic the first time I looked into it, GNU/kFreeBSD has probably made glibc a bit more … malleable.
But most importantly is that the whole Hurd project at the moment does not have any real technical reason to exist, it only has one huge symbolic value for the GNU project, beginning with the idea that “Linux is not the Free operating system”.. which I could accept if it wasn’t coming from the project sponsored by FSF. The same FSF that insists that you should not use any proprietary operating system, that you should only and always use Free software and so on so forth.
Is Hurd the example of Free Software people should use? Do they insist on their argument even when it is totally, technically, unsound? I’m afraid some of the people in the FSF do. Luckily, FSF is not just those, and there are numbers of reasonable, hard-working and capable people. Which is why even I have signed copyright assignments to FSF with a bit of rant attached), and why I try to contribute to GnuPG when I can (given I use it).
Once again, though, what’s the problem if a bunch of elitist developers feel like working on a toy system? It really isn’t something new; heck Plan9 is, as far as I can tell, mostly developed for that. With a few difference: most of the people I saw involved with Plan9 are also involved in the suckless projects (and I rarely, if at all, agree with the premises of such projects), and they definitely are not very interested in making more users for any software at all, so their approach is well suited to their goals, not so for the GNU people, but oh well.
The problem I have, with actually any toy project, is with the people who keep insisting to find philosophical reasons to show others why their project is really, very, so much important. It happens (awfully often on Identi.ca) with both Plan9 but, more often lately, with Hurd. And when I do show my disagreement, I usually end up flooded with defences of said projects (“they don’t bother you”, “everybody should keep using what they prefer”, … sure of course — then why can’t I voice my personal opinion?).
This brings me with categorizing most of the people involved in toy project (or actually, any project — with mainstream projects it is a bit more shady to go from one category to the other) in three categories: the silent doers, the vocal doers, and the advocates.
For the silent doers, those who know they are working on a toy project and have no expectancy for people to consider it “important for the greater good”, I have fondness: you go with it and try to get something good out of it — I have done something like that with G/FreeBSD: Gentoo has had libarchive (bsdtar) from way before it went mainstream as a dependency of GNOME and KDE.
I’m a bit more polemic with the vocal doers: sure, you’re entitled to advertise your choice, no way I’m going to argue against it; but I’ll also not refrain from stating my disagreement. That shouldn’t be a problem, no? And I’m sorry, but I’m also not going to generally be convinced by your reasons to keep developing. It’s not a lack of respect, and I’m sorry if you feel this way, but… I don’t really care. If you want to show me something, show me technical reason why your work could be important to me, or to others, but technical.
But please, spare me the advocates. They talk just too much (after a passing reference to Hurd I get three, continued messages, trying to argue for it? I’m going to be a bit disappointed — I reply and I get another three? I’m seriously cranky), and of the wrong arguments. I really don’t care about the philosophy of a subproject. I subscribe to the basic philosophy of Free and Open Source Software, and I maintain that it can be technically superior if the project accepts that proprietary software can (and usually enough does) have better technical aspects. Survival of the fittest, for me, is happening only in technical terms.
Clear enough now?
Thanks for explaining your reasons. As answer:Firstoff: FUSE is essentially an implementation of parts of the translators system (which is the main building block of the Hurd) to Linux and NetBSD recently got a port of the translators system¹. That’s the main contribution to other projects I see.¹: http://netbsd-soc.sourcefor…On the bare technical side, the translator-based filesystem stands out: The filesystem allows for making arbitrary programs responsible for displaying a given node (which can also be a directory tree) and to start these programs on demand. To make them persistent over reboots, you only need to add them to the filesystem node (for which you need the right to change that node). Also you can start translators on any node without having to change the node itself, but then they are not persistent and only affect your view of the filesystem without affecting other users. These translators are called active, and you don’t need write permissions on a node to add them.The filesystem implements stuff like Gnome VFS and KDE network transparency on the filesystem level, so they are available for all programs. And you can add a new filesystem as simple user, just as if you’d just write into a file “instead of this node, show the filesystem you get by interpreting file X with filesystem Y” (this is what you actually do when setting a translator but not yet starting it (passive translator)).One practical advantage of this is that the following works:$ settrans -a ftp: /hurd/hostmux /hurd/ftpfs /$ dpkg -i ftp://ftp.gnu.org/path/to/*…The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work.You could even define a Gentoo mirror translator (`settrans mirror: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2`Or you could add a uniounmount translator to root which makes writes happen at another place. Every user is able to make a readonly system readwrite by just specifying where the writes should go. But the writes only affect his view of the filesystem.Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most initscripts in the Hurd: Just add a translator to a node, and the service will persist over restarts.It’s a surprisingly simple concept, which reduces the complexity of many basic tasks needed for desktop systems.And at its most basic level, Hurd is a set of protocols for messages which allow using the filesystem to coordinate and connect processes (along with helper libraries to make that easy).Also it adds POSIX compatibility to Mach (while still providing access to the capabilities-based access rights underneath, if you need them). You can give a process permissions at runtime and take them away at will. For example you can start all programs without permission to use the network (or write to any file) and add the permissions when you need them.And then there are subhurds (essentially lightweight virtualization which allows cutting off processes from other processes without the overhead of creating a virtual machine for each process). But that’s an entire post of its own…And then there is the possibility of subdividing memory management and using different microkernels (by porting the Hurd layer, as partly done in the NetBSD port), but that is purely academic right now (search for Viengoos to see what its about).So in short: The translator system in the Hurd is a simple concept which makes many tasks easy, which are complex with Linux (like init, network transparency, new filesystems, …). Additionally there are capabilities, subhurds and (academic) memory management.Best wishes, ArnePS: I decided to read your post as “please give me technical reasons to dispell my emotional impression”.PPS: A reason why you got answers: You publicly attacked a Hurd advocate and webcomic author (“or spend time actually hacking at something that is needed by users and that is making FLOSS lag behind?”). identi.ca is public, so people reply to that to not let the attack seem as if it were accepted practice.
Thanks for explaining your reasons. As answer:Firstoff: FUSE is essentially an implementation of parts of the translators system (which is the main building block of the Hurd) to Linux and NetBSD recently got a port of the translators system¹. That’s the main contribution to other projects I see.¹: http://netbsd-soc.sourcefor…On the bare technical side, the translator-based filesystem stands out: The filesystem allows for making arbitrary programs responsible for displaying a given node (which can also be a directory tree) and to start these programs on demand. To make them persistent over reboots, you only need to add them to the filesystem node (for which you need the right to change that node). Also you can start translators on any node without having to change the node itself, but then they are not persistent and only affect your view of the filesystem without affecting other users. These translators are called active, and you don’t need write permissions on a node to add them.The filesystem implements stuff like Gnome VFS and KDE network transparency on the filesystem level, so they are available for all programs. And you can add a new filesystem as simple user, just as if you’d just write into a file “instead of this node, show the filesystem you get by interpreting file X with filesystem Y” (this is what you actually do when setting a translator but not yet starting it (passive translator)).One practical advantage of this is that the following works:$ settrans -a ftp: /hurd/hostmux /hurd/ftpfs /$ dpkg -i ftp://ftp.gnu.org/path/to/*…The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work.You could even define a Gentoo mirror translator (`settrans mirror: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2`Or you could add a uniounmount translator to root which makes writes happen at another place. Every user is able to make a readonly system readwrite by just specifying where the writes should go. But the writes only affect his view of the filesystem.Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most initscripts in the Hurd: Just add a translator to a node, and the service will persist over restarts.It’s a surprisingly simple concept, which reduces the complexity of many basic tasks needed for desktop systems.And at its most basic level, Hurd is a set of protocols for messages which allow using the filesystem to coordinate and connect processes (along with helper libraries to make that easy).Also it adds POSIX compatibility to Mach (while still providing access to the capabilities-based access rights underneath, if you need them). You can give a process permissions at runtime and take them away at will. For example you can start all programs without permission to use the network (or write to any file) and add the permissions when you need them.And then there are subhurds (essentially lightweight virtualization which allows cutting off processes from other processes without the overhead of creating a virtual machine for each process). But that’s an entire post of its own…And then there is the possibility of subdividing memory management and using different microkernels (by porting the Hurd layer, as partly done in the NetBSD port), but that is purely academic right now (search for Viengoos to see what its about).So in short: The translator system in the Hurd is a simple concept which makes many tasks easy, which are complex with Linux (like init, network transparency, new filesystems, …). Additionally there are capabilities, subhurds and (academic) memory management.Best wishes, ArnePS: I decided to read your post as “please give me technical reasons to dispell my emotional impression”.PPS: A reason why you got answers: You publicly attacked a Hurd advocate and webcomic author (“or spend time actually hacking at something that is needed by users and that is making FLOSS lag behind?”). identi.ca is public, so people reply to that to not let the attack seem as if it were accepted practice.
First of all, I’ll just say that I really didn’t just attack a figure in Hurd for what I meant it: my original comment was to Hook, who I hope to consider more of an acquaintance, so it was meant in a totally different light.And my personal feeling is still there by the way: I still think that spending time on something more useful to Free Software would have a better net gain than Hurd.As for the technical arguments you mention.. none of them seem to specifically target Hurd: they rather all seem to identify with the wide area of microkernel-based operating systems; and while there is no doubt that development of microkernel-based operating systems is a good research, nothing in my opinion gives Hurd any special standing in the landscape.For what concerns FUSE, as far as I can remember, and as far as the “Wikipedia page”:http://en.wikipedia.org/wik… reports, it bears no link to Hurd by itself: the code is derived from AVFS, which in turn seem to be more connected with Midnight Commander than anything. As far as I can tell, even the idea of translators predates Hurd entirely, and definitely the groundbreaking idea of FUSE is simply to interface the usual VFS with the Kernel rather than with some library.
Regarding your post to Hook: That’s the disadvantage of a completely public, message-based discussion system: Posts get seen with far less context than in other ways.Since the inception of FUSE, Linux finally has something which resembles translators to some degree. If you look at the number of applications it found, you can easily estimate the advantage adopting the Hurd would have brought to free software much earlier (and a Hurd with more traction would offer more options).And the advantage of the Hurd is that the filesystem is the integration point of the processes (while staying POSIX compatible), different from plain Mach, for example, which has less accessible structures. And it has more than 65% of the debian packages available.But I did not expect your feeling to change. You wrote about your emotions but requested technical information. You have that information, now.
And btw (forgot to add): My post was never intended to influence you to contribute to the Hurd, but only to tell you, why I think that it is a technically interesting project (aside from philosophy).
I think the main difference between projects like Haiku and Hurd is that the latter got rewritten too many times, doesn’t have direction and isn’t driven to satisfy specific needs.Haiku had made impressive progress out of scarce resources and nowadays it might not be yet out of the toy phase but looks like it has a good foundation.
@lu_zero: that has changed. See hurd.gnu.org for the direction.
I polished my answer and published it on http://draketo.de/light/eng…