RMS Says Hurd Could Be Loosed in 2002 582
Mark Cappel writes "According to PCWorld, RMS said in an interview in India that Hurd will see the light of day this year."
This discussion has been archived.
No new comments can be posted.
RMS Says Hurd Could Be Loosed in 2002
Related Links Top of the: day, week, month.
UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
what's the hurd? (Score:1, Informative)
I don't understand how it can be a "collection of servers". This is from here [fsf.org] a page off of the Hurd link in submission.
Help.
Re:Ads (Score:3, Informative)
Hurd is (currently) built on top of Mach and provides the major operating system services you'd expect in a POSIX-like kernel. Mach is a microkernel and doesn't provide any (well, doesn't provide many) of this kind of thing itself. It acts as a kind of supporting frame for the processes that do the real work.
Re:What makes Hurd different? (Score:4, Informative)
Hurd is a completely ground-up new design. It's not a Unix or Unix-like kernel, though it does provide those services.
Earlier (Nov 2000) Slashdot story on Hurd (Score:2, Informative)
Re:"Free" Linux Distro (Score:5, Informative)
For your information, Hurd is a microkernel with device drivers as user-space applications, ie. they are not linked into the kernel as in Linux. Since no linking takes place, the GPL does not apply and you can have as many closed-source drivers as you like. GPL does not apply to stand-alone applications if they do not link with GPL code.
Re:what's the hurd? (Score:5, Informative)
The HURD is a Hird of Unix Replacing Daemons. Clearer?
What's a Hird? Hurd of Interfaces Representing Depth. There, all clear now?
Seriously, the HURD is a microkernel system. Instead of having a (relatively) big kernel that provides all the necessary services, a microkernel system has a very minimal kernel and provides most of the services a kernel usually provides by way of userspace daemons (the Hird of Unix Replacing Daemons) instead. [everything2.com]
Academic CS guys have been saying microkernels are the way of the future for years now. Mac OS10 runs on the Mach microkernel. Windows NT was supposed to be a microkernel, although by the time it actually made it to the light of day so much had been stuffed back into the kernel for performance reasons it really isn't one.
The number one drawbacks to microkernels, as the above might lead you to guess, is performance. On a single processor system expect a microkernel to lag significantly performancewise in comparison to a monolithic kernel with equal optimisations. That's a result of the fact that so many things we think of as system services are user processes instead, and of the communication overhead involved (message passing between components is used extensively, and this is not the fastest way to handle things on a uniprocessor system.)
Why do I say "on a uniprocessor system?" Well, some of that overhead becomes unavoidable anyway when you move to a multiprocessor system, and a microkernel is inherently multithreaded, so it's quite friendly to multiprocessor systems. So as multiprocessor systems become more common the performance gap may drop.
Currently the HURD is a collection of servers that run on top of the GNU Mach microkernel. Does that sentence make more sense for you now? I hope so.
The GNU Mach microkernel is something of a performance dog, but at this point the HURD is still at a development only stage anyway so it doesn't much matter. It will probably be moved to an L4 [tu-dresden.de] microkernel instead before it's used in production machines. The L4 family gives much improved performance. Still slower than a highly tuned monolithic kernel like Linux, particularly on uniprocessor systems, but much closer.
So if microkernels are slower, why use them at all? Well, they have the potential to bring an entire new world of flexibility to computing. Imagine having different "personalities" - different collections of "kernel service" daemons, so that your box can run Linux, BSD, Solaris, VMS, or even Windows sessions, on the fly. Imagine being able to switch between them, or run different ones simultaneously, without having "root" privileges and without affecting other users. This is just one of the many interesting things that could be done on a microkernel system but not on a monolithic one. Another one is a system where any user can do all sorts of things that normally require root access, except for mess up other users.
None of the pre-existing systems seem to have ever really taken advantage of microkernel design - rather they just use a microkernel to emulate a single monolithic kernel (usually BSD.) However, there are some pretty incredible microkernel only tricks out there waiting to be done, and the HURD developers plan on finally doing them.
For starters... (Score:5, Informative)
The quick form is:
1. All system services are processes in Mach, including any form of I/O and authentication, They may be switched in/out be the administrator at will.
2. Users may create their own services that are available to themselves or to others. EX. A user can write their own encrypted filesystem that works out of a single large file in their regular home directory. When they log in, they start up their EFS server, mount the filesystem to their own process and work in it. It is not visible to anyone but themselves, and is visible to their own programs as if it was just another directory. Sound fun?
3. Network services start at low/no authority and gain authority based on the ID/password provided by the requesting client. This really reduces the threat of network service attacks. No more root exploits in FTP or HTTP or other services. (In traditional services, the server has high authority and lowers it based on ID authentication)
If these aren't enough fun, read up to see more.
Why the Hurd is needed (Score:5, Informative)
I am happy to see so much interest in the Hurd, even though most of the comments seem to be negative. Let me try to clear up some facts, that hopefully make it clearer what the Hurd is about.
The Hurd was started before Linux was started. So, the Hurd was not a knee-jerk reaction to Linux, GNU/Linux or whatever else. Linux steadily grew, and many people contributed to it, but few contributed to the Hurd. And everybody is happy that we have a very reliable and high-profile free operating system, GNU/Linux, today.
But there are still reasons to continue development of the Hurd. First, it is not, like Linux, an reinvention of Unix, it is a complete redesign. From scratch, essential system services were identified as independant from the rest of the system and put as a seperate program into user space. Care was taken not to force system code to the user. And care was taken to allow the user to replace system services with his own implementation, or extend the system by new services.
So the Hurd consists not of a single kernel, or a single microkernel plus a monolithic server (like Darwin), but it consists of a microkernel plus a dozen and more system servers, plus an independant number of user servers. The authentication model allows the servers and client applications to communicate without prior mutual trust. This design is what makes the Hurd technically enthralling and _completely_ different from any other free operating system kernel in existance. (There are some other systems build like that VSTa and sawmill for example, but they are much less developed than the Hurd).
The Hurd system has thus a mroe complex design than the Linux kernel, for example. Sure, the Linux kernel is not easy to understand. You have all the scheduling, memory management, the driver framework, the virtual file system layer. In the Hurd, you have all that plus a lot more. Many interfaces that are internal in the Linux kernel are external in the Hurd, and accessible by the user. So much more care had to be taken in the design of the Hurd, so it is much harder to get to usable results, because the design had to come before the implementation.
Also, the many concepts, and the new way to think about operating system services set forth consequently in the Hurd, make up a higher barrier to entry for new developers, who have to learn a lot more things before they can make significant contributions than in other software projects. I will not go into the technical advantages of this design here, because that would take too long, but there are many interesting things you can do (as an unprivileged user) in the Hurd you can't do in other systems (or can't do that easily and naturally, eg profitably).
But there are other reasons beside technical advantages that can draw your attention to the Hurd, and they are not related to naming GNU/Linux GNU/Linux. The Linux kernel consists of code from an unknown number of developers, and an equal number of copyright holders. This means two things: The license for the copyright, GPL version 2, can never, ever be changed anymore. Now, you might think of it as a great thing. But licenses need to be changed to adopt to new laws and new technical developments. Software will be used in areas it was never used before (like web services). So, sometimes it is important to update the license of a program, just as you update the software itself. The GPL version 3 is in preperation, and the Linux kernel will not be able to take advantage of its protection.
There is another problem with many copyright holders: Depending on the country you are in (definitely in the US), it becomes very difficult to defend the license in front of the court. I am not a lawyer, but Eben Moglen is, and he has told us before about the difficulties to enforce the GPL 2 on the Linux kernel. So far he has succeeded, but as the FSF is not the only party that has copyright on parts of the Linux kernel, it is much more difficult to enforce the license than, let's say, for gcc. Add to that the fact that Linus explicitely allowed binary-only modules, and you are in muddy water.
A complete operating system, of which the FSF is the only copyright holder, with the FSF's commitment to free software, is a huge strategic advantage for the upcoming battle against world's IP exploitation.
So, the Hurd does exists for two reasons: First, it does something that no other free software does, for which there is a real need. And, it cannot be done by building on other free software, for both technical and legal reasons.
For more information, please visit http://www.gnu.org/software/hurd/hurd.html, and checkt he FAQ and the introduction material in the Documentation section.
Thanks,
Marcus Brinkmann (marcus@gnu.org)
Re:Benefits? (Score:1, Informative)
I can try, but explaining all advantages, and all potential advantages, and explaining why it works and what other advantages result, takes a long time. So it is better you read the introductory papers on http://www.gnu.org/software/hurd/docs.html as well
Some advantages:
1. You can develop your own servers and attach them to the filesystem. If they speak the Hurd protocol(s), your servers will automatically be seamlessly integrated in the overall system. This is how user space filesystems work, but also user space network protocol stacks, user space crash servers, user space exec servers (reading your binary formats) etc. All this as a user, un-privileged, without cooperation by syadmins.
2. You can give up permissions and regain them (in exchange for a password for example). This gives you real security.
3. The Hurd already comes with a couple of natural extensions to POSIX. For example, you can have multiple user and group ids, some effective, some available (and you can exchange them), You can fine control the ids of running processes, process groups etc. In fact, you can control even things like environment variables in running processes.
4. As all system servers are in user space, you can debug them with gdb. Even the critical servers, but for this you have to start a second Hurd. Which brings me to
5. this point: you can run multiple instances of the Hurd or other systems in parallel. In fact, it is theoretically possible (and not hard to implement) to "soft-reboot" this way, eg, you start a new Hurd instance, migrate what you need from theone instance to the other, and turn down the old instance.
6. Those multiple instances can be started by an unprivileged user, of course!
That comes off a bit strange at first, but once you get into the mode of thinking, everything becomes a filesystem or other server and plugs itself into the Hurd design. The possibilities are endless.
Thanks,
Marcus Brinkmann
Re:What makes Hurd different? (Score:5, Informative)
The Hurd is really just like WINE except that it pretends to be a monolithic UNIX system instead of pretending to be a Win32 system. The HURD is currently ported only to Gnumach, but this may change. Darwin refers to both the Berkley UNIX translation layer and the underlying microkernel.
Imagine the ugliness of moving parts of XFree into the kernel. WinNT/XP and Darwin move parts of the video subsystem into the kernel for performance reasons. NT set out to be a true microkernel, and perhapse NeXT started with this goal as well. The HURD doesn't move any of the server code into the kernel. The HURD on Gnumach follows a clean microkernel/sever seperation. Mach is a beast of a microkernel, but in essence the system is a much more pure microkernel. Your video driver goes beserk (supposedly the cuase of most NT/XP bluescreens nowadays) and all you have to do is restart the video server. Maybe you have a watchdog server running to restart essential servers that go kaput.
Of course, there's also the liscence issue for liscence bigots. You can get Darwin's source, but IIRC, you can't redistribute changes you make. I think everyone here will gree that this is less of a Good Thing than GPL or BSD liscenced kernel code.
As for me, I'm a design bigot. Gnumach is more of the Right Way to do Mach, but it's still the beast that is Mach. Bonus points for being a microkernel, but Linux is still more elegant (as are the *BSD kernels). UNIX monolithic kernels do a pretty good job of providng a minimum numberof orthogonal services and primitives that can be well tested and well understood. This is one principle of good design. Mach has over 100 system calls implementing all kinds of non-orthogonal services and primitives. Darwin refers to Mach and the BSD userland personality tranlator designed for Mach. HURD is just the userspace POSIX translator that was supposedly designed to be microkernel agnostic, so you could easily port it to a different microkernel and have HURD running on QNX or RtLinux, or even a monolithic *BSD or Linux kernel. There are efforts to port the HURD to the L4 microkernel. They've discovered that the HURD as presently implemented is highly dependant on certain aspects of Mach. They're debating rewriting the HURD from scratch becase of all of the Mach dependancies. It looks like they'll try and port the HURD to a "Virtual Kernel" and then have a thin library that gets linked in to wrap the VK calls and translate for the actual kernel (and perhapse a few userland servers, depending on exactly how the VK and actual microkernel break up kernel and server functionality.)
If the L4-HURD people suceed, you might actually see the HURD outperform *BSD, Linux, et. al. Microkernels have inherently worse agregate throughput due to the increased coontext switching. However, some L4 implementations cheat and put several tasks in the same address space and simply change the read-write permissions on memory pages instead of actually switching contexts (and flushing the TLB) between tasks. This is called lazy context switching and may actually allow L4 to outperform all of the kernels that use conventional context switching. Of course, the monolithic kernels could also use lazy context switchng, but they are harder to modify. I have a copy of L4 on my machine that is only 49,847 bytes large. About half of that has tobe machine-specific code, so often times it's easier to rewrite L4 from scratch when "porting" to another architecture. After all, there's probably more than 50k of object code that changes between releases of the Linux kernel.
People get confused and claim that Darwin is something of a NetBSD kernel or FreeBSD kernel merged with mach. The kernel has a userland personality that translates Berkley UNIX (BSD) systm calls to mach system calls. There's not really any NetBSD or FreeBSD code in the kernel as far as I know. The kerel is basically the NeXT kernel and BSD 4.3 personality server ported from m68k to PPC and an update to BSD 4.4 personality.
The NetBSD and FreeBSD connection comes from the userland utilities. Originally, most of the userland utilities were ported from NetBSD, but now Apple has snagged one of the main FreeBSD developers, so the userland is becomming more like FreeBSD.
Re:What about software? (Score:3, Informative)
You can install the Debian GNU/Hurd just as you install Debian GNU/Linux (with more edges, I suppose). As the standard windowing system you get XFree86 of course (and I use Window Maker as the wm on my GNU/Hurd system).
Thanks,
Marcus Brinkmann
Re:Why the Hurd is needed (Score:2, Informative)
Re:What IS the status? (Score:1, Informative)
The Hurd is complete as an operating system, in the sense that it provides a full blown POSIX compatible API that works.
It is usable if your requirements are within the features it does provide.
It is not ready for production use, because it still crashes too early under heavy load (bugs) and lacks some features important in a production environment (pick one, let's say firewalling).
I should probably be a bit more verbose about this on the web page, but I only have so and so much time and it is more important to fix the bugs and add the features, than to keep track of what is buggy and what is missing.
We are always looking for skilled volunteers to write documentation, status reports etc, so if you want to help with it, be welcome.
Thanks,
Marcus Brinkmann (marcus@gnu.org)
Bah -- VSTA is a better microkernel-based OS. (Score:5, Informative)
If the HURD increases interest in microkernel-based OSen, good for it -- I *like* my drivers running in userspace! (heckuvalot easier to write and debug that way, no? heck -- that means one can write a prototype driver in Python before putting together the final version in C; let's see 'yall do that in Linux!)
Admittedly, it's not nearly as close to being end-user-ready as the HURD, but for folks doing embedded systems work (or who want a cool OS to play with), it's seriously worth looking into.