A Debian GNU/Hurd snapshot
lwn.net
A Debian GNU/Hurd snapshot
1–10 of 46 posts
Re: A Debian GNU/Hurd snapshot
#2As 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 apparently using Mach.
and now (from the article):
- GNU/Hurd 2013 is available for the 32-bit x86 architecture only
- Hurd can currently only make use of one CPU (or CPU core). That is to say, it will still run on multi-core and SMP machines, but only utilizing a single processor.
- Hurd generally uses device drivers ported from Linux 2.0 ... So the latest and greatest shiny hardware might cause trouble.
Once upon a time if you could get it to run on your hardware it was at least vaguely competitive, but now the thought of putting it on my 64bit quad core laptop... well... what a waste.
And instead of trying to even keep up, they are still trying to pick the right micro kernel...
"In years past, Richard Stallman was quoted as saying that Linux was a good option to use while the Hurd was still incomplete"
Re: A Debian GNU/Hurd snapshot
#3Hurd 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 and OS X have zipped by. It feels like nothing short of an apocalypse will bring the micro-kernel back. I think the only major one in the wild in QNX (Blackberry OS), and that's waning. OS X / NT are no longer microkernels.
"Worse is better" still rings true, in more ways than one.
Re: A Debian GNU/Hurd snapshot
#4As 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…
I wonder what could be done to actually turn the project around. There are articles on HN almost everyday about small project management this and agile that. What might actually help this project?
Re: A Debian GNU/Hurd snapshot
#5Hurd 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…
Components were very successful with Visual Basic, but (despite the C# description[1]) haven't really been front and center in languages and operating systems. I honestly think it is because we don't have something at the bottom that was built components first. Decoupling designs is hard, and we get systems of objects and not components.
1) 2nd paragraph of introduction http://www.microsoft.com/en-us/download/confirmation.aspx?id...
Re: A Debian GNU/Hurd snapshot
#6Hurd 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…
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.
Re: A Debian GNU/Hurd snapshot
#7A 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, am glad that they decided to get it stable before they get it fast.
I will always wait for the day I can say my computer runs GNU. Nothing else, just GNU.
Re: A Debian GNU/Hurd snapshot
#8Hurd 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…
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.
MINIX seems to be working pretty well these days.
Re: A Debian GNU/Hurd snapshot
#9Hurd 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…
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.
Most of the kernels that try very hard to achieve correctness (in the embedded / real-time space that would be used in military or aerospace applications) are microkernels. Microkernels have a smaller number of primitives that are more orthogonal, so they are easier to implement correctly and audit them, and you get some amount of preemptibility for free.
Also, as far as I know, the only kernel that has been proven correct with a mechanically verifiable proof is an L4 variant.
Re: A Debian GNU/Hurd snapshot
#10Hurd 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…
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.