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."
Until Hurd is closer to Linux or BSD in partition size and overall capabilities, it isn't going to pick up much in the way of popularity.
What they have now is a rather "chicken and the egg" syndrome - it won't achieve popularity until more people start developing for it, and people won't care enough to develop for it until it's more popular.
However, the biggest drawback to Hurd is probably the fact that the people it might most appeal to (people who don't like linux or bsd style unix purists) are less likely to use it because they won't want to put up with the Hurd philosophy, when BSD is already there.
Who is going to use it? Linux has all the bells and whistles for people who love the GPL, and the BSD people who like pure unix and freedom (I know, what is pure unix anyway) are going to stick with *BSD.
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.
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.
Microkernels attempt to give you a much more "UNIX-like" way of making a kernel: a lot of independent little "servers" that talk to each other and are somewhat isolated from each other. A bug in one kernel module will often not crash the whole system, and there is much less coupling between kernel components. Microkernels are not the most efficient way of achieving that kind of modularity, since the memory protection mechanisms they use are more costly than relying on compiler/language support together with dynamic loading, but given that people are going to continue to write lots of C code for the kernel, a microkernel may be the best compromise for achieving a modular, extensible kernel in the real world.
Well, it's good to see that both the Hurd and the Darwin projects are coming along. I'll certainly give this a try. Its hard for any new kernel architecture to replace something as mature, functional, and widely-used as Linux. But if something like the Hurd turns out to be significantly easier to extend and hack, it may well catch up quickly. Another path to acceptance is that people find that, despite having fewer drivers and less functionality, the functionality that something like the Hurd offers may be easier to configure and deliver to end users in prepackaged form (i.e., without "make menuconfig" and lots of obscure decisions).
I think that KISS is no longer a part of the de facto Unix world. When you have hundreds of different ways of keeping things simple that have hundreds of simple kludges and workarounds to keep simply working together, the accumulated legacy cruft is, simply, no longer simple. It's a wonderful example of how incredible complex systems can emerge from the very simple behaviours of a few agents. Unfortunately, that makes it a royal pain in the ass sometimes.
I installed it on my system on its dedicated spare disk, boot it, run it and update the release from time to time.
It's not great as for device support but getting there. Drivers have always and will always be a problem for ANY OS (look at MacOS X and *BSD for living examples.) There are other features in the OS itself that make it forth a try.
If you guys are curious about it, you should definitely give it a try. Some compatibility layer is also provide for Linux drivers and apps. This needs work but what doesn't really.
The good thing is the upper layers which will provide POSIX compatibility for Unix developers to port their work. Pretty straightforward. The main reason why the distro has grown so largely in a small amount of time.
I read false assumptions and mistaken comments on this list about what is HURD. It's a kernel like Linux, and it's based on a microkernel architecture. Mach 4.0 happens to be this micro kernel but the architecture is not locked down so this can evolve if needs to be.
I read also people asking why does HURD exist at all. The answer is pretty simple: Why not? In the ten years it has existed, it should have died many times but it's still here. It's not a commercial OS like BeOS, some it doesn't need to generate streams of revenues to survive. It's just a bunch of code with ideas in it that are still pretty amazing today for it to still occupy developers to put efforts in it.
After all, we are living in a society that should encourage diversity and growth of new ideas (the US haven't being built with pioneers.) So, I am getting sick and tired of the moronic way of thinking in black & white (binary): Only two alternatives (Linux vs. Windoz) and no space for the others . And why is that? Why not letting people who enjoy using BSD and developing with HURD just do it without being hassled by the 2 main opponents?
Feeling grumpy because of the rain today.
PPA, the girl next door.
-- I feel better now. Thanks for asking.
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...
The only reason microkernels exist is limitations in existing protection mechanisms. There are only two levels, kernel and user, and each must be protected from the other. My question is this: what about something like the x86 segmentation mechanism? x86 segments have the cool property that a piece of code has the privelege level of the segment containing it. The nifty thing about that is that there are 4 privlege levels, so that you can have the kernel at the lowest level, less important stuff like the GUI at a higher level, and the app at the highest level. That way nothing can crash a more important component. I was wondering why this scheme hasn't been extend to paging. On every memory reference, the processor could check the privelege level of the page containing the currently executing code, and make sure that the target memory has an appropriate privlege level. This makes things even faster than a mono-kernel, since the only thing that is necessary to do a system call is a simple jump to the appropriate code (which would be dozens of times faster than a standard system call on x86). This shouldn't be any slower than the current way of doing things. The privlege of the current code would only have to be read whenever a page boundry was crossed, and would only reference memory during a TLB fault (which would have to reference memory anyway). The proc already does a protection check on the kernel/user bit on the page table entry anyway, so that scheme could be extended to multiple privlege levels without a slowdown. Am I missing something, or does an existing processor already do this?
A deep unwavering belief is a sure sign you're missing something...
It's best to avoid processor-specific functionality
in large architectural decisions if you want to be
portable. Besides, it's nicer for modern systems
to have components that are layered better than
a cake, so that if I have two very important parts,
I know that they can't crash each other
accidentaly.
For every problem, there is at least one solution that is simple, neat, and wrong.
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.
Ignore the "p2p is theft" trolls, they're just uninformed
We should all use Hurd instead of Linux. Linux numbers disk partitions from 1 (/dev/hda1, /dev/hda2, ...), while GRUB, the Hurd bootloader, numbers partitions from 0. As any self-respecting computer scientist knows, it is more proper to index things beginning with 0. Therefore, Hurd is a superior operating system, and we should all immediately switch to Hurd.
Secession is the right of all sentient beings.
Dude, nice attempt to bait the GNU people.
You imply that people either love freedom or the GPL, but not both. Do we *really* have to have that conversation again here? Unless you're being paid by microsoft, this is just senseless infighting between two groups whose goals are almost totally in alignment.
It reminds me of a time some friends of mine wouldn't speak to each other. Why? They were both animal rights advocates- but one group thought that it was a good idea to argue that animal testing was ineffective, and the other team thought this was a bad idea because it implied that if testing worked, it would be a good idea. As a result, the movement splintered, while the research advocates ("animal rights opponents") spoke with a unified voice. The internal strategic debate ruined the overall message they were both trying to send.
The parallel to the BSD vs. GPL debate is striking. It is a fun and important debate to have, but ultimately the harm that comes from ubiquitous closed-source can't-build-on-it software, which satisfies the goals of neither camp, vastly overwhelms the importance of this philosophical discussion. It makes it seem like theologians arguing over how many angels can fit on the head of a pin. If I was Microsoft's head evangelist, I'd be silently funding extremists on both sides trying to create bad political blood between these groups.
I'm not saying we shouldn't argue, obviously the issues need to be fleshed out. I'm just saying that these arguments ought to show respect for the other side (no more "we're more freedom-loving than you" namecalling), and that they ought to always be mindful of the context they are operating in - discussing the best way to create a body of free software in a world of proprietary de facto standards.
So I'm begging with all of you, show respect for your adversaries in this discussion. Acknowledge that the point of view held by the other side is understandable even if you believe that it's in error, but most importantly always make a special effort to identify the context of the discussion: that is, how can we best preserve freedom against those who would prefer all software to be proprietary?
microsoftword.mp3 - it doesn't care that they're not words...
If you open yourself to the foo, You and foo become one.
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.
I would have to disagree. The kernel could easily provide services that would provide memory mapping to the driver. I don't see why not. In fact, with proper protection mechanisms in place there's no reason why any user app should not be able to figure out real memory addresses. I don't think that would be ugly.
>>>>
It would be quite ugly. There are several problems that crop up. First, each driver would have to dynamically map pieces of process address space into its own space during execution (paltry 4GB address space on x86). To do that, you not only have to make a round-trip to the kernel, but you have to mess with the process address space (which involves an AVL-tree lookup and attempts to merge regions). The kernel doesn't have to do this, because whenever a system call is invoked, the current process's address space is already mapped. Then there is the fact that it becomes a pain to manage all those shared mappings. There can easily be hundreds of processes in the system, and multiple drivers processes would have to map each one. Managing that many shared mappings quickly becomes very messy (and very dangerous, due to the extensive sharing of memory).
A deep unwavering belief is a sure sign you're missing something...