Slashdot Mirror
Hurd: H2 CD Images
An anonymous submitter sends in: "The Debian GNU/Hurd team released a new Hurd CD Image. Snapshot images are produced at a four to eight week interval and the H2 images are the tenth of the series. The Hurd has grown from one CD image in August 2000 (A1) to four images in December 2001 (H2). These images are snapshots of a developing operating system, so suitable precautions must be taken when making an installation. Similar to other architectures, most important programs reside on CD 1, while the other ones contain less important packages. For the moment, Hurd doesn't support card sound and partition size is still limited to 1 GB. Hurd use the Debian packaging system (dpkg and apt as for Debian linux) , so it is simple to install and update packages."
http://www.gnu.org/software/hurd/hurd.html
HURD is a microkernel, based on Mach, an early experimental microkernel that, commercially, is the basis for some Unixes (Digital Unix, IIRC) and NextStep. Mach itself is tiny and deals with little more than task switching, IPC, and memory management. Processes run over Mach to provide the major services, so there's a TCP/IP server, and a file system server, etc, together with the device drivers. The whole lot, Mach + services is HURD (actually, I can't remember if HURD actually uses Mach directly or something based on it. Someone else can address that)
Technical advantages? Depends on who you ask. Mach is not known for being a particularly good example of a microkernel, and Torvalds himself has dissed it. It's just a different approach ultimately. I believe, from experience, that it's generally easier to implement things like real time work in a microkernel because a more monolithic structure requires attention be spent in almost every part of a much larger kernel ensuring everything has a finite latency, but that doesn't mean it's impossible.
Nothing in the above should be taken as meaning support for either architecture, but opinions on this score are so extreme that I'm expecting to be flamed anyway. Oh well, c'est la vie.
You are not alone. This is not normal. None of this is normal.
security. security. security. HURD is less usable right now but will catch up soon. its more secure and less failure prone (crashing a server/translator/device driver doesnt bring down the whole system unlike winxx, linux, bsd or any other OS). its also more secure with user privs allocated to device drivers and the removal of a single root account.
Because they want to work with something new.
Because they have some ideas as to how the hurd could be adapted to their purposes.
The list goes on.
A lot of people are saying things like 'this will take years to reach the popularity of linux' or 'until it has all the bells and whistles'. Hello....
Who ever said the hurd was supposed to be ready yet? I don't recall hearing it. The hurd is there for people to work on because they want to, period.
There was a time when Linux was just as much of an ugly duckling, you know.. where nobody would use it for anything serious. It was something to be tinkered with, nothing more.
So in terms of 30 year old baggage, HURD is out there with Linux, BSD Lite, QNX and Darwin/MacOS X.
Me, I like the *ix way of thinking. If I dislike anything about GNU/Linux, BSD, etc these days, it's how far they're going away from the KISS principles that make *ix excellent.
You are not alone. This is not normal. None of this is normal.
Usually. The problem is that x86 just wasn't designed for microkernels (or operating systems in general, it seems). A system call (which is essentially nothing more than a jmp) takes 40 times longer than a regular function call (on my PII 300 anyway). That's the performance hit for a monolithic kernel like Linux. A context switch (which microkernels do tons of) takes two user/kernel transitions, plus one save of register state (~100 bytes on x86) and one restore of register state. In computer time, a context switch is glacially slow. Now, microkernels circumvent a lot of the slowdown through tricks like buffering commands (batches commands and sends them together in one message), but it still has more overhead than the monolithic kernel method. Of course, given that people think that KDE2 is a usable piece of software (speedwise), it seems that people don't notice speed differences anyway, so the point may be moot.
A deep unwavering belief is a sure sign you're missing something...
IANAKEOAS ( I am not a kernel expert of any sort) but microkernels differ from monolithic kernels is many ways other than hardware drivers running as services. They only pass messages between components meaning EVERYTHING is a server. Want to run Linux programs on a Mach kernel? Just run a Linux server and the software will run just fine. A good example of this is MkLinux and Windows NT. Windows NT runs a Win32 as a server but by the same token can run a POSIX server so POSIX compliant software also runs on it. MkLinux is a Mach kernel running a Linux server to run Linux software. Microkernels in theory are platform agnostic as they only pass messages between various servers. Most people except Linus Tovalds really dig microkernels and have put alot of work into them. Another advantage is you can remain platform agnostic in design yet run servers specific to hardware you're running on. You can go from running on a StrongARM system with 16 megs of RAM to a 32 processor x86 system using a majority of the same code. Notable microkernel based OSes include Windows NT, MacOS X, and of course HURD.
I'm a loner Dottie, a Rebel.
Under VAX/VMS, you didn't jump directly to the code though. The resulting page access fault would take to long to execute. You did a call that triggered a change-mode which went through a dispatcher. However this was relatively fast as no process switches were involved. Also, it meant that the argument list was always passed in a checked form (however, not the contents of the list, that was up to the system service).
Unfortunately, Unix concentrated on the two levels only, User and Kernel. Some RISC microprocessor designers then decided that all this extra stuff was superfluous so they dumped the support from the MMU.
So if you design for the lowest common denominator, then ok, you have two levels only. The uKernel makes it difficult because you have to context switch to process requests. If this is a heavily used system service, do you really want to do this? However, modern processors combined with a modern Unix, can context switch pretty fast.
See my journal, I write things there
Which also means that you don't have to put up with LILO messing up your system every now and then, or having to run 'lilo' every time you install a new kernel or want to change something in the boot configuration.
Then there's the debate of putting GNU on everything ... why ... GNU doesn't own it ... the author owns it ... and unless GNU wants to pay for my life like it does stallman ... my software won't be GNU ... it will however follow the GPL license ... well that is ... until I make it BSD code :-) ..
Where do you get this thing about "putting GNU on everything"?
The only thing I can think of that you could mean is the whole GNU/Linux thing.
There is a kernel called Linux.
There are operating systems built using that kernel and also using the GNU utilities and other GNU code (i.e. things that actually come from the GNU project, not just stuff that's under the GPL).
These operating systems are generally called Linux, just like the kernel. I call them Linux just like most people do, it's a nice easy name and people have a pretty good idea what you mean when you use it.
The FSF would like people to call these operating systems GNU/Linux to reflect the GNU code that's used in them as well as the Linux kernel. This has nothing to do with Linux being under the GPL. It has nothing to do with them wanting to "put GNU in front of everything". They explicitly and emphatically are not asking people to call Linux (the kernel) anything except Linux.
I can understand disagreeing with their wish that you call these operating systems GNU/Linux. Like I said I call them Linux. But from your post it doesn't seem that you actually understand their position well enough to disagree with it. They aren't asking for GPLd programs in general or software in general to be prepended with GNU. I doubt very much that you have any reason for your apparent fear that they will wish to call your software GNU/whatever just because it's under the GPL. I'm assuming that you were genuinely confused on this point.
If you were just trolling then yes, ha ha how stupid of me to respond seriously, you really got me there. My I'm stupid. Well done.
I hope you were honestly confused and that I've helped you to understand the FSF's position. By all means disagree with it but try not to misrepresent it.
If a module runs with limited privileges, security flaws in it can't be exploited to subvert the rest of the system, and sysadmins can safely allow normal users to install (or even develop) special-purpose modules for themselves without risk to any users who don't want to use those modules.
The problem is that x86 just wasn't designed for microkernels (or operating systems in general, it seems)
I can smell a flamebait when I read one. Sorry, but that statement is plain silly. ia32 has (as you asked earlier in an other comment) excellent features to support a microkernel (or any OS), such as multiple levels of privileges, extensive protection mechanism and relatively fast context switching.
A system call (which is essentially nothing more than a jmp) takes 40 times longer than a regular function call (on my PII 300 anyway).
A jmp?? Don't you want it to return??? Linux uses a software INTERRUPT to do system calls (bad decision in my opinion, ia32 provides fine call-gates that are a lot faster).
A context switch (which microkernels do tons of)
A microkernel does not have to do tons of context switches. I think what you are talking about is message-passing kernels. A microkernel does not have to based on message passing. It can use calls, and in fact the ia32 architecture lends itself very nicely to switch between privilege levels quickly, thereby providing protection that a monolythic kernel lacks.
The prove that a well designed microkernel can be VERY fast is QNX.
GNU was never really finished -- if the HURD kernel is ever final, it will be the last piece. But when you clone a highly modular system like Unix, you end up with a lot of bits and pieces that are useful as separate products. So GNU's libraries, utilities, and (most of all) compilers developed a life all their own. Personally, I've never been impressed with the quality of GNU software, but it does have functionality that closed-source venders always seem to overlook. So GNU products are almost ubiquitous in the Unix world, and have a fair following on other platforms.
So time passes. It's 1991. People are still waiting for an alternative to paying fees to whoever owns Unix. (It changed hands several times.) One cheap alternative is minix a sort of toy Unix that sells for $100. But a certain Finnish grad student can't even afford even that much. He decides to write his own Unix kernel. He gives away copies to a few friends. Who give it to a few friends... All of a suddent, lots of people are using this kernel to run all the GNU software. Which means there's now a free alternative to Unix! Project GNU has succeeded! It's just not complete.
And since the final piece of the puzzle is a non-GNU program, that program ends up being the name for the whole conglomeration! Much to the disgust of Stallman. Maybe he's just testy because Torvalds doesn't like EMACS.