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!'"
Except this one, of course.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
... if GNU/HURD comes out before Longhorn?
Maybe the second program should be a better web server.
/* oops I accidentally made a comment, sorry */
that 1st program wasn't a web server by any chance, was it?
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?
return 0; }
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."
Mach was still an active CMU project when the Hurd glacier began its very slow creep from the peaks of lofty idealism towards the throng of onlookers waiting patiently for the free unix kernel they always craved to reach them. I understand there are actually a few brave souls still standing there waiting.....
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.
.: Max Romantschuk
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
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.
Or they could decide to restart it.
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!
would it make any sense for Apple to look at L4?
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 Carbon libraries to run on it, and given the fact that OS X is now arguably the best OS out there and is earning heaps of praise from geeks, luddites, and just about every other type of user, and 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...
Given all those facts...
Whould it make sense for Apple to now completely rewrite it DOWN TO THE KERNEL LEVEL!!!
I really hope I don't have to answer that.
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 much time would it take to port it over ?
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows)
/. in 2006 doesn't have a new flame topic:
/. lips is, in regard to anything, when will HURD run Linux? ;-)
Courtesy of Gooooooogle
The thing is, GNU/HURD will still be... Linux. Don't shout, yes I know, the thing is, people call Linux, Linux.
Then people say, aaahaaaa Mr Bond... it is really GNU/Linux.
Well I am not so sure anymore. Debian think so, but why not call it GNU/Gimp/OOo/Java/Perl/apache/*all other installed apps*/Linux.
Is GNU software is great, and calling Linux+GNU 'Linux' is wrong, but calling any installation of the Linux kernel 'Linux' is correct regardless of other software.
If I call my OS Linux, I do so without reffering to the installed user space apps, however necessary they might be.
I think the person who is most keen to see HURD is Linus himself! After all, he has been waiting since 1990!
I do hope that
HURD v Linux (and HURD will never sell with that name - IMHO)
HURD running on top of the GNU Mach microkernel first booted in 1994 and became GNU's official kernel
The development of the GNU/Hurd has important emotional and practical value to GNU fans because in 1990s GNU had not completed any kernel and used the Linux kernel out of necessity. Thus, a number of GNU fans feel that they will have "pure GNU" only with the Hurd kernel.
I do think that some of the GNU ramblings are a bit ungrateful to Linux kernel. Without Linux it would be in 5 years that people would wake up to *nix OS's types, and in 5 years we would be where we were in 1994.
I see one thing, with the FUD over linux, will the same FUD establish itself over the huge sprawling software base of GNU?
Will GNUimp get sued by Adobe? How will this GNUism evolve?
And the final question on every
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
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.
A commercial company might take old code, given it a new name, and shipped it as a brand new thing. But GNU starts a brand-new, hot project based on better microkernel architecture and they use for it a name that people already associate with failure.
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.
Reminds me of the Dilbert comic strip ...
I've been boycotting Dilbert since its authors became BSA propaganda whores.
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.
Neat concept, but what if your graphics driver goes out?? Will it respawn automagically? Whaty if the hard drive controller's driver dies? Sometimes a neat concept ends up not being very practical. I would rather have the OS die if the hard drive controller's driver kicks off as there's less of a probablility of hard drive corruption. If the driver code for the hard drive dies and the kernel keeps running, would you not have lost alot data?
Gorkman
Look, congrats and all, but if I'm going to run a pointless operating system, it's going to be one that's actually impressive, like MenuetOS .
I may be out of date, but wasn't this Tannenbaum's contention: that microkernel was possibly superior to monolithic architecture because of the stability of the kernel space?
I'm a little excited by the possibility of a solid Open MK, but a little dismayed at the thought that I may have to re-read Tannenbaum and Wirth (Oberon Project) to figure out what's going on. Does anyone have a link to an overview/comparison of kernel architectures? If so, this old fart thanks you.
"The mind works quicker than you think!"
While there are many "dying" projects out there (remember the "Windows replacements OS" hype?), HURD has always had the most of critique, mainly because it embodied the very promise of a GNU system to many people in its days.
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.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
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.
On BeOS, when the sound subsystem crashed you would get a message informing you of this, and it would automatically attempt a restart. On Windows or Linux when the sound subsystem crashes, the odds are you've got a kernel panic (since the drivers run in kernel space).
I am TheRaven on Soylent News
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 kind of like a hack). For sysadmins there is much less privileged code to worry about. (There's lots more but those are the ones that spring to mind).
HAND.
Windows XP's kernel is a modified microkernel design. Most people are unaware of this, but it means that the vast majority of the code your applications call are also running in user space. For example, on Windows 64 machines, there's a Windows 64 environment, a Windows 32 (WoW64) environment, and so on. In the olden days, there were DOS VDMs, POSIX, and OS/2 sub-systems.
Not every Windows or Linux driver is kernel-space, but most are.
However, with adequate testing, crashes due to buggy drivers are rare. If you choose to run crap drivers, of course you'll see problems. Including on
Andrew van der Stock
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. :-)
You're describing the bootstrapping problem, which if I recall correctly is actually described on the GNU website, somewhere.
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.
When I read about projects like this I know it is being worked on by guys who are more interesting in writing code than finishing a project. That's great for them, kudos that they have spent over twenty years on the same basic idea, but what about the people who wanted to actually get some work done in that time frame. The hurd is interesting as an example of a micro-kernel - but I got MP3's to rip, video to encode, documents to write, emails to reply to and life to get on with. Let us all know in another 5 years when they have some useful code running on the hurd.
All those moments will be lost in time, like tears in rain.
The only module that was converged with the kernel was the graphics subsystem. The NT kernel still remains a microkernel design to this day.
guess nobody bothered to g**gle it: New kernel for Darwin:
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
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 by big corporations.
Looking with the benefit of hindsight, I'm willing to predict that HURD may become a viable OS, but it will never be very popular. It has been in existence for so long that it seems unlikely that it will gather momentum now. It may have some advantages, but it doesn't seem to be solving any pressing problem. Its defenders claim it has more stability, security, and flexibility than other systems, but these do not seem to be big problems with either Linux or OSX, so why switch?
Oh, I definitely never intended to imply that the HURD is stupid, not at all.
:-) And they are, from what I can see, treading very new ground, and that's always slow.
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 was its major source of revenue.
There's a huge amount of embecded knowledge on how PC hardware works buried in the Linux code, and rewriting that whole thing from scratch would be a gargantuan project. They've been working on it for, what, 11 years now? A total rewrite would take at least 3 or 4, during which all forward progress would stop. Just not a very good idea.
But I think it's great that the HURD is finally moving, at least a little bit. I will admit, I was a bit shocked that after roughly 15 years, they're just now able to load a program. But, hey, it's not like I needed it done last week or anything.
Reiterating: the more OSes, the better. I just don't think they should start over on Linux itself.
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.
it just took time to emerge
Damn, those Gentoo guys don't miss a beat, do they?
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?
an ill wind that blows no good
Hopefully I'll evolution to a being that uses HTML properly... dammit.
Post-rock/Ambient/Drone and other noise.
Funny... he's not going to miss you...
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.
I wish that my inferiority complex were as good as yours.
-RenderHead
So basically you're saying that All Slashdotters use Operating System XYZ and Browser ABC, except for when they don't. :P
:)
Your statistics have proven beyond a shadow of a doubt that, yes, we use computers and web browsers to view web sites.
Bravo
The kernel is not implemented as true microkernel. There is seperation, but the message passing is limited to IO request packets that are sent to and from the HAL from (properly written) drivers. The drivers run in the same thread but in a different execution context / ring (IIRC through a "door").
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.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
... and I was expecting "Hello world!"
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.
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". Yes, they're buggy to begin with, and they take the house down, so you fix them. If I understand it correctly, the HURD kernel would have a fixed driver interface (being in its own keyspace and all), and what would that get you? Buggy closed-source drivers. Exactly what Linus is against, and mostly for good reasons.
Kjella
Live today, because you never know what tomorrow brings
Yes, the BSA is making sure copyrights are respected, and that indirectly helps the open source licenses. But the BSA has been hostile to open source, and the more open source catches on, the more power the BSA loses.
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't matter.
Microkernels would be helped tremendously if 80x86 CPUs did not only have rings but also regions...because a faulty driver can write to anything inside its ring and lower-priviliged rings.
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
So in order for some piece of code in a certain page A to read from another page B, it should be that A.page_ring = A.read_ring. The same goes for write and execute access.
This mechanism has many advantages over the current one:
a) ring protection is per page and not per segment. Segments become totally irrelevant for protection.
b) there is no need for ring gates. A process in ring 3 can execute code of ring 0 if the kernel page allows it. There is also no need for special instructions like 'syscall'.
c) higher-privileged code can have const data be read from lower-privileged code.
d) device drivers can easily be isolated from the kernel.
e) there is no need for special 'virus' protectiobn bit, since executable code can have write ring set to 0 and execute ring to 3 (which means an application can not execute data).
These microkernels running services make much more sense on a processor with multiple cores - the main problem on a traditional "single-threaded" processor is there is way too much OS overhead 25-30% with the microkernel strategy, compared to a monolithic kernel. So in 5 to 10 years, as the HURD moves forward galacially like the plot to Dr. Who, this will be a good foundation for the new generation of processors.
"Mozilla" (Netscape) wasn't killed because of the rewrite. They were killed because version 4.7x sucked, and they couldn't compete with free as in beer.
The article isn't saying that they could only just now boot HURD, it is saying that they moved from the Mach microkernel to the L4 microkernel, and since the move they have just been able to run programs.
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.
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.
BSA tactics: you pay them or we hurt you financially.
Yes, the BSA is enforcing legal licenses (albeit, IMHO, draconian, and legal only under our current business-subservient patent system), but otherwise it really is the same thing. The mafia provided a service; a group of thugs wouldn't drop by and ruin your business. The BSA prevents a group of lawyers from stopping by and ruining your business.
The cost of litigation, even when you are in the right, is a far more dangerous weapon, in this business climate, than a baseball bat. A lawyer can impoverish you for years, a baseball bat is likely just to involve some transient pain and medical expenses.
... grumble, grumble, grumble, mutter, mutter, Millenium... Hand... Shrimp, I tol' 'em, I tol' 'em.
He's saying that he wants drivers that don't crash, but microkernels that allow crashing drivers to "just be restarted" lead to a permissive atmosphere, in which driver writers don't care if their drivers crash or not.
His contention is that in a situation where a crashing driver kills everything, driver writers are much more careful, and crashing drivers are not accepted by users.
Yes, there is a research proposal on the subject of creating a compatibility layer to run Linux drivers directly in HURD user-space. They are actually thinking about making that the default or using OS-kit or making their own driver infrustructure. I think in the end youll see both the Linux drivers and the OS-kit drivers with OS-kit being the perfered. But this is all from memory and I'm too lazy to look it up.
"We Don't Need No Truthless Heros!" - Project 86