LWN: Comments on "GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released"

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

jengelh — Sat, 21 Nov 2015 09:58:51 +0000

>tedious [...] to loop-mount images. That can not be avoided on Linux because the FS code runs in the kernel. The Hurd avoids the issue entirely by running the code as the user who does the mount.

Well, through UML, one could run the entire Linux kernel as a user ;-)

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

massimiliano — Thu, 12 Nov 2015 07:47:19 +0000

Wouldn't fuse be enough to do this on Linux?

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

sthibaul — Thu, 05 Nov 2015 23:56:13 +0000

> I'm yet to see a system on which administrator trusted HURD enough to use it at all!

There are several Hurd porterboxes out there, where people can completely safely loop-mount whatever images they wish.

> FUSE could be fixed over time. This may not be easy, but this could be done.

No. The FUSE model will still go through the kernel, and I don't believe we can ever really trust what happens there.

In the Hurd, FS operations are performed between the applications and the FS translator, the kernel is only involved for the generic RPCs.

> it's developers don't concentrate on solutions for real-user problems but try to tackle some completely useless abstract ideas.

This looks just FUDish to me. Did you really read the pages mentioned above or watch one of my presentations?

> when HURD is brought up to stop things like systemd...

That hasn't actually happened.

But I guess I'll just stop wasting my time on trying to convince somebody who apparently just refuses to get convinced.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

khim — Thu, 05 Nov 2015 23:48:32 +0000

About FUSE, I have yet to see a system on which the administrator trusted FUSE enough for enabling it for users he doesn't trust.

And I'm yet to see a system on which administrator trusted HURD enough to use it at all! FUSE could be fixed over time. This may not be easy, but this could be done. HURD couldn't be fixed because it's developers don't concentrate on solutions for real-user problems but try to tackle some completely useless abstract ideas.

Randall Munroe thinks that HURD would become useful after the end human civilization but I'm not that hopeful.

The people could waste their time and money on what they want (hey, HURD hacking is still potentially more productive timewaste than things like GTAV), but when HURD is brought up to stop things like systemd... this just makes me sad.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

sthibaul — Thu, 05 Nov 2015 19:03:45 +0000

khim, please don't make a simplistic conclusion from a simplistic answer about the difference between the Hurd and Minix :)

“why would you need to empower non-root user today”

As suggested by other commentors: because you prefer to avoid running code as root (and again that's just an simplistic instance of the advantages the Hurd can provide). It is indeed tedious to have to go through root to loop-mount images. That can not be avoided on Linux because the FS code runs in the kernel. The Hurd avoids the issue entirely by running the code as the user who does the mount. The user can even run the code as no-user, thus even protecting himself from bugs in the FS code that the image may trigger!

Really, please read the URLs I pasted before taking part to the discussion. The implications of translators can not be simplified in just a couple of comments.

About having root access, I for instance don't have root access on the Linux Debian systems I work on, and that can be a pain at times for mounting ISO images.

About FUSE, I have yet to see a system on which the administrator trusted FUSE enough for enabling it for users he doesn't trust.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

mathstuf — Thu, 05 Nov 2015 18:47:41 +0000

> There is still the absurd limitation that loopback-mounting images requires root

Well, AIUI, the filesystem code in the kernel tends to be very trusting of the data inside. I imagine there are exploits possible by using subtly invalid images.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

nybble41 — Thu, 05 Nov 2015 16:23:45 +0000

> There is still the absurd limitation that loopback-mounting images requires root...

There is actually a way around that with FUSE and libguestfs: <http://libguestfs.org/guestmount.1.html>.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

pboddie — Thu, 05 Nov 2015 15:20:08 +0000

It seems to me that the per-user applications thing could have value - I've tried to tackle this myself using distribution packages, in fact - although it risks running into a bunch of old problems that rear their ugly heads again in the "virtualisation solves everything" pixie-dust-topped world that will see the average server running their own share of compromised and malware-infested virtual machines, to which the "solution" will presumably be to put firewalls between them and everything else and announce it as a feature.

One thing apart from installing packages that used to be a big problem was mounting media: if you didn't have the permissions, you'd have to find "someone with root" to help you out. There is still the absurd limitation that loopback-mounting images requires root, which effectively translates as the libraries tightly bound to the kernel that understand filesystems being unusable without someone turning the master key. As I recall, this is one of the things used to promote the Hurd.

(Don't worry, I didn't take your reply as sarcasm, given the absence of any broad, easily-falsified claims stated as near-fact. I also find it amusing that people downplay things like the Hurd while playing up things like virtualisation, when the two things are just different sides of the same coin.)

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

fb — Thu, 05 Nov 2015 12:57:19 +0000

> Ask anyone who has worked in a moderately large organisation who needed to install software, didn't want to chase down tens of dependencies, and was told that the systems administrators didn't have the time or inclination to install every package that the users wanted, even though it's a matter of issuing a single command.

Having first hand experience with such environments, so I am very sympathetic to this use case.

However, I don't see how Hurd increases its value proposition for having a decent solution for it:
- often the BOFH admins don't want //any// modification whatsoever to the environment (so support for user customization would be a bug, not a feature).
- when the admins would allow local (e.g. inside $HOME) installations, OSX's "~/Applications" pattern seems to me to be a better solution.

Wouldn't it be better to solve this by just having application bundles getting installed into "~/Applications", or a package management system that supports installing stuff into $HOME?

PS: I am not the OP.
PPS: I am not being sarcastic nor do I mean to be derogatory.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

pboddie — Thu, 05 Nov 2015 11:34:39 +0000

Ask anyone who has worked in a moderately large organisation who needed to install software, didn't want to chase down tens of dependencies, and was told that the systems administrators didn't have the time or inclination to install every package that the users wanted, even though it's a matter of issuing a single command.

Sure, you could probably reboot your computer using distribution media, gain root, do what you want - at least in organisations that didn't lock this down - but you'd only become more "popular" amongst those sysadmins. Or maybe quitting your job and applying for a sysadmin job is what you'd recommend? Or buying your own computer, bringing it to work and putting it on the network?

It turns out that the non-technical issues are really important after all, even when designing technology. If you were being sarcastic, you need to work on your ending, though, because that actually sounds genuine.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

khim — Thu, 05 Nov 2015 01:21:17 +0000

IOW: Hurd solves the problem which was important 30 years ago but which is totally non-issue today. I mean: why would you need to empower non-root user today? Anyone who wants to be a root in a today's world could! And when it's impossible (things like iPhone) it's not because of technical issues, but because of politics! Just why would I want a system where non-root is especially powerful in today's world? To develop software for mainframes? Mainframes support virtualization, too - it fact they do it better than most other systems.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

rsidd — Tue, 03 Nov 2015 14:58:49 +0000

Hurd translators (all three links are about that) look nice. In a way fuse is an implementation of that. I guess the lesson is cool features aren't enough, stability (production-readiness) and compatibility with existing hardware is essential. For example, Dragonfly BSD has many cool features -- the Hammer filesystem, variant symlinks, vkernels, swapcache -- and has far better hardware support than either Hurd or Minix 3. I used it long back (before Hammer). But am not tempted on modern hardware (laptop / workstation) though I may still consider it for a fileserver or something down the line. Ok, I am tempted even on my current machines, but feel that for my kind of work the tradeoff in time spent tweaking / features gained isn't worth it.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

pboddie — Tue, 03 Nov 2015 12:26:54 +0000

I actually tried to use crosshurd a while ago. At the time, I was also debootstrapping Debian Wheezy (the GNU/Linux variant) into another partition for an eventual upgrade to my system, and was going to migrate to that, but I wanted to see if I could get the Hurd variant working, too. Unfortunately, it failed in some way or other and I left the idea behind: even though I'm interested in new stuff, I generally want my system to just work, which is a compromise that isn't often understood (in that distribution people either think you want to break everything to debug their new stuff or you're a dinosaur who hates change).

From what I understand, there are lots of nice things that the Hurd should allow with the translator model. I remember being disappointed a couple of decades ago (this was on Ultrix!) that you couldn't have something like a Unix socket that masqueraded as a normal file as far as other processes were concerned, where the process that created the socket would behave like a server responding to normal file operations. Just recently, I was reminded that this kind of thing would be nice to provide file-like views of database tables, for instance.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

sthibaul — Tue, 03 Nov 2015 10:55:24 +0000

The Hurd has a way more flexible way to provide advanced features for users. Minix remains an administrator-centered system, while the Hurd really insists on empowering non-root users. See for instance
https://www.gnu.org/software/hurd/community/weblogs/ArneB...
https://www.gnu.org/software/hurd/faq/still_useful.html
https://www.debian.org/ports/hurd/hurd-doc-translator

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

juliank — Tue, 03 Nov 2015 08:10:49 +0000

The hurd has a Debian system :) with a lot of software available via apt.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

rsidd — Tue, 03 Nov 2015 05:30:20 +0000

For those who want such a system (tiny microkernel with drivers, filesystems, etc implemented on top), Minix 3 seems to offer everything the Hurd does, with much better hardware support plus an extensive software base (most NetBSD packages work). Is there anything in theory that the Hurd does, or will do, better than Minix 3? Serious question.

GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

jcm — Tue, 03 Nov 2015 04:48:16 +0000

I'm curious...who on LWN actually runs Hurd these days? (this is NOT meant to be a derogatory statement)

And beyond that, makes me wonder if LWN shouldn't have an optional annual survey (xkcd style even) with these kinds of questions. The demographic here is fairly unique from the point of view of studying the Open Source community.