Slashdot Mirror
Debian GNU/Hurd Preinstalled by UK Computer Maker
Anonymous Coward writes "Space-Time Systems in Malvern, England, is now offering
computers with GNU/Hurd pre-installed
in parallell with the Debian GNU/Linux
system. Please see
this page for more information." Warning: the Space-Time Systems site loaded slowly when I checked it this morning. You may want to use the (slightly out-of-date) Google cached version for the moment.
A monolithic kernel DOES have some inherent advantages over a a microkernel, but the advantages of the microkernel outweigh its disatvantages. The whole concept of having servers respond to requests and communicating via IPC has the following advantages. 1. The are much more independant, which leads to more stability and easier coding. (You can make changes in one without chaning another, long as the interface remains the same.) 2. The are much more easily updated and maintained. 3. They are much more asynchronous since objects can make requests, then immediatly return and do some more work. This is especially good in something like a file system server or graphics server. For example, in the BeOS drawing kit, my application can make a request to draw a line. The line functions sends the message and returns immediatly. My app can continue its work while the line drawing occurs in the background. It helps even more in hardware accelerated things, since the server can have the hardware do some rendering, while the app continues to do some physics in the forground or something. All this leads to higher performance. Its true that IPC does incur some overhead, but it can be managed with. I don't know who Be does IPC in BeOS (and I don't think they are telling) but it obviously works well since BeOS apps are extremely fast and responsive. If the IPC overhead was really that bad I don't think BeOS would respond as well as it does in media apps. The other thing that bothers me is that you C programmers seem to think that Object Oriented programming incurs a huge amount of overhead. It does incur some, but it is negligable, and vastly outweighed by the fact that by using systems objects to represent the API, the system is not only easier to program, the API can evolve in time without adding a huge amount of weight to the system. I doubt if the performance hit is even 3 or 4%. And the time it saves can be put to good use optimizing the algorithms used. Finally, object oriented systems are much easier to make extensivly multithreaded, and even on a single processor machine, mulitple threads help because the processor does not stall on one task so long. Especially in an OS, which is mostly limited by the speed of the hard disk. By puting disk access into a seperate thread from the program, it stays MUCH more responsive. So not only CAN an object oriented, microkernel OS be fast, it already exists in the form of BeOS. Although it does bother me that HURD is slow at this point. Even BeOS developer releases were lightning fast, and if HURD is to be such a new OS, why is it slow at the beginning. Or is their a lot of overhead built in? Or maybe it is much farther from release than this article would have you believe. If all this sounds like some mind expanding thing, I urge you to go to Be's website and read the whitepaper on the MediaOS. It is heavily marketing based, but has some really nifty concepts.
A deep unwavering belief is a sure sign you're missing something...
Since a few people seem to be interested, I will recapitulate the overall HURD status, from my personal experience and my reading of the debian-hurd and bug-hurd mailing lists.
First, is it usable? Well, it depends for what. It is still quite unstable. Filesystems are under active development, but there are still some problems with them (the ``native'' Hurd filesystem, if that means anything, is ext2 just like Linux, but the ext2 demon still has problems, one of them being that sometimes entire file blocks are replaced by zeroes — this will be fixed soon). The TCP/IP stack is a copy of that of Linux (but the Hurd maintainers are having trouble keeping up with the changes made to the Linux networking code). The security mechanisms are extremely flexible but that sometimes causes problems (for example, the Hurd has one more set of file permissions besides user, group and other permissions, the ``not-logged-in'' permissions, and no tools yet exist that will allow to manipulate these permissions). There are also some strange limitations: for example, Hurd will not work on a partition of more than 1Gb, and it crashes rapidly if not given a swap partition.
X Windows will work with a set of patches. Some other programs cause problems, and sometimes it's the program's fault (because it makes assumptions about the Unix-like nature of the system which are not verified under the Hurd).
On the other hand, the Hurd is stable enough to bootstrap itself (compiler, microkernel, libraries, demons) and perform tasks that do not have stringent hardware requirements.
The Hurd shares the same libc as Linux (the GNU libc, currently version 2.1.2). So eventually it should be binary compatible with Linux (right now it is not, but there is no severe problem with that, it is only a matter of time). This is one of the great hopes of Hurd, the possibility of making the transition completely smooth.
The slowness of the progress on the Hurd is due to nobody working on it full time. Some very competent programmers are devoting a lot of time to it (Thomas Bushnell, Brent Fulgham, Roland McGrath, Marcus Brinkmann and certainly a few I'm forgetting), but they are overwhelmed by the immensity of the task.
In theory, though, the Hurd should be easier to develop than Linux, because it is more inherently modular, and because of the fantastic possibilities of gdb under the Hurd. Also, you do not need to reboot to test changes to the ``kernel'', and you can debug a live kernel without problem; plus, you can test some experimental features without endangering the base system. So, there is no reason that Hurd can't become very solid and stable — quite the contrary in fact. But they just need more volunteers. And the FSF unfortunately cannot affort to hire someone on it full time (say, why not write a check to the FSF specifying that you would like to see it employed for Hurd development?).
On the other hand, in the domain of performance, it is probable that a microkernel architecture can never be at par with a monolithic kernel, at least on single-processor machines. For the moment, the Hurd is horribly slow with filesystems (rm -rf is just a nightmare), but this is mostly because it is completely unoptimized. Still, even when it is, it will probably remain noticeably slower than Linux. It has been claimed, however, that the difference may be significantly less than expected; but it is yet too early to see.
The main advantage of the Hurd is its flexibility. User-land filesystems are part of that. In fact, you do not even need to be root to write a filesystem. (That is one of the things which angers me the most about Linux, the need to be root to mount a simple loopback file.) The Hurd is completely virtualizable, whereas Unix hardly is (well, there is a ``user-mode Linux'', but it is even more experimental than the Hurd), so any user can set up her own virtual sub-hurd with its own set of users, permissions and so on. The security system is soooo flexible: much better than access control lists, it uses capabilities (àla Eros) in the form of Mach ports. If this were made practical, this would be a huge gain on the security side, because you would practically never need to be root for anything, just introduce the ad hoc capabilities and permissions. And the virtualization possibilities let you surround dangerous demons by ``sanitary cords'', making the system much harder to break into. So, theoretically, the Hurd can be a very secure system. Finally, the whole translator system can be used in yet unthought-of ways to provide wondrous communication mechanisms between programs.
However, the real question now is whether binary compatibility with Linux plus the great extra features and flexibility can be sufficient motivation for people to move to the Hurd when it is more stable, and, in the mean time, for more developpers to draw their attention to it. The lack of hardware support, on the other hand, is not a big problem: Roland McGrath has an experimental project for making the Mach microkernel run with the Flux OSKit, so that all the Linux hardware support would immediately benefit the Hurd.