Live data from Hacker News

Debian GNU/Hurd Status Update [pdf]

people.debian.org

31–40 of 55 posts

Re: Debian GNU/Hurd Status Update [pdf]

#31

Earlier quoted context omitted.

You can either follow my guide [1] based on updated cross-gnu scripts, or try out gnuxc [2] for bootstrapping a full Hurd distribution, with the caveat that it requires your host to be Fedora. [1] http://blog.darknedgy.net/technology/2015/07/25/0/ [2] https://github.com/dm0-/gnuxc

I found this bit in your post interesting: "kdbus (which was called “neutered Mach IPC” by Neal Walfield)" - does that mean mach ipc provides typed interface registration / binding between userland processes? I admit, I know very little about mach and thought it was for kernel/user-space communication only (both directions)

does that mean mach ipc provides typed interface registration / binding between userland processes?

Yes, practically all Mach subsystems other than virtual memory have ports implicitly created for them. This includes tasks (address spaces) and threads (units of CPU time), which together form processes.

Re: Debian GNU/Hurd Status Update [pdf]

#32

>Hardware support >● i686 >● start of 64bit support WTF? They started 30 years ago and still on an 32bit architecture nobody cares anymore? Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche…

You realize i686 is a catch-all term for 32-bit x86 processors, right? It's arguably the only 32-bit architecture anyone cares about.

ARMv7?

Re: Debian GNU/Hurd Status Update [pdf]

#33
post #10

The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer linking to rump libraries has been able to play OGG files on a Hurd system: https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027... Though obviously in the very initial stages, the implications of this development taken to its end could be enormous. Have…

Exciting! "processes running under multiple uids" Why?

I remember seeing a demo of a very early version of HURD in 2002, and I thought this was the most interesting thing about it. I think in the demo, Marcus Brinkmann showed how in the midst of editing a file in vi in user mode, you could open another file in superuser mode, do an edit there and then go back to the old file in user mode.

Re: Debian GNU/Hurd Status Update [pdf]

#34
Practical question: If I was to get some cheap hardware, like a Chromebook, could I get a Debian GNU/Hurd development environment dual booting on it? What would I have available? I'd at least want a decent shell, tmux and vim and support for the display's full resolution.

I suppose the easier route would be a virtual machine, but I think being immersed in it would be good.

I've wanted to get into kernel or other low-level development for a while and this seems like a perfect entry point. Linux seems too complicating on the surface which is intimidating. And politics suck (see systemd).

Re: Debian GNU/Hurd Status Update [pdf]

#35

>Hardware support >● i686 >● start of 64bit support WTF? They started 30 years ago and still on an 32bit architecture nobody cares anymore? Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche…

You realize i686 is a catch-all term for 32-bit x86 processors, right? It's arguably the only 32-bit architecture anyone cares about.

A lot of phones are 32bit.

Re: Debian GNU/Hurd Status Update [pdf]

#36

Practical question: If I was to get some cheap hardware, like a Chromebook, could I get a Debian GNU/Hurd development environment dual booting on it? What would I have available? I'd at least want a decent shell, tmux and vim and support for the display's full resolution. I suppose the easier route would be a virtual machine, but I think being immersed in it would be good. I've wanted to get into kernel or other low-…

bash, tmux and vim are all supported. You can even have a full Xfce desktop.

Hardware support is unfortunately flaky, in part because the GNU Mach code lacks some features like PCI MSIs and uses drivers from the Linux 2.6 era through DDE. Virtualization is definitely the route through which people run it.

The rump integration will hopefully change this situation, assuming it advances forward.

Re: Debian GNU/Hurd Status Update [pdf]

#37
Linking to the slides without the actual presentation should be punishable by death. The entire point of slides is to supplement the presenter's speech, so if they're completely self-explanatory without any talking, then you're doing your presentation wrong.

Re: Debian GNU/Hurd Status Update [pdf]

#39

Practical question: If I was to get some cheap hardware, like a Chromebook, could I get a Debian GNU/Hurd development environment dual booting on it? What would I have available? I'd at least want a decent shell, tmux and vim and support for the display's full resolution. I suppose the easier route would be a virtual machine, but I think being immersed in it would be good. I've wanted to get into kernel or other low-…

bash, tmux and vim are all supported. You can even have a full Xfce desktop. Hardware support is unfortunately flaky, in part because the GNU Mach code lacks some features like PCI MSIs and uses drivers from the Linux 2.6 era through DDE. Virtualization is definitely the route through which people run it. The rump integration will hopefully change this situation, assuming it advances forward.

I figured this would be about the size of things. I suppose I'll start with a VM. I realized I mentioned Chromebooks in my first post -- reminder to anyone that ARM is not supported, so get an Intel-based model.

Re: Debian GNU/Hurd Status Update [pdf]

#40

I'm not drunk on wine at an OS research conference but I have to ask anyway: Aren't microkernels obsoleted by hypervisors?

Not really, no. A microkernel can be a self-reliant, real-time, event driven OS which can be embedded in any number of specific appliances with a specific skillset for a specific job.

A hypervisor is generally used as a way to run another bloated OS on top of a microkernel. Even if you were to run with the idea of containers directly on top of a hypervisor, you're still looking at more layers of indirection that are meant to generalise the use of the entire stack.

Microkernel = specific.

Hypervisor = microkernel with specific purpose of running general stacks on top.

That's how I would distinguish the two in this instance.

Post reply on HN