|
|
Subscribe / Log in / New account

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

Posted Nov 5, 2015 1:21 UTC (Thu) by khim (subscriber, #9252)
In reply to: GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released by sthibaul
Parent article: GNU Hurd 0.7, GNU Mach 1.6, GNU MIG 1.6 released

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.


to post comments

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

Posted Nov 5, 2015 11:34 UTC (Thu) by pboddie (guest, #50784) [Link] (4 responses)

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

Posted Nov 5, 2015 12:57 UTC (Thu) by fb (guest, #53265) [Link] (3 responses)

> 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

Posted Nov 5, 2015 15:20 UTC (Thu) by pboddie (guest, #50784) [Link] (2 responses)

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

Posted Nov 5, 2015 16:23 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> 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

Posted Nov 5, 2015 18:47 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> 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

Posted Nov 5, 2015 19:03 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link] (3 responses)

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

Posted Nov 5, 2015 23:48 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

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

Posted Nov 5, 2015 23:56 UTC (Thu) by sthibaul (✭ supporter ✭, #54477) [Link]

> 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

Posted Nov 21, 2015 9:58 UTC (Sat) by jengelh (guest, #33263) [Link]

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


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds