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