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.
the main (only?) disadvantage to a microkernel OS like Hurd is that in order to have all drivers be servers, you have a lot more Interprocess Communication. In general, this is a huge speed hit-things like video card drivers have go between process spaces twice just to draw a pixel (line, if you are talking accellerated cards). This is actually why between NT 3.51 and NT 4.0, Microsoft moved the video card drivers into the kernel - they went from one kernel and one IPC call to just a kernel call, sacrificing speed for a big video performance boost.
;-)
Of course, the ideal thing would be to figure out how to make IPC and context switches 'free' (i.e. very low cost as far as CPU time go), probably at the memory management and processor level. If you could cache say, three process structures in backup registers on a chip, you could potentially get something like a microkernel for no added cost CPU-time wise. That and the fast context switching of Sun's MAJC chip would probably completely change computer OS design.
Of course, after you do that, you are pretty close to just building memory management and task switching directly into the CPU - you are one step away from not needing an OS at all
If you could cache say, three process structures in backup registers on a chip, you could potentially get something like a microkernel for no added cost CPU-time wise.
Oddly enough, the old Z80 had two sets of general purpose registers which could be swapped with a single instruction. Something like that ported forward into a modern CPU, and extended to include TLB and segment registers, etc could be the answer. Of course, that's easy to say and I'm not a CPU archetect.
Kind of makes you wonder why they are even shipping Hurd anyway.
It does seem to be a bit early to do HURD pre-installs. I suspect they are desperatly reaching for anything that will differentiate their product from the many others. If they really want to do that with HURD though, they need to wait, or hire some programmers.
On the other hand, it looks like it is just a matter of time (as in finding some) before I end up with a HURD system. It has some intrigueing features.
While I am excited that Debian has come out with a GNU/Hurd, and would be even more delighted if they came out with a GNU/*BSD Distribution as well, I wish they would have waited to dilute their efforts until they were able to release Linux distributions more often than once every year. The Debian distribution is hands down one of the best if not the best in terms of completeness, organization, and stability, but the price tag is using libraries and versions of software that are over a year old (or running the "unstable" version which, trust me, can be very unstable at times).
It is their distro and they can do as they like, but as a longtime Debian user (and hence "debugger") I wonder if diversifying their distribution like this wasn't putting the cart before the horse. Potato (the 2.2.x based release) will likely come out about the same time as the 2.4.x kernel, and I fear it will be another year before Woody (presumably 2.4.x based) will be released, about the time 2.6.x or even 2.8.x comes out.
Don't get me wrong, I like the long-term direction of having similar releases of dissimilar Open Source/Free OSes. I just wish the issue of timely releases had been adequately dealt with first, before so much effort was divided in so many directions.
The Future of Human Evolution: Autonomy
Ummmm...isn't the Linux kernel GPL'd also? Maybe this is the first machine to be completly composed of GNU software, but it doubt ALL of it is.
Finkployd
Linus Torvalds that touches on the monolithic/microkernel issue:
The Linux Edge - Linus Torvalds
This is also a good place to find a copy of the
famous argument Linus had on the subject with
the author of Minix:
Appendix A: The Tanenbaum-Torvalds Debate
The big thing is it is a microkernel design. The difference is that, while a monolithic kernel (e.g. Linux) is one large program that serves up everything from task switching to video (Frame Buffers), a microkernel (Mach) serves only memory management, task switching and inter process communication (IPC). Everything else is served by "servers" that are requested for services through the IPC. /. article some weaks ago, there was an argumentation agains micro kernel design, and the entire micro kernel reserach. The article argumented that monolithic kernels have proved by practice that they work and are prortable and scalable. While this is true, it is true too, that you may create anything using only assembly language, and even succed to create a stable and extensible program. But you still do use C, Ada, LISP, Erlang, Python, Perl and everybody elses' pet language (Not to forget any of them!).
While Linux provides for kernel modules, the implementation of them are not as nice and general as the implementation of servers.
Each server may run in its own memory space (Is this the case with Hurd?), providing for security (A crashing video driver won't crash the harddrive driver). Linux kernel modules, however are linked into the kernel, just as any dynamic library is loaded into an ordinary program.
In addition to this, a micro kernel design provides a lot more flexibility for future extensions.
In a
--The knowledge that you are an idiot, is what distinguishes you from one.
The Hurd implementation is aggressively multithreaded so that it runs efficiently on both single processors and symmetric multiprocessors. The Hurd interfaces are designed to allow transparent network clusters (collectives), although this feature has not yet been implemented
It runs on my dual-Celeron-with-Voodoo-3 BP6.
It seems stable, albeit slow, and there isn't much hardware support. Or software support. And those translator thingies, hmmmm. But hey, it's cool to play with.
If you ever spot an out-of-date package in Debian unstable, please file a wishlist bug against the package. Instructions on how to submit a bug are outlined here.
In fact, please do it ASAP, because potato is freezing in a week.
> Unless HURD does things that other OS's cannot do.
Well, of course, anything that any OS can do, a Turing machine can do. So it's more a question of relative ease.
If we imagine the Hurd as more or less finish, it can do all the things that Linux does, perhaps slower (though it is hard to predict by how much), especially on single-processor systems. But here is a concrete use that the Hurd might have which would not work on Linux: it would make it possible to sell computing power on a machine (for example to put a web server on it), including root access (something which is often desirable), to several different clients without any interaction between them, and without compromising the system security. Because Hurd can be virtualized. This is an example something which could provide motivation to get the Hurd working.
I'd say the debugging is easier, except that what you're trying to debug is much more complex, so that as a whole the whole debugging process is more difficult. Essentially, because the Hurd servers are heavily multithreaded programs that pass messages to each others in all sorts of ways. That is always hard to debug, even in user space.
I don't think this is really the reason why the Hurd has progressed so slowly, though, no matter what Stallman may say. Or at least, there are other factors in play.
I have a dream... that all computers of every architecture will come preinstalled with linux.
I have a dream... that all computers will not be judged by the clock speed of thier processors, but by the file system of thier hard drive.
I have a dream today....
I have a dream... that when a brand new video card comes out, I will have a linux driver and an X-server all ready install... out of the BOX!
I have a dream... that people will figure out that it doesn't matter what distrobution of linux you are running... Kernel 2.2.14 is Kernel 2.2.14! It doesn't matter what color packaging the box comes in.
I have a dream today...
-----------
"You can't shake the Devil's hand and say you're only kidding."
If that's all.. would someone explain exactly what's so great about that?
:)
:)
It's conceptually pretty which makes the Computer Scientist in all of us smile..
Seriously, there are a lot of advantages to microkernel's because you solve the problems in a more generic way. Example: any good microkernel inherently supports all the real-time stuff you would need because that is how it's device drivers work (Mach did not do this in the past.. i donno about now) and there are commercial microkernels which work quite well on this philosophy. This means that when your video driver crashes it dose not crash your system. It also make it much easier to write OS emulation software.
It is also nice that unprivliged users can do all sorts of cool things like create there own file system or user privlage tracking system without creating a security hole. This security system is one of the more revolutionary parts of the Hurd as I understand it. Example: you can add and remove privliges from a running process under the Hurd.
There are advantages and disadvantage and it is generally agreed that the advantages will eventually out weight the disadvantages AND the cost of porting all the software.. the question is when.. sorta like cleaning up your room..
Jeff
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
I am sure you are trying to make a point here, but I'll be damned if i can find it. Basically you are saying that linux is crap, but it's good since that is the way it should be?
Linux is a lifeline into almost thirty years of UNIX tool development. This is a wonderful thing for developers, because we don't have to keep re-learning a new set of tools every few years. But that doesn't mean that Linux is the ultimate operating system outside of that context. That's something that Linux advocates often forget.
I want a distribution that will install completely on floppies if I so desire. I want a distribution that will use the absolutely newest version of some form of software (even newer than unstable for debian) that will at least be able to test stuff out instead of compiling it for myself (ever tried to really live on a 340Mb hd as a linux user? It can be painful).
I have a dream that computer components would be completely 100% backwards compatable and allow me to just take a PIII or something like an Anthalon and just stick it into my 486's motherboard and get it to run. I would like to have a working copy of various GNOME applications that will always work fast and be scable to the processor and memory requirements of a machine. I have a dream that all packages will be allowed for a distribution and that no matter what I install I can upgrade and remove it seamlessly without complaint. I have a dream that all the really interesting developments in computers would not be just for the very elite people in the world and make them more approachable. I have a dream that uncertainty would be removed in the field of technology so that I can be guaranteed at least a decent source of employment. I have a dream that there would be more games that would be scalable and easier to run on crappy machines and not necessitate purtchess of expensive stuff that will be gone shortly.
I have a dream that all kinds of access would be possible for the internet and that truely free internet access would actually work work for linux like it does already for windows and the Mac. I dream of all these things without a heed for their lack of possibility and those of the world call me a Quixotean fool for what ammounts to impossibility in terms of actually advancing civilization. We al dream for these things but they never come true. We all search for things that are not there and we try to believe. What is it that we really want? I want a computer that has all of my interests in heart. But the bastard machines have betrayed me at every turn! Ahhh the humanity of it all! What do I actually care if some person dosn't hae the grapes to actually just get a video card that is a little less powerful or a processor that is in fact a little slower than the absolte best? Does it really affect me? Does the universe cease to turn and does the su n then burn out? Do I suddently become fated to have my life
eclipsed by the shadow of Zuses's wrath? I propose not really.
Linux does a better job of my needs but why the bloat to the total operating system in the array of implimentations of such things as grahics? Why do simple dos games that ran quite well on 286s (Wolfenstein) and such still preform slugglishly on higher end 486 machines? Why the obcession with pretty pictures and the like? Why do we need to observer all that is there without regard to content or use?
Yes we dream of things but will they come true for you or I or any of the people on this spinning blue sphere in any fashion at all? I think not.
Slashdot social engineering at it's finest
And why exactly does clock speed not matter compared to the file system? If I have an 8088 processor and have this magical filesystem on a floppy does it mean that suddently I can play quakeII or what?
I think in this weary world we have clock speed does matter. I should think quite a great deal. Why then do we have overclocking at all in the first place.
Slashdot social engineering at it's finest
What the arguments basically sum up to is that because you have to communicate with each of those processes and such for even mundane things like the video card or the hd and such that the speed goes down. The nightmare that I envision is that eventually people will not even care the machine is just screwing around with it's time because processor power will just increase.
Slashdot social engineering at it's finest
Just take a look at the difference between say something like perl which is interpreted for the most part and something like assembly.
Assembly can do things quite quickly however it is not very easy (not impossibly mind you just takes a lot longer).
That is basically what is happening here; because you are not executing snippets of the code you are executing programs that will interact with another kernel. Because of this you could have for instince say have a problem in playing quake or such when you need to do something like write temp data to the hd or something that it would force something else (maybe the keyboard to take a less active role or maybe the mouse) then boom someyone kills you with the BFG10k or something.
Yes X does this already but some of that is changing look at the frambuffer in the 2.1 and 2.2 kernels.
Slashdot social engineering at it's finest
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.