Slashdot Mirror

← Back to Stories (view on slashdot.org)

GNU Hurd To Develop SATA, USB, Audio Support

Posted by timothy on from the ear-to-the-ground-gets-you-trampled dept.

An anonymous reader writes "Hurd, the GNU micro-kernel project that was founded by Richard Stallman in 1983, may finally be catching up with Linux on the desktop... Plans were shared by its developers to finally bring in some modern functionality by working on support for Serial ATA drives, USB support, and sound cards. There are also ambitions to provide x86-64 CPU architecture support. GNU Hurd developers will be doing an unofficial Debian GNU/Hurd 'Wheezy' release this year but they hope for the Debian 'Jessie' release their micro-kernel in Debian will make it as part of some official CDs."

9 of 274 comments (clear)

  1. Not in Debian by KiloByte · · Score: 5, Informative

    they hope for the Debian 'Jessie' release their micro-kernel in Debian will make it as part of some official CDs.

    Sorry, but Hurd is being demoted to a second-class (ie, unofficial) port. The rules say that a port that fails to be included in two subsequent releases, gets moved to the debian-ports ghetto, with shining neighbours like hppa (long dead) or sh4 (never has been).

    In some ways, that's a pity -- like, improving other code by forcing removal of buffer overflows/asinine truncations related to PATH_MAX. In others, well, it's Hurd...

    --
    The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
  2. HURD not founded in 1983 by RMS by paroneayea · · Score: 5, Informative

    HURD wasn't started till much later, in 1990: http://en.wikipedia.org/wiki/Hurd The operating system of GNU was started in 1983, work on the kernel wasn't till much later.

    --
    http://mediagoblin.org/
  3. Re:Really, who cares? by ciotog · · Score: 4, Informative

    Actually RMS has said that development of the Hurd stalled largely because of the introduction of Linux, but that there was enough work already put in to it that that they didn't want to cancel it altogether.
    http://www.gnu.org/software/hurd/hurd-and-linux.html

  4. Re:Real artists ship. by gpierce11 · · Score: 5, Informative

    Not only did Stallman write EMACS, but he also wrote parts of GCC, the debugger, and gmake. These are not negligible contributions.

  5. Re:Absurd by Anonymous Coward · · Score: 0, Informative

    That may <s>or may not</s> be a reason for ridicule or pity, depending on your character.

    GNU/Hurd project started: ca. 1990
    USB 1.0 spec released: ca. 1995
    SATA rev 1.0 released: ca. 2000
    First AMD64 CPU: ca. 2005
    And only now they plan to build support for 20, 15, and 10 year old technologies into 25 year old project.

    It tells me about lack of proper coordination, poor project architecture and complete lack of interest from anyone outside.

    I mean, compare with Linux kernel, where every year sees a new architecture or two added by third parties interested in those architectures and new drivers appearing because somebody in the community needed them or wanted to try writing a driver.

  6. Re:Real artists ship. by Anonymous Coward · · Score: 5, Informative

    You'd be surprised how often Stallman's name appears in a Man page for something REALLY useful in Linux. The only reason you don't hear about more recent projects from him is because a lot of the stuff he's written follows the UNIX ideology of giving people a lot of really small tools that can be combined in unique and useful ways.

    Granted none of the stuff his name appears on works outside of the terminal, but 50% of my day in Linux is spent in a terminal because I do embedded development. The guy's tools just work, which is great.

  7. HURD vs QNX by Dr.+Spork · · Score: 4, Informative

    I know that HURD has been the butt of our jokes for a while. Even if you get it to run, it's painfully slow. However, these problems are not inherent to the microkernel architecture, since QNX is lightning fast and is very much microkernel-based. The downfall of HURD was that the processes kept the CPU occupied with message passing rather than actually running programs. QNX figured out how to minimize these overheards. I can be done. RIM (now "Blackberry") bought QNX and closed the source code, which is sad, but it hasn't destroyed the sound rationalle for microkernels.

    1. Re:HURD vs QNX by Animats · · Score: 4, Informative

      I know. QNX does a lot of things right. The company, though, is notorious for driving its customers and employees nuts. It's been sold twice, one to Harmon (car audio) and then to RIM (now Blackberry). The code went from closed source to open source to closed source to open source to closed source. During the latter part of the Harmon period, you could download the entire kernel source.

      The developer community was fed up by this. During the open source periods, there were QNX builds for many major open source products, like Firebird (what Firefox was first called) and GCC. Those are no longer maintained.

      The QNX kernel is only about 60K bytes on x86 platforms. All it does is message passing, CPU dispatching, memory management, and timers. There's also a built-in process called "proc", which is a few hundred K. All device drivers, file systems, and networking are in user space. One of the great things about having such a tiny kernel is that it can be fully debugged. It needs to be changed very rarely. It can be put in ROM and stay unchanged for the life of the machine. In many embedded applications, it is. If the Hurd kernel is much bigger than that, they're doing it wrong.

      You can still get QNX for free for non-commercial purposes. Few people do.

  8. Re:Why should I bother? by cheesybagel · · Score: 4, Informative
    You do not need to recompile a Linux kernel to use new device drivers either because it has loadable modules. But Linux is still monolithic.

    In a microkernel the device driver would be running as a lower priority process communicating with the rest of the operating system via message passing. Rather than running in the same CPU ring level of protection and potentially crashing the OS when you have a driver bug.