Dr. Dobbs' Journal On Hurd 190
wiredog pointed out an article that's currently running in Dr. Dobbs that talks about Hurd [?] , what it is, and what it is meant to do, as well as what's cool about it. The article starts off slow, but then gets into some good info.
Does it support Beowulf clustering? (Score:1)
HURD : 10 Years too late (Score:1)
We all know full well what happened. Linus Torvalds waltzed right in, wrote the kernel for them singal handedly, and wrapped the GNU tools around it. Linux pre-empted HURD by a good 5 years, and it has (Quiet rightly) become a mainstream Operating System.
Starting the HURD just seems more like sour-grapes on the part of Stalman to be honest. When he realised how popular Linux and Linus were becoming, he decided to try and steal their thunder. Sadly, HURD is too complex and too late to make an impact. So now RMS resorts to calling Linux "GNU/Linux" to try and get back a little of the glory that Linux has.
HURD? I wouldn't bother.
OS X (Score:1)
Hurd and L4 microkernel (Score:1)
It would be a big job, and its just a discussion so far.
Re:Some (out-of-date?) observations on microkernel (Score:1)
Hurd daemons and Linux modules: the same thing? (Score:2)
Avoid the HURD (Score:4)
The HURD is an ambitious project which has had a rocky history, but there remains several black marks against it which seem to me to be fundamental flaws which are inherent to what it is and what it wants to do.
Firstly there is the fact that it is based upon an implementation of the Mach microkernel, which has been the favourite of OS courses but which has been shown to be rediculously inefficient in real world situations where performance rather than elegence is a major factor. You need to have a fast kernel in any case, and Mach just can't cut it. If the HURD is to succeed it needs to move onto using a more serious architecture rather than some ivory tower toy kernel.
Secondly, the current implementation of its server system is prone to an inordinate amount of deadlocks and race conditions under heavy loads, partly due to the Mach kernel, partly due to some sloppy coding in some of the IPC code. This means that whilst the HURD is fine for the casual home user, under heavy loads (such as running a webserver), you are likely to get a lot of system lag or even freezing.
Until these serious flaws are sorted out, the HURD is still in the "hobbyist" category rather than the "real world" one. It's nice to study, but it needs to have a lot more work before it's ready for heavy use.
Re:QNX? (Score:1)
If you want to complain about that, why not point to the microkernel based AmigaOS, which may still rate as the most popular microkernel OS, despite not having been sold in nearly a decade.
Eighty Megs and Constantly Swapping (Score:1)
The real Threed's
--Threed
Re:Obviously no understanding of project plans... (Score:1)
ummm, what about Apple's Darwin? which is based on the Mach3.0 micokernel? I realize that Apple is not a huge company, but that still seems like more than limited maintenance to me.
You morons. (Score:2)
I'm sickened by the current generation of slashdotters and their pathetic post; will no one build a Beowulf Cluster of these things? Where are my GRITS???
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
The Hurd is _not_ a great idea. (Score:1)
The Hurd was an interesting project that I tried pursuing but I only found myself abandoning. I had a running Hurd system for awhile and even wrote a few utilities (this is what mount might look like: http://nyct.net/~mbac/_mount.c), it really leaves a lot to be desired. The "micro"-kernel is about as big as the Linux kernel. The ext2fs driver is userspace and (last I checked), can only mount 1 GB filesystems because it mmap()s the partition. It's a clever idea, but the end result is not usable and I'm worried that they'll layer hack upon hack to try to maintain the clever idea and still keep it useful. Every basic system interaction involves a server and a translator. All servers must be explicitly multi-threaded and a running system can only go a few days before you've leaked all of your memory. This system is obviously still very beta, but these bugs are already plaguing the system.
The programmers that work on the Hurd are very talented and for the system to have as many problems as it does, I worry about how less talented people are going to deal with it. That article and this comment should not be an alternative to actually playing with the system. Give it a try. The experience is worthwhile even if you end up deleting the system 2 hours later. Hey, you might like it and think I'm an idiot and make it badass enough to smash Linux. That'll show us. :)
Also, the article mentions that the only way to add a new network protocol to Linux is by adding it to the kernel. This is untrue as the raw sockets interface allows you to develop your own protocols. This is how routed, gated, and dhcpd function without requiring explicit kernel support.
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:2)
Yes, but since more OS functionality will be implemented in user space, you can expect to see fewer `system calls.'
That's an exokernel. In a microkernel, you still have the IPC to the userspace daemon to contend with.
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:3)
f so why would I use Hurd, If i stick with Linux (a product that works in the here and now) I will eventually get all the advantages that they are talking about anyways.
Kernel modules are not at all the same thing as microkernel. For example, imagine a system where I (as a non-root user) can load modules at will. You canm do the same. My modules don't affect you and vice versa, so there is not a security problem. Thus, we can each load a different 'module' with different semantics to make a remote FTP site look like a mount point, and both of us will be happily unaffected by the other's choices.
That is not to say that Linux won't still have it's place. One of the trade-offs in a microkernel design is that 'system calls', which are implemented as IPC, tend to have a higher overhead. Linux will tend to run faster because of that. Also, some of the more interesting Linux kernel code may end up in a thin wrapper to serve as a HURD daemon and vice versa.
That's one of the big advantages of Free Software, good and useful code get's re-used.
IBM Got Tricked too... (Score:2)
And note that both Digital (now Compaq) and NeXT Inc. released reasonably serious products based on Mach. (Albeit, in the case of OSF/1, something predating the "worship-of-microkernel" days of Mach...)
It does not seem reasonable to merely characterize this as
the same was true of IBM, Sun, HP, Digital, and "everyone else" too.I'm not sure I'd go along with
either. Linus hasn't claimed that "portfolio;" he hasn't gone out evangelizing in that area; he seems to take a much more "pragmatic" standpoint in, in fact, suggesting on occasion that "free software" isn't of such crucial importance. Don't take that too far in the wrong direction, but I'm skeptical of the "ambassadorship"...Re:Obviously no understanding of project plans... (Score:2)
And as for the "GNU code being only a fraction," it happens to be the fraction through which everything else happens to get activated. No GLIBC means no user space.
XFree86 isn't crucial to the system in the same way; many of us have systems that are well and useful despite not including X at all.
And it is most interesting that you chose to ignore the fact that I indicated that RMS makes himself look ungracious when he demands credit; it's as if you want to imply that I didn't recognize that...
University of Dresden has some good material... (Score:2)
And it turns out that it's harder to get good performance than anyone thought, easier to throw it away, and I expect it's pretty easy to throw away reliability when adding additional components...
As you say, "loadable kernel modules" are likely to be good enough a whole lot of the time.
The flip side is that if Hurd gets "usable," some of the special facilities like translators may provide a slick test bed to try out new things that would be neat to add to Linux. Performance may suck, but an AMD "Sledgehammer" should make Hurd not too unusable :-).
There may not be an Oracle port, but it might provide a good place to prototype:
The OS that I would sort of like to see get more attention is EROS; unfortunately it's so different that it is unlikely to be self-hosting any time soon. It's not Unix, and its merits would be discarded by pretending it were.
I would suggest that a whole lot of the reason for the "death of OS research" is the giant shadow of Redmond; when Microsoft was pushing "NT Everywhere," research groups were running scared. It may be coming time for them to poke their heads out of the ground again...
Obviously no understanding of project plans... (Score:4)
It wasn't until Microsoft pulled Raschid and other critical researchers out of CMU, and IBM's WorkPlaceOS project failed that the "glow" came off.
At present, Hurd only runs on IA-32, but that hearkens back to the "immense aura of failure" surrounding Mach. Mach has only seen limited maintenance over the last few year.
If you have no compiler and no other such tools, you can't build the kernel, you can't run the kernel, you can't use the kernel.
No, they got the order straight.
The problem isn't with RMS trying to steal the glory from Linus for building a kernel; it's not with Linus stealing the glory from RMS when he built a kernel using the tools RMS helped build.
The problem is with the ingrates down the line that don't give credit where it's due.
It is fair to say that just about everything at the layer sitting on top of the Linux kernel "comes from GNU." Between GLIBC (whether version 1 or 2), GCC, and BINUTILS, the layers that make Linux useful all do come from FSF efforts. It certainly does look less than graceful when RMS "demands credit;" that doesn't mean it's an outrageous state of affairs for him to think he can expect some credit.
And the notion that Hurd is the all important be-all end-all project of the FSF is pretty silly; the people that want to participate are participating, and it is not evident that the FSF is spending big bucks or otherwise big efforts into its development...
Re:HURD : 10 Years too late (Score:2)
RMS and co. got tricked by all the academics into thinking that their new OS would have to be a Microkernel to be taken seriously. You see, the Hurd was started before Linus started working on Linux, but it's advanced architecture made it much harder to debug.
In waltzes Linus, some kid that wasn't worried about elegance, but instead wanted software that he could actually use, and all of a sudden it was possible to actually use the GNU system without any proprietary software. This was almost certainly a blow to the Hurd, but it has also been a tremendous win for Free Software. I am sure that even RMS would agree that it is better to have a completely free system with Linux than to have to continue to host GNU development on some other proprietary system. Besides, Linus has been an excellent ambassador for Free Software.
That being said, you can't hardly blame the FSF for finishing the Hurd. When finished it will have some very cool features, and they have put enough work into it, that it doesn't make sense to chuck it all out the window.
Now, I am not saying that RMS isn't interested in some of the credit for Linux's success, as that is clearly part of his goal. On the other hand, without the GNU tools Linux could not have been written, and it wouldn't have been useful when it was done, so he does have a point. Besides, RMS is clearly mostly interested in highlighting the fact that Linux systems are Free Software. To him this distinction is a very big deal.
Feel free to call it "Linux," I generally do, but you should do some research before you malign people you don't know.
Re:IBM Got Tricked too... (Score:2)
Thanks for a very informative post. I was aware that pretty much the entire industry fell in love with Microkernels, but I didn't realize that so many of them had actually sunk money into such osen.
I suppose that you are even right about Linus not being an ambassador for "Free Software," except possibly by example. I consider myself an advocate of Free Software, so it is a little disheartening to think that the creator of Linux might be disqualified simply because he is "too pragmatic."
Oh well, line me up with the rest of the zealots...
Significance of HURD (Score:2)
The sad fact is I don't see HURD taking off, ever. It doesn't really offer enough significant advantages over Linux to convince people to move. The advantages are more from the development perspective than from a user perspective. Transparent FTP isn't quite enough to get people to move over, for example. Something like EROS (www.eros-os.org) is more likely to be the successor to Linux because of the incorporation of significant functionality into the kernel that could not be easily installed into Linux.
In short HURD is a neat idea and the lessons that are learned from its development will most likely be harnessed elsewhere (e.g. we shouldn't try X, the HURD people had all these sorts of problems when they tried that approach).
Re:Hurd daemons and Linux modules: the same thing? (Score:2)
Running things from within the kernel is faster because you don't have to do any context switches. A context switch is when the CPU swaps in a different process. This includes restoring all the CPU registers and doing some record-keeping. That's one of the major reasons that microkernels are generally slower -- drivers and file systems have to be swapped in before they can do their work.
Re:Avoid the HURD (Score:1)
At least that's how it goes, AFAIK.
Re:Read it and discover the technical inaccuracies (Score:1)
"Fat, drunk, and stupid is no way to go through life."
Re:Read it and discover the technical inaccuracies (Score:3)
I disagree. The point about how there is no simple way to add new features into the kernel is a crock:
I am not a kernel hacker, but according to Linus' essay in Open Sources [oreilly.com] , the kernel design is quite modular, thank you.
As a user of the kernel, I understand the use of modules and this seems to be a modular way to add features. AFAIK, the module feature of Linux is and interface.
Bottom line: how accurate is this article?
"Fat, drunk, and stupid is no way to go through life."
Re:Read it and discover the technical inaccuracies (Score:3)
"Fat, drunk, and stupid is no way to go through life."
Microkernels are a fraud (Score:1)
The fact is, microkernels are a fraud [tunes.org], and the HURD, by embodying the advertised model, is both the victim and the accomplice of this fraud.
Conceptually, microkernels are an abstraction inversion: they force you to hand-implement run-time modularity using a non-modular low-level language, instead of auto-implementing modularity by compiling a modular high-level language into non-modular binary (see: SPIN, Fox, ML/OS, Squeak, and more).
Modularity is a source-level concept. Enforcing it at the binary level is DUMB and EVIL. Binary level should be efficient. Linux got it right (as far as a C kernel can).
If you want dynamically reconfigurable kernels, don't bother with HURD and microkernels, they do not provide any specific advantage for that that "monolithic" kernels don't have. If you really want dynamism, use dynamic languages (LISP, Smalltalk) or at least modular languages (Modula-3, SML, OCaml), not C.
BTW, VSTa is a free software microkernel that has actually worked for years, yet never attracted any specific interest: who cares how it works underneath? What matters is the high-level features it actually provides. In practice, nobody cares about the puny features provided by microkernels.
-- Faré @ TUNES [tunes.org].org
Choices (Score:1)
Re:What's the point with HURD? (Score:2)
RMS has said that if the Linux kernel were available at the time that the Hurd started, the FSF wouldn't have bothered with it. But since a lot of work has already been done on it, he wants to see it finished.
But the resources dedicated to the Hurd are not huge (if they were, it would probably be further along).
Re:Avoid the HURD (Score:2)
They aren't as enthused about working on it because they realize it's got unrealistic political bullshit wrapped up in the technical design.
-
Re:Avoid the HURD (Score:2)
"If A then B" does not in any way imply "if B then A".
I suggest you consult an elementary logic text before pursuing this discussion any further.
-
Re:Avoid the HURD (Score:3)
Sure; but how many years old was Linux when it was like that?
Hurd isn't "in the beginning" in age, just in capabilities.
-
Re:Linux, Hurd: What I think. (Score:1)
Re:They fail to point out (Score:1)
--
Re:HURD : 10 Years too late (Score:2)
Pardon me... how did they write that editor? The compiler? The tools? They wrote them using "non-free" (for Stallman's definition of "free") versions of the same tools.
Bootstrapping's always been a problem, even if (particularly if) you're willing to start from scratch. <sarcasm>And, hey - even if Stallman and crew had started from scratch... how in the world could you expect them to write a "free" OS and tools on top of a "non-free" BIOS?!? </sarcasm>
"Non-free&a mp;quot; software pretty much had to be, and was, used to develop the first versions of Stallman's "free" software. The fact that HURD came later than the tools wasn't because of any need for "pure" tools to build the OS. I'd bet it was because working on the tools was more fun and more immediately rewarding than working on an OS. Now, saying "Linux was OK, it got us to the point where we could work on the real OS" - that's nothing more than a huge steaming heap of "not invented here" attitude using free software as an excuse to shield a bunch of fragile egos.
its not recommended by the average user (Score:2)
If they want to attract developers or users or anything, then someone needs to make it easy to install. Like there needs to be a hurd distribution.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Re:RMS is going to be upset (Score:3)
Hurd, how many years in development? (Score:4)
When I first heard of HURD back in, what, 1992 or 1993, I thought it sounded like a great idea. But now it's the better part of a decade later and the thing still isn't out of ALHPA testing!
I'll stick with Linux, thanks...
I was thinking of the immortal words of Socrates, who said, "I drank what?"
Re:Oh spare us the LINUX evangelism (Score:2)
So NT became less stable as it became more monolithic? The problem with microkernel is not stability, per se. It's "performance".
Do you have a link supporting this assertion? (Score:2)
Do you have a link supporting this assertion? I really doubt Apple moved FreeBSD into the Mach kernel.
Re:HURD : 10 Years too late (Score:2)
Personally, I find development of the HURD much more interesting than development of the Linux kernel. I personally don't care too much about how popular the operating system becomes (either Linux or HURD) but I think it's fascinating that work on a design that actually shows some innovation is taking place in the public sphere.
You basically seem to have a big problem with Richard Stallman. Say what you will about him, but I can guarantee that you wouldn't be using Linux right now if it weren't for him.
I Love that Song! (Score:2)
Hurd is the word!
Have you heard about the Hurd?
Well the Hurd, Hurd, Hurd,
Hurd is the word!
Good (unintentional) point! (Score:2)
Of course, XFree86 has nothing to do with GNU.
So maybe we should be calling it GNU/Linux/XFree86? Perhaps LiGNUxX?
For that matter, none of it would be the way it is without the C programming language or the TCP/IP standard (the standards, not the code), and it wouldn't have grown so quickly without the "killer app" Apache service, so maybe we ought to call it C/TCP/IP/GNU/Linux/XFree86/Apache?
Personally, my Linux system wouldn't run the way it does without Perl, Vim, Netscape, and xterm (which together consume more cycles than any GNU code), so I suppose I ought to call what I'm running Perl/Vim/Netscape/xterm/C/TCP/IP/GNU/Linux/XFree8
Things like short, catchy, popular names aren't important. It's only fair to acknowledge everybody's essential contribution, it's not as if one of these contributors is insisting on the lion's share of the credit when these are all about equally important. Oh, wait...
--------
GPL != GNU (Score:2)
While GPL was originally designed for the GNU project, that doesn't mean that every project under the GPL is a GNU project. The popularity of the GPL is a combination of the obnoxious "thou shalt have no license before me" mutual-incompatibility clause of the GPL and Stallman's "only GPL is free" propaganda. But only projects originating from the FSF are GNU projects, by any reasonable definition, regardless of whatever GNU references are made in the names of the projects.
KDE is by no means part of the GNU project, because it wasn't initiated by the FSF (it was, in fact, opposed by the FSF, and a pointless duplication-of-effort/division-of-resources encouraged, due to it being less than pure GNU/free).
The GNU components are not so hard to replace, they were, after all, simply cloned from earlier proprietary versions. The reason they are used is that it doesn't make sense to rewrite them; they work fine and the only reason to do so would be out of spite (or perhaps pure frustration about all this GNU/Linux garbage; while I've heard lots of talk in this direction, it's easier to ignore irritating rantings than to shut them up). If someone wrote a nice public-domain printf formatting function back in 1980, and it got used in Linux, would you think he'd be justified in insisting that Linux be called "printf/Linux" because "you can't run Linux without printf!" ?
The main credit for those cloned Unix tools should go to the original designers, not mere GPL-cloners, and ample tribute is already paid in the choice of name.
All this "GPL/Linux" crap is one more attempt to make out the FSF, and therefore Stallman, to be the root of all software freedom. It's nonsense. Stallman's a bit player with a big mouth and a talent for attracting attention. Free software has been around as long as computers have been made in standard models, previously with the superior freedom of public domain. If the FSF GNU/free thing really was a moral issue, rather than an attempt by Stallman to make himself famous, he wouldn't care about the name (and the FSF webpage wouldn't be full of references to his personal life).
--------
HURD delayed by romantic entaglements! (Score:3)
A heartwarming sentiment, but not all was roses for GNU/Stallman:
Clearly he was feeling smothered by the relationship, and expressed his discomfort in his code. If he couldn't control his love in real life, he could at least manipulate the code-surrogate he created to show his true feelings.
Torn up by losing the love of his life, GNU/Stallman destroyed 90% of the kernel code in a drunken fit of despair-driven rage. Thereafter he insisted on a complete redesign, being unable to cope with any reminders of this tragic romance.
And that's why we run Linux.
--------
Re:Avoid the HURD (Score:4)
I haven't heard of any major problems with it.
-Matt
This article is not impressive! (Score:2)
The Tanenbaum-Torvalds Debate (Score:3)
One place to read the debate is here. [oreilly.com]
The quote from Linus you are likely remembering is this:
However, Linus had some other points as well, like multi-threaded filesystems on a microkernel being a hack:
My perception is that Linus' view at the time of this exchange was that Microkernels have a theoretically superior design but monolithic kernels have a practically better design. I don't know if Linus' views on this has changed in the nine year interval since this debate.
have a day,
-l
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:2)
Re:Hurd daemons and Linux modules: the same thing? (Score:2)
In a microkernel architecture, if the tcp/ip implementation isn't as multithreaded as you want, you are free to grab any tcp/ip server around that fits your criteria.
If your microkernel doesn't scale to the number of processors you want, just pop in another microkernel and away you go. No need to change the rest of your servers (assuming your old microkernel and your new microkernel use the same interface).
Essentially, a microkernel is slower, but more flexible. A monolithic kernel is faster, but less flexible.
Same old story...
Re:IBM Got Tricked too... (Score:2)
When I arrived here at CMU in '94, there was a joke going around that Mach was destroying everything it touched. (We'd abandoned it by then, heheh.)
The reason microkernels are unfashionable and people have abandoned them is because, by and large, they suck. Note that there are in fact much better microkernels out there, such as IBM's L5 and K42 (both open source, I think). The big picture is that in 99% of cases, people either don't need the extensibility, or a Linux-style kernel module is good enough. It's just not worth engineering for the other 1%. After ten years of trying to find alternative extensible OS technologies that don't suck, the OS research community has mostly realized this fact, and extensible OS research is dying.
Re:HURD on RISC (Score:2)
Re:Read it and discover the technical inaccuracies (Score:2)
WRONG. This is classic microkernel propaganda.
> For example, while Linux has module interfaces
> for supporting different file systems, there's
> no way you can load a module for a real-time
> scheduler.
There is no way for a microkernel to plug in a module for real-time scheduling unless it is designed to allow different schedulers to be plugged in. The fact that "it's a microkernel" doesn't make everything magically pluggable.
No matter what kind of kernel you've got, you can plug things in if and only if the kernel designers built in the right hooks and interfaces for the functionality you're trying to plug in. Whether the plugging in is implemented with kernel modules or user-level servers is largely irrelevant.
(User-level servers can be more robust and may require less privilege, but very few people care about that.)
Re:Oh spare us the LINUX evangelism (Score:2)
Re:Read it and discover the technical inaccuracies (Score:2)
It wasn't the greatest example, but microkernel modules can be anything, and are generally low level. For example, while Linux has module interfaces for supporting different file systems, there's no way you can load a module for a real-time scheduler. Any scheduler changes (and there are a lot of people interested in Linux real-time scheduling) would have to be made in the actual scheduler code itself. Similarly, things like memory management which are typically low level monolithic parts of the Linux kernel could each be in their own module. This is what the Hurd is - lots of processes running providing the OS services.
Linux modules, on the other hand, have more in common with device drivers than microkernel architectures. Which is the way Linux wants it, of course...
Re:Linux, Hurd: What I think. (Score:2)
Cool! I've never been any good at using kernels without any software on top.
Re:HURD on RISC (Score:3)
RISC machines are in general really fast at big monolithic tasks, like number crunching, not at task-switching. So if you go to a microkernel that needs to do a lot of context switches, RISC performance will probably be bad.
If the microkernel had better message-passing within it (I'm told Chorus is good at this), then the frequent task switching becomes unnecessary and performance improves. But Mach got it wrong.
Really dumb arguing here (Score:2)
On the other side, you have a group of people who knows nothing about operating systems arguing that microkernels are superior because of some kind of elegance factor they don't understand, plus they are annoyed that Linux has become successful (or at least that it has gone mainstream).
This is right up there with goofy junior high arguments about the PlayStation 2 vs. Dreamcast that are based on sound bites picked from biased gaming news sites. Most amusing to watch!
Re:Hurd in all the best places? (Score:2)
I think Mach needs something like 4 meg of runtime memory to manage IPC (?). 'Thing is that since it is completely dynamic, each kernel metacomponent (like a filesystem driver) needs to have a very generic interface. These add up. Then you need to configure the various objects at boot time and store that in ram. A statically compiled kernel can use standard compiler tricks like dead code elimination (especially if you are allowed to make the whole program assumption) to axe out huge swaths of unneeded code.
The real value of microkernels is stability. You can use a buggy driver, if you need to. On a production system. The driver can crash without killing the kernel. Just add a heartbeat monitor and you get life-support for buggy drivers. The boon for developers of said drivers is obvious.
Now is where I start speculating: I'd like to see a pyKernel. Write low level performance critical parts of the code in C, but write the rest of the kernel in python. An example: the code that performs context switch is obviously in C, but the code that implements the policy is in python.
I know there's a LISPos project, but IIRC it got stalled early on in bickering and overreaching (If you run code from a safe language, you can get rid of expensive process separation and run them all in one memory space). Any other projects out there?
Re:Avoid the HURD (Score:2)
Re:Smells like FUD (Score:2)
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:2)
Re:HURD : 10 Years too late (Score:2)
Re:Avoid the HURD (Score:2)
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:3)
"Sweet creeping zombie Jesus!"
Re:RMS is going to be upset (Score:2)
By the way, people on the Hurd mailing lists are talking about leaving the Mach kernel. L4 is being considered as an alternative. Nothing has been settled yet, as far as I understand, but it's quite interesting to follow the conversation.
Re:HURD : 10 Years too late (Score:2)
First I wrote: Another thing: I don't see how the GNU project can "steal" glory from the success of Linux since the success of Linux is dependent on the GNU project which provides the tools and the license. Calling the running Linux system (kernel and user applications etc.) "GNU/Linux" is the least people could do
Then you wrote: So we should call all apps compiled with MS compilers "Microsoft/HelloWorld"?
Do we call all applications compiled with GCC 'GNU/MyApp'? We're talking about a whole operating system with applications and documentation, not just a single application.
When someone writes an operating system similar to Windows in architecture using Visual Basic and ports the Microsoft Office suite and all the "Visual" tools to it, that system (OS and tools) will certainly be called MS/Something (or maybe "MS-something").
Re:Linux, Hurd: What I think. (Score:2)
You said: Me either, but what makes you think I use predominantly (or any) GNU utilities? Quite frankly GNU/KDE/XFree/Linux is a little too bulky for me, so I'll just stick to calling it Linux.
You are using predominantly GNU utilities. That's a fact. Each time you type ls or cd you execute GNU code. The bash shell is GNU code.
KDE and XFree is just a tiny part of the whole system when compared to the GNU utilities and the amount of other GPLd applications. It might be the part that shows most, but they're not essential to the system.
Re:Linux, Hurd: What I think. (Score:2)
The everyday commands distributed with most Linux systems are GNU utilities (I don't know about those utilities on e.g. BSD systems and if that is what you run then you are most likely to be correct when you say that they're not GNU). Bash is the default shell on most GNU/Linux system, tcsh is not. I believe that I am correct when I say that most GNU/Linux users use bash (wasn't there a poll about this?).
You also say: Combined KDE and XFree take up more room than pretty much anything else on my system. So much for them being a "tiny part".
You simply can't have a running Linux environment without GNU! *That's* my point. I do not count megabytes, I count the number of components that are GPLd. Please note that KDE is *one* of those components.
Re:HURD : 10 Years too late (Score:2)
You: Pardon me... how did they write that editor? The compiler? The tools? They wrote them using "non-free" (for Stallman's definition of "free") versions of the same tools.
Maybe they did it so that they immediately could start to develop the rest of the tools using their own free, reliable, extensible, portable compiler?
You: Non-free&a mp;quot; software pretty much had to be, and was, used to develop the first versions of Stallman's "free" software.
Of course. But only enough to develop the compiler.
You: I'd bet it was because working on the tools was more fun and more immediately rewarding than working on an OS.
There is nothing whatsoever wrong with that. Programming should be fun and rewarding.
You: Now, saying "Linux was OK, it got us to the point where we could work on the real OS" - that's nothing more than a huge steaming heap of "not invented here" attitude using free software as an excuse to shield a bunch of fragile egos.
Ok, so let's say that everyone in the GNU project have tiny fragile egos. Do you have an ego big enough to explain in exactly what way this should stop them from continuing to work on the Hurd?
Re:GPL != GNU (Score:2)
You: While GPL was originally designed for the GNU project, that doesn't mean that every project under the GPL is a GNU project.
I don't believe I made that claim. What I did say was "You simply can't have a running Linux environment without GNU!" and I still think that this is a valid claim.
If you are a Linux user (and therefore also a GNU utility user and user of a vast amount of GPLd software), you should think more than once before saying the GNU project is nonsense.
Re:GPL != GNU (Score:2)
You: Again, despite it's use on most Linux systems, I see no reason to start calling Linux GNU/Linux. You seem to have a difficult time understanding that point.
I see no reason to stop calling it GNU/Linux.
Re:Linux, Hurd: What I think. (Score:2)
You: Let's face it, you were trying to be a know-it-all and you made a few assumptions that you shouldn't have.
Sorry but you're wrong. Mastodon Linux (whatever that is) would not be at allif it wasn't for GNU. And yet again, I did not say that every GPLd thing was a part of the GNU project.
Re:HURD : 10 Years too late (Score:3)
You wrote: HURD would have been a really cool system, if Richard Stalman had got his priorities right in the first place and written the GNU Kernel before he wrote all the system tools! No, GNU did it the other way around, and now they spend what, 5 years? righting a kernel?!
Writing the kernel with what? Using a non-free editor, a non-free compiler, a non-free libc and other non-free tools? Would that be regarded as "free" by anyone?
I don't know if RMS is involved personally at all in the Hurd effort today (I would be happy if he was). I don't see why people attack him... The GNU Hurd is a perfectly "legal" and quite interesting free Unix project. I find it hard to believe that it's supposed to be a form of "revenge" on the success of the Linux kernel. I think it's rather a separate effort to supply a highly modular and portable Unix kernel. I don't know if the Hurd is supposed to do the same kind of impact as the Linux kernel did (is doing).
Another thing: I don't see how the GNU project can "steal" glory from the success of Linux since the success of Linux is dependent on the GNU project which provides the tools and the license. Calling the running Linux system (kernel and user applications etc.) "GNU/Linux" is the least people could do.
Re:That's not really a plus point is it? (Score:2)
Perhaps you should find out a little more about the history of the HURD. It was always (and still is) a fundamentally more ambitious project than Linux - perhaps too much so for the time (time when it was started
To suggest that "Stallmann and his crazy comrades have produced little more than hype" shows just how ignorant you are (gosh, I wonder why you're an AC
best wishes,
Mike.
Re:HURD : 10 Years too late (Score:3)
Ah, there's nothing like the smell of revisionist bullshit in the afternoon.
http://www.gnu.org/gnu/initial-announcement.htm
Announced in 1983.
How exactly does that square with your little theory when Linus didn't post the first Linux sources until around 1991 (v0.02)?
Mike.
What's the point with HURD? (Score:2)
Re:Hurd daemons and Linux modules: the same thing? (Score:2)
Kernel modules are run in kernel space.
This make kernel modules faster than Hurd Daemons.
What are the good points ?
Re:Oh spare us the evangelism (Score:3)
Have you ever heard of QNX, its a microkernel, it works.
I read that the drawbacks to microkernels is that they are a bit slower due to less code operating in privilidged mode. But microkernels are more scaleable i think.
(i am not an expert)
Re:Avoid the HURD (Score:2)
Re:Avoid the HURD (Score:5)
The first difference is that OS X is a single server and the Hurd is a multi-server. That is, on OS X all the Mach stuff communicates with is one large Free-BSD kernel with its hardware dependent stuff ripped out. The Hurd on the other hand has each system call handled by a separate thread of execution.
The second difference is that Apple moved the BSD kernel into the same kernel space as the Mach microkernel. This means that they don't have the context switching overhead that traditional Mach based systems have.
Oh spare us the LINUX evangelism (Score:4)
Care to elaborate? Actually there was nothing wrong with the NT microkernel design originally. 3.51 was fast and I believe fairly stable. As far as I can tell the instability came from the UI which has been allowed to contaminate the architecture.
Linux has indeed shown that Monolithic kernels can work well, but there are too many who believe that Linux is the peak of OS design and that it can't be beat, so what's the point in even trying?.
Well in n number of years, we'll all be talking on kuro5hin about the days when Linux was a really good OS for the hardware of it's day and wasn't slashdot great before IBM bought VA. In other words don't stop looking just because what you've got works.
Never attribute to malice that which can be adequately explained by stupidity.
Re:"Alpha" OS (Score:2)
Some of the ideas from Alpha were reused in Spring, and some of the ideas from Spring were reused in Java, and some of the ideas from Java were reused in .NET, but along the way, the
protection stuff got lost.
The real problem with microkernels (Score:4)
That's a valuable quote. It's a real objection to the way microkernels are usually done. It's not really a problem with microkernels, though. It's a problem with processes as a primitive.
Most operating systems today have the "process" as a primitive. A "process" is a collection of address spaces, some kernel state, and one or more "threads". Interprocess communication typically looks like an I/O operation. When process A "calls" process B, process B sees something that looks like an I/O completion and has to find a thread to service it. One thread in B is enough to make it work; many are required to make it work fast. Allocating and managing those threads adds another level of scheduling complexity to service tasks.
The problem comes from the fact that what you want is a subroutine call between processes, but all you usually get is an I/O operation. If the kernel offered a safe way for a thread in one process to call into another process, the problem Linus points out would go away.
A better way to think about this is to think of "objects" rather than "processes". Think of the CORBA object model, but with all the objects in different address spaces on one machine. All that's needed is a way for a thread in one address space to call through some kind of call gate into another address space. The operation required looks like a system call, or a Multics ring crossing, except that it's between peers. The L4 crowd has been getting close to this, and if they ever do L5, they'll probably do it.
x86 hardware almost supports this; if you abuse the segmentation and "task gate" hardware enough, you can get it to support inter-address-space calls without going through the kernel. Maybe. Sort of. It's not quite the right tool for the job. The latest SPARC CPUs are supposed to have hardware support for this, put in for the Spring project.
That's the direction microkernels ought to go. The end result would be a system that works like CORBA/DCOM/etc objects, but much faster and safer. Current implementations of "big object" systems either turn off protection or run slow.
Re:Read it and discover the technical inaccuracies (Score:2)
Accurate enough. In the Hurd, things like the TCP/IP stack (is this implemented in the Hurd yet?) are userspace programs. In Linux, it's kernel space. You theoretically could rewrite Linux like that, but it would take a massive amount of coding and you'd wind up with.. a microkernel!
---
You have been TROLLED (Score:2)
Siqnal 11
User ID: 210012
to
Signal 11
User ID: 7608
What we have here is a troll pretending to be a different troll. Let us hope the recursion stops here.
Re:To whom the article concerns (Score:2)
Test editors are already there. EVERBODY gives them away for free.
Word processors are there in theory, but the propriatary wars continue and so file formats keep them from going commodity long past when they should. This can't be maintained forever as soon every bloody feature that everyone wants will be in every bloody word processor.
Spreadsheets are a dime a dozen. Again, only propriatary file formats and scripting languages maintain the propriatary houses at the moment.
StarOffice, for all its warts already comes damn close on these two, others are coming up from behind.
One more generational click and XML/HTML based apps will be as viable as lower level coded apps are now.
Whole new ball game then.
Sure, MS and its ilk arn't just going to roll over and play dead, but as their core products become mature beyond extending, and this WILL happen, they'll be more and more up against it when it comes to fighting open source.
If nothing else people will still buy and use Office, but it'll be hard for MS to get more than the price of a game for it because the value will no longer be there, and if MS really thinks that people will 'subscribe' to a word processor when they can get one for free that resides in one tenth of one percent of their HD they're smoking something.
And just think about what speeds quadruple current will do for the emulation crowd!
My money is on the horse that says the speed of boxes 3 years down the road is going to pretty much change everything.
Sure, the uber geeks are still going to go for elegance over speed and user functionality, and the propriatary houses are still going to pushing 'functions' of no more value than slowing your computer down to 286 speed, but the raw power of the system will even out the bumps in the road and prevail.
The only real fly in the ointment would be a new killer app, but for the first time in PC history I don't see one down the pike.
The spreadsheet was a killer app, but we were all waiting for that one ahead of time. Same for the WYSIWYG word processor and 3D games. All killer apps when they came out, but all apps that we forsaw and eagerly waited for.
I listen to music on my PC. I watch TV, movies and video tape on my PC. I play games in multi dimensionality, I can run my house from my PC. My PC is networked against my other PC's, and against the world.
All we're eagerly awaiting NOW is bandwidth.
To whom the article concerns (Score:3)
So, everyone out there saying " HURD sucks," why yes, you are right, it does and the article even says so.
"Linux can do anything the HURD can do and do it faster," why yes, you are right, * and the article even says so.*
But the article dosn't concern people who are interested in the current functionality of the OS's, it concerns people who are interested in *thinking about* how OS's work. More specifically it mainly addresses people who actually write and/or maintain kernel code because that's what they LIKE to do.
If you don't think about kernel architecture and kernel code and just want to boot the system and see what sort of fps you can get in Quake this article wasn't intended for you.
The article brings up some good and intruiging POINTS about kernels, which is the POINT of the article.
I have some of my own ideas about the issues involved which the article prodded me into thinking about some more, so it is also a *successful* article.
The modularity of micro kernel code certainly has some advantages, but from a kernel coders point of view a monolithic kernel's code can be made just as modular with a clear interface between modules. If it is not done that way at present that is the fault of the coders, not the architecture.
Ok, the Linux kernal code grows and grows, but not all aspects of the code are COMPILED into the user's actual kernel. In this sense the kernal already has modularity of sorts to the end user. If you don't have a USB port you don't compile USB support into the kernel in the first place.
The key advantage of the micro kernel brand of modularity is that you can add or remove USB support * without recompiling.* This will be of primary advantage to the system *maintainer.*
When does a Linux box go down? When you have to modify some core function of the kernel that requires a complete recompile usually. With a micro kernel you upgrade from USB to USB2 by pulling one module and plugging in another. Done. No reboot.
The downside, as we all know, is system performance takes a hit from the resulting extra overhead to support communications between modules.
But look, Moore's law remains in effect. A few months ago IBM announced they had enough stuff in development in the lab * right now * to keep Moore's law in effect for at LEAST the next ten years. Think about that, and that dosn't take any new, currently unknown and undeveloped technology into account.
* What is known technology, right now, will keep Moore's law in effect for the next decade.*
In a year and half that 1.2 gig AMD is going to be a 2.5 gig something or other, and it will be CHEAPER than current boxes. In 3 years it will be 5g and cheaper yet.
So what are we going to use all that added power for? To get 400 fps in Quake instead of 200?
No, I'll TELL you what we're going to use it for, (because that's the kind of swell guy I am), we're going to use to run abstraction layers to the entire software architechture to make end use and system maintainability easier, THAT'S what we're going to use it for.
Will benchmarks for a micro kernal be slower than benchmarks for a monolithic kernel? Yep, sure will, BUT. . .
They'll BOTH be faster than human perception, just as vi appears to run equally fast to the human user on a 486 and a PIII 900.
And APPARENT speed is all that matters people.
Is the day of the micro kernel here? No, and the article itself says so.
Is it coming? You bet it is.
Maybe not today. Maybe not tomorrow, but soon, and for the rest of your life.
Re:Isn't Linux Moving towards Kernal Modules Anywa (Score:2)
Re:Avoid the HURD (Score:2)
>I haven't heard of any major problems with it.
That is because it is Apple, and any kind of kernel is an improvement!!!
Isn't Linux Moving towards Kernal Modules Anyways (Score:3)
(a product that works in the here and now) I will eventually get all the advantages that they are talking about anyways.
I am not a kernal hacker....So I admit I do not understand all the issues here, but I do not see any reason to jump.
You Bastards... (Score:2)
Anyone got a mirror of the article? I'd love to read the it but for some strange reason [slashdot.org] the site seems to be down.
Hurd in all the best places? (Score:3)
Obviously this depends on the general overhead for the microkernel itself, and the resources available, but its a nice idea. A fully tailored OS is a necessity on things that are 'thin-clients'. Sounds like an option.
Typical Slashdot... (Score:2)
--
Boston Hurd Uses Group meets Sunday, November 5 (Score:3)
Building 2 is part of a complex at the intersection of Massachusetts Avenue (Route 2A) and Memorial Drive. As you cross the Charles River from Boston on Mass Ave, it is the first set of buildings on your right. A map is at http://whereis.mit.edu/bin/map?state=0&pri.x=325&p ri.y=137. I don't
know where the best parking is, since I walk...
HURD on RISC (Score:2)
Smells like FUD (Score:2)
But given time, and work, it has progressed to be a very usable kernel. If the same sort of time and effort is put into the Hurd, will it not also succeed?
Some (out-of-date?) observations on microkernels (Score:2)
1) The performance generally stunk. This may have changed, but I recall seeing user-level network protocol stacks get completely clobbered by monolithic kernels. There were a whole bunch of ways of getting around this (including moving entire protocol stacks into the applications!), but most seemed to fall into the category of "making microkernels run faster by making them not really microkernels anymore".
2) The assumption that complexity just vanishes if you break everything up into a whole bunch of little servers. If you compare a microkernel to a modern, multi-threaded OS written in a OO language, then the thing you get from having a microkernel is protection from memory-smashing bugs in one service taking down other services. That's good, but not revolutionary.
A monolithic OS can die because the file system code runs amok. A microkernel-based system with the same class of bug might still be "up", only you can't get to any files, or run any programs. A user won't really care either way.
A lot of the advantages of microkernels seemed to be predicated on OS development and debugging staying exactly as godawful as it was back in the late 80s and early 90s. I hacked on an Ultrix kernel, so I have vivid memories of how gruesome the whole process is. I am assure by OS guys that things have come a long way since then.
Also, I should point out that Mach is a pretty huge for a microkernel. It's got everything in it but the kitchen sink. I think the Plan 9 monolithic kernel was smaller than just the Mach microkernel (not even counting all of the stuff you have to pile on top of it to make it actually work).
Re:Hurd daemons and Linux modules: the same thing? (Score:2)
Hurd's relation to Apple's Darwin? (Score:2)
It seems that Darwin will have a pretty secure future due to Apples deep commitment and there will also be a large number of commercial applications to Mac OS X available in the future, which could be ported to the open source Darwin. In addition it is pretty compatible with Linux/Unix systems so Linux users would feel at home quickly.
As OS X is practically Darwin added with Apple's proprietary components, why not make open source versions of these components and voila, a Mac OS X compatible free OS, with a superb UI, easy software installation etc. It would probably be easier than developping Wine for Linux!
Any insights on these ideas?