LWN: Comments on "Signs of life from GNU Hurd"

Signs of life from GNU Hurd

nix — Wed, 10 Aug 2011 10:59:18 +0000

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

paulj — Wed, 10 Aug 2011 09:00:08 +0000

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

viro — Wed, 10 Aug 2011 07:29:24 +0000

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

paulj — Wed, 10 Aug 2011 06:41:21 +0000

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

sthibaul — Tue, 09 Aug 2011 18:56:03 +0000

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

sthibaul — Wed, 03 Aug 2011 07:19:54 +0000

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_.

Signs of life from GNU Hurd

slashdot — Tue, 02 Aug 2011 11:51:44 +0000

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

viro — Tue, 02 Aug 2011 04:37:32 +0000

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

sthibaul — Mon, 01 Aug 2011 23:37:44 +0000

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".

Once again: icing is pointless without the cake...

nix — Mon, 01 Aug 2011 14:10:07 +0000

The third reason is that different people on the same machine can then run *different VPNs*. There's no hope of doing that on Linux as it stands, even with the global routing table, because the per-user iptables rules run in POSTROUTING so cannot affect packet destinations. But having to change the global routing table for something completely per-user and not security-related is a kludge anyway. A userspace TCP stack is definitely the right way here. (Sure, it may not be so high performance, but if you're using a VPN performance isn't going to be at the top of your list anyway.)

License

runciter — Mon, 01 Aug 2011 13:08:19 +0000

I, for one, would never make a significant contribution to a non-copyleft project. And while I don't mind GPL2 that much, when a developer contributes to Linux, he has to bear in mind that he is also contributing to TiVo and other companies like TiVo, which will use his code against the spirit of the license under which it was released by exploiting loopholes in the license. Everything else being equal, I would definitely choose to contribute to a GPL3+ project over a GPL2 project.

License

slashdot — Sun, 31 Jul 2011 05:29:15 +0000

I doubt that there are many who care whether a project they contribute to (or even less, that they use) is GPL2 or GPL3.

I expect that most people contribute to a project because they find it enjoyable to contribute to that specific project, and their interest in the license is most likely limited to checking that it is a free software and/or open source license.

Signs of life from GNU Hurd

slashdot — Sun, 31 Jul 2011 05:18:56 +0000

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).

Signs of life from GNU Hurd

bersl2 — Sat, 30 Jul 2011 08:32:30 +0000

Wow, somebody in here has some strong feelings against the HURD.

Once again: icing is pointless without the cake...

Kissaki — Fri, 29 Jul 2011 05:32:03 +0000

It sounds to me like you're comparing this apple to an orange. Hurd has some architectural differences that have little practical impact in the current implementation, but bode well for the future.

If you want to use Hurd as a system from which to video chat with your friends tomorrow, well, that might be a challenge. Maybe you should use Linux instead. If you are interested in seeing what the Hurd concepts are about or might bring down the road, you might want to play in this sandbox.

As for why you would want to run a VPN client as other than root, I hope you're kidding. Two trivial answers occur off the top of my head. The first one is that a non-root VPN client means VPN client bugs don't automatically threaten system-compromise. The other is that as a normal user I can take advantage of VPN technology without having to bug the sysadmin and get him or her involved in the key exchange.

For me, the security implications and practical benefits of the differences are exciting. In my mind Hurd is a nice step towards capability based security (instead of ACL based). I hope my theory bears out, but even if it doesn't the modularity is much closer to the unix philosophy as I learned it (small tools that do one thing well) than the monolithic kernel could ever be.

Nice article... but light on technical details

kevinm — Fri, 29 Jul 2011 05:23:21 +0000

Likewise, an illustration of features "that users have actually always wanted but never dared ask their administrator" would have been welcome. It could be mentioned, as an example, that mounting an NFS, FTP, or ISO 9660 file system (or anything else) does not require root privileges.

This is great - but unfortunately, it's about 10 years too late. The idea of users having a distinct administrator - large multiuser machines for general purpose computing - is an anachronism. It would have been awesome when I was at university in the 90s if I could have mounted an NFS share under my home directory without root permission. Today, with my own desktop Linux system - it's simply an elegant solution to a problem that I no longer have.

It's also worth pointing out that you can get a 99% solution for most of these use cases on todays UNIX-like systems, using system call interposing. Sure, it's a bit crufty - but it works well enough for the few occasions when it's necessary to do something like run your own TCP/IP stack.

License

dlang — Thu, 28 Jul 2011 22:02:58 +0000

I think most people would agree with you on that statement.

I think that you would find many people disagreeing on which of the two has the advantage however.

License

runciter — Thu, 28 Jul 2011 21:18:34 +0000

An important point that has not been mentioned so far is that Hurd is under GPL3+, whereas Linux is stuck with GPL2. While it doesn't make a difference to users, that point alone can be a significant advantage to potential contributors.

Linux is not the only competititor of GNU/Hurd!

renox — Thu, 28 Jul 2011 09:39:15 +0000

I wonder why GNU/Hurd is always only compared to Linux: there are other kernels such as L4, MINIX 3 which are also competitors..

A comparison with these other micro-kernel would be more interesting!

Why it does not make sense?

kingdon — Wed, 27 Jul 2011 18:03:50 +0000

Mi vidas ke la esperanta vikipedio havas artikolon pri Hurd, ĉe http://eo.wikipedia.org/wiki/Hurd

And since google translate doesn't (yet :-)) have esperanto: I see that the esperanto wikipedia has an article on Hurd, at http://eo.wikipedia.org/wiki/Hurd

This is what started the whole discussion...

jrn — Mon, 25 Jul 2011 00:05:52 +0000

>> Who mentioned wanting that?

> Huh? Are you joking? This is what started the whole discussion:

No, I wasn't joking. Thanks for explaining.

If you had said "Though that might be its goal, I don't believe the hurd gives users and programs even close to as much control over their computing environment as possible today", I don't think anyone would have disagreed.

Why it does not make sense?

sthibaul — Sun, 24 Jul 2011 16:39:01 +0000

> You are trying to "sell" HURD to someone other then "developers who want to dig deeper into system development".

Ooops, no, as civodul explained, there's a misunderstanding here. We are not targeting end users yet. We target at providing more power to end users. And now that Debian GNU/Hurd is quite easy to install, we welcome developers who want to help in that direction.

Also, we don't really aim at replacing Linux. Linux is "good enough", indeed, and does it well. The Hurd simply wants to try to be yet better in some aspects, which we have already explained.

Why it does not make sense?

civodul — Sun, 24 Jul 2011 13:15:36 +0000

Hey, funnily I happen to be an Esperanto enthusiast too! :-)

(BTW, sorry I wasn't clear in my initial comment: I didn't mean to say that GNU/Hurd is Ready for the Desktop, obviously, but rather that it's *designed* with user freedom in mind as opposed to being merely a toy for "developers who want to dig deeper into system development".)

Why it does not make sense?

khim — Sun, 24 Jul 2011 09:12:08 +0000

Making a point about "baah you need to run in KVM anyway" does not make sense.

Of course is does! Remember the context. You are trying to "sell" HURD to someone other then "developers who want to dig deeper into system development". This means they are not interested in the virtual possibilities. They want to use HURD here and now. And here and now KVM is just as much part of HURD development as it is part of Linux kernel development.

Yes, a big detail. But it's mostly about plugging existing drivers, is already being worked on, is already working for network boards, is now being integrated, and will probably continue with disks.

It's nice to know it's "already being worked on". When you'll finish it you'll need to fix the programs (because few developers will want to install HURD to do so), then you'll have a case for someone other then "developers who want to dig deeper into system development". Lot's of work - and looks like too few people to do it.

Throwing a model just because the implementation lacks some driver does not make sense.

Throwing model? Of course not. Throwing the implementation? This makes perfect sense.

I think HURD developers forget the main principle of IT: Good Enough (sometimes formulated as Worse is Better). Linux is used everywhere because it's
1. Good enough.
2. Cheap, familiar and well-known.
Note that "everywhere" means "everywhere where Windows is not used" (on servers Linux replaced UNIX not Windows). If you believe HURD should replace Linux (or any other OS) at some point you should explain what unique feature of HURD will push this switch and to do that you need to explain why anyone will care about said feature enough to ignore existing deficiencies.

Decide for yourself: do you want to push HURD as real OS (then it competes with FreeBSD, Linux, and Windows - and you need to concentrate on drivers and real applications) or do you want to push it as toy/learning OS (then it competes with Minix, Plan9 - you need to concentrate on documentation and learning courses).

HURD enthusiasts often looks as Esperanto enthusiasts: they preach the "bright future" where everyone will use HURD (or Esperanto) and positively refuse to talk about reality (which does not give you real reasons to believe said "bright future" will ever materialize).

This is what started the whole discussion...

khim — Sun, 24 Jul 2011 08:14:19 +0000

> If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have:

Who mentioned wanting that? (Note that there are other ways than programming to help develop, of course, like contributing documentation or reporting bugs.)

Huh? Are you joking? This is what started the whole discussion:

Sadly, the conclusion of the article (that GNU/Hurd is for "for developers who want to dig deeper into system development") dismisses this aspect.

IMNSHO conclusion is quite correct: HURD is not ready for "normal geeks" (let alone "normal users"). Right now it's only useful for someone who believes in it and wants to help development.

Fine-grain virtualization

sthibaul — Sat, 23 Jul 2011 22:59:39 +0000

It seems like you just refuse to admit anything.

Making a point about "baah you need to run in KVM anyway" does not make sense.

*Obviously*, hardware support, right now, is a concern. But really it's a detail, and using it as an argument does not make sense. Yes, a big detail. but it's mostly about plugging existing drivers, is already being worked on, is already working for network boards, is now being integrated, and will probably continue with disks.

You have to start with something. Writing drivers doesn't provide any interesting to code on and talk about. Writing translators does. Writing both at the same time is really not reasonable. Throwing a model just because the implementation lacks some driver does not make sense.

Fine-grain virtualization

jrn — Sat, 23 Jul 2011 14:02:06 +0000

> If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have:

Who mentioned wanting that? (Note that there are other ways than programming to help develop, of course, like contributing documentation or reporting bugs.)

Fine-grain virtualization

khim — Sat, 23 Jul 2011 13:31:55 +0000

Each Hurd subsystem is virtualized, meaning that as long as you implement the subsystem's interface, you can replace the default subsystem instance.

This is the sales pitch I've first hard about 20 years ago - before I've heard about Linux, in fact.

Compare this with running a complete GNU/Linux system in QEMU/KVM with its own file system image, etc.

Huh? You mean HURD does not need it's own "QEMU/KVM with its own file system image, etc"? News to me. Last time I've checked the only way to use it was to run it in QEMU/KVM because support for contemporary hardware was nonexistent and support for real world programs was abysmal.

Conversely, sharing among full-blown GNU/Linux VMs is much harder.

Sure, but sharing between Linux/MacOS/Windows and HURD is even harder - and this is the only actually available mode today.

If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have:
1. Decent hardware support (including 3D, plug-and-play and all that), or
2. Some unique server software which does not have analogues under Linux.

1 is hard requirement for desktop, 2 is hard requirement for server (a lot of hostings nowadays use KVM anyway so hardware support is not as important but since you need to pay for the privilege each month... you need some substantial benefits to even contemplate the switch).

Once again: icing is pointless without the cake...

khim — Sat, 23 Jul 2011 13:19:00 +0000

While with translators you can choose to virtualize only the network, and not files, or vice-versa, etc.

Once again. Sure, you have great icing for your cake. But you don't have a cake! For example:

Also, even if you have your own machine, using translators permits to run the VPN client as non-root.

This supergreat! Why just why will I want to run the VPN client as non-root? Just "to be cool"? Nope, I will probably want to run some kind of program. In my case it's Ekiga and P4. Both of them work with Linux and don't work with HURD (even if Ekiga can be compiled under HURD it's useless since HURD does not support my webcam). Also note that in my case VPN uses TPM encription which is not supported on HURD.

Hardware support outside disk/network is quite a bit left behind, yes, because it's important to have something interesting to do with it before supporting it, and support can be handled through driver glue layer.

So even if theoretically I can easily use all these fancy translators practically they only exist to do fancy experiments. In some virtualized system. KVM or something like this... And since I need to install KVM to do play with system development anyway... why not play with Linux instead?

Fine-grain virtualization

civodul — Fri, 22 Jul 2011 13:15:48 +0000

You are right that a full virtualization technique like KVM makes it possible to run a customized networking stack, file system, etc. without being root.

Virtualization is the key, but the main difference is granularity.

Each Hurd subsystem is virtualized, meaning that as long as you implement the subsystem's interface, you can replace the default subsystem instance. Compare this with running a complete GNU/Linux system in QEMU/KVM with its own file system image, etc.

The Hurd's approach allows for selected sharing. Just because process A uses a different networking stack than process B doesn't prevent it from accessing the very same files, communicating with B over a pipe, mapping pages from B's address space into its own, etc. Conversely, sharing among full-blown GNU/Linux VMs is much harder.

You can do the same with Linux

patrick_g — Fri, 22 Jul 2011 04:28:30 +0000

What is the performance impact of using Mach instead of L4 ? Why the project "Hurd on L4" was cancelled ?

You can do the same with Linux

sthibaul — Thu, 21 Jul 2011 20:47:34 +0000

Sure, you can kill a flee with a hammer, but beware of the damage on the desk.

Using KVM will imply having to set up ways to move data between the host and the guest, because it's an all or nothing virtualization layer. Citrix made a good job at providing such things over their remote desktop layers to get e.g. seamless copy/paste, but it becomes more and more complex.

While with translators you can choose to virtualize only the network, and not files, or vice-versa, etc.

Hardware support outside disk/network is quite a bit left behind, yes, because it's important to have something interesting to do with it before supporting it, and support can be handled through driver glue layer.

Now, yes, there is utopia in the Hurd project. So what? As mentioned in the article, working on it helped us quite a bit with other, non-utopia things. Working on a utopia project can thus still be a win. And if the utopia can actually get true, all the best.

You can do the same with Linux

khim — Thu, 21 Jul 2011 20:28:25 +0000

One important point was completely missed: it's not centralized like on usual systems.

KVM does not require any root privileges so you can do that too: just run VM with your particular fancy feature and only programs in that VM will be able to use this stack.

Also, even if you have your own machine, using translators permits to run the VPN client as non-root.

And this is more important then the ability to use USB or Bluetooth handset because... ? Face it: all HURD goodies are only icing on the cake. And currently you don't have a cake. I mean: you don't have a system which can actually be used by real users on real (=buyable as new) hardware.

May be eventually HARD will reach this state, who knows. But I, for one, don't hold my breath.

Not really a good point...

sthibaul — Thu, 21 Jul 2011 19:59:47 +0000

One important point was completely missed: it's not centralized like on usual systems. The user can't impose the use of his own TCP/IP stack to all the other users. It's when you start a process that you decide which stack your process should use.

Also, even if you have your own machine, using translators permits to run the VPN client as non-root.

Not really a good point...

dlang — Thu, 21 Jul 2011 19:45:53 +0000

and there's no security risk with any user setting up a new network stack for the OS

sure.

there are reasons that the administrators on systems don't let everyone on a system do all these things.

but if you want to do those things, don't argue with the administrators, just run your own machine (and if your response is that your company won't let you, then you probably shouldn't be doing it anyway, it's the companies network, not yours)

Not really a good point...

civodul — Thu, 21 Jul 2011 19:38:59 +0000

Well, "here and now", GNU/Hurd allows users to extend the system at run-time, without root privileges. "Extending" means users can launch their own instance of any subsystem, be it a file system, networking stack, console, authentication service, or a complete sub-Hurd.

Nice article... but light on technical details

sthibaul — Thu, 21 Jul 2011 19:09:41 +0000

Translators are not only about files, but also network, user authentication, sound stream, etc. Everything in the system actually.

For instance, on a Linux system, to use a VPN, you need to set up a tap, which is a privileged thing. With translators, since the TCP/IP stack itself is not hardwired in the kernel but translated, you can start your own stack as a translator, using a UDP stream via the main TCP/IP stack to send packets to some remote place, and then you can make your application use that translator, thus getting the VPN feature without needing privileges.

Not really a good point...

khim — Thu, 21 Jul 2011 18:40:26 +0000

It can be noted that users can develop and run their own file system, networking stack, and whatnot without (1) requiring root privileges, and (2) compromising or otherwise interfering with the system.

Practically speaking this is true for Linux as well. Since HURD is pretty much useless as a desktop you need to run it in some kind of VM. If you run Linux in VM you can develop your own filesystem, networking stack or whateever without affecting host system.

Sure, this is huge theoretical advantage... and it remains theoretical for the last 20 years. Rule of thumb says it'll become practical advanatage in another 20 years... well, maybe. If anyone will still care by then.

Overall, I recommend looking at the rationale and examples available at http://hurd.gnu.org/ and in particular http://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html and http://www.gnu.org/software/hurd/hurd-paper.html .

This talks mostly about state of your desktop in year 2030. This article about situation here and now...

Nice article... but light on technical details

alfille — Thu, 21 Jul 2011 18:37:08 +0000

Your references are helpful, but seem very dated. VAX, ftp, Xerox NS are the examples given. One worries that the design hasn't evolved.

The "translators" seem similar to FUSE in allowing user space filesystems. Could you describe the differences?

Nice article... but light on technical details

civodul — Thu, 21 Jul 2011 17:10:56 +0000

I find the article light on technical justifications and examples.

For example, the phrase "by giving users and programs as much control over their computing environment as possible" deserves to backed. It can be noted that users can develop and run their own file system, networking stack, and whatnot without (1) requiring root privileges, and (2) compromising or otherwise interfering with the system. Sadly, the conclusion of the article (that GNU/Hurd is for "for developers who want to dig deeper into system development") dismisses this aspect.

Overall, I recommend looking at the rationale and examples available at http://hurd.gnu.org/ and in particular http://www.gnu.org/software/hurd/hurd/documentation/trans... and http://www.gnu.org/software/hurd/hurd-paper.html .