Slashdot Mirror
Dr. Dobbs' Journal On Hurd
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.
Thanks in advance.
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?!
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.
Hey! Mach is already in use for OS X and has been in use in the for quite some time on NeXTs.
There was talk recently about moving Hurd to the L4 microkernel, L4 is aparently runs faster and has more developers.
It would be a big job, and its just a discussion so far.
1) Speed problems are irrelevant in the long run. Moore's law will overcome them. (This assumes that the basic design is good, so you don't have to keep piling on more and more complexity to correct basic flaws - Like DOS and Windows.) 2) You might be right about that. Breaking a big program written to solve a complex problem up into a lot of little modules doesn't give you a simple program, it gives you a complex program with more of the workings exposed. Computer Science professors will love that because it makes it easier to teach people about it, but it doesn't necessarily make the program any better. The advantages I see to the microkernel are (a) it should make it easier to get new volunteers to sign on to write or improve one daemon. (b)You can choose not to load daemons you don't need. This doesn't mean much to a workstation or a full-purpose server, but it might really slash the overhead in a specialized application that doesn't need so many services. E.g., for a PDA you can dump the standard keyboard and video daemons, replacing them with something appropriate to the limited hardware, and you can lose a lot of stuff that isn't going to be used at all. But PDA's can't afford an inefficient kernel yet. And for a larger specialized appliance, how often will the savings be worth the trouble of using a non-standard, untested load? It will be interesting to see how this works out... Mark Moss
Can someone explain the trade offs between the two models? From a very high level (I'm no kernel hacker), they seem like they both solve the issue of maintainability.
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.
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.
No Further Message /. ID is lower than the real Bruce Perens'.
The real Threed's
--Threed
>>Mach has only seen limited maintenance over the last few year.
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.
Hundreds of comments, and everyone here thinks Stallman hasn't written an OS. I guess no one has heard of emacs (EMACS Makes A Computer Slow...)
:)
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.
pb Reply or e-mail; don't vaguely moderate.
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.
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.
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.
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"...If you're not part of the solution, you're part of the precipitate.
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...
If you're not part of the solution, you're part of the precipitate.
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...
If you're not part of the solution, you're part of the precipitate.
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...
If you're not part of the solution, you're part of the precipitate.
HURD to me is more of a research kernel. It's there to see if a Microkernel setup can go from a toy OS setup to a real OS setup. To my mind it is the alpha for the next operating system after Linux, or when they decide that adding functionality to the kernel isn't going to work anymore and they need to start moving stuff into user space and trimming the kernel down. When they do that, they can look over the work that HURD has done and the things that it has learned in the process. I see it as research for overhead issues and how to make a microkernel fast enough for real use, and how to debug and optimize a microkernel setup. The lessons learned with HURD will help elsewhere.
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).
Interesting points. I will look into the HURD documentation. It can do really amazing things that will never be possible under linux. Can it really do things now, or is this still vaporware? I ask only because I have been hearing about HURD since I started with Linux in 1995, but Linux is running my computer, not HURD. I'll check it out. Later
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
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 , 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."
"You're gonna need a bigger boat." - Chief Brody
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
The fact is, microkernels are a fraud , 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.org
-- Faré @ TUNES.org
Reflection & Cybernet
This is what competion is about even in the open source world choices help stream line everything. I have the choice to use what I want and how I want it.
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).
What do you think the g in glibc stands for? Keep in mind that even libc5 was a fork of the gnu C library. I'll bet GNU code is run every time you type ls or cd, and when you run your shell, and....
By that same reasoning, what does that make FreeBSD, OpenBSD, NetBSD and the BSD-du-jour?
--
Information wants to be beer, or something like that.
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!
Only 'flamers' flame!
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?"
Life is a tale told by an idiot, full of sound and fury, signifying nothing.
William Shakespeare
For NT 4.0 they basically moved everything but the kitchen sink into Kernel space, which helped increase the speed of the system at a huge cost in stability.
So NT became less stable as it became more monolithic? The problem with microkernel is not stability, per se. It's "performance".
cpeterso
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.
Do you have a link supporting this assertion? I really doubt Apple moved FreeBSD into the Mach kernel.
cpeterso
We already have BSD and Linux, does
anyone really see that any real problems
are going to be solved with another
POSIX style OS? Even with the microkernel
differences, it really doesn't look like
a big step forward...if you want to build
a new OS, why not actually make it new?
I'd be far more willing to switch / put
effort into something which actually has
some potential to change things - like
EROS. see http://www.eros-os.org/
Eg mathematically provable security,
orthogonal persistance.
I think you are correct. For NT 4.0 they basically moved everything but the kitchen sink into Kernel space, which helped increase the speed of the system at a huge cost in stability.
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
Yeah, that was pretty much my point.
-- It only takes 20 minutes for a liberal to become a conservative thanks to our new outpatient surgical procedure!
Well the Hurd, Hurd, Hurd,
Hurd is the word!
Have you heard about the Hurd?
Well the Hurd, Hurd, Hurd,
Hurd is the word!
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
You really should learn some history before you open your mouth. Linux is a kernal not a full OS. Linux is very nice, but would be pretty useless without X, or the GNU tool set which include all the C libraries. Linux without GNU would be unusable.
6 , right?
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...
--------
I do not count megabytes, I count the number of components that are GPLd.
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).
--------
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.
--------
huh? that ast against linus discussion where everybody could read that in practice Linus was against microkernels happened before Linu[s||x] got famous.
. . . . . . .
may u!sh 2 sm!le at dz!z bad nn.!m!tat!ion
If you have ever read about OS, this article is a waste of your time. To summarize this article, it simple states that Linux is a monolithic kernel and the Hurd is a microkernel. Then it proceeds to spiel on what monolithic and microkernel are, as if it came out of any OS book. It doesn't really tell you what Hurd is meant to do! It tells you about the functioanlity of a microkernel. Worst of all, it doesn't tell you what Hurd is now doing and not doing yet. I am not impressed. RIP Hurd.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
One place to read the debate is here.
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
There's more to a microkernel than just modules. Sure, Linux has pluggable modules, but they run in kernel-space. HURD's use of "servers" is much different.
There are pretty good reasons for that: VAXen had 16 general purpose registers, while (as an example) Alphas have 32 integer registers, and 32 FP registers. Copy those out, and copy the stored values in, for every context switch, and it adds up. Modern RISC architectures provide some balm for this, though, and not just because their clock rates and memory speeds are approximately four bazillion times faster than those of the VAX.
This is about Hurd, not Linux.
wolf31o2 Developer, Gentoo Linux Games Team
Mach was developed on RISC machines (IBM RTs, then MIPS). Microkernel performance sucked.
> microkernel modules can be anything
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.)
NT is not a microkernel OS. There is a HUGE amount of code running in kernel space, much more than (say) Linux.
I'm sure that if Richard Stallman were dead, his body would whirl dervishly in the grave over this characterization of the GNU project. :-)
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...
If you can get someone to compile it for you.
perl -e 'fork||print for split//,"hahahaha"'
Cool! I've never been any good at using kernels without any software on top.
perl -e 'fork||print for split//,"hahahaha"'
While I'm not the final expert on these matters, I suspect that the opposite of what you suggest is true. CISC machines tend to be much better at context switches. It does depend on the machine... but the VAX (about as CISC as you can get) could task-switch in a handful of cycles, while some RISC machines take hundreds.
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.
Let's see, we have one group of people who knows nothing about operating system design arguing that monilithic kernels are superior because they vaguely remember hearing that Linus Torvalds said that monolithic architectures are better than microkernels.
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!
A few hackers (among them Christopher Chimelis and Ron Farrer, well known for a lot of other work on the Alpha) have started porting it to the Alpha architecture. Have a look at the sourceforge site.
bravo!
No brownie points to give, sorry!
The problem is that compared to a pared down monolithic kernel, the savings aren't that good. If at all. NB: I'm making things up as a go along, so add salt to taste, and don't hesitate to flame and correct:
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?
If you count the number of hours actually spent developing HURD compared to those spent developing Linux, you'll see that HURD has had FAR less development time. Sure it started earlier, but that doesn't mean its been actively developed since the early 90's!
A deep unwavering belief is a sure sign you're missing something...
That't not totally true. On the BeOS at least, kernel calls are made directly, the kernel is mapped into each process's address space and the only overhead is that of the ring change (no context switch required.) Calls to various servers are usually batched. For example, the Interface Kit will collect all drawing functions you call and send them in one big batch to the app_server. The resultant overhead from sending the message is far outweighed by the actual functionality offered by that one message. QNX's Photon works much the same way. According to QNX, drawing through Photon, which uses messaging, is about as fast as making calls directly into the graphics driver. It introduces more latency, but in terms of raw throughput/cpu usage, it is about the same. When you look at the real-world performance of these two systems, you'll notice that they are faster than most UNIX's, microkernel or not.
A deep unwavering belief is a sure sign you're missing something...
I think that there is a little bit of a difference. The loadable modules that Linux uses right now are primarily device driver style modules, and are loaded into kernel-space when they load. What the article is talking about is the inability right now under Linux to add significant system-level features (the example given was networking stacks) outside of kernel space. So there is not a way to extend the kernel in Linux without directly fooling with kernel code, one way or another. This hurts the maintainability of the system, as the amount of stuff lying around inside the kernel grows and grows. Additionally, the monolithic style (according to the writer) lacks a nice strong abstraction barrier that makes it possible to alter components individually without breaking something in the system. If the line between where things like basic kernel services and things like device interactions or networking is not clear in the code, than the odds are that if you alter one of them, you're going to end up having to alter them all. In an ideal world, the layer of abstraction insulates the rest of the system from changes. You want to rip out the old memory management code entire and put in a new one? Great. As long as you provide the same interface (API calls & c.), nothing else should need to be altered. This is of, of course, an ideal situation. Systems that are designed that well are few and far between, but in general a little extra abstraction is going to save you maintenance headaches in the long run, which can be very important on a system like Linux, which is going to go through multiple iterations and have significant modification done to it on a semi-regular basis. Generally, this is a long term problem and not an immediate one. No one is going to complain next week that non-modularity is ruining their life (okay, the guy who wrote the article), but in 5 years, when the code base has swollen more, and when advances in hardware make the performance ding due to using a more modular solution less noticable, than there may be some harried kernel hackers bemoaning the complexity (and ugliness) of a system that has grown without good abstraction and without a good non-kernel space module system.
"Sweet creeping zombie Jesus!"
It's not whether it works, it's whether the users of it (or in this case, the developers) have their lives made easier. After ten years or less, development on the Linux kernel will have stopped as there will be too many faciltiies to try and put in.
Mind you, ideally should we be using UNIX for most portable devices?
Well written microkernels (like QNX) work o-k. Bloated almost-backward-compatible proprietary monsters (like MS w* products) will not :)
--
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
You wrote: Remember RMS's reply to Jorrit, regarding an LGPLed "open source" 3D engine: "I don't support the Open Source Movement,so I can't have a discussion with you in the name of open source."
r eedom.html.
I say: Here's the text on "Open Source" at the GNU site:
http://www.gnu.org/philosophy/free-software-for-f
It's 11pm, do you know what your deamons are up to?
It's Debian GNU/Hurd, in the same way as it's Debian GNU/Linux.
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.
It's 11pm, do you know what your deamons are up to?
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.
It's 11pm, do you know what your deamons are up to?
You said: You do realize that there are BSD versions of ls and cd, don't you? If you were as familiar with my system as as you claim to be, you'd also realize that I use tcsh and not bash.
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.
It's 11pm, do you know what your deamons are up to?
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.
It's 11pm, do you know what your deamons are up to?
It *may* invalidate it?! LOL!
;). IIRC waiting for Mach4 wasted a lot of time, and I suspect there were many other problems.
;). RMS wrote GCC and EMACS himself. I doubt you have any comprehension of how hard he, and his "crazy comrades" have worked, although you almost certainly reap the rewards of their labour.
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.
Tales from behind the Lagom Curtain
don't get me wrong: i think RMS has had a very strong positive influence on the political free software and open source (like it or not, RMS) movements. but they're not beholden to him, he did not create them, and neither was his idea.
further, i think you're right about non-Linux projects being very worthwhile. but attributing all the distaste for HURD to anti-RMS/FSF sentiment is off base. the fact that HURD is still in alpha, seven years or so after being started, is a big minus. but the bigest problem is the fact that your statement: is simply false. HURD has nothing new to offer. most of its ideas are lifted wholesale from other places, and the organization of those ideas is entirely non-innovative. there are plenty of non-Linux projects that're very worthy of your statement above. i'm not even a Linux user any more, in favor of them. but HURD doesn't qualify.
if you're looking for good OSs, QNX is a good microkernel, Mac OS X has some very good potential (although the free parts are basically just another Unix), and i personally prefer Inferno and Plan 9 (which HURD took a few ideas from).
i speak for myself and those who like what i say.
I don't understand why the FSF is throwing so much energy into working on HURD. The Linux kernel is already GPL and therefore complies with the FSF goals. Why is the FSF working on this when they already have that component to help make a free operating system?
Prevent email address forgery. Publish SPF records for y
>Do we call all applications with
>GCC 'GNU/MyApp'? We're talking about a whole
>operating system with applications and
>documentation, not just a single application.
Of course not. It is common knowledge apps compiled with gcc need not be in GPL in most cases.
Some people call Linux "GNU/Linux" because
1. it is always distributed with GNU tools
2. The kernel itself uses the GPL license
3. So, essentially the kernel and its tools are
GPL'd.
3. Nobody found it offensive calling it this way
>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").
Again, not.
1. MS won't allow them to be called MS/Something
2. They're just PORTS of MS apps, not the actual
bundling of MS apps, unlike Linux distribs,
almost all of which bundle actual GNU apps.
When/how did microsoft show that microkernels dont work ?
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)
One more version to go before they can cash in on the nostalgia of all those Speed Racer fans.
The Web is like Usenet, but
the elephants are untrained.
What has Hurd's possible scaling problems got to do with Linux? :-)
They're both kernels but otherwise they haven't got much to to with each other.
Of course, problems with Hurd leads to lesser comptetition for Linux, which could be seen as good or bad depending on you viewpoint.
/.Mattsson - My native language is not English, so please don't whine over linguistic errors. (That's lame anyway...)
I'm sure it must be hard to believe that someone might have read something before it was posted on slashdot.
The site is called "News For Nerds, Stuff That Matters" -- NOT "Bleeding Edge News, Stuff That Happened Tomorrow"
"Being alive is a crock of shit." --Kilgore Trout
Doh it was an analogy. Making a program suid-root reduces safety, and should be avoided as much as possible. Giving a program access to kernel space reduces safety, so why should we not try to avoid it?
Correction accepted: I should have said "Graphics system" and not UI .Lazy me.
But I think you got my point.
Never attribute to malice that which can be adequately explained by stupidity.
Linux demonstrated years ago the Monoliths work. MS showed Microkernels don't.
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.
If all services are provided by other servers how can I code anything? Try to read file? Sorry fs server is not running. Try to setup alarm? Sorry time server is not running. Of course one can require POSIX compatible system but what's the point running micro kernel if you always have basic set of servers (everything required to be POSIX compatible).
Idea of translators described in the article sounds nice, but if you think about it it's only mounting in user space. I don't know how mounting is done internally, but I have often wondered why I have to be root to be able to do it. In the end I cannot imagine any good reason why this couldn't be done with Linux. Monolithic kernel with device drivers as modules as the current trend with linux seems to be sounds like the best solution for me. Though I would break some quirks inherited from UNIX.
_________________________
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
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.
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.
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!
---
How am I supposed to fit a pithy, relevant quote into 120 characters?
Compare:
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.
WARNING: there is a trojan on your
The Darwin kernel is monolithic, so that 5% slowdown must be coming from somewhere else.
Since Linux was written by obsessive cycle-counting hackers instead of grad students, it seems fairer to compare it to L4 or EROS than Mach.
I think SawMill (no, not the window manager) is more interesting than the Hurd. It seems more developed (since it borrows lots of code from Linux) and runs on a faster kernel (L4).
Did he mean X as in the windowing system, or X as in a free variable?
> I disagree. The point about how there is no simple way to add new features into the kernel is a crock:
:-) )
It depends what 'simple' means.
> I understand the use of modules and this seems to be a modular way to add features
Yes. Modules are modular. But loaded modules become part of the kernel. So when you want to extend the _system_ for, say, a new network protocol, you end up extending the _kernel_.
As a comparison, under The HURD, you don't need to be root to extend the system. You don't even have a way to crash it when extending it (well, you shouldn't,
A comparison would be the development of a server (like ftpd, or dhcpd) under non protected OS (MSDOS, Win31, win95, Mac OS) and Linux. Under the former, you can crash the os while developing. Under the later, you cannot crash the os. You don't need to reboot. You don't need to be root (but you won't bind to privilegied ports).
> Bottom line: how accurate is this article?
Much more accurate than I thought when I started reading it.
I suggest that you read a bit about the Hurd (start at official site). It can do really amazing things that will never be possible under linux. It worth the read, even if only for the intellectual entertainement.
Cheers,
--fred
1 reply beneath your current threshold.
> The fact that "it's a microkernel" doesn't make everything magically pluggable.
Mmm. The 'scheduler' example of the previous poster was infortunate, but in a broad sense, everything is pluggable in a Hurd *system*. Scheduler was a bad example because it is done at the micro-kernel level, (like memory managment) so is only as pluggable as the micro-kernel designers decided it was.
I agree with you that micro-kernel per-see don't give anything more modular, but a multi-server system will be totally pluggable, in the sense that you can replace any server by your own, or add as much servers as you want (they won't be 'second-class citizen'. Hey, try to add a system call to linux !)
It won't magically solve all the world-problems, it will be probably of an unmanagable complexity, but it it damn cool.
Cheers,
--fred
1 reply beneath your current threshold.
> Want a working microkernel OS with source? Darwin. And you know what? If the Free Software Foundation collapses tomorrow from the weight of its hubris, no one will be any wiser for it but many will be the better for it.
You are interstingly stupid.
First, without the FSF, there would probably never be any 'Darwin' (because there would have been no GNU/Linux, hence the concept of having a system with free (as beer) avalaible source would still be alien)
Second, some of us value more the freedom to the free-as-beer. For us, Darwin don't fit the bill.
Third, if FSF dispear tomorrow, then I can continue to use GPL'ed code. I can continue to use GPL'ed derived code.
If apple disapear tomorrow, you cannot continue developing and extending darwin. Unlucky boy.
Fourth, thinking that Darwin can be a replacement for the Hurd at a technical level (a working microkernel OS) shows a profond misunderstanding of what The Hurd is trying to achieve (a multi-server microkernel).
> Keep politics out of software. That way lies idiocy.
You seem to be pretty knowledgable on idiocy.
Cheers,
--fred
1 reply beneath your current threshold.
I've been spreading it for quite some time. Markup languages are the obvious solution to the general WP problem, and HTML is becoming the ubiquitous format for documents.
Sooner or later we'll be able to tell MS to take its proriatary WP file formats and shove them.
We could do it TODAY if everybody got on board.
The problem for the code factories is the core apps are truely becoming commodities.
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.
Which isn't the average user. It's an interest piece for geeks. Period. It dosn't pretend to be anything else. The article ITSELF claims that Linux is fully functional now and the HURD isn't.
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.
This is still more of a good idea than a usable system, advanced users only need apply.
And the fact that this was moderated at 3,Int just underscores his point!
RMS is going to be pissed, but not because of the title of the article. The author actually gets it right in the text. RMS will be pissed because the author attributes open source to the Free Software Foundation:
Remember RMS's reply to Jorrit, regarding an LGPLed "open source" 3D engine: "I don't support the Open Source Movement, so I can't have a discussion with you in the name of open source."Why would it be harder than a monolithic kernel?
if (!signature) { throw std::runtime_error("No sig!"); }
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.
Yes, but since more OS functionality will be implemented in user space, you can expect to see fewer `system calls.'
BH
Fools! They laughed at me at the Sorbonne...!
Ok But Isn't Linux moving to a module Kernal anyways.
Yes I can not spell...Wait....for a second there I almost cared.
If 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.
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.
Yes I can not spell...Wait....for a second there I almost cared.
I would have to disagree with you there. Basically any machine (either CISC or RISC) has to do a few things to switch context - save the old register and MMU state and then restore new state.
The time taken to program the MMU's memory mapping registers should not be affected by whether the processor is CISC or RISC, so we can rule that out of the equation. Saving and loading register contents is wildly different on different architectures though, and this is where the performance would differ.
I once wrote a preemptive multitasking system for the Acorn Archimedes computers, which use ARM2 RISC chips. As they were RISC, they only had 22 instructions - but two of them were LDM and STM, which means "load multiple" and "save multiple" respectively. These instructions allowed you to dump a whole load of registers to or from a location in memory as fast as the memory bus could take it (1 cycle per register, IIRC). Also, register R15 held the program counter, the flags (including interrupt enable/disable), and the CPU mode (i.e. user or kernel).
All this niceness means that you could use one single instruction to do a context switch - with interrupts disabled in Kernel mode, you could simply say "Load multiple R0 to R15" and it would load in all the registers, enable interrupts, switch CPU mode to User and jump into the correct place in the process's code segment. This would take one memory cycle per register (i.e. 16 memory cycles).
My experience with CISC CPUs is that even though they have vastly less registers to save and restore, you need many instructions to do all the separate things that the ARM chip can do in one go. This is why I'd contend that RISC context switches are at least as fast as CISC, if not faster!
He made all that stuff up and someone thought it was "Insightful". Ah, well..
Why do I keep typing pythong?
The Hurd is older than Linux. So its lack of progress is not caused because of its age, but because of design decisions.
No sig for the moment.
Mhmmm... good idea...
No sig for the moment.
I found it interesting that there was no mention of QNX in the article, as wouldn't it be a fairly good example (albeit, not open-source) of a microkernel where every other function is a module? I have heard nothing but good things about QNX, and running their 1.44 floppy demo was a hoot.
JoeK
What Would Sutekh Do?
Anyone got a mirror of the article? I'd love to read the it but for some strange reason the site seems to be down.
Marxism is the opiate of dumbasses
I've long been a subscriber to DDJ. It's really good to see them covering microkernels. With projects like my own, xMach using a similar basis (Mach4 and a single server) it makes for a good read. And I'd like to say to all the Linux people here who will say how great Linux is and how great monoliths must be - Linus used to praise AST for making Minix a microkernel. He used to say he wished he had made Linux a microkernel. For some reason, when he got famus and had to back Linux 100% of the time, AST was a moron for making Minix a microkernel, and monolithic kernels rocked his nads!!! Linus loves flip flops!
--
But X isn't a kernel, it's a windowing system.
arnald
The latter, my post was intended to be humorous but obviously went over your head.
Oh well.
arnald
Apologies for the appalling pun. But its relevant. The thing that leapt out of the article for me was 'Hey, this would be great for portable devices'. Write a translator for Bluetooth gear, instant wireless networking. Write another for GSM WAP cellular stack communication.. instant wireless productivity connections. Don't have a filesystem? Chuck it. Added an IRdA port to your device? Plugin a new service and off you go. This would rock.
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.
http://twitter.com/onion2k
Not really. Its just a matter of degree. When the linux kernal first came out it was very monolithic. As the quote above says "it became clear very quickly". In other words not from the beginning.
Linux modules are an attempt at encapsulation. HURD's microkernal is even more of a step in that direction.
Its like asking is Java type safe? Well yes. Compared to C it is. But compared to other languages no it is not.
Personally I look forward to the day when HURD is ready for the end user. Linux is very good, but ultimately I am not a kernal hacker. I feel no real attachment to it. If HURD can advance the state of the OS on my machine all power to it.
Phil
You really should learn some history before you open your mouth. Linux is a kernal not a full OS. Linux is very nice, but would be pretty useless without X, or the GNU tool set which include all the C libraries. Linux without GNU would be unusable.
The HURD kernal is about 10 years old. It is usable but not prime time yet. I think that this is a pity because it would be good to have it out in the world. I think that Linus comment that HURD has forgotten that they need to produce something is perhaps moot. Having said that GNU has always produced high quality tools, and has always had a cautious release policy. A full release emacs for instance is always very stable having been extensively beta tested before hand. Compare this with the early versions of linux, or even some of the development versions nowadays...
I don't know which is better:- the release early and unstable, or release late and solid, both have their advantages. Either way I look forward to HURD, so we can complete the full OS that "Stallman and his crazy comrades" have already provided me with.
Phil
I'll just use Linux, thanks
Adam
"Cool! I've never been any good at using kernels without any software on top."
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.
"Each time you type ls or cd you execute GNU code. The bash shell is GNU code." You do realize that there are BSD versions of ls and cd, don't you? If you were as familiar with my system as as you claim to be, you'd also realize that I use tcsh and not bash. "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." Again, they may not be essential to *your* system, but they certainly are to mine. Combined KDE and XFree take up more room than pretty much anything else on my system. So much for them being a "tiny part".
" I believe that I am correct when I say that most GNU/Linux users use bash (wasn't there a poll about this?"
Most linux systems are distributed with GNU utilities. I'm not talking about *most* GNU systems, or *most* Linux users. I'm talking about myself.
"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."
The GPL isn't what makes something GNU, otherwise the Linux kernel would be GNU and we wouldn't be having this discussion.
I simply can't have a running Linux environment without the contributions of hundreds of individuals and groups... I'm not about to call Linux, GNU/AC/DB/AV/../../../../Linux, though.
"I'll bet GNU code is run every time you type ls or cd, and when you run your shell, and...."
And I'll bet BSD code is run every time I do that, too... I'm not about to call it BSD/Linux, though...
That's my opinion, too... But some people think I should start calling Linux GNU/Linux. They apparently think that it matters.
Ranessin
--
--
You are a fucking moron.
There were only 3 guys there.
Think "Slashdot Effect".
Sigh.
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...
Who gives a fuck? As long as it works properly, what does it matter?
http://www.fsf.org/software/hurd/debian-gnu-hurd.h tml
I love Linux and use it exclusively (except at work where I am forced to use windows, sigh) but, I don't believe that Linux is the final word in computing. Hurd may not be the answer and may never be a viable alternative. I don't know and I am not qualified to say. I will say that it is admirable that they are trying to advance the state of free operating systems and I hope they succeed. I just don't understand the mentality of the posters here think that they should not even try, because we have Linux. Actually, I do understand, it is simply because RMS and the FSF are behind it. If Linus was to announce that Linux 3.0 was going to be a rewrite using the microkernal idea, people would be proclaiming what a genuis he was. I am really tired of reading the moronic flaming that goes on here at Slashdot anytime an article mentions RMS or the Free software foundation. I am aware of the problems that Stallman's rhetoric has caused, but, I am also aware that without all the work done by him and the FSF, I would not have any alternative to Windows today. For that he has earned my respect and deserves yours.
Can somebody point me to a site where one can go to discuss issues intelligently. I am sick of the noise here.
Have their been any studies on how a microkernel may perform under RISC processors like StrongARMs, SH3, and MIPS? It's possible that HURD's shortcomings are only in the CISC world. Anyone have any info?
Wasn't the same sort of thing applicable to Linux?
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?
... at least, not in the medium run (and in the long run, of course, we are all dead). Why do I think this? 1. Well, speed problems often scale to the size of the task, even in the OS. 10 years ago, I was sure that "just a bit more cpu speed and context switch speed" would solve most major OS bottlenecks. If you had told me 10 years ago that OS's were going to have to handle real-time video decoding off gigabit networks and similar horrors, I might have sung a different tune. Of course, eventually we'll run out of cool, ever-more-cycle hungry things to throw at our machines - but I think that's a fair way away. Secondly, not all parts of CPU architecture follows Moore's law at quite the same rate. Architectures are optimized for SPEC, not context switches - which, in some ways, get more and more expensive (in cycle terms, not in real terms, of course) as register files and various other forms of per-process and per-thread get larger. The advantage that you describe in for PDAs seem kind of sketchy. Learning about a "single daemon's" message passing protocol with the rest of the system is no harder and no easier than learning about the method calls that call the equivalent module in a operating system. As for microkernels being able to dump things like device support - how long have we been able to build custom UNIX kernels now? Granted, you can't dump support for (say) processes, but I put it to you, that if you're really pruning back your system to bare bones, then the microkernel probably won't be a very good match for the PDA either. I doubt that the same microkernel can be (a) a great building block for building fully-featured systems on top of it, and (b) a fine base for a completely minimal PDA os. There are just too many competing demands, here.
I haven't really followed this debate since '95, so I may be completely off-base here. I recall at the time, there were a couple big problems with micro-kernel rhetoric:
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).
Believe you me, no one is having an ego trip anywhere near the powerline my Boss is...I swear one of these days he's gonna look at the ceiling wrong & it will spontaneously combust...hopefully people don't follow ;)
-RedElf
You know, I have one simple request. And that is to have sharks with frickin' laser beams attached to their heads!
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?