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!'"

Comments

Dyu think Microsoft will ever live it down ...

[ggvaidya]

... if GNU/HURD comes out before Longhorn?

Re:Dyu think Microsoft will ever live it down ...

[typhoonius]

Mark my words, 2005 will be the year of HURD on the desktop.

Re:Dyu think Microsoft will ever live it down ...

[njvic]

Come on... Microsoft will never live up to HURD. Everybody knows it takes many Longhorns to make one HURD.

*ducks*

Re:Dyu think Microsoft will ever live it down ...

[djdavetrouble]

Mark my words, 2005 will be the year of HURD on the desktop.
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...

Mach Microkernel vs L4

[TangoCharlie]

What are the relative benefits of L4 vs the Mach Microkernel? Better performance? As I understand it, MacOS X's microkernel is also based on the Mach microkernel... would it make any sense for Apple to look at L4?

Re:Mach Microkernel vs L4

[Anonymous Coward]

Probably not. The Darwin kernel is really a monolithic layer over the top of a microkernel, not a proper microkernel system. Historically, at least, you gave up too much speed to do a proper microkernel, so monolithic kernels were de rigeur in any application outside the OS laboratory. Just because Darwin is written atop of Mach, it doesn't necessarily follow that Darwin uses a microkernel; and the design of Darwin is that of a monolithic kernel, not a microkernel.

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

[js7a]

L4 has only seven system calls, compared to several dozen in Mach. It fits in about 32KB, too, which is very much smaller than Mach.

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:

Kernels based on the L4 API are second-generation -kernels. They are very lean and feature fast, message-based, synchronous IPC, simple-to-use external paging mechanisms, and a security mechanism based on secure domains (tasks, clans and chiefs). The kernels try to implement only a minimal set of abstractions on which operating systems can be built flexibly.

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.

Re:Mach Microkernel vs L4

[joib]

This article explains the philosphy behind L4, and how it's different from Mach.

Re:Mach Microkernel vs L4

[Anonymous Coward]

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).

Re:Mach Microkernel vs L4

[bstone]

5% overhead for running a system that has all the features in reliability alone has got to be well worth it.

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).

Dilbert

[john-gal]

Reminds me of the Dilbert comic strip where an old man waves a piece of paper around and says "At last, I have formed a strategy that is acceptable to all departments. Now if only there were a way to reproduce text from one piece of paper to many."

Re:Mods...

[Anonymous Coward]

I'm guessing it will be more Daikatana than DNF.

Competition is a Good Thing

[Max Romantschuk]

The HURD kernel is often joked about, but I for one does hope that it will eventually become a viable alternative to the Linux kernel. Competition is seldom a bad thing, especially not among free software projects.

Re:Competition is a Good Thing

[Anonymous Coward]

So why not have the people working on Hurd work on something new instead, or work on improving Linux?

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:It hurds

[mirko]

The Hurd Project was started in 1983 (it's an instrumental featuring the speech where Stallman explained the origin of the GNU project).
Now, 22 years later, a definitve breakthrough has been performed.
I see this as an excitement :

1. They kept working on it THAT long despite slandering and scepticism such as yours
   
2. The rest of the software library (glib, bash, etc.) is already ready
   
3. With Linux, Hurd and BSD amongst others, we are slowly getting back to the same variety we had 20 years ago, when we had to exchange basic listings and to port these onto various platforms (Sinclair, Commodore, Amstrad, Sharp...)
   

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.

Re:It hurds

[Anonymous Coward]

Or they could decide to restart it.

Wikipedia link

[ceeam]

http://en.wikipedia.org/wiki/L4_microkernel_family

Well, it's not that much :)

[Leffe]

Let me quote from the l4-hurd mailing list (posted 02 feb):

At Wed, 02 Feb 2005 01:12:44 -0500,
"B. Douglas Hilton" wrote:
> So, how much longer before Python will build on L4-Hurd? :-)

If you mean "building" as in "compiling it", that should be possible as soon as we ported the dynamic linker, or at least made sure the dynamic linker "builds" (ie, "compiles"), if python can be cross-build.

If you mean "building" as in "compiles _and runs_", then we are talking about a much longer time-frame :)

With my glibc port, I can already build simple applications, but most won't run because they need a filesystem or other gimmicks (like, uhm,
fork and exec), and I only have stubs (dummy functions which always return an error) for that now.

So, for the time being, a measure of progress is what functionality is implemented: drivers, filesystem, signal processing, process
management, etc. Luckily, we have so much existing knowledge to draw from (the Hurd on Mach source code, for example), that I am carefully
optimistic that progress can kick in very quickly once we have sorted out some fundamental (low-level) design issues and got a sufficient
understanding of the details of the system.

Thanks,
Marcus

I might as well quote this too, which I think this story most likely refers to (posted on 27 jan~):

Hi,

with the changes of today, the glibc patch set in CVS supports startup and initialization up to the invocation of the main() function - this means important things like malloc() work.

Of course, there is a lot of cheating going on, and the implementation is full of gaps and stubs. But this step forward means that we can do
easy testing by just writing a program and linking it to glibc, and run it as the "bootstrap filesystem" server.

TLS/TSD seems to work without any problems - important things like the default locale are set up correctly, and thus strerror() works. __thread variables are supported, glibc uses them itself.

There were a couple of fixes and extensions needed in wortel and the startup code, but it wasn't so much. My understanding of the glibc code has reached an all-time high (not that this required much ;)

If you want to reproduce all this, you need to configure, make and install the software as usual. It is important that your compiler can find the installed header files afterwards! Only then you can reconfigure your source with "--enable-libc" and try to build the C library according to the README.

Static linking against this new libc should be possible after (manual) installation, I guess, but I always use a very hackisch and long gcc
command line to cheat myself into a binary that I can then use as "filesystem server" (the last one in the list) in the GRUB configuration. See the README for details.

I think that this basically concludes the first step of the initial bootstrap phase. By being able to link a program against glibc, and
by booting all the way up to that programs main() function, we can now easily explore and develop the system in any way we want.

The dinner is prepared! :)

Thanks,
Marcus

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 :)

[The_Dougster]

Wow, something I wrote actually trickled back into /. Amazing. I was just joking about Python, of course.

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 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.

Great

[Pan T. Hose]

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?

Re:Benchmarks?

[Anonymous Coward]

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.

Dilbert == BSA whore

[Anonymous Coward]

Reminds me of the Dilbert comic strip ...

I've been boycotting Dilbert since its authors became BSA propaganda whores.

Re:Dilbert == BSA whore

[dustmite]

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:Dilbert == BSA whore

[HuguesT]

Please think it through, Dilbert is right. How can you not support the BSA's actions ?

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

[ProfitElijah]

> 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

[AbbyNormal]

Have you ever received a letter from the BSA? Coinicidentally, we only received one after we let one of our MS action pack subscriptions lapse (but purchased another). In not so many words, they threatened with forcing us to prove we've destroyed our remaining unlicensed copies of software. Ironically on the same day, we received our renewal receipt for the Action Pack. You can imagine all the "warm and fuzzies" the BSA letter gave us.

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.

Re:Mods...

[Billly Gates]

I actually started the lame Duke Nukem posts as a joke, but oddly I had Mozilla mentioned as well. The netscape code finally after 2 years had to be deleted and rewritten.

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:Well worth the wait ...

[Mark_MF-WN]

HURD will never ever be where Linux is...

By that logic, no one should ever start a new software project that isn't already being met (however inadequately) by some other piece of software. Why did Linus start writing Gnu/Linux, when there were already great operating systems like Windows/Dos, and Unix/Unix?

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:Benchmarks?

[Malor]

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.

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 :)). 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.

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?

[lokedhs]

But they didn't go that way, and restarting Linux kernel development would be pretty stupid, IMO. :-)

In a way, you could see the new HURD to be a restart of the Linux kernel development. I.e. a new, better(?), kernel. And I wouldn't call it stupid, quite the contrary. New development is always good.

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:Let's see here

[ThousandStars]

Arguably, Apple took even longer, since it was looking at next-generation operating systems before Copland development actually started. In addition, NeXT began (IIRC) in 1986.

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.

Re:choose a new name for a new kernel

[Tumbleweed]

The L4Ka-based kernel is a new project that sounds like it has a lot of promise

I don't think something called "El Forka" sounds all that inspiring.

there is a research project to port darwin

[Anonymous Coward]

guess nobody bothered to g**gle it: New kernel for Darwin:

Apple's Darwin operating system is the open source base for Mac OS X. The underlying kernel is based on Mach. This project requires implementing a replacement for Mach based on the L4ka Pistachio kernel. Since ports of both exist on similar platforms (IA32 and PPC), most of this project will consist of building an emulation layer for Pistachio which can provide system call interfaces to match those provided by the existing kernel. In addition to implementation and testing, performance evaluation will be an important aspect of this project. Since part of the project is already done and the whole thing is quite large, an important aspect wiill be defining a doable subset, in conjuction with anyone doing part of it for BE. Starting early is advised on this project so no late applications will be considered.

Re:Let's see here

[Anonymous Coward]

given the fact that OS X represents the most compelling reason to switch to Apple computers in years, and given the fact that in just a few years the OS has amassed a compartively huge following of developers and applications...

Would it make sense for Apple to now completely rewrite it DOWN TO THE KERNEL LEVEL!!!

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.

Parent needs a glass hat

[QuietRiot]

It took Linux a long time to be recognized as a viable alternative to other Unices.

Your point? The world now knows there are viable alternatives, and they can be had for historical lows on price.

I don't think this can be easily done again.

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.

And I doubt that Hurd would have any noticeable advantages over Linux.

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.

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 ...

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

Re:More interested in development

[osierra.com]

This is best illustrated by the parable of the OSs and the gun:

• With Unix you shoot yourself in the foot.
• With DOS you keep running up against the one-bullet barrier.
• With MS-Windows the gun blows up in your hand.
• With MacOS it's easy to shoot yourself in the foot -- just point and shoot.
• With SVR4 the gun isn't compatible with your foot.
• With Linux generous programmers from around the world all join forces to help you shoot yourself in the foot for free.
• With HURD you'll be able to shoot yourself in the foot Real Soon Now.

Re:Benchmarks?

[Rich0]

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...

Re:Dilbert is bad, very bad.

[MightyYar]

This is one of those pieces of writing that is becoming more common today - where a large part of the article is dedicated to some supposed grievous omission in a body of work. Can you imagine being judged on what you hadn't done? From the article:

Major Issues That Dilbert Rarely or Never Addresses, Although It Certainly Could:

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...

Export of jobs to cheap labor markets

Is this guy serious? Hello, Elbonia???? He has clearly not read much of the strip.

* Union-busing * Corporate Welfare * Repetitive stress injuries, exposure to chemicals and other work-related hazards

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.

* Sexual harassment * The glass ceiling for women * Planned obsolescence

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.

* Cost-benefit analysis defining a finite number of workplace injuries or deaths as acceptable * Pension fund fraud * Tax abatements and subsidies for unnecessary projects

Jeese... again, just not funny material here. Also, not something that most cube-dwellers will run into except in the newspaper.

* Blue-collar workers who actually make the stuff that Dilbert designs -- people who, incidentally, face many of the same problems he does, and with far less ability to do anything about it

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.

Re:It hurds

[halivar]

it just took time to emerge

Damn, those Gentoo guys don't miss a beat, do they?