Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Debian GNU/Hurd snapshot

lwn.net

Post reply on HN
Print view View original

21–30 of 46 posts

Re: A Debian GNU/Hurd snapshot

#21

Post by Florin_Andrei »

rookieMP wrote: post #7

A lot of people will point and laugh at HURD, calling it a really sad project or whatever. Why? Considering the small number of developers, it has come along spectacularly. Over time, HURD has been improving at a decently consistent rate. I remember a time when it was nearly impossible to get it running even on QEMU. God damn people, sure it's missing features; but those features don't inhibit it running. I, for one,…

> I will always wait for the day I can say my computer runs GNU. Nothing else, just GNU.

Well, um... why?

Re: A Debian GNU/Hurd snapshot

#22

Post by Florin_Andrei »

lelf wrote: post #17

I tried it long time ago. And it's something magical about the fact that you can have one system (GNU/Linux) and don't have any binaries for other (GNU/Hurd), only sources for mach, hurd, gcc, glibc and can piece by piece (cross-)compile everything and get a working system (with gcc! you compile it by cross-gcc which you compile from your native gcc). And yes, /dev/null is just translator (think of it as mount point)…

Wait, these are all separate processes?

What happens if you crash / ?

Re: A Debian GNU/Hurd snapshot

#23

Post by InclinedPlane »

rookieMP wrote: post #16
InclinedPlane wrote: post #14

Earlier quoted context omitted.

Are you joking? Linux is named after a guy, why? Because it started out as a single person project. So did many other major open source projects. The reason why so few people still work on HURD is because it's not seen as very promising or interesting or practical.

Oh right, and Linus Torvalds wrote all the millions of lines of code that comprise the Linux kernel. Sure it started out as a single person project, but it certainly didn't stay that way. One of the reasons development on Linux progresses so quickly is because of the vast number of developers. HURD, to contrast, had a small base initially and has remained that way.

Are the last 2 sentences of my post not visible on your monitor?

Re: A Debian GNU/Hurd snapshot

#24

Post by robotresearcher »

Florin_Andrei wrote: post #22
lelf wrote: post #17

I tried it long time ago. And it's something magical about the fact that you can have one system (GNU/Linux) and don't have any binaries for other (GNU/Hurd), only sources for mach, hurd, gcc, glibc and can piece by piece (cross-)compile everything and get a working system (with gcc! you compile it by cross-gcc which you compile from your native gcc). And yes, /dev/null is just translator (think of it as mount point)…

Wait, these are all separate processes? What happens if you crash / ?

The service restarts. What happens if you crash the Linux kernel?

I'm a happy monolithic kernel user, but there are some great ideas in the microkernel model. Just seems to never quite be the best practical choice except in some niches.

Re: A Debian GNU/Hurd snapshot

#25

Post by lelf »

Florin_Andrei wrote: post #22
lelf wrote: post #17

I tried it long time ago. And it's something magical about the fact that you can have one system (GNU/Linux) and don't have any binaries for other (GNU/Hurd), only sources for mach, hurd, gcc, glibc and can piece by piece (cross-)compile everything and get a working system (with gcc! you compile it by cross-gcc which you compile from your native gcc). And yes, /dev/null is just translator (think of it as mount point)…

Wait, these are all separate processes? What happens if you crash / ?

Yep, user space. It will be restarted.

(Note that I may lie to you about /, it's somewhat special and I don't remember details).

Edit: oh, and when it crashes it will get handled by crash server (you guessed it, user-space program) which can kill/suspend/coredump it. You can choose even by env variable!

Re: A Debian GNU/Hurd snapshot

#26

Post by filmgirlcw »

m0th87 wrote: post #3

Hurd is one of those pieces of tech that just makes me sad. Performance implications aside, micro-kernels feel so much more "right". It feels like proper software engineering techniques applied to the kernel-level. How cool would it be to be able to, e.g. replace the default scheduler with something that satisfies your niche requirements? But in Hurd's quarter century of life, it's gone nowhere, while Linux, Windows…

Exactly - and I don't think OS X was ever truly a microkernel, it used Mach as the base for XNU, but it was always a hybrid kernel even going back as far as the NeXTStep days.

QNX is all that is left and as you say, it's waning -- fast. And ironically, QNX in BlackBerry OS has lost many of the so-called advantages it had in the past, because a large portion of the OS is dedicated to running Android in an emulation layer, thus using a monolithic kernel anyway. sigh

Stallman failed and that's OK. Giving the world emacs and GCC was enough, frankly. He used to always make it seem like Linus just got "lucky" and happened to make a kernel before Hurd was done -- but that wasn't the case at all. Linus got a working kernel working faster and Linux proved to be better than anything Hurd could achieve, full-stop.

Re: A Debian GNU/Hurd snapshot

#27

Post by pilgrim689 »

m0th87 wrote: post #3

Hurd is one of those pieces of tech that just makes me sad. Performance implications aside, micro-kernels feel so much more "right". It feels like proper software engineering techniques applied to the kernel-level. How cool would it be to be able to, e.g. replace the default scheduler with something that satisfies your niche requirements? But in Hurd's quarter century of life, it's gone nowhere, while Linux, Windows…

I wouldn't say QNX is waning... It's used in trains, nuclear power stations, cars, embedded systems etc. If anything, QNX is a good counter-example to your argument because it's one of the few really successful microkernels out there.

edit: a broader list of where QNX is used: http://www.qnx.com/company/30ways/

Re: A Debian GNU/Hurd snapshot

#28

Post by m0th87 »

pilgrim689 wrote: post #27
m0th87 wrote: post #3

Hurd is one of those pieces of tech that just makes me sad. Performance implications aside, micro-kernels feel so much more "right". It feels like proper software engineering techniques applied to the kernel-level. How cool would it be to be able to, e.g. replace the default scheduler with something that satisfies your niche requirements? But in Hurd's quarter century of life, it's gone nowhere, while Linux, Windows…

I wouldn't say QNX is waning... It's used in trains, nuclear power stations, cars, embedded systems etc. If anything, QNX is a good counter-example to your argument because it's one of the few really successful microkernels out there. edit : a broader list of where QNX is used: http://www.qnx.com/company/30ways/

Interesting. I'm so deeply embedded in the web/mobile world that I forgot there are some very real RTOS requirements that drive QNX uptake to this day.

Re: A Debian GNU/Hurd snapshot

#29

Post by chrisdevereux »

lelf wrote: post #25
Florin_Andrei wrote: post #22

Earlier quoted context omitted.

Wait, these are all separate processes? What happens if you crash / ?

Yep, user space. It will be restarted. (Note that I may lie to you about /, it's somewhat special and I don't remember details). Edit: oh, and when it crashes it will get handled by crash server (you guessed it, user-space program) which can kill/suspend/coredump it. You can choose even by env variable!

What happens if you crash the crash server?

Re: A Debian GNU/Hurd snapshot

#30

Post by m0th87 »

papsosouid wrote: post #10
strictfp wrote: post #6

Earlier quoted context omitted.

Remember that microkernels aren't just trying to achieve modularity - they also take a stab at robustness by failure recovery. This is IMO doomed to fail - you are much better off trying to achieve robustness by correctness. Monolithic kernels focus more on correctness and therefore progress much faster.

Monolithic kernels don't "focus on correctness". Some people might when writing one, plan 9 for example. But plenty don't, like linux as the most obvious example.

Interestingly, important parts of the Linux kernel are proven correct (e.g. the scheduler). But yeah...not the whole thing.
Post reply on HN