Nice article... but light on technical details [LWN.net]

Nice article... but light on technical details

Posted Jul 21, 2011 17:10 UTC (Thu) by civodul (guest, #58311)
Parent article: Signs of life from GNU Hurd

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.

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.

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 .

to post comments

Nice article... but light on technical details

Posted Jul 21, 2011 18:37 UTC (Thu) by alfille (subscriber, #1631) [Link] (1 responses)

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

Posted Jul 21, 2011 19:09 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link]

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

Posted Jul 21, 2011 18:40 UTC (Thu) by khim (subscriber, #9252) [Link] (19 responses)

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

Not really a good point...

Posted Jul 21, 2011 19:38 UTC (Thu) by civodul (guest, #58311) [Link] (18 responses)

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.

Not really a good point...

Posted Jul 21, 2011 19:45 UTC (Thu) by dlang (guest, #313) [Link] (17 responses)

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

Posted Jul 21, 2011 19:59 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link] (16 responses)

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.

You can do the same with Linux

Posted Jul 21, 2011 20:28 UTC (Thu) by khim (subscriber, #9252) [Link] (15 responses)

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.

You can do the same with Linux

Posted Jul 21, 2011 20:47 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link] (4 responses)

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

Posted Jul 22, 2011 4:28 UTC (Fri) by patrick_g (subscriber, #44470) [Link]

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

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

Posted Jul 23, 2011 13:19 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

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?

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

Posted Jul 29, 2011 5:32 UTC (Fri) by Kissaki (guest, #61848) [Link] (1 responses)

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.

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

Posted Aug 1, 2011 14:10 UTC (Mon) by nix (subscriber, #2304) [Link]

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

Fine-grain virtualization

Posted Jul 22, 2011 13:15 UTC (Fri) by civodul (guest, #58311) [Link] (9 responses)

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.

Fine-grain virtualization

Posted Jul 23, 2011 13:31 UTC (Sat) by khim (subscriber, #9252) [Link] (8 responses)

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

Fine-grain virtualization

Posted Jul 23, 2011 14:02 UTC (Sat) by jrn (subscriber, #64214) [Link] (2 responses)

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

This is what started the whole discussion...

Posted Jul 24, 2011 8:14 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

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

This is what started the whole discussion...

Posted Jul 25, 2011 0:05 UTC (Mon) by jrn (subscriber, #64214) [Link]

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

Fine-grain virtualization

Posted Jul 23, 2011 22:59 UTC (Sat) by sthibaul (✭ supporter ✭, #54477) [Link] (4 responses)

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.

Why it does not make sense?

Posted Jul 24, 2011 9:12 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

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

Why it does not make sense?

Posted Jul 24, 2011 13:15 UTC (Sun) by civodul (guest, #58311) [Link] (1 responses)

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?

Posted Jul 27, 2011 18:03 UTC (Wed) by kingdon (guest, #4526) [Link]

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

Why it does not make sense?

Posted Jul 24, 2011 16:39 UTC (Sun) by sthibaul (✭ supporter ✭, #54477) [Link]

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

Nice article... but light on technical details

Posted Jul 29, 2011 5:23 UTC (Fri) by kevinm (guest, #69913) [Link]

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.