Slashdot Mirror
First Program Executed on L4 Port of GNU/HURD
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!'"
... if GNU/HURD comes out before Longhorn?
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.
Trolling using another account since 2005.
http://en.wikipedia.org/wiki/L4_microkernel_family
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!
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%. (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.
From the overview:
Other links: L4KA homepage, background info, more info with some historical L3 links.
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.
When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
How fast is GNU/HURD compared to GNU/Linux? How about non-GNU/Linux?
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.
Well, this is fairly wrong but some of the truth is there.
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).
If the system is able to stay up without further drive access, that could potentially allow you to copy data still in RAM. If the OS simply instantly failed when the HD controller went, then any data in RAM would absolutely be lost.
:)). But most drivers wouldn't be that hard to restart... video and network are two very good examples. I have seen many 2.4 kernel crashes from what appeared to be network-driver failures. Presumably, a microkernel might have survived whatever the problem was.
:-)
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.
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. 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.
Oscar Sierra
I think his point is that:
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...
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.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
> 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.