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.
I'm a user space developer. I'd be pretty wary of getting into the mad world of kernel development, and one of the things that would put me off is the difficulty of running a debugger against my code. So one of the attractive things about the HURD is that I could do stuff that would normally require me to be a kernel hacker in user space, making the whole development process easier.
Except that it isn't. Not according to Stallman and the HURD developers, anyway. The received wisdom, confirmed by RMS and others, is that one of the things that allowed Linux to streak ahead of the HURD in completeness and useability was the relative ease of debugging on a monolithic kernel, compared to the microkernel.
Clearly, I'm not getting something important: can someone lay it out for me? I'd be dead grateful...
--
Xenu loves you!
http://www.gnu.org/software/hurd/hurd.ht ml
This is due to the way the communication works. On a monolithic kernel, when a process needs, say, to perform a filesystem read, it will invoke a processor trap to go in kernel mode (protection level 0), then perform the task as a privileged task (from the processor's point of view). The overhead is just a trap call, which is comparatively low: even the branch prediction mechanisms are not invalidated by this. On a microkernel, on the other hand, the process needs to send a message to the server task. Essentially, things proceed thus: the client task writes the message to a memory page, then goes in kernel mode to ``send'' the message to the server task (all that is just as fast as for a monolithic kernel); then it starts waiting for the reply. But that means it is unscheduled and another task (presumably the server task) is scheduled in its stead. The reschedule may be slow, since it involves replacing all the registers, but that is not the worst part. The worst part is that the paging register is changed (the virtual memory layout is unique to each task, so a task change must change the paging register, CR3 on an Intel), and that means that the TLB (``Translation Lookaside Buffer'', the cache for the paging mechanism) gets flushed. This is why processes are so much more costly than threads (which share the same address space), and this is why RPC calls are so costly. There are two context switches (TLB flushes) for each single message sent from the client to the server (plus, possibly, its reply).
At a sufficiently abstract level, a monolithic kernel is nothing else but an I/O access library which is shared by every process and which enjoys certain specific rights. In a way, every process ``carries its own copy of the kernel'' with it. On the other hand, for a microkernel, the ``library'' approach is replaced by a ``client/server'' approach.
There are possible ways around the problem. A microkernel architecture like QNX uses a single address space. Since user tasks operate at the same privilege level, they are not protected the ones from the others. It may be possible to put the device drivers at ring 1 (between the kernel at ring 0 and the user processes at ring 3), I think NT does this; but this contradicts the basic principles of symmetry which the Hurd tries to enforce. Segmentation might also help things, but it is hard to work with. Or, simply, more modern processor architectures might not enforce a TLB flush with each change of address space, but simply mark TLB entries with the address space with which they are associated (or some such thing), or some such thing. I think the Alpha does something of the kind.
On a SMP machine, the cost of an RPC call is not nearly so high: imagine the client task is running on processor A while processor B is idle; when the request is sent, processor B immediately starts executing the server task, and when the client task starts waiting, it is not replaced by another task because no other task is waiting, processor A just waits until processor B finishes execution, so no context switch occurs on either processor if the scheduler is good enough. Essentially, we have not used two processors, but merely the fact that two processors have two TLB's.
It may also be possible to group requests as much as possible before unscheduling the client. But that is rather hard to do. This is what the Xlib does for the X protocol, but I do not see how the libc (which is the analog of the Xlib for the Hurd protocol) could do the same, considering the semantics it has to obey (notably that each call must return an error code).
When RMS started out fighting for free software, he had a dream that one day, we would have a whole operating system based on this idea, and on the GNU Public License. They had already worked to make other free software, which ran on UNIX machines, but no kernel. (Things like emacs, compilers, X server, window managers). His eventual dream was for the HURD kernel, which would be the foundation for the GNU/HURD operating system. However, development went slowly, and when in 1991, Linus Torvalds released the Linux kernel, it was quickly paired up with the already available GNU tools to create a complete operating system. Thus, Linux became the kernel used to make the operating system that HURD was meant for. If you go and read the HURD webpage, and gnu.org (Note correct link: http://www.gnu.org/software/hurd/hurd.ht ml ), then you will notice that they talk about the key advantages to HURD, being that it's object oriented (always a plus for easy modification, though often means drop in speed) and several other things that industry techies have critized the linux kernel for not having. Honestly, for Linus and his cohorts to do something drastic to the linux kernel ("Hey, let's modify it so it does ...") it would be a project that would take years to develop.
/.
However, I have never tried HURD myself, probably will never even do so unless their development kicks into action quickly like Linux has so they can survive, so I cannot verify anything. All that I know is probably just what I've read in the various FAQ's and on
It is more stable than other easily available options like Windows 98/NT.
It provides access to, and a healthy environment for, a large pool of standard tools: gcc, Perl, Python, awk, Emacs, etc.
The first is what we usually hear about, but the second item is just as important. If you were using UNIX on the job or at school in 1988, then you'll be pretty much at home in 2000, because everything is generall the same. I used UNIX on a Sun workstation for software development in 1991, and all of that experience carried over when I started using Linux at home and at work in 1999. Nothing much has changed. It's good to be able to keep that knowledge over a long period of time and not have to relearn in every few years.
In that light, the line between Linux and the Hurd is pretty irrelvant. We already have a working key that lets us access the tools we want, so it doesn't matter what kernel is beneath them. There's no reason to run over to or even follow the development of the Hurd.
That's not to say that Linux is the ultimate OS, because it isn't. It's a total piece of junk in many ways, but that's what you expect with UNIX, and that's where Linux descended from. There are great opportunities for operating systems with much different philsophies. Look at the OS in the Palm, for example. It's not an OS in the geeky computer user sense, but it does exactly what it needs to do, is extraordinarily useful, and people like it. Hurd is too close to the UNIX/Linux style for anyone to care.
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.