First Program Executed on L4 Port of GNU/HURD 596
wikinerd writes "The GNU Project was working on a new OS kernel called HURD from 1990, using the GNU Mach microkernel. However, when HURD-Mach was able to run a GUI and a browser, the developers decided to start from scratch and port the project to the high-performance L4 microkernel. As a result development was slowed by years, but now HURD developer Marcus Brinkmann made a historic step and finished the process initialization code, which enabled him to execute the first software on HURD-L4. He says: 'We can now easily explore and develop the system in any way we want. The dinner is prepared!'"
Mods... (Score:3, Funny)
Except this one, of course.
Re:Mods... (Score:4, Funny)
Re:Mods... (Score:4, Funny)
yes, you are and yes, we did.
Re:Mods... (Score:5, Interesting)
After a slow start Mozilla is finally ready and moving fast.
Hopefully the same fate will happen with Hurd as soon as developers come and take it seriously. Its a selfulling prophesy in free software.
DNF? Well its proprietary so who knows
Re:Mods... (Score:3, Funny)
Dyu think Microsoft will ever live it down ... (Score:5, Funny)
Comment removed (Score:5, Funny)
Re:Dyu think Microsoft will ever live it down ... (Score:5, Funny)
I am going to start a project to rename every friggin FOSS project there is to gain popularity. I happen to know a little about publicity and advertising, and I can tell you right off the bat that products like the gimp, hurd, lame, gnu, etc etc will never gain widespread acceptance until they have a more marketable name. Case in point: Mozilla --> Firefox.
Hurd will now be known as (dropping all of the stupid recursive abbreviation crap that RMS is so fond of) FUTURINO OPERATING SYSTEM
The Gimp will now be called PHOTOFRIEND.
Lame is hereby dubbed - MUSICSHRINK 5000.
Gnu/Emacs shall become - WORD-O-LATOR FREE
and so on...
Re:Dyu think Microsoft will ever live it down ... (Score:3, Funny)
Uhhh, yeah. That ummmm big anti-HURD ad campaign that Microsoft is running on all the TV stations.
Re:Dyu think Microsoft will ever live it down ... (Score:5, Funny)
*ducks*
what about second? (Score:4, Funny)
Re:what about second? (Score:3, Funny)
Re:what about second? (Score:3, Informative)
I remember that slashdotting the first time around... pretty funny to link a beta OS up like that to be taken down in minutes by the hoard.
Re:what about second? (Score:3, Informative)
Actually the machine never died, just the pfinet server.
what 1st program? (Score:3, Funny)
Mach Microkernel vs L4 (Score:4, Interesting)
Re:Mach Microkernel vs L4 (Score:3, Informative)
The big thing is that in ring0, no one can interrupt you. So a kernel can run many cycles uninterrupted by applications. Mainly, this is used for scheduling and precise timing.
What L4 seeks to do is bring all levels of processing out to ring4. By doing this, they minimize the amount of code that cannot be preempted. (I'm sure you've heard about t
Re:Mach Microkernel vs L4 (Score:5, Informative)
The x86 uses rings but everything else just uses the supervisor vs user state (since that is all anyone uses the x86 for: rings 0 (supervisor) and 3 (user)).
You can be interrupted in ring 0 (on x86) or other architectures' kernel privilege level. They usually have an interrupt state flag that needs to be set but, as far as I know, this never has to do with privilege level (except that most interrupts turn it off so that you can clear the interrupt).
There is no "ring 4". On x86 it is "ring 3" (there are 2 bits for the ring level) and other chips just have "user mode" (hence, this is the generic term for this state).
Resource starvation and priority inversion have nothing to do with the notion of CPU privilege levels and can both occur on L4.
The real power to a microkernel comes from the modularity. It is much easier to maintain several small programs than one large one. Plus, it means that any problem in one of them harms nobody else (and that process can later be restarted instead of bringing the whole system down like Linux would with a bug or faulty driver). Additionally, a lean microkernel can stay resident in CPU cache so all kernel code can be run without memory latency overhead (only memory access and device access causes a problem).
The disadvantage is that the additional level of indirection in the message-passing between processes takes longer than just jumping to the kernel to execute a function and then returning (it isn't quite that simple but you get the idea).
Re:Mach Microkernel vs L4 (Score:3, Funny)
A 'ring' of truth, perhaps?
To Intel engineers/who's interested (Score:3, Interesting)
The ring protection should have been inside the page table. A page descriptor has enough room for that. It should have been like this:
Page Descriptor with Ring Protection:
bit 0: page present/missing
bits 1-3: other
bits 4-5: current ring
bits 6-7: Read ring
bits 8-9: Write ring
bits 10-11: eXecute ring
bits 12-31: page frame
Why Multics went under (Score:3, Insightful)
That story has been told I don't know how many times. Multics went under for the same reason HURD never took off. It was aimed too high for the resources available. When it became evident that nothing was going to come out of it in a reasonable time frame, Bell Labs got out of the project and that was why Unix was born. Nearly the same thing happened in the HURD/Linux story, the main difference is that Multics/Unix were commercial projects done
Re:Why Multics went under (Score:4, Interesting)
Re:Mach Microkernel vs L4 (Score:4, Interesting)
The Hurd is an interesting design. With luck, it will demonstrate both that the performance hit is no longer of major importance, and that a true microkernel has advantages over monolithic kernels. Only time will tell, of course, if those advantages are going to be properly exploited; but I must admit to curiosity as to what might be implemented above the Hurd that would not be possible (or would be significantly harder) with Linux.
Re:Mach Microkernel vs L4 (Score:5, Interesting)
But the small size doesn't make most systems faster. Running the same Unix API, L4 adds execution time overhead beyond the default monolithic Linux kernel, about 5% [psu.edu]. (Does anyone know the figure for Linux-on-Mach? I know it's much greater than 5%....) However, there are some significant advantages having to do with debugging, maintainability, SMP, real time gaurentees, memory management, configurability, robustness, etc. Detailed discussion here [cbbrowne.com].
From the overview: [tu-dresden.de]
Other links: L4KA homepage [l4ka.org], background info [unsw.edu.au], more info with some historical L3 links [tu-dresden.de].
Frankly, I think L4 is very much the right way to do things. I wish I could say the same for other parts of HURD.
Re:Mach Microkernel vs L4 (Score:2)
Re:Mach Microkernel vs L4 (Score:5, Insightful)
When you think about it, a system running 5% slower than today's system is only one month behind on Moore's curve. (2x performance in 18 months is 5%/month system speed increase). Wait an extra month to buy your next machine and you can have the same performance on a far sounder foundation. (Of course this assumes you're doing your conversion sometime after Hurd L4 actually runs the things you need).
Re:Mach Microkernel vs L4 (Score:3, Informative)
5% overhead for running a system that has all the features in reliability alone has got to be well worth it.
5% overhead in the system calls only. In their own timeslice, threads run without any performance penalty, up to the point where they need to IPC some server task like a file server or so.
So it depends if your application is more I/O or compute bound.
But you're right: 5% is next to nothing, even on low-end embedded platforms.
Re:Mach Microkernel vs L4 (Score:3, Insightful)
That's being foolish. There's plenty of "experimental" OSes around, many of them Free Software, like EROS [eros-os.org]; that isn't what the HURD should be doing. It shouldn't be this neat system where development breaks away completely from what programmers are used to writing, therefore guaranteeing that porting of applications will be a tedious, and ultimately fruitless, process.
What the HURD developers should be doing is (risking the wrath of the community) be less revolutionary, and get something going. The tea
Let's see here (Score:3, Insightful)
Given the fact that some features in OS X took Apple over 12 years to get into a shipping product (development on Copland started in 89), and given the fact that for years Apple had suffered with a horribly buggy, non standards compliant, limited system that was the Classic Mac OS, and given the fact that Darwin with the Mach kernel is an excellent open source unix system, and given the fact that huge amounts of time and money were spent getting OS 9 and Ca
Re:Let's see here (Score:3, Interesting)
Copland was abandoned, thank god.
Mac OS X actually was shipping in 1989 - it was just called NeXTStep [wikipedia.org] back then and didn't have Classic. We actually had two NeXTstations in our house back in college in the early 90s, a cube and a slab.
Too bad they had to gussy it up to make it look more like Mac OS 9- to be accepted by the faithful, it was a much more elegant de
Re:Let's see here (Score:5, Interesting)
Also, not only did OS X take a long time to develop, it took an even longer time to become usable. The first desktop version, 10.0, was released in Mar. 2001, and it sucked. Actually, it worse than sucked, it was closer to a beta than a release. I consider it more of a developer's preview. The next version, 10.1, released in Sept or Oct 2001, was usable but still too slow, particularly for the hardware at that time. The first version I would call good, and good enough for the casual user, was Jaguar, 10.2.
Most estimates of the cost of developing OS X in its present are around $1 billion. (Cost of acquiring NeXT was $420M, plus all the development time and money. I think part of the Copland money was counted in there too.) That's a whole lot of development time, money and effort to throw out for a hypothetical, potential and probably minor speed increase. Given the further elaboration above, I agree with the parent's implied answer.
Still, one could argue that much of the time the parent and I count as "working" on OS X didn't really count (i.e. Copland, which failed, and NeXT, much of which didn't make it into OS X), but these timelines were still important in making today's OS X what it is.
there is a research project to port darwin (Score:4, Informative)
guess nobody bothered to g**gle it: New kernel for Darwin: [uq.edu.au]
Re:Let's see here (Score:5, Insightful)
Palm OS is on its 4th kernel. Did anyone notice? I didn't. I've been a full-time Palm developer for two years, and I couldn't even tell you which version has which kernel (except that I'm pretty sure they switched kernels when they ditched 68k processors for ARM). Did they have to "completely rewrite it down to the kernel level"? Nope, that's just the point: they did the opposite. They left it the same all the way down to the kernel level; it's just the stuff below the kernel level (and a few minor piece above it) that they changed.
The point is, switching out kernels is not necessarily that tough a thing. Sure, it can't be done overnight, but it doesn't force you to rewrite your entire OS.
Much more to the point, if you research it a little, you'll find that Linux has already been ported to L4Ka [l4ka.org]. And the version of Linux that was ported still runs exactly the same software as regular Linux. If some small team of researchers can port Linux to L4Ka just to give themselves a convenient development platform, then I guess Apple could do the same thing to OS X if they had any interest in doing so.
Re:Let's see here (Score:3, Interesting)
After the port would OS/X be, faster, more stable, more secure, or more portable?
I would bet it could be done. The bigger questions is should it be done.
Re:Let's see here (Score:4, Funny)
I'm sure he would, if you will reconsider your use of the contraction "you're [wsu.edu]."
Re:Let's see here (Score:3, Funny)
Re:Mach Microkernel vs L4 (Score:5, Informative)
Re:Mach Microkernel vs L4 (Score:3, Informative)
You will realise how long it took the (handful of) HURD developers to port to L4. I don't think Apple has any ambitions in that direction. It just wants to sell a working system.
Re:Mach Microkernel vs L4 (Score:3, Informative)
Yes, MacOS X is Mach-based. Mach, however, is not really a microkernel in the true sense of the word. Compared to L4's size, Mach is a huge monster. Somebody else already provided a link to an introductory (if old, from 1996) article [l4ka.org] by the L4 creator Jochen Liedtke.
As a matter of fact, the L4KA group is looking into this. See, for example, this thesis [ira.uka.de] currently in progress.
The main benefit is that L4 is actually a true microkernel. It has someth
Dilbert (Score:4, Funny)
Dilbert == BSA whore (Score:4, Informative)
I've been boycotting Dilbert since its authors became BSA propaganda whores [bsaengineers.com].
Re:Dilbert == BSA whore (Score:5, Insightful)
The BSA is making sure copyrights are respected (i.e. the law). Now the only way we are going to get reasonable copyright laws is when people realize that current terms are unacceptable. If people think that they can get away with copyright infringement they wont put as much effort into voicing their opinion regarding how much they think current laws sucks.
In other words people are now saying: "yes, copyright sucks but it doesn't affect me, I can get all the software/music/videos I want (not need) through [P2P du jour], and I can get away scott-free".
Moreover the BSA supports Linux. Yes it does.
It is when companies and individuals realize how much money their have to give to BSA members like Microsoft, Adobe, Apple and others and what little return they get that they'll take a long hard look at Linux and all the excellent Free applications out there.
There is no need for a vast majority of people to give their money to run Windows or Photoshop. They can get all the software they need and more and stay on the right side of the law.
The GPL, BSD license and the like all use the underlying copyright laws. If copyright laws are not enforced then those licenses are worthless as well.
Dilbert is supporting the BSA and so should you. The worse the BSA treats the consumer, the more strongarmed its tactics are, the more audits it conducts, the better for Free software.
Unless you think you have a right to freely access all the copyrighted works in the world?
Re:Dilbert == BSA whore (Score:3, Insightful)
BSA protects the rights of their members, they just protect the rights of some members more than those of other members.
Re:Dilbert == BSA whore (Score:5, Informative)
> Please think it through, Dilbert is right. How can you not support the BSA's actions ?>/tt>
Easily. I support its basic principles - protecting its memebers' copyrights - but its actions are indefensible. Take some of the following examples. In 2003 they sent a letter to a German university demanding they take down infringing software from their site. The software? OpenOffice. Also in 2003 it attacked Massachusetts, the only state holding out against the DoJ's settlement, for adopting an open source policy when no such policy existed. In 2000 when I was working for a small company in London, we received a letter threatening to make us "the focus of a BSA investigation" if we didn't get licenses for all the pirated software in use at our offices. We had licenses for all our proprietary software - namely Informix and Solaris. In 2002 they attempted to raid kickme.to's offices in order to find information about their customers, when kickme.to is just a redirection service with no hosted content of its own. Only last month they published a whitepaper calling for the enforced cooperation of 3rd parties (i.e. ISPs) with rights holders. In other words they want the existing, much abused, DMCA subpoena and takedown notice fortified. In 2001 they said the cost of piracy was $3 billion. In 2003 they said it was $29 billion. I guess $3 billion is not enough money to make the headlines, so they had to re-engineer their spurious mechanisms to produce a better figure.
In short the BSA is a bully, a liar and its actions are, as the grandparent poster argued, indefensible.
Re:Dilbert == BSA whore (Score:5, Informative)
Basically, they are a roving band of pirate lawyers looking for plunder. Mafia tactics, that border on harassment, not these "do-gooders of Copyright laws" you proclaim.
motivation matters (Score:3, Insightful)
The Dilbert cartoon does make one wonder about Scott Adam's attitudes towards issues of copyrights and freedom, and that is a justifiable reason to criticize him if it is true. That he indirectly and accidentally may or may not have a short-term positive effect on open source licenses doesn'
Re:Dilbert == BSA whore (Score:3, Insightful)
Although GP has a point, forcing people to pay for software would encourage adoption of cheaper alternatives for now, you are right, this is the real danger: an installed base of DRM. Companies like Microsoft currently charge "monopoly prices", which are "what the market will bare". They aren't so stupid as to charge so much that people are forced to look at alternatives. So when the first "major" round of DRM comes, people will just accept it, rationalising the decision by saying "well, it doesn't cost THA
Re:Dilbert == BSA whore (Score:5, Interesting)
Indeed, ouch, I find that very disappointing, I'll join the "Dilbert boycott". How patronising too, their lame psychological manipulation strategy: "As an engineer like you ..." .. isn't that how you try manipulate 6-year olds? The BSA's tactics disgust me in general.
I used to like Dilbert, but I cannot stand any comic strip that whores itself out to corporate interests in this way. A comic strip is not an advertising platform.
Re:I just deleted Dilbert from my RSS reader (Score:3, Funny)
You're all a bunch of whiners. Either the strip is funny, or it's not. If it's not, don't read it and shut the hell up. Boycotting a strip that you're reading for free every day is not going to affect anything.
Re:Dilbert is bad, very bad. (Score:5, Insightful)
Um, Dilbert is a comic strip. It is meant to be funny and it attacks some areas of interest to a specific niche of readers. If you think you can address other issues in a funny way, by all means write another comic strip!
Now, to pick apart his list of things he says are never addressed in Dilbert...
Is this guy serious? Hello, Elbonia???? He has clearly not read much of the strip.
Oh yeah, those are really funny topics that the average geek encounters on a day-to-day basis.... HELLLO, Dilbert takes place in a cube-farm! There is no union in the average cube-farm environment, and when there is interaction it usually leads to a feeling that I would describe as PRO union-busting.
Again, he must not read the strip. Alice's character is there, I think, to humorously depict a woman's experience in a male bastion. Also, I think that they address planned obsolescence sufficently.
Jeese... again, just not funny material here. Also, not something that most cube-dwellers will run into except in the newspaper.
Man, alive, this is not a "blue-collar" strip. Again, if this guy wants to make a new strip that targets a different audience, he is welcome to. I don't feel that it is a valid criticism to blame a comic strip, or even any other piece of literary or artistic work, for targeting the wrong audience. Try to restrict yourself to commenting on the content provided. Man, he only has three frames a day! I imagine this guy gets his panties in a bunch over Garfield because none of the characters has ever developed feline AIDS.
GNU-Mach was just plain Mach in 1990 (Score:2, Funny)
Competition is a Good Thing (Score:5, Insightful)
Re:Competition is a Good Thing (Score:3, Interesting)
So why not have the people working on Hurd work on something new instead, or work on improving Linux? Competition can also hurt, by splitting up the resources into many small parts
False Dichotomy (Score:3, Insightful)
Oh, it has lots of advantages, particularly for "kernel" developers and system administrators. For developers, implementing e.g. new file systems is much, much easier than in a monolithic kernel (although FUSE has helped here it still feels
Re:False Dichotomy (Score:3, Insightful)
Re:Competition is a Good Thing (Score:4, Insightful)
It's true that combining all the resources and working for The Right Thing is a good idea in theory, but one that fails in practice. The problem is that people can't seem to agree on what The Right Thing is. If they did, there would be no need for politics. For now, I see a need for both competition and politics.
(And the places that have eliminated both are usually called dictator states.)
Re:Competition is a Good Thing (Score:4, Insightful)
Yes sir, I'll reassign the coding monkeys to fit your wishes... wait, what was that? they are volenteering to do this and that's what they want to do? they don't have a boss? well, that's news to me bud, cause I gots a guy right here who wants me to stop the project, yup, stop it right away, cause he wants to tell the coders what they are to do on their own free time. what's that you say? bite your shiny metal ass? well, I never!
Re:Competition is a Good Thing (Score:3, Insightful)
They are working on something new: a true microkernel. They are making it backwards compatible so that people can easily use it.
Competition can also hurt, by splitting up the resources into many small parts
But since nobody knows ahead of time which part is the right one, we have to bear that cost. Microsoft and the Soviet Union believed that they were smart enough to predict everything. The Soviet Union also blossomed initially be
Parent needs a glass hat (Score:5, Interesting)
Your point? The world now knows there are viable alternatives, and they can be had for historical lows on price.
The world's got practice. It's no longer in the same state it was in '91. Back at that time, very few people had unix machines on their desk or at home. Unix ran in the computer room at work or school and you connected to the system but did little in the way of administration. Millions have been introduced to "the unix-like way of life" (TULWOF), superuser status, and have developed desires to exploit the powers of their machines in an infinite number of ways. The world is primed to be wowed again.
I see our future selves laughing at our current fascination with Linux like we now look at time we spent with DOS. We'll see someday how horribly inflexible it was compared to what's coming in this next generation of operating systems. Your post shows you know very little about the Hurd and what possibilities it will allow. One cannot currently imagine all the fun things people are going to do with it (them?) X years from now.
Exactly not the case. There are *profound* advantages [to "the Hurd"].
If and when a usable system comes to fruition is the question. Developers. Developers. Developers. Get them excited and you'll soon be doing things with your machine you'll never even have considered possible. Maybe not yourself, but people will be doing things they never dreamt possible. There are fundamental differences that are difficult to comprehend having experienced only monolithics. Granted, most of the advantages are not so much at the user level, but from a system administration perspective. Guys working "in the computer room" will probably have much more to be excited about than somebody with a user account. If you know what "having root" is like, the possibilities coming with the Hurd's architecture will be much more meaningful than they would to a typical user. However "typical user accounts" will be much more powerful on a box running the Hurd. Even low level stuff like filesystems floats up into "userland" allowing you the ability to customize your environment to great extents without affecting other users on the same machine.
Maybe more people should work on the current telephone system instead of wasting their time with VoIP. Maybe you should have worked harder at your old job instead of trying to find a new, better job? The Hurd is to Linux users like Linux is to DOS users. If Linux (as currently implemented) lives in N-space, the Hurd lives in N+1.
Resources get split up; sure. Consider however how the body of developers grows every day as more and more are introduced to TULWOF. None of us get to justify or dictate how others spend their free time. Get excited about the underdog. Linux has enough developers, don't you think? Will developments made on a new system with completely different rules positively effect Mr. Torvalds pet project? Most certainly I presume. I see the relationship as symbiotic. The Hurd takes on the huge body of software that has been developed due to "the Linux revolution" of the last decade and Linux takes from the Hurd (besides the jealousy that I can only predict will develop eventually) new techniques and perhaps, somehow, some type of hybrid approach to the kernel. There's no telling really; I can only imagine good things coming to both camps. Your attitude of discouraging work on such projects, done freely by others, I see as sel
Linux (Score:3, Interesting)
BTW, Revolution OS is a great movie, even my non-nerd friends loved it. You can pick it up here: http://www.amazon.com/exec/obidos/ASIN/B0000A9GLO/ revolutionos-20/103-9235316-0475036 [amazon.com]
Re:Linux (Score:2, Informative)
Wikipedia link (Score:5, Informative)
Well, it's not that much :) (Score:5, Informative)
I might as well quote this too, which I think this story most likely refers to (posted on 27 jan~):
This uses a lot of advanced words I have no idea what they could mean though, but I don't mind as long as someone does and writes an article
Still a long way to go. Not much one can do except wait... or send in patches if you have kernel hacking experience!
Re:Well, it's not that much :) (Score:5, Informative)
L4-Hurd is pretty nifty, I think. Of course I run Gentoo and whatnot personally for the usability aspects, but I've been following the L4-Hurd port for a while now and this is an amazing little bit of news.
I can't wait to start experimenting with the new features. This is really cool.
Here's a coral cache link to the HurdOnL4 [nyud.net] Wiki page which I set up last summer. It's slightly out of date, but provides a lot of background behind whats going on and some basic information about the build and boot process.
When you retrieve the CVS sources, read the README and all the docs because they contain the most up-to-date information available about building the system.
Porting applications (Score:2)
Great (Score:5, Interesting)
"hello, world" anytime soon ? (Score:4, Funny)
How much time would it take to port it over ?
choose a new name for a new kernel (Score:3, Insightful)
The L4Ka-based kernel is a new project that sounds like it has a lot of promise and may address problems that both Linux and commercial kernels have with modularity and extensibility. This new kernel should get a snazzy new name to get that message across.
Re:choose a new name for a new kernel (Score:5, Funny)
I don't think something called "El Forka" sounds all that inspiring.
flame of the day (Score:3, Interesting)
timely (Score:3, Interesting)
Can't anybody over there write an OS? (Score:3, Informative)
The Hurd website, wiki, etc. haven't been updated in years.
At a more fundamental level, there's a design disaster in the making here. L4 seems to make the same mistake Mach made with interprocess communication - unidirectional IPC. This design error is called "what you want is a subroutine call, but what the OS gives you is an I/O operation". This is a crucial design decision. Botch this and your microkernel performance will suck.
QNX gets it right - the basic message-passing primitive is MsgSend, which sends a message and blocks until a reply is received (or a timeout occurs). The implementation immediately transfers control to the destination process (assuming it's waiting for a message), without a trip through the scheduler. That's crucial to getting good performance on real work from a microkernel.
Mach botched this. Mach IPC is pipe-like, with one-way transmission. And that's a major reason Mach was a flop. (Note that the version of Mach used for the MacOS isn't the final "pure Mach", it's a Berkeley BSD UNIX kernel with Mach extensions.)
Why does this matter so much? Because if send doesn't block, when you send, control continues in the sending process. Later, presumably, the sending process blocks waiting for a reply. But who runs next? Whoever was ready to run next. If you're CPU-bound and there are processes ready to run, every time you do a message pass, you lose your turn and your quantum, and have to wait. So programs with extensive IPC activity grind to a crawl on a loaded system.
But if message passing is tightly integrated with scheduling, a message pass doesn't hurt your thread's CPU access. Control continues in the new process with the same quantum (and in QNX, the same priority by default, which avoids priority inversions in real time work). Now message passing is only slightly more expensive than a subroutine call, and can be used for everything.
There is a big literature about Mach, Minix and related underperforming academic microkernels, while the key architectural details of the commercial microkernels that work (basically QNX and IBM's VM) aren't well publicized. But you can dig the information out if you work at it.
Re:It hurds (Score:5, Interesting)
Now, 22 years later, a definitve breakthrough has been performed.
I see this as an excitement
Now, we will see it emerge and, why not, get sufficient audience to become unavoidable. In 20 years from now, it'll be like it's an opportunity as weel as any other so it's not missed, it just took time to emerge, like my favourite whisky [scotchwhisky.com].
Re:It hurds (Score:4, Funny)
More interested in development (Score:3, Insightful)
Re:More interested in development (Score:5, Interesting)
Re:More interested in development (Score:3, Interesting)
This is precisely my problem with RMS's theory of freeness. The original reason he developed his whole GNU ideology was due to not being able to get hardware interfaces to work correctly. In other words, he wanted to get some work done and was prevented from doing so by the software he needed not being available. RMS being RMS, he decided he would solve the problem himself, and found that the info he needed to hack the drivers wasn't available. Now there are two possible AND EQUALLY VALID solu
Re:More interested in development (Score:3, Insightful)
Re:More interested in development (Score:3, Interesting)
Easy, they just used Linux, so where's the problem? Now you could use Linux and get your work done, meanwhile they've been creating the next generation of OS technology that much Linux kernel code will probably be ported to so you can make an evolutionary step to a system with very, very high reliability features. Plus extreme flexibility.
Re:It hurds (Score:5, Funny)
Damn, those Gentoo guys don't miss a beat, do they?
Why has a GNU kernel been so elusive? (Score:3, Interesting)
It has always been a mystery to me that so many difficult problems have been solved by so many brilliant GNU teams (gas, gcc, gdb, gld, bfd, glibc, emacs, m4, grub, bash ...) that developing a good kernel has eluded them. The people that have developed these packages are certainly skilled enough. They have also demonstrated tremendous drive. Any ideas?
Re:Why has a GNU kernel been so elusive? (Score:3, Insightful)
Ultimately, people either write things that they need, or stuff they're interested in. In the case of the Hurd, Linux and 386BSD (and then the other *BSDs later) removed much of the need for a `GNU kernel', so it probably mostly left people who were working on it just because it was interesting.
And many of those packages that you've mentioned are a lot simpler than a *
Re:Why has a GNU kernel been so elusive? (Score:3, Insightful)
The hurd developers on the other hand set out to create something that is better than anything that has ever been developed before.
When you consider that, it is not hard understand why linux is one of the more popular mainstream kernels out there, whereas hurd still isn't ready for serious use.
Re:It hurds (Score:2)
I see HURD more like a bad simile.
Re:Benchmarks? (Score:5, Insightful)
Microkernel systems are always slightly slower because of the message passing overhead but they can be much more secure and stable because all of the device drivers are run in user space. Contrast it with systems such as Windows and Linux where drivers are in kernel space and it is impossible to have a stable or secure system with poor drivers, and in fact most of the problems with Windows and Linux crashing is caused by buggy drivers running in kernel space. When the drivers are just user processes like in HURD then a faulty driver can't crash the system and if it goes berserk it'll just get terminated just like a buggy browser or text editor without affecting the stability of th entire system.
Re:Benchmarks? (Score:3, Interesting)
Re:Benchmarks? (Score:5, Interesting)
Software failure is more common than hardware. In many cases, drivers can be restarted. Your specific example is probably the toughest one I can think of offhand... you'd have to have a copy of the HD controller cached somewhere to be able to restart it. (since, obviously, you can't load it from HD
You also, of course, have the advantage of each driver/process running in its own address apace, which would probably make very complex code, like the 2.6 Linux kernel, more manageable.
Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now.
But they didn't go that way, and restarting Linux kernel development would be pretty stupid, IMO.
Re:Benchmarks? (Score:5, Interesting)
The funny thing is that back when Linux was started, it could been seen as a restart of the HURD kernel development. What goes around comes around. :-)
Re:Benchmarks? (Score:3, Insightful)
I was speaking specifcally about stopping development on the current Linux and starting over, which I think would be very dumb. Usually, rewriting a big software project from the ground up kills it. Mozilla, for instance, ceased to be a viable commercial force because of its rewrite; Microsoft ate it alive. Firefox is doing pretty well now, but no commercial entity could have made that mistake and survived, if selling browsers
Re:Linux Driver Portability (Score:3, Interesting)
Re:Benchmarks? (Score:4, Informative)
Re:Benchmarks? (Score:5, Insightful)
1. Yes - if your filesystem code crashes, you could end up with a dirty filesystem.
2. Yes - if your hard drive code crashes, you could end up with a dirty hard drive.
But:
3. No - if your webcam driver crashes, you won't end up with a dirty hard drive.
Right now with linux, if a kernel-level driver of any kind panics, the whole thing goes down the tubes.
Certainly a little compartmentalization can't possibly hurt. It won't fix every problem, but it does prevent a small problem in a non-essential driver from taking down the whole system.
As you point out, it will still be critical for some pieces of code to just work without bugs at all. However, the amount of that code can be reduced in a microkernel design.
Also - I don't think TWAIN is windows-specific. I seem to recall using TWAIN on a Mac many a year ago...
Re:Benchmarks? (Score:3, Informative)
I think it's really nice how Linux, by making the code accessible, allows smart people to improve it in ways that were not originally in the plan.
Re:Benchmarks? (Score:3, Informative)
Not every Windows or Linux driver is kernel-space, but most are.
However, with adequate testing, crashes due to buggy drivers are rare. I
No. (Score:3, Informative)
But drivers that require "fast IO" are running in the same address space as the kernel.
So while the IORP-using drivers shouldn't be able to take the system down, I wouldn't call it a microkernel exactly.
Re:Benchmarks? (Score:3, Interesting)
And that's also why drivers in Linux (at least in my experience) are far superior and "just work". Seriously, I don't want my GFX card/network card/printer/webcam/whatever driver to crap out at any time, only to get "just restart it".
Re:Well worth the wait ... (Score:5, Interesting)
Fankly, I think it's a great thing that BSD and HURD will be putting some pressure on Linux to be the best. Competition makes them strong, and the cross-fertilization of ideas makes them stronger still.
Besides, HURD may end up being superior to Linux in some domains, such as high-reliability systems (think banking servers), driver development, OS research, shared systems, and the like.
Re:OMFG (Score:4, Insightful)
But putting the whole history aside, you could see HURD as an exercise in OS development following the route of the more progressive design theories. You might be able to imagine how this pulls the interest of a small group of developers over a longer time, despite of the fact that development is going slowly.
You know how Free Software has the ability to evolve and persist aside from political influences, well, here is your new schoolbook example.
Re:In the words of Linus... (Score:3, Funny)
HURD v Linux
Let me be the first to post the Kottke/HURD troll.
Re:I'm assuming RMS will switch (Score:4, Informative)
To answer your question, the GNU devs started out with proprietary operating systems -- primarily SunOS, I think -- and took advantage of the modularity of UNIX to replace one utility at a time. This is why the kernel was the last piece -- because most of what makes a UNIX system run actually resides in user space.
Attempts to create free versions of other OS types -- ReactOS comes to mind -- have a harder time following this example, because most other operating systems are not designed in such a modular way. So they start with the kernel.