Signs of life from GNU Hurd [LWN.net]

Signs of life from GNU Hurd

Posted Jul 31, 2011 5:18 UTC (Sun) by slashdot (guest, #22014)
Parent article: Signs of life from GNU Hurd

There is simply no way the Hurd project as it is now can succeed, because:

1. A lot of work that went into Linux (such as hardware support) would need to be duplicated, and that would require a massive amount of time/funding which just won't be available (because Hurd isn't popular, chicken and egg issue)

2. A monolithic kernel like Linux will always be better for the common use cases due to superior performance (and currently much more features), while Hurd's advantages would perhaps be for use cases that very little people care about (for example, nowadays computers are usually personal, so running something as root is a non-issue)

3. While a microkernel might be easier to develop, or might be easier to make reliable, Linux is already extremely mature and rock-solid, completely negating that advantage

4. You can just ignore the subsystems that Linux provides and plug in your own worse performing but customized ones (e.g. alternative TCP/IP stack in an LD_PRELOAD library), sometimes even in a very clean and standard way (e.g. filesystems using FUSE, block devices with nbd, network with tun/tap)

5. You can use virtualization, containers and several other mechanisms which provide similar "system in a process" features while continuing to use an existing popular and full-featured OS

Overall, the only way the Hurd could turn into something useful is to change it to use (unmodified) Linux instead of Mach/L4/whatever as a "supporting microkernel" and turn the Hurd into a set of Linux system daemons providing ad-hoc IPC interfaces (like the existing dbus, systemd, PolicyKit, ConsoleKit, etc.) and into FUSE filesystems, assuming that there actually are any useful parts that can be salvaged that way.

Should Linux have any shortcomings (like maybe too slow IPC/message passing, or inability to easily implement some things in userspace), those could be addressed in a generic way and then merged upstream as overall kernel improvements (like FUSE).

to post comments

Signs of life from GNU Hurd

Posted Aug 1, 2011 23:37 UTC (Mon) by sthibaul (✭ supporter ✭, #54477) [Link] (8 responses)

Such a conclusion shall not be unanswered.

1. The plan is precisely to inherit the Linux hardware support through the DDE layer...
2. Running something as root is definitely an issue. There are all kinds of breaches here and there, and CVEs flowing. Xorg tries to *not* run as root for instance.
3. Linux is mature and rock-solid, yes. At least what is mature in it. New FS implementations some ext4 still have an experimental phase, in which encapsulating it can be very useful for debugging.
4. LD_PRELOAD is full of potential for horrid issues. You need to distinguish between the application FDs and the FDs you are running in your library, which is very bugprone. FUSE does not implement quite a few things. I've just realized that you can give a tun/tap to a user, so that the application running it can be non-root. This is indeed a good thing. That however does not permit to implement e.g. dynamic table routing, which vpn clients often need (and I do not like running as root).
5. The virtualization part (in particularly full virtualization) is a hammer for a fly. Containers & namespaces are indeed more like the Hurd approach, we'd say "at last there are such facilities in Linux". They however have a hard time getting everything integrated mainstream, I'm not sure they will complete it. The Hurd, from the start, uses indirection, and is thus already flexible.

"change it to use (unmodified) Linux instead of Mach/L4/whatever as a "supporting microkernel""

I guess here too you missed the DDE layer plan. That plan being considered, Linux has not much to bring compared to Mach: the IPC interface would have to be completely rewritten. The FUSE part is already in the plan, there is some embryon of code.

"assuming that there actually are any useful parts that can be salvaged that way."

Of course, if you just take Linux, then you have a Linux system and there's no use in doing that :)

Our plan is rather to take bits from Linux, such as drivers & FS implementations, and integrate them in the Hurd landscape.

I'd like to repeat again: we don't plan to replace Linux. I guess there might be some difference in what one can mean by "succeed".

Signs of life from GNU Hurd

Posted Aug 2, 2011 4:37 UTC (Tue) by viro (subscriber, #7872) [Link] (5 responses)

Umm... You'd better be damn careful about the licensing - taking Linux fs code and putting it under GPLv3+ would be a license violation. Additional restrictions and all such... There is some code in there that happens to be v2+, but default license is v2-only and *that* is not convertible to v3+. Moreover, any changes done to v2+ code converted into v3+ one will be yours to maintain. Indefinitely. They simply can't be folded back into mainline, not without creating a kernel impossible to distribute...

Signs of life from GNU Hurd

Posted Aug 9, 2011 18:56 UTC (Tue) by sthibaul (✭ supporter ✭, #54477) [Link] (4 responses)

Oops, I missed that comment.

Yes, there are licence concerns with taking existing code. And that's exactly where the Hurd architecture helps: it doesn't make a kernel of it. It runs it in separate processes in userland. Thus no licence issue at all, you can even have processes running proprietary code.

Signs of life from GNU Hurd

Posted Aug 10, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

So where exactly in the GPLv2 does it say that it's ok to take GPL licensed code and mix it with incompatibly licensed code if the GPLed code is run as a separate process? I can't find such an exception anywhere. It's a fallacy to think that you can just wash away copyright derivation and license issues by inserting purely technical shims, like IPC (hallo Android and BlueZ), or processes and some custom message passing syscalls.

If you're thinking of the Linux exception that clarifies that the normal Linux syscall interface is generally a boundary for GPL derivation, so that it's 100% clear that userspace processes running on the Linux kernel aren't bound the kernel's licence: that clearly does not apply to the kernel's own code.

Signs of life from GNU Hurd

Posted Aug 10, 2011 7:29 UTC (Wed) by viro (subscriber, #7872) [Link] (2 responses)

That depends... One could, e.g. take fs code and write a userland implementation of the same fs derived from it, speaking 9P or e.g. FUSE. Derived as in "uses block allocator functions copied verbatim from the original". Leaving it under GPLv2, of course. Now, 9P is network-transparent. You've got yourself a server for a network filesystem, Linux boxen can connect to it and mount the sucker. *Can* we use the license to prohibit e.g. Plan 9 clients from connecting to such server? I seriously suspect that it would qualify as additional restriction (not to mention being utterly obnoxious).

Depends on the nature of API they are exposing... Hell, nevermind 9P; suppose somebody implements userland nfsd using block device and using something like libe2fs for fs access. Put that sucker under GPL; are you seriously claiming that mounting from such server makes your nfs client a derivative? Or that one is not allowed to use any kind of GPLed code in such a project?

Signs of life from GNU Hurd

Posted Aug 10, 2011 9:00 UTC (Wed) by paulj (subscriber, #341) [Link]

To be clear, I'm making the point that technical tricks, like moving code to separate processes, does not of itself change the licensing situation. I'm replying to the implication in sthibaul's comment (an implication he may not have intended) that the Hurd's micro-kernel + user-space server architecture inherently provides some kind of license-washing function.

What exactly the licensing implications are of taking Linux fses, wrapping them in user-space daemon code and having them talk to some general FS-namespace muxing daemon in a micro-kernel, such that it effectively depended on that Linux fs code, I couldn't quite say. Your word would carry some weight on that issue though.

Signs of life from GNU Hurd

Posted Aug 10, 2011 10:59 UTC (Wed) by nix (subscriber, #2304) [Link]

It is plain that in such a situation, the client code could *not* be considered a derived work: it might not have changed while the GPL serverside code was written. (Also, GPL NFS servers and non-GPL clients talk to each other every day without legal issue.)

Since the server and client code are not even necessarily running on the same machine, you probably couldn't use the reasoning that the combinaton of both linked together is a derived work of the GPLed part, because there *is* no such version.

(but IANAL and even if I were an L I'd be a UK L in any case. So my blatherings are doubly irrelevant.)

Signs of life from GNU Hurd

Posted Aug 2, 2011 11:51 UTC (Tue) by slashdot (guest, #22014) [Link] (1 responses)

It seems to me it would be MUCH simpler and better to either implement the Mach IPC interface in userspace in terms of POSIX, or as a Linux kernel module, rather than somehow attempting to run Linux drivers in Mach or some other microkernel.

Fundamentally, the Linux driver interface is enornomous, constantly changing, and partially documented, while I guess the Mach or L4 IPCs API are much smaller and well-defined.

Also, the "DDE" layer page only mentions block, network, USB and sound drivers, while of course a useful system needs at least 3D acceleration as well, plus a lot of miscellaneous stuff.

Not to mention that non-driver parts of Linux like the scheduler, MM subsystem, etc. have been extensively worked upon to be fast, reliable and scalable to SMP systems, and I don't see how anything else could possibly compare to that.

If the plan is to do MM and scheduler in userspace, then that's probably not going to be of any real use other than as a toy, and anyone using whatever new feature the Hurd provides will want to do that in conjunction with at least the Linux kernel-mode scheduler and MM so that things will work at decent performance and scale properly to SMP systems.

And of course, that way Linux users would be able to just run the Hurd easily along with existing other software.

Again, this assumes that once you get rid of everything that Linux already does (and where there's no chance at all that an userspace solution with much less developers can compete), there will be something left in the Hurd, which I'm not sure whether it's the case.

Oh, and for the record, a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system, while having the same isolation and better security (no buffer overflows, ever!) than the latter, so the whole concept of a C-based microkernel-based system might be in fact totally obsolete.

(yeah, this is kind of a trollish comment, but I believe it reflects reality)

Signs of life from GNU Hurd

Posted Aug 3, 2011 7:19 UTC (Wed) by sthibaul (✭ supporter ✭, #54477) [Link]

Let's answer to the troll then.

"I don't see how anything else could possibly compare to that."

"work at decent performance and scale properly to SMP systems."

Again, we don't want to replace Linux. And yes, you can have decent performance and scale properly on SMP systems without comparing to Linux, i.e. not on 1000-core machines & such. BSD kernels achieve it well for their use for instance, and there are much less companies etc. than on Linux.

"there's no chance at all that an userspace solution with much less developers can compete"

Again, we don't want to replace Linux. There's no way we can achieve the same speed etc. So what? That's not the point. The fact is that even with much less developers, we actually got to the point that the Hurd works, has 68% Debian coverage with its nice installer and the nice translator feature.

"a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system while having the same isolation and better security (no buffer overflows, ever!)"

No buffer overflows, right. That alone does not bring full security. Yes, there are other ways to do it. Now, please bring us the code. GNU/Hurd _has_ working code _now_.