Live data from Hacker News

A Debian GNU/Hurd snapshot

lwn.net

31–40 of 46 posts

Re: A Debian GNU/Hurd snapshot

#31

Earlier quoted context omitted.

Why? Because in the time HURD has sat around trying to figure out whose code to use and call HURD, other people have actually written useful kernels. Minix for example.

Minix was first released in 87, three years before development on HURD even began. Yeah, okay, that was just nitpicking. But they're not doing that anymore, so why bother complaining about it anymore? Sure, it's not up to snuff yet, but perhaps it will be decently soon. Development on HURD has really surged in the past year or two, I'd like to say.

The operating system as a whole is GNU and that project started in 1983. Hurd is just the kernel.

It took them 7 years to even name the kernel that hadn't been written yet. I feel like that says something.

And then when an actual GNU-licensed kernel came along, they ignored it and kept plugging away on vapour.

Re: A Debian GNU/Hurd snapshot

#32
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 la…

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.

Well, it uses it now. (But yes, not as a microkernel.)

You never know how something will come handy — learnt Hurd programming => now not afraid of Mac OS X kernel'ish stuff

Re: A Debian GNU/Hurd snapshot

#33

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.

Linus is a good, pragmatic designer and a fantastic manager. Do give him some credit for fostering the kernel community.

Re: A Debian GNU/Hurd snapshot

#34

Earlier quoted context omitted.

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?

Nope. Sorry.

Re: A Debian GNU/Hurd snapshot

#35
post #33

Earlier quoted context omitted.

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.

Linus is a good, pragmatic designer and a fantastic manager. Do give him some credit for fostering the kernel community.

I did say "one of the reasons", not "the only reason".

Re: A Debian GNU/Hurd snapshot

#36

Earlier quoted context omitted.

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.

I was not criticizing, I was genuinely curious.

Okay then, I donwloaded Debian Hurd and made a VirtualBox image out of it. This should be fun.

Re: A Debian GNU/Hurd snapshot

#37
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 la…

> Linus just got "lucky" and happened to make a kernel before Hurd was done -- but that wasn't the case at all.

The funny thing is it's not even the case that there's only room for just 1 production-quality open source kernel. Through all this time the *BSDs have done rather well in comparison. We might just conclude that despite a great body of work that we all respect and owe a lot to, maybe GNU/FSF isn't all that great at managing a project. (See also: Emacs Schism, GCC vs. ECGS, GCC vs. LLVM.)

(Aside: Personally, I booted Debian GNU/HURD on a Pentium II more than ten years ago to try it out. At the time it was slow and had a bunch of drivers ported from Linux 2.0. It sounds like not much has changed, however I never did get X working, so good job there.)

Re: A Debian GNU/Hurd snapshot

#38
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.

Reading the Plan 9 kernel code hasn't convinced me that its authors focused on correctness. The kernel code is pretty, and its twenty-year-old architecture could pass as only ten years old; but even excluding drivers, there is no shortage of bugs.

Re: A Debian GNU/Hurd snapshot

#39
post #2

As time goes on GNU HURD becomes sadder and sadder :/ They can't even seem to be consistently settled on their basics like what micro kernel they are using https://en.wikipedia.org/wiki/Hurd#Other_microkernels In the 2000s they experimented with 3 other micro kernels, all of which went "no where". Over half a decade spending their limited dev resources on work that ultimately went no where since they are still appare…

The Hurd authors might find your part-time projects just as sad and pathetic as you find theirs. There's not much I can say beyond that, since you've based your judgement on vague and wishy-washy concepts like going somewhere, being "vaguely competitive", and keeping up. It's no business of yours to criticize the direction of a project you have no involvement or stake in, especially when you can't articulate what direction you'd prefer.

Re: A Debian GNU/Hurd snapshot

#40
post #38

Earlier quoted context omitted.

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.

Reading the Plan 9 kernel code hasn't convinced me that its authors focused on correctness. The kernel code is pretty, and its twenty-year-old architecture could pass as only ten years old; but even excluding drivers, there is no shortage of bugs.

You found lots of bugs reading the plan 9 kernel source, and forgot to report them?
Post reply on HN