Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
GNU is Not Unix Linux

Test Driving GNU Hurd, With Benchmarks Against Linux 335

An anonymous reader writes "After last week's news that GNU Hurd is coming, Phoronix set out to install Debian GNU Hurd and to provide GNU Hurd vs. Linux benchmarks. Linux was mostly faster than The Hurd while also having much better hardware support, multi-core SMP support, and other modern functionality."
This discussion has been archived. No new comments can be posted.

Test Driving GNU Hurd, With Benchmarks Against Linux

Comments Filter:
  • Serious question (Score:4, Interesting)

    by AdmiralXyz ( 1378985 ) on Monday July 18, 2011 @03:18PM (#36802658)
    Not trying to troll here, but why would one use GNU Hurd? What does it offer over Linux? The only fundamental technical difference of note I see is that it's got a microkernel, and arguing about monolithic kernels vs. microkernels is like arguing about vi vs. Emacs: I haven't seen anyone do it seriously, instead of tongue-in-cheek, in years. I imagine there are "non-free" parts of Linux scattered about, and maybe that's a reason to use GNU Hurd, but pretty much all of those are due to device drivers, and making a new OS won't help with that. Even rms admits it's a waste of time [reddit.com]. Does Debian really have nothing better to do?
  • Linux vs HURD (Score:5, Interesting)

    by mswhippingboy ( 754599 ) on Monday July 18, 2011 @03:29PM (#36802776)

    At the risk of being lambasted, I don't understand why everyone is kicking so hard at HURD. Sure, it's nowhere close to Linux in any respect, but then it never attracted the throngs of developers that Linux did. OS/X is proof that the idea of building on the mach kernel can result in a sound and performant OS. I for one salute those that have stuck with or picked up development of what many would consider a lost cause. Eschewing a technology because it's not popular does not engender innovation. Personally, I hope the HURD team begins to attract more developers and eventually begins to catch up with Linux because competition, even in the FOSS arena, is always a good thing.

  • Re:Linux vs HURD (Score:5, Interesting)

    by gl4ss ( 559668 ) on Monday July 18, 2011 @03:45PM (#36802932) Homepage Journal

    hurd is an example of how despite being open and free, you can still run the ship with closed minds. it almost seems like a grant money scam.

  • Re:Linux vs HURD (Score:4, Interesting)

    by steveha ( 103154 ) on Monday July 18, 2011 @04:27PM (#36803390) Homepage

    I think that people kick at HURD because of the grand claims made by some HURD fans. These grand claims have not panned out.

    If you look at the old HURD FAQ [gnu.org], you will see claims that "Linux and BSD don't scale well" and that HURD, being based on Mach, should scale better for SMP; furthermore, HURD would be "considerably more flexible and robust than generic Unix".

    The superior architecture of HURD was supposed to make it easier and faster to develop and debug HURD, and thus HURD was going to leapfrog past Linux as the obviously better solution.

    Kernel debugging in Linux is significantly harder than user-space debugging. The microkernel design of HURD was supposed to allow for things like file systems to be written and debugged with the ease of user-space development under Linux. That being the case, it seems surprising that HURD is so far behind Linux after so many years.

    I'm not an expert on this stuff, but here are my thoughts on the current Linux and HURD situation:

    First, Linux scales really well now. People are using Linux on really large SMP systems.

    Second, a microkernel architecture, while more robust than a monokernel, cannot be as fast as the monokernel. If one subsystem wants another subsystem to do something, it must format and send a message; the other subsystem then receives the message, unpacks it, validates it, and then does the action. This is more secure and more stable than the monokernel, where the one subsystem will just make a function call in the other subsystem's code; but it is inherently slower. So Linux is scaling better than HURD expected, and Linux has an inherent speed edge, so HURD is unlikely to outperform Linux. Meanwhile, while it might be true that HURD is easier to debug than Linux, the kernel developers have figured out how to debug Linux, and there just isn't enough benefit there to warrant a switch to HURD.

    Finally, Linux is widely used and well understood; lots of businesses are running mission-critical apps on Linux. Even if HURD's microkernel design gave it a theoretical edge on Linux for reliability, the real-world experience is all on Linux; it has been shown to be Good Enough while HURD is only theoretically better.

    steveha

  • Re:Linux vs HURD (Score:4, Interesting)

    by mswhippingboy ( 754599 ) on Monday July 18, 2011 @04:30PM (#36803442)

    Actually, if I were a developer interested in getting heavily involved in OS development (which I am), and had the time (which I don't), something like this would be appealing to me. Trying to get one's arms around Linux, much less to be able to obtain commit status is about near impossible for someone just starting out. HURD is much smaller and the mountain to climb much lower to reach the point of being able to contribute to the project. I also think it's premature to write off micro-kernel technology all together at this point. Massively Multi-core CPUs (as in 100's or 1000's of cores) may mitigate the performance hit that micro-kernels suffer from on today's hardware and may prove to be a better fit than the monolithic Linux kernel of today. I don't know that to be fact, though no doubt many here will point out how wrong that position is, but it makes sense to me instinctively. The point is, no knowledge gained is wasted knowledge and whether it leads to enhancements to Linux or boosts the viability of this technology, the endeavor is certainly worth exploring.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...