Slashdot Mirror


Hurd: H2 CD Images

An anonymous submitter sends in: "The Debian GNU/Hurd team released a new Hurd CD Image. Snapshot images are produced at a four to eight week interval and the H2 images are the tenth of the series. The Hurd has grown from one CD image in August 2000 (A1) to four images in December 2001 (H2). These images are snapshots of a developing operating system, so suitable precautions must be taken when making an installation. Similar to other architectures, most important programs reside on CD 1, while the other ones contain less important packages. For the moment, Hurd doesn't support card sound and partition size is still limited to 1 GB. Hurd use the Debian packaging system (dpkg and apt as for Debian linux) , so it is simple to install and update packages."

1 of 312 comments (clear)

  1. Re:microkernels may be the way out by be-fan · · Score: 1, Redundant

    Of course it would. But the different parts of it (drivers, file systems, personalities, distributed shared memory, clustering, video support, VM strategies, etc.) could be developed and tested by different developers, independently. With the Linux architecture, almost everything goes through the bottleneck of the Linux kernel developers, and it just isn't working in practice: important functionality takes years to make it into the kernel. It's not for lack of effort or dedication, it's the architecture and lack of modularity.
    >>>>>>>>
    Umm, read kernel traffic sometime. The "Linux kernel developers" are a very large and diverse group of people. They're not some committe that rules the kernel by fiat. That's Linus's job, as well it should be. He ultimately gets to decide what goes into the kernel, and making it a microkernel (say, moving the VM to a seperate process) would not make things any different. Instead of people posting VM patches (as they do today) people would just post VM processes.

    Of course, compiling is "complicated". It a process that involves many steps and is completely alien to many users. It also takes forever. And minor configuration problems result in complete failure. And if the module you want isn't part of the kernel distribution, things only get worse.
    >>>>>>>>>>..
    I never said that compiling wasn't complicated. I'm just saying that it could easily be hidden behind a GUI tool. The configuration is the complicated part, make bzImage && make modules && make modules_install could easily be done by a nice KDE app.

    With a microkernel, module installation could be as easy as installing a new command line program. You can still make configuration mistakes, but a lot of the time and effort can be eliminated. And with a really good microkernel architecture, you can also automate the process much more than it currently is.
    >>>>>>>
    In a proper modular design, installing a new module *is* just a matter of putting a file in the correct directory. BeOS, for example, did this very well. (It wasn't a proper microkernel, drivers were dynamic modules).

    It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.
    >>>>>>>
    Take a look at BeOS sometime. Its a work of art, and really not much less monolithic than a standard Linux install, except that networking is in userspace. (app_server == X server, media_server == aRts, etc).

    --
    A deep unwavering belief is a sure sign you're missing something...