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."

Comments

microkernels may be the way out

[markj02]

I think this may be the way out for the current problems with the Linux kernel. The 2.4.17 Linux kernel distribution is almost 30Mbytes of sources, gzipped. Most drivers, installable file systems, and other kernel functionality, are either in the kernel source or need to be installed from sources. Getting the right ACPI or APM options requires endless recompiling and rebooting. A bug in any one kernel module will usually take down the whole system. None of the major Linux distributions has placed reconfiguration of the kernel within reach of the average user, and even for the experienced user it's kind of a pain. Imagine where Linux would be today if you needed to recompile the entire command line toolkit or all of KDE every time you install a new version.

Microkernels attempt to give you a much more "UNIX-like" way of making a kernel: a lot of independent little "servers" that talk to each other and are somewhat isolated from each other. A bug in one kernel module will often not crash the whole system, and there is much less coupling between kernel components. Microkernels are not the most efficient way of achieving that kind of modularity, since the memory protection mechanisms they use are more costly than relying on compiler/language support together with dynamic loading, but given that people are going to continue to write lots of C code for the kernel, a microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.

Well, it's good to see that both the Hurd and the Darwin projects are coming along. I'll certainly give this a try. Its hard for any new kernel architecture to replace something as mature, functional, and widely-used as Linux. But if something like the Hurd turns out to be significantly easier to extend and hack, it may well catch up quickly. Another path to acceptance is that people find that, despite having fewer drivers and less functionality, the functionality that something like the Hurd offers may be easier to configure and deliver to end users in prepackaged form (i.e., without "make menuconfig" and lots of obscure decisions).

Re:microkernels may be the way out

[be-fan]

I think this may be the way out for the current problems with the Linux kernel. The 2.4.17 Linux kernel distribution is almost 30Mbytes of sources, gzipped.
>>>>>>>
A microkernel-based OS would be just as big. Unlike Microsoft, the Linux developers need to develop (and distribute) all of their own drivers.

Getting the right ACPI or APM options requires endless recompiling and rebooting.
>>>>>
That's not the fault of the monolithic design. AtheOS, for example uses a modular monolithic kernel, and it can dynamically update kernel components.

A bug in any one kernel module will usually take down the whole system.
>>>>>
But Linux is generally as stable as any microkernel, and monolithic kernels like FreeBSD are more stable than any existing microkernel (except maybe QNX).

None of the major Linux distributions has placed reconfiguration of the kernel within reach of the average user, and even for the experienced user it's kind of a pain.
>>>>>>>>
And it would be the same on a microkernel. The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary. Since compiling can be hidden behind a GUI tool, and the kernel only takes a few minutes to compile on modern hardware, this doesn't gain much.

microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
>>>>>>>>
Experience has shown that a moduler monolithic kernel seems to be working quite well.

Re:microkernels may be the way out

[markj02]

A microkernel-based OS would be just as big.

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.

The compiling process isn't complicated, the configuring is. That configuring would still be present on a microkernel system, its just that less compiling would be necessary.

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.

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.

Experience has shown that a moduler monolithic kernel seems to be working quite well.

It functions well. It doesn't "work well" in the sense of being easy to install, configure, or extend.

I run it.

[pinkpineapple]

I installed it on my system on its dedicated spare disk, boot it, run it and update the release from time to time.

It's not great as for device support but getting there. Drivers have always and will always be a problem for ANY OS (look at MacOS X and *BSD for living examples.) There are other features in the OS itself that make it forth a try.
If you guys are curious about it, you should definitely give it a try. Some compatibility layer is also provide for Linux drivers and apps. This needs work but what doesn't really.

The good thing is the upper layers which will provide POSIX compatibility for Unix developers to port their work. Pretty straightforward. The main reason why the distro has grown so largely in a small amount of time.

I read false assumptions and mistaken comments on this list about what is HURD. It's a kernel like Linux, and it's based on a microkernel architecture. Mach 4.0 happens to be this micro kernel but the architecture is not locked down so this can evolve if needs to be.
I read also people asking why does HURD exist at all. The answer is pretty simple: Why not? In the ten years it has existed, it should have died many times but it's still here. It's not a commercial OS like BeOS, some it doesn't need to generate streams of revenues to survive. It's just a bunch of code with ideas in it that are still pretty amazing today for it to still occupy developers to put efforts in it.

After all, we are living in a society that should encourage diversity and growth of new ideas (the US haven't being built with pioneers.) So, I am getting sick and tired of the moronic way of thinking in black & white (binary): Only two alternatives (Linux vs. Windoz) and no space for the others . And why is that? Why not letting people who enjoy using BSD and developing with HURD just do it without being hassled by the 2 main opponents?

Feeling grumpy because of the rain today.

PPA, the girl next door.

Re:not BSD ... but BFD ...

[SuperDuG]

The idea is not that GNU is bad, just askewed in their views. I would be willing to bet that 95% of the people who write GPL software, myself included, would not agree with stallman. Then there's the debate of putting GNU on everything ... why ... GNU doesn't own it ... the author owns it ... and unless GNU wants to pay for my life like it does stallman ... my software won't be GNU ... it will however follow the GPL license ... well that is ... until I make it BSD code :-) ..