You can do the same with Linux [LWN.net]

You can do the same with Linux

Posted Jul 21, 2011 20:47 UTC (Thu) by sthibaul (✭ supporter ✭, #54477)
In reply to: You can do the same with Linux by khim
Parent article: Signs of life from GNU Hurd

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.

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