Submitted by Torvalds has indeed chimed in on the micro vs. monolithic kernel debate. Going all 1992, he says: “The whole ‘microkernels are simpler’ argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. The whole argument that microkernels are somehow ‘more secure’ or ‘more stable’ is also total crap. The fact that each individual piece is simple and secure does not make
the aggregate either simple or secure. And the argument that you can ‘just reload’ a failed service and not take the whole system down is equally flawed.” My take: While I am not qualified to reply to Linus, there is one thing I want to say: just because it is difficult to program, does not make it the worse design.
Is a tradition Eugenia need not have started.
At least he’s stopped saying ‘boys and girls’
Totally agree: unless it’s strictly necessary, it would be better to leave these kind of comments on the comment section as everyone else. Putting it as “my take” looks as if the writer is trying to push his personal opinion down the reader’s throat.
Putting it as “my take” looks as if the writer is trying to push his personal opinion down the reader’s throat.
I don’t really see anything wrong with editorial content, in fact that’s the primary reason I read sites like Ars Technica – to get the insight/opinions of people who are much better informed than I.
I will agree that in the past, the “My take:” schtick on OSNews has seemed like a cynical attempt to take a contrarian position and fire people up in the comments area. In this case, though, Thom’s comment is pretty reasonable, even if you don’t agree with his opinion.
just because it is difficult to program, does not make it the worse design.
Or at least get a clue as to what makes one design better than another.
There exists an easy way to have modules within the same address space that can not destroy each other. The Motorola 68020 had a CALLM instruction for that purpose. It is amazing that CPU manufacturers have not used it in modern CPUs.
The solution is very simple: an inter-module call saves the current module id on the stack and loads a new module id from the destination. If the new module id is invalid or inaccessible, an exception occurs. Otherwise, execution continues with the new module as the current module. Local module calls can only operate within the memory space defined by the current module descriptor.
Is a tradition Eugenia need not have started.
I disagree. I enjoy getting the opinion of the people who post these articles. I think they are very knowledgeable in the OS arena or they wouldn’t be editors here. As a very busy person, it helps me decide whether or not I even want to pursue the topic further. Otherwise, you must think these editors are just link monkeys out crawling the web. I think they are more than that. Everybody is _so touchy_ these days.
My take: While I am not qualified to reply to Linus, there is one thing I want to say: just because it is difficult to program, does not make it the worse design.
Linus answered your own question in that paragraph:
“…whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. The whole argument that microkernels are somehow ‘more secure’ or ‘more stable’ is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure. And the argument that you can ‘just reload’ a failed service and not take the whole system down is equally flawed.”
Basically, you get something far slower for extremely negligible gains is what he’s saying there. Ergo – the worse design.
Edited 2006-05-09 21:59
The fact that each individual piece is simple and secure does not make the aggregate either simple or secure.
This is true only of algorithmic software. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. Why? Because this is the same model used by electronic logic circuits.
Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear.
Again.. asked and answered.
“So while UNIX people use pipelines for a lot of important things, and will absolutely swear by the “many small and independent tools”, there are also situations where pipelines will not be used.
You wouldn’t do a database using a set of pipes, would you? It’s not very efficient, and it’s no longer a simple flow of information. You push structured data around, and you very much will want to access the database directly (with a very advanced caching mapping system) because not doing so would be deadly.
The point he seems to be making is that not everything works well through streams of data and message passing. Some things need locks and shared data structures. Every “Hybrid” kernel out there has found that to get the basic functionality of a kernel working you need to break down the walls of the microkernel and let different sections share data. By his definition these aren’t microkernels. The shared data structures (and therefor shared address spaces) makes them monolythic.
I honestly don’t know enough about OS design to weigh in intelligently on the subject.
Microkernels are like communism.
Great idea on paper, but basically impossible to succesfully implement for a plethora of reasons.
I wouldn’t call communism a good idea on paper.
Compare microkernels with anarchy instead. That’s closer. Both great ideas, but if they are to be implemented cleanly they won’t work. Compromises are necessary for both ideas.
Most kernels today, including linux, are hybrid kernels. And for a good reason.
Hey, I agree with you!
I do think all modern operating systems should indeed be using a hybrid kernel. Certain aspects are suited to be monolithic and certain modularized. To think everything can be lumped under one methodology is myopic.
“Great idea on paper, but basically impossible to succesfully implement for a plethora of reasons.”
This comment is not true; see the performance of the L4::Pistachio microkernel… some system calls in that system are performed as faster as in Linux.
See L4, is a good example of a good design and implementation of a microkernel.
http://www.l4ka.org
I’ll wait until that kernel is used for anything besides saying “Wow, cool it’s a microkernel.”
Until that point, it might as well be Minix.
You are basically saying that because Linux is more mature, the general concepts are more sound.
Why not go a step further and declare MS Windows the best Operating System EVER!
Why not go a step further and declare MS Windows the best Operating System EVER!
It is! Just ask Microsoft. As one of the most successful software companies on the planet, they must be right.
Right?
My apologies for not including a large red sign warning “sarcasm”. I guess the moderators didn’t get it. 🙂
I think his point is that it’s not tested in the real world, like say the linux kernel. Until then, you can’t truly judge how good it is.
Now, I don’t know whether or not it is actually used out in the wild heavily, so his point could be moot.
People always make the ‘looks good on paper’ argument with Communism when it holds true for any ideology.
Maybe what’s at fault with Linux here isn’t a technical matter but rather the failure to manage a proper development process.
Books have been written on how to mimick the linux development process because it has proved so effective at producing reliable and flexible code quickly.
Don’t go dissing it without backing it up. Also, the term “proper” here brings up some connotations which won’t make people want to listen to your ideas
.
These people either got their brains washed or they have no idea of their own at all.
“Microkernels are like communism.”
Indeed, just as GNU …
I like whats best for me. If that so happens to be a microkernel then so be it.
This is why we have competition, but I mean if they are truly better I am still confused as to why they are not prevelant among all the OS’s!
Anyhoo, Communism does not even look good on paper. Why would you say that? I think especially that part where you don’t own anything, oh and that whole part where it goes against human nature.
Wouldn’t it be awsome to actually here linus talk though? I could imagine it now… THATS BULL!
“Anybody who has ever done distributed programming should
know by now that when one node goes down, often the rest
comes down too. It’s not always true (but neither is it
always true that a crash in a kernel driver would bring
the whole system down for a monolithic kernel), but it’s
true enough if there is any kind of mutual dependencies,
and coherency issues.”
There are two kinds of distributed programming, cooperative and competitive. When a cooperative worker goes down, typically, the whole project goes down. When a worker in a competitive program goes down, a competitor picks up the load.
Distributed.net and seti@home are examples of robust distributed computing. So’s bittorrent, although of a different model.
To be honest, it sounds like an argument of abstraction. Monolithic kernels have everything programmed together in one jumbled mess. Microkernels section things off and use ways of communicating the relavant things between different parts. For me, this whole argument has always come down to abstraction. Abstraction does use additional resources, but I, personally, believe it yields better results in the long run. Linus is an exceedingly gifted programmer, but I have to disagree with his view here.
Abstraction does use additional resources, but I, personally, believe it yields better results in the long run.
Nope. Read it more carefuly. This has nothing to do with abstraction. The problem is that mikrokernel forces you to program almost EVERYTHING as distributed algorithm – that is way harder and way more complex.
You may have noticed complaints about how hard it to write multithreaded programs that use those fancy dualcore CPUs. Now complex distributed code is order of magnitude harder to write and maintain than that.
And at the end of process, you will end with slow and unreliable monster.
Edited 2006-05-09 21:59
Nope. Read it more carefuly. This has nothing to do with abstraction. The problem is that mikrokernel forces you to program almost EVERYTHING as distributed algorithm – that is way harder and way more complex.
Huh? Microkernels are basically extremely small kernels that facilitate message passing and basic hardware abstraction, and delegate everything else to user-space.
Think about the relationship between Linux and X.org (or Linux and SANE), and then imaging more X.orgs for sound, networking, etc. Then extend it a bit more so there’s an X.org for the VM another for the scheduler.
Imagine they all communicate using a specific messaging system. That’s a microkernel. It has got absolutely nothing to do with multi-threading.
Inded, every kernel, regardless of how it’s designed, has to deal with loads of non-trivial concurrency issues (in particular race-conditions).
Edited 2006-05-09 22:43
Huh? Microkernels are basically extremely small kernels that facilitate message passing and basic hardware abstraction, and delegate everything else to user-space.
Well, one thing has to be said: whereas we are speaking about “microkernel”, we should rather be speaking about “microkernel based OS” – with all services included.
Sure, microkernel itself can be pretty simple. However, microkernel based OS will most likely be much more complex than equivalent monolitic OS.
Think about the relationship between Linux and X.org (or Linux and SANE), and then imaging more X.orgs for sound, networking, etc. Then extend it a bit more so there’s an X.org for the VM another for the scheduler.
Yes, exactly. As I have a lot of experiences with low-level X11 programming and its asynchronous nature, I must say that idea of implementing VM or scheduler as message driven service seems to me pretty horrible.
Edited 2006-05-09 22:58
Sorry, I thought you were saying the problem was that they were multi-threaded (the dual-core thing threw me off).
The problem is that mikrokernel forces you to program almost EVERYTHING as distributed algorithm – that is way harder and way more complex.
You have NO idea what you’re talking about.
>it yields better results in the long run.
Perhaps, but when?
Not yet: MacOS X show that a micro-kernel can give poor performance (normal it has Mach underneath) if usable, can it provide fault tolerance to faulty drivers? Is-it more stable than say Solaris?
Mmm, I don’t think so. So while advantage of micro-kernels are not so easy to get, the inconvenients are real.
Having to do lots of research to get ‘not too ugly’ performances is good for academics but for the other..
Some other micro-kernels have better performances than Mach (if still slower than monolithic kernels), but apparently their theoretical supeority isn’t a good enough argument for FOSS developpers to dump existing monolithic kernels to work on them..
Sure there are some commercial niche player with very good muk, but as evidenced by their niche status, having a muk is not in itself a killer feature in general.
Monolithic kernels have everything programmed together in one jumbled mess.
No, they don’t. Monolithic kernels are just as modular as microkernels. The difference is that monolithic kernels integrate drivers into their address space, whereas micro-kernels don’t. This keeps micro-kernels safe from coding errors (e.g. buffer overflows), but not semantic errors
Micro-kernels still have issues: what do you do if the scheduler server dies? Sure you can restart it, but you’ll have lost track of the state of every running process. What happens if a file-system driver dies: when you restart it, can you be sure all existing system calls will be completed; if they’re not, will that affect stability?
Furthermore, it is possible to sandbox device drivers in a monolithic kernel, using certain API constructs, giving them most of the benefits of microkernels: one example of this is the Nooks project.
To be honest, it sounds like an argument of abstraction.
It’s not, it’s about enforcing policy. Both monolithic kernels and micro-kernels have similar designs: both are usually quite abstracted and modular as it’s the only way to manage a large and complicated piece of software like an OS kernel. The difference is that a microkernel puts in place special code to enforce that policy.
However this code almost always has severe performance penalties; only one major operating system thus far – QNX – has managed to pull it off without sacrificing efficiency Given that monolithic kernels can be just as modular as microkernels, and can insulate drivers as well as microkernels, the enormous amount of extra work required to implement an interface between kernel and userland simply isn’t warranted.
The only exception to this is possible security orientated operating systems. Here, the separation of policy is important enough to sacrifice performance / put in the extra work.
Edited 2006-05-09 22:45
only one major operating system thus far – QNX – has managed to pull it off without sacrificing efficiency
I daresay the Amiga microkernel-based OS was pretty efficient
I daresay the Amiga microkernel-based OS was pretty efficient
I daresay that Amiga hardware was not capable of memory isolation, therefore could not have the real microkernel….
Edited 2006-05-09 22:55
From http://en.wikipedia.org/wiki/AmigaOS
Technical Overview
The main modularisation technique in AmigaOS is based on dynamically-loaded shared libraries, either stored as a file on disk with a “.library” filename extension, or stored in the Kickstart ROM. All libraries are accessed via an indirect jump table, which is always stored in RAM. That way, every library function can be patched or hooked at run-time, even if the library is stored in ROM.
The most important library in AmigaOS is exec.library, which is actually a microkernel as well as a library. As well as pre-emptive multi-tasking and access to other libraries, it provides high-level inter-process communication via message passing. (Other microkernels have had performance problems because of the need to copy messages between address spaces. Since the Amiga has only one address space, Exec message passing is quite efficient.)
The most important library in AmigaOS is exec.library, which is actually a microkernel as well as a library. As well as pre-emptive multi-tasking and access to other libraries, it provides high-level inter-process communication via message passing.
Indeed, but beeing more exact they should have said that Amiga Operating System is a hybrid mixing two ideas: of a microkernel and of an exokernel.
The AmigaOS was very slick how ever the hardware and 680×0 CPUs and motherboard chips at that time rather limited in supporting this elegant design.
How about the new Amiga OS 4, will this extend the OS and maintain it as a microkernel / exokernel ?
The most important library in AmigaOS is exec.library, which is actually a microkernel as well as a library.
Argh, it is so anoying! 20 years have passed and that technology is still kicking our ass.
I know! Just imagine what could have happened if Commodore had opened the platform! Apple might have been a distant memory.
Would the US Navy have sued Commode for using a military rank as a tradename, though?
Monolithic kernels are just as modular as microkernels.
Ok, Can i use dynamically loadable 2.14 driver on 2.16 kernel?
http://www.linux-ntfs.org/content/view/187/
2.6.16-1.2111_FC5
2.6.16-1.2107_FC5
2.6.16-1.2096_FC5
2.6.16-1.2080_FC5
2.6.15-1.2054_FC5
These guys have a compiled driver for every kernel revision.
This is an absolute nonsense.
Doesn’t it make sense to have only latest version if you said what linux is modular?
AmigaOs inspired OS-es are truly modular and have a lighting fast message passing. Of course it lacks memory protection, but there are 3 ways: 64bit protection domains or the “Singularity” approarch with safe languages or both at the same time.
I’d suggest you do some reading about Linux’ CONFIG_MODVERSIONS and what it means before writing such complete nonsense.
“7. Module versioning
Module versioning is enabled by the CONFIG_MODVERSIONS tag.
Module versioning is used as a simple ABI consistency check. The Module
versioning creates a CRC value of the full prototype for an exported symbol and
when a module is loaded/used then the CRC values contained in the kernel are
compared with similar values in the module. If they are not equal then the kernel refuses to load the module.”
Fedora is compiled with CONFIG_MODVERSION=y by default, forcing all external modules to be recompiled to match the -exact- kernel version used.
G.
Ok, Can i use dynamically loadable 2.14 driver on 2.16 kernel?
A. This has nothing to do with Micro vs. Monolithic kernel debate; if anything, it shows you lack of understanding what debate is all about.
B. The reason you won’t be able to load 2.4 drivers on a 2.6 kernel is simple: ABI changes. If micro-kernel X has changed its kernel-land to user-land interface between version 1.0 to version 2.0, a 1.0 driver will be just as incompatible as 2.4 drivers are today.
Eeek… Edit doesn’t work. Sorry for the bold.
A. This has nothing to do with Micro vs. Monolithic kernel debate
True microkernel OS is modular.
True monolithic OS is not modular. It is a tight, heavily tuned piece of code.
I didn’t said i’m a linux expert. But i have little experience with fedora5 and gentoo. What i see from the user point of view is what linux modularity is a kind of hack.
B. The reason you won’t be able to load 2.4 drivers on a 2.6 kernel is simple: ABI changes
Serious ABI change in not backward-compatible way is a mostly clinical issue. Probably they should do it in next “major” version, but not the “minor” version.
Well, i don’t care how linux versions are called since this is not my OS of choice.
Sorry if i insulted your feelings or whatever =]
… You didn’t insult me. Your comment was just, err, out of place.
“Monolithic kernels have everything programmed together in one jumbled mess.”
why is it “jumbled”?
why is it a “mess”?
have you ever read the kernel source code?
I don’t know if Linus means to say that monolithic designs are better than modular / component based designs (not just for the OS, but all applications), but I certainly can’t agree with the idea that monolithic designs in general are better at all.
If that’s what he does mean, than one can only assume he isn’t particularly fond of OO-design, which is pretty much universally regarded as a Good Thing.
there is a reason why much of the core code of the linux kernel is written in C rather then C++
and i think the stance on OO is that while its a good thing as you get stuff like code reuse and similar, it adds a whole lot of complexitys on top. and those complexitys have a bad habbit of adding up as the project grows.
Edited 2006-05-10 08:10
Except that many use oo to handle complexity.
“there is a reason why much of the core code of the linux kernel is written in C rather then C++
”
Yeah, and the reason is that most people don’t know C++ or have stupid preconceptions against it. Just read the thread where Linus says he’s against C++ in the kernel.
“there is a reason why much of the core code of the linux kernel is written in C rather then C++
”
Yeah, and the reason is that most people don’t know C++ or have stupid preconceptions against it. Just read the thread where Linus says he’s against C++ in the kernel.
Unfortunately, when you rely on volunteers, and you don’t have an actual architect, the best thing you can do is pick a simple easy to understand language.
The history of object oriented programming is strewn with the corpses of failed attempts at operating systems, both commercial (Apple’s) and academic (Clouds) precisely because people, including those who are quite expert at the language, don’t really understand C++.
(At this point in history, I believe it is safe to say that Andy Koenig, and, possibly, Alex Stepanov, are the only people who _really_ understand C++)
> To be honest, it sounds like an argument of abstraction.
> Monolithic kernels have everything programmed together
> in one jumbled mess. Microkernels section things off
> and use ways of communicating the relavant things
> between different parts.
That is a misconception then. Monolithic kernels do use simple well defined abstractions and they are split into functionally separate components. The difference is, monolithic kernel uses direct function calls instead of messaging.
With a true microkernel there is a speed hit taken in message passing etc.
The is really no need to place /everything/ in user space.
With that said, the solution seems to be more in line with what OSX, NT, and maybe even Linux do today.
Not all the functions need to be compiled directly into the kernel. Some things can be loaded as “modules” while things like memory management, disk i/o etc. are all in “Monolithic” type kernel to eliminate some of the overhead of message passing.
“Is a tradition Eugenia need not have started.”
haha, that’s hilarious. I wish I had mod points to bring that out of the depths of -5 land, but I do not. Maybe I would have more mod points if I posted more of what people want to hear rather than what I think.
Thom tolerates no criticism.
I think it’s pretty clear who won this argument the first time, and it will be the same this time – Monolithic kernels will continue to be the status quo for a while, and hybrid kernels will continue to either be monolithic-leaning or a fair mix. The reason that I doubt that Torvalds would be wrong is the incredulous statements made by microkernel supporters: “Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.”
“Making software free, but only for folks with enough money to buy first class hardware is an interesting concept.”
Last time I checked, most of us were running x86, or possibly PPC, boxen. Linux can be used on hardware at least a decade old. Constantly, the reasons for using microkernels are being withered away, and between reasoning like segedunum’s and Linus’, there seems to be no need for a non-monolithic kernel unless it’s a niche application.
He can rub people up the wrong way at times, but you’ve got to admire him for his plain speaking and speaking his mind. Some of this stuff made me laugh:
“And anybody who tells you that distributed algorithms are “simpler” is just so full of sh*t that it’s not even funny.”
“As to the whole “hybrid kernel” thing – it’s just marketing. It’s “oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let’s use a cool name and try to imply that it has all the PR advantages that that other system has”
This has happened with Windows in many ways. The whole userspace audio thing in Vista was just a PR response where they’ll say something like “Making our systems more robust, resilient and fault tolerant”. In the next version of Windows things will probably get brought back into the kernel “For the purposes of maximising performance for customer benefit”. You just can’t win with it. It’s all fluff.
Stole my thunder! I was about to ask Linux to tell us what he REALLY thinks! 🙂
ask the kernel? and do kernel’s have gender’s?
Kernels have feelings, too (but perhaps not genders) 😉
If kernels have no genders I cannot understand how come we ended up with “Hybrid” Kernels…
Gee… Kernel sex is a strange concept…
If kernels DO have genders, do microkernels get PMS?
This has happened with Windows in many ways. The whole userspace audio thing in Vista was just a PR response where they’ll say something like “Making our systems more robust, resilient and fault tolerant”. In the next version of Windows things will probably get brought back into the kernel “For the purposes of maximising performance for customer benefit”. You just can’t win with it. It’s all fluff.
What they did in windows vista was not to move audio divers to userspace, but move parts of the audio stack which were in kernel space even if they shouldn’t, to userspace. Software mixing, etc – real drivers keep in kernelspace. Basically, they had too much crap in the kernel (the libalsa equivalent) and they’re moving it back to userspace. Which is a good thing, BTW
In my opinion Linus was just at the right place at the right time. Tell me again: What is so fantastic about Linux as a kernel?
(1) It works.
(2) It’s free (both libre and gratis)
(3) There aren’t many other alternatives which fit #1 and #2.
I fully agree with Linus – it’s like you’d take ej: a gnome app (evolution) and instead of taking all the libraries and putting everything in a single adress space to run it, you’d run a “gtk server”, a “glib server”, a “fontconfig server”, a “libpng server”…it’s the same concept but applied to userspace (and if userspace continues increasing the complexity some people suffering from microkernelitis will advocate this model for userspace)
Microkernels are a extreme: “put everything in separate address spaces”. Or IOW: Make real the isolation concepto from OO programming. Like most of extremisms, it doesn’t works well in practice. In practice, the best thing to do is to do whatever it has sense in a given moment – like when the USB printer drivers were moved from the kernel to userspace (via libusb)
I fully agree with Linus – it’s like you’d take ej: a gnome app (evolution) and instead of taking all the libraries and putting everything in a single adress space to run it, you’d run a “gtk server”, a “glib server”, a “fontconfig server”, a “libpng server”…it’s the same concept but applied to userspace (and if userspace continues increasing the complexity some people suffering from microkernelitis will advocate this model for userspace)
I disagree. Yes, it is stupid just to have things modularised for he sake of modularisation, but if one were to seperate Evolution into the front and back ends, the back end datastore can be used in other applications, in terms of retrieving information etc.
Having seperate ‘daemons’ for taking care of things is ok, but it starts to become stupid when it gets to the point that something is done a certain way, not because it’ll yield better performance or reliability (or both), but “well, I’ve done the rest of the system like that.
Just to let you know, it is already like that. Evolution is the frontend, and eds (Evolution Data Store) is the backend.
You can interact with eds with different fontends (such as the clock/calendar applet of the gnome panel, the lightweight Dates and Contacts apps, and all the “addressbook aware” apps that are around).
Besides, there exist a “gtk server” project, that creates the guis on the fly based on client requests. It’s not much used, though.
“My take: While I am not qualified to reply to Linus, there is one thing I want to say: just because it is difficult to program, does not make it the worse design.”
A design is the structure of a solution which is to be implemented, or created and finished. The micro-kernel is a bad design, as your rate to completion is significantly slowed due to strict adherence to the u-kernel philosophy. Also look at the empirical data. Where are the ubber u-kernels? Why do the majority of modern OSs use monolithic kernels?
“Why do the majority of modern OSs use monolithic kernels?”
Ehm, Rashid was the chief developer of Mach microkernel. Now is the chief developer of Windows kernel (that is an hybrid monolithic kernel with elements of microkernel).
The vice of Rashid was Tevanian. Avie was the chief developer of Next kernel, XNU and Apple Darwin (an hybrid microkernel with elements monolithic kernel).
In fact, the 97% of the world installed base are partialy microkernel…
I think the real question is: “Why do the majority of modern OSs don’t use pure micro- or monolithic kernels?”
Buddha said: the truth is in the middle. (I’m not buddhist! :-D)
Ehm, Rashid was the chief developer of Mach microkernel.
He was the faculty member under whom much of the Mach work was done as graduate research.
Now is the chief developer of Windows kernel (that is an hybrid monolithic kernel with elements of microkernel).
No. He’s senior vice president of research at microsoft. Rick’s never been directly involved in Windows development.
The vice of Rashid was Tevanian. Avie was the chief developer of Next kernel, XNU and Apple Darwin (an hybrid microkernel with elements monolithic kernel).
You should read Wilkes and Sears comments on Avia’s work on Mach memory management. You would find it interesting.
In fact, the 97% of the world installed base are partialy microkernel…
No. Just because you draw a box around your vm and scheduler and label that box “microkernel” does not mean that you have a microkernel implementation.
Press claims to the contrary, Windows/NT is not a microkernel based OS. Neither is Linux. Mach was, and I suppose Darwin is. (I’m too lazy to look at the Darwin source code.) That’s pretty much it in desktop OS land.
How can you say that microkernel is a bad design??
Simple, clean, modular and extensible design are the base of all the huge software applications we have.
Microkernel has all that features built-in by design, turning the operating system in a “module loader” and a communication proxy between them.
The microkernel possibilities and capabilities are higher than the monolithic kernel’s.
Examples: L4Linux paravirtualization; several “OS personalities” running in the same machine, etc.
Yeah, those are true in theory.
There’s a “thin” line between designing well and overdesigning.
That line happens when the time to code the design is comparable to the expiration time for the software.
Kernels are something of a “we need it now not next decade” piece of software.
I think what’s said about modularity and plugin is only true at the higher level.
Firefox plugin works b/c it’s at the highest level. There is little or no distributed interactions between them.
Take the plugin a few levels down and have it all interact with each other and you have a mess. That’s a reason that general OS concepts are taught in the first OS course while distributed OS concepts are taught in the 2nd higher level OS course.
It’s because distributed systems introduce a number of newer problems. Microkernel essentially builds a distributed system on top of the microkernel. Considering that software lies on top of that – you have a distributed system on top of a distributed system. The complexity of something like that makes my head spin. That’s what Linus mean by microkernel being totally impractical when you get down to use the concepts.
Linus may know Linux but he does not understand the hidden nature of software. If he did, he would know that basing software construction on the algorithm is the real reason for the current crisis. Switch to a signal-based, synchronous software model and the problem would disappear. Of course, in such an environment, every application becomes a simple extension of the system and there is no operating system per se.
We need to start seeing a program for what it really is, a communication system. During execution, every statement or instruction in an algorithmic procedure essentially sends a signal to the next statement, saying: ‘I’m done, now it’s your turn.’ A statement should be seen as an elementary object having a single input and a single output. It waits for an input signal, does something, and then sends an output signal to the next object. Multiple objects are linked together to form a one-dimensional (single path) sequential chain. The problem is that, in an algorithm, communication is limited to only two objects at a time, a sender and a receiver. Consequently, even though there may be forks (conditional branches) along the way, a signal may only take one path at a time.
This is one of the reasons that we need to move to a signal-based synchronous, signal-based model.
ROTFL.
So why wasn’t this:
http://www.rebelscience.org/Cosas/COSA.htm
accomplished anything?
Freaking washed-up, rehashed, neural network AI people.
pffft.
The best quote:
“What follows is a list of prominent individuals that I consider to be the real enemies of reliable software even though they all profess otherwise. These people are doing the computer industry and the world a great disservice. They are using their positions of authority to perpetuate a myth, and a very harmful myth at that. They have built a personality cult around [Frederick] Brooks and his fallacious doctrine just as they have done with Alan Turing over the years.”
well, gee, the damn Turing guy and his machines. If it wasn’t for him, all our software would rock!
ahahaha… Thanks. Any publicity is good publicity.
You may mock signal-based programming, but why don’t you try writing some examples yourself in an imaginary language and see the benefits? application writing becomes much easier with signal-based programming.
I admit the guys at rebelscience.org are a little over-the-top concerning the rest of their stuff, but I can not say that they haven’t hit the nail in the head with the signal-based programming model.
Where can I find more on this technique?
Why an imaginary language? Is it natural and easy to do in standard languages like C or even Object Oriented languages like C++, Python or Ruby without having to follow difficult to follow rules etc?
Is there a language out there that does this naturally if it is so greatly advantageous to program that way?
Where can I find more on this technique?
There are several existing synchronous reactive programming languages out there such as Esterel and Signal. However, they do not go far enough, that is, they do not go to the individual instruction level like the COSA model. COSA also introduces several innovations not found elsewhere such as the automatic resolution of data and event dependencies.
The only problem is that current CPUs are optimized for the algorithm and a true signal-based environment like COSA would suffer a performance hit. My hope is that this will change soon because this is the future of computing. There is no escaping it. We’ve been doing wrong from the beginning but it’s never too late to change.
Can you recommend any good online information on this signal based programming in relation to the algorithm based one?
I’m interested in what you’re saying but certainly not convinced.
I checked that COSA website posted somewhere earlier. It doesn’t well describe what this signal based system is for us 99.999% normal programmers. It talks a lot about Oh how wonderful it is and what the ultimate result is supposed to be in terms of reliability etc but nothing else.
Maybe I gotta dig deep and look for some documentation or something. Is it possible to provide good links to technical and detailed stuff etc? Thanks if so!
Can you recommend any good online information on this signal based programming in relation to the algorithm based one?
Ultimately, COSA development will be done using a graphical/visual environment. Some of us are discussing the initial implementation of a COSA language of sorts that can be used to demo COSA’s capabilities. For now, just read the following pages. It should give you a fairly good idea regarding what COSA programming is about.
Software Composition in COSA
http://www.rebelscience.org/Cosas/components.htm
Operating System:
http://www.rebelscience.org/Cosas/System.htm
I admit the guys at rebelscience.org are a little over-the-top concerning the rest of their stuff, but I can not say that they haven’t hit the nail in the head with the signal-based programming model.
I can. They’ve made the same mistake Brad Cox made when he invented objective-C. Software is not like hardware for a lot of reasons.
But here’s a typical comment from the rebelscience site:
Unfortunately for the world, it did not occur to early computer scientists that a program is, at its core, a tightly integrated collection of communicating entities interacting with each other and with their environment. As a result, the computer industry had no choice but to embrace a method of software construction that sees the computer simply as a tool for the execution of instruction sequences.
I suggest the author read Minsky’s early work. “signal-based” programming is the Nth in an infinite series of attempts to model the asynchronous processes that make up software as if they were synchronous. It is doomed to the same failure of all such attempts.
The closest anyone’s gotten to a workable synchronous model was Tony Hoare, with Communicating Sequential Processes. (CSP).
I suggest the author read Minsky’s early work. “signal-based” programming is the Nth in an infinite series of attempts to model the asynchronous processes that make up software as if they were synchronous. It is doomed to the same failure of all such attempts.
This makes no sense, IMO. Synchronous, signal-based applications abound. There are spiking (pulsed) neural networks, spreadsheet cells, etc… all over the place and they work perfectly.
> This makes no sense, IMO. Synchronous, signal-based applications abound. There are spiking (pulsed) neural networks, spreadsheet cells, etc… all over the place and they work perfectly.
You fail to understand the following: there is no “one size fits all” solution to every imaginable engineering problem. Synchronous programming languages are great to solve certain classes of problems, as do functional languages, imperative languages, logic languages, declarative languages, etc.
It’s OK to be excited about a cool technology; just keep in mind it won’t bring world peace (nor automagically solve all software reliability problems).
The best way to obtain software quality is to put the right tools for the job in the hands of open-minded people.
You fail to understand the following: there is no “one size fits all” solution to every imaginable engineering problem. Synchronous programming languages are great to solve certain classes of problems, as do functional languages, imperative languages, logic languages, declarative languages, etc.
Actually all languages are equal and they can solve the same problems, and this is already proven. Programming languages differ at the degree of easiness to solve a problem, but signal-based programming goes above all these models, because it is a modelling technique that reflects reality so well that it becomes very easy to solve most, if not all, problems.
All the other programming models are used to emulate signal-based programming. Most programs are a bunch of signals (gui or other type events) and responses. Even functional programs are.
Actually all languages are equal and they can solve the same problems, and this is already proven.
Turing equivalence is not equality. Syntactic sugar matters, which is why some languages are more suitable to certain problems than others. (Otherwise, we’d simply program Turing machines directly.)
While it is true that computation consists of communication and transformation, it is not true that such is synchronous.
The best way to obtain software quality is to put the right tools for the job in the hands of open-minded people.
This is the often repeated argument from people who are used to think in terms of the only software model they know, the algorithmic model: multiple tools for different jobs. This is precisely why algorithmic programming is flawed. It demands a plularity of tools, hence the current mess.
Programming will not come of age until a single software model and development method is used universally. This is not currently the case because we are doing the wrong way. The truth is that, once one understands the true nature of computing (it’s all about communication between sensors and effectors), one realizes that the signal-based synchronous approach is the only way to do things. There is nothing that can be done the old ways that cannot be done better and more reliably with the signal-based model.
Edited 2006-05-10 19:01
> This is the often repeated argument from people who are used to think in terms of the only software model they know, the algorithmic model: multiple tools for different jobs.
Blah.
I’m used to think in terms of whatever abstraction fits the job; i.e. with signals when I am developing reactive systems, with functions and trees when I am writing Lisp code and so on.
Electrical engineers, too, do use a lot of intellectual tools to do their job. They don’t use an all-encompassing, unique tool to solve any EE problem.
Programming will not come of age until a single software model and development method is used universally. This is not currently the case because we are doing the wrong way. The truth is that, once one understands the true nature of computing (it’s all about communication between sensors and effectors), one realizes that the signal-based synchronous approach is the only way to do things. There is nothing that can be done the old ways that cannot be done better and more reliably with the signal-based model.
Wow…
You see, that’s the sort of statement that just begs the question.
Maybe you’re right, but are you *demonstrably* right? Provably right? How about the next person that comes along with the ultimate paradigm? How do I judge between that paradigm and yours? Will it take me 10+ years of study to understand which is truly the right one? The fact is, we developers have to make judgement calls all the time. And the fact is, in real life one has to make judgement calls all the time. Is there one and only one approach to mechanical engineering? Manufacturing? Management? Finance?
In my life as a developer there is only one paradigm I have come across that one can argue is “provably” better than the others that predated it, and that is the relational model, and the reason it is provably better than previous DB models is because one can use formal logic TO prove it, and that is because the relational model is purely a logical model and has nothing to say about specific implementation. It is also easier to prove because it is of limited scope and fits well within a recognized logical framework: set theory.
But it seems to me you are saying you have both a logical model and an implementation model, and that they are better–across the board–than any and all previous approaches to any and all computing problems. Am I right? How do you go about proving this? Is there a single mathematical model I can look at to get a grasp of this?
Don’t get me wrong… I agree with much of your assessment about what is wrong in computing today. There is a ridiculous plethora of different formats, protocols, syntaxes, official and unofficial standards. It gets dizzying to think of it all. But I am not sure the real world can support the polar opposite of that, which is one standard to handle everything.
(I’m imagining that a more capable theorist than I could come up with some sort of reductio ad absurdum, but I am more interested in exploring right now than arguing.)
But it seems to me you are saying you have both a logical model and an implementation model, and that they are better–across the board–than any and all previous approaches to any and all computing problems. Am I right? How do you go about proving this? Is there a single mathematical model I can look at to get a grasp of this?
The COSA model is a synchronous model. It is the same model used by logic circuits. Essentially, COSA transforms software into a signaling system comparable to hardware. My claim is simple and is not an extraordinary claim that requires extraordinary proof: if logic circuits can be proven correct, so can COSA programs.
The COSA model is a synchronous model. It is the same model used by logic circuits. Essentially, COSA transforms software into a signaling system comparable to hardware. My claim is simple and is not an extraordinary claim that requires extraordinary proof: if logic circuits can be proven correct, so can COSA programs.
I recommend that the author read David Gries’ polemic against “starwars” software development.
Logic circuts can be proven correct (to the extent that they’re accepted as never being metastable) because they implement a small enumerable set of state transitions.
You can prove a basic logic circuit correct by inspection of all of its states and transitions in a short period of time.
From this, you can build on the mathematics of formal logic and build up pieces into larger logic circuits and rely on the formalism. This works to a certain level.
But then logic circuits reach a certain level of complexity, and hey presto, they get buggy. (Ever see the errata sheet for a complex processor chip?)
But general software is far more difficult to prove correct. Take a simple mathematical algorithm. It has, in theory, an infinite domain and a potentially infinite range. You can’t prove it correct by inspection, and formal techniques don’t get you much farther.
Neither of these, however, address Gries’ simple but elegant point: You can’t prove programs correct, anyway. All you can prove is that they perform according to specification. But that leaves you wondering if the specification is correct….
The COSA model is a synchronous model. It is the same model used by logic circuits. Essentially, COSA transforms software into a signaling system comparable to hardware. My claim is simple and is not an extraordinary claim that requires extraordinary proof: if logic circuits can be proven correct, so can COSA programs.
But that answers nothing. I can chain some simple conditional statments together and make a provably correct program. A sufficiently large collection of these can conceivably handle any software problem. But, the whole problem becomes one of the programmer’s conception, rather than whether the if-then-else statements actually do what they are supposed to. I don’t see how a signal-based program can escape this scenario. May as well try to escape logic altogether.
And by the way, I wasn’t asking whether your model is “provably correct”, but whether it is provably superior. Big difference. It may have seemed like a non-sequitor, but I brought up the relational model because it is a perfect example of the sort of thing the programming world should be striving towards: an expression of logic in programming that has complete conceptual integrity. I believe it can be demonstrated through logic to be provably superior to any other method of data management created. That sounds like a big claim, but I make it due to a simple syllogism:
1. Logic is the ideal tool to handle computational tasks, since it is the only way to prove correctness at any level.
2. The relational model is simply a complete application of logic to data management, allowing one to express any and all manipulations of data in a logically consistent way.
3. Thus, the relational model is the ideal data management tool, and any deviation from that is only an undesirable limitation.
(For any who want to flame me for this, at least please do yourself the credit of spending some time thinking about this syllogism first)
Within the scope of data management, the relational model allows one to create systems that are provably correct, through data definition and constraints, allowing one to express exactly what should and should not be allowed to happen to the data. Now the problem with the relational model is one of implementation–namely that it has never been truly implemented, and the systems that exist almost all allow grievous violations and circumventions of the logic that one might express. But at the conceptual level it has that certain… completeness.
I fail to see any such conceptual integrity or completeness in the greater scope of programming paradigms, including the COSA model. I’m waiting for it anxiously, and just not seeing it. I think functional programming may be the closest we have come to that sort of thing in the programming world, but it still seems disappointingly difficult to handle any but the most self-contained, algorithmic sorts of tasks. Meanwhile, I still maintain that whether your programming is signal-based, algorithmic, functional, object-oriented, monolithic, distributed–whatever, you still can’t escape the fact that complex logical systems are difficult to prove correct, and the more complex they become, the closer you come to requiring an infinite amount of time simply to *make* the proof. It is not a limitation of the paradigm, but of the human mind itself. I don’t see any way around it any more than there is a way to escape the scenario we live in called “universe” (to paraphrase Buckminster Fuller).
“The best way to obtain software quality is to put the right tools for the job in the hands of open-minded people.”
This is the often repeated argument from people who are used to think in terms of the only software model they know, the algorithmic model: multiple tools for different jobs. This is precisely why algorithmic programming is flawed. It demands a plularity of tools, hence the current mess.
I use the argument because of analogy to other tool usages. Amazingly enough, in carpentry, not all fasteners are nails, and the hammer is the wrong tool for inserting screws.
I’ve used both imperative and declarative languages. For some jobs, imperative languages are the best tool, and those seem to be the majority of problems. For others, I prefer declarative languages. There are even times when functional programming makes sense. That’s just one of many dimensions in language choice.
The “true nature” of computing is not merely about communication. It is also about command and control, algorithmic transformation, and randomness.
By throwing out the algorithmic part, you throw out the mathematical foundation of symbolic manipulation. You may wish to live in a world with mathematics, but I do not.
“I suggest the author read Minsky’s early work. “signal-based” programming is the Nth in an infinite series of attempts to model the asynchronous processes that make up software as if they were synchronous. It is doomed to the same failure of all such attempts.”
This makes no sense, IMO. Synchronous, signal-based applications abound. There are spiking (pulsed) neural networks, spreadsheet cells, etc… all over the place and they work perfectly.
That there are some problems that can be modeled synchronously does not imply that all problems are effectively modeled this way.
Although most of the users would reply with a “WTF” to your post, your post is quite correct. Unfortunately it would take many years for people to realize that.
Although most of the users would reply with a “WTF” to your post, your post is quite correct. Unfortunately it would take many years for people to realize that.
Thanks for the support. I’ve been promoting signal-based computing for over 10 years and it’s only recently that I’ve begun to make a dent in the existing paradigm. It’s amazing what years of brainwashing in schools can do to us humans. It makes us blind. But this a fight that we must all win because the software reliability crisis is very real and extremely dangerous.
Thanks for the support. I’ve been promoting signal-based computing for over 10 years and it’s only recently that I’ve begun to make a dent in the existing paradigm.
Is there currently *any* actual open source software demonstrating the efficacity of these concepts that I can download and toy with?
While I am not necessarily buying into your “paradigm battle”, I find the concepts interesting. My interest isn’t so much in the microkernel/monolithic kernel debate, but in distributed programming in general. My current project is largely signal-based, with an IPC mechanism handling communication between separate processes. Is your approach intended only for low-level programming, such as kernels, or would it apply to any sort of software development?
If the end result of your 10+ years of effort is just a series of theoretical papers and conceptual drawings, with no actual working software, I have to remain skeptical. However, giving the benefit of the doubt, would it be possible to implement a working model of your ideas given a set of modules and an IPC mechanism in some scripting language, such as Python, Ruby, or even PHP? What page of your website would be the best starting point for this?
Honestly, this whole discussion of signal-based computing seems quite reminiscent of the dicussions in Functional programming (although FP does not explicitly use signals, the effect seems similar, as are the claims to “software correctness”). The main difference being that the functional programming guys actually have tons of working software out there. What are the parallels and differences between your concepts and those of the functional programming (eg. the Lisp machine)?
Honestly, this whole discussion of signal-based computing seems quite reminiscent of the dicussions in Functional programming (although FP does not explicitly use signals, the effect seems similar, as are the claims to “software correctness”). The main difference being that the functional programming guys actually have tons of working software out there. What are the parallels and differences between your concepts and those of the functional programming (eg. the Lisp machine)?
Signal-based programming is reactive programming: code is invoked when a state change is detected.
Functional programming is the exact opposite: there is no state, only computations. Values are copied with each change, and special constructs called monads are used to make sure memory space is reused and operations are invoked sequentially.
You may consider signal-based programming as event-driven programming where code can be attached to any variable. I have posted an example of a phonebook application at
http://www.rebelscience.org/phpBB2/viewtopic.php?t=33
where anyone interested in signal-based programming can discuss it there.
Personally I found signal-based programming much easier than anything else, but it has to be used together with functional programming; some aspects of FP are very useful (like combinatorial programming), some others are not that useful (like making the sequence of computations irrelevant – nobody things without sequencing in mind), and some others are plain irritating (like not being able to update state – not all state update is bad; plus there is no useful FP program without monads anyway).
If the end result of your 10+ years of effort is just a series of theoretical papers and conceptual drawings, with no actual working software, I have to remain skeptical. However, giving the benefit of the doubt, would it be possible to implement a working model of your ideas given a set of modules and an IPC mechanism in some scripting language, such as Python, Ruby, or even PHP? What page of your website would be the best starting point for this?
As I mention elsewhere, there are already working reactive languages out there, e.g., Esterel, Signal, etc… Project COSA goes much further down to the elementary instruction level. My idea is that COSA should be a graphical environment because software is represented more like a logic circuit. Also, it is easier to get gestalt of a complex program using simple icons. I haven’t done any programming on COSA other than a neural network that I use for my AI research (which takes most of my time). I would be happy to work full time on a COSA OS/virtual-machine and dev studio if I could secure enough funds.
As far as distributed computing is concerned, the COSA model is ideal since all elements in COSA are concurrent. However, since COSA is synchronous, in order to get the full promise of reliable code in a multiprocessor system some way would have tobe found to synchronize the various processes. That said, COSA does not prohibit asynchronous processes since it also supports message-passing via queues.
However, since COSA is synchronous, in order to get the full promise of reliable code in a multiprocessor system some way would have tobe found to synchronize the various processes.
This, of course, is the boundary at which all attempts to do pure synchronous programming fall down: when they meet the asynchronous nature of the real world.
Anyone who has ever designed mixed-signal integrated circuits will easily understand why.
This, of course, is the boundary at which all attempts to do pure synchronous programming fall down: when they meet the asynchronous nature of the real world.
Not true. The real world is both synchronous and reactive. All reactions are synchronized by a universal clock because the fundamental interval (at the Planck level) is the same for all processes/interactions. The universe is ONE, as its name implies.
Not true. The real world is both synchronous and reactive. All reactions are synchronized by a universal clock because the fundamental interval (at the Planck level) is the same for all processes/interactions. The universe is ONE, as its name implies.
This is the wrong forum for debunking quack quantum mechanics, but the uncertainty principle pretty much guarentees on a quantum level that the universe isn’t synchronous.
But that doesn’t matter, because behavior at a quantum level is not emergent at a macro level, and it’s pretty easy to demonstrate that at a macro level the universe remains asynchronous.
If you don’t think so, I’ve got a bluetooth package for you to debug.
> Honestly, this whole discussion of signal-based
> computing seems quite reminiscent of the dicussions
> in Functional programming (although FP does not
> explicitly use signals, the effect seems similar, as
> are the claims to “software correctness”). The main
> difference being that the functional programming guys
> actually have tons of working software out there. What
> are the parallels and differences between your
> concepts and those of the functional programming (eg.
> the Lisp machine)?
“signal based” programming is not related to functional
programming, but rather object-oriented programming
(what he says sounds like message passing programming
to me), while functions should always be valid
messages, they aren’t stateful in fp, so his “reactive”
paradigm is based on explicit use of side effects.
Furthermore, as you stated, (and in my personal
experience) functional programming has real software
to show it’s merits, even when it isn’t purely
functional, or is written in “impure” langauges such
as scheme and sml, as referential transparency on
various levels of the program makes it much easier to
reason about the code.
I hope that fp advocates don’t appear dogmatic, because
many of the benefits are very practical and result in
code that is pleasant for me to read.
I should also note that most Lisp advocates advocate
dynamic programming and code=data much more strongly
than functional programming. (not that either are
contradictory with functional programming, the language
Joy has all three qualities) From the common lisp code
that I have seen, most use state extensively throughout
the program (though it is not difficult to write
functional code in the language). In the case of
Scheme, there is a lot more functional code written
in it, but it isn’t purely functional either.
Similarly, it is quite possible to write functional
code in most garbage-collected languages, such as Perl
and Python. “Higher Order Perl” is a good resource for
perlers.
Edited 2006-05-10 22:50
Bah advocating/promoting doesn’t worth much.
Make a big opensource software with real world usage such as a clone of kword or of firefox, then you’ll get lots of followers, if it’s really flawless..
In the meantime, my favourite quote is still ‘there is no silver bullet’.
“Monolithic kernels have everything programmed together in one jumbled mess”.
My take: Anyone who says their code isn’t a jumbled assortment of code, including Microsilly coders, is full of crap.
My take: Anyone who says their code isn’t a jumbled assortment of code, including Microsilly coders, is full of crap.
No, they’re just professional. Anyone who’s done a computer science degree will know about software engineering, particularly choice and construction of algorithms. Anyone who’s spent some time designing software, and examining the design of other software, will know a lot about software architecting, particularly common design patterns and anti-patterns. Anyone with both these skills, and a bit of pride in their work, should be able to create something that is not a jumbled mess.
And while they’re at it, they can use Doxygen or JavaDoc to document it as well.
I wouldn’t call communism a good idea on paper. Compare microkernels with anarchy instead.
On paper, communism and anarchism (I suppose that’s what you mean) are pretty much the same thing. I think you’re thinking of socialism.
In any case, socialism, like capitalism, look good on paper, are historical processes (the former coming out of the latter). It’s not a question of looking good on paper or not – they just happen.
I doubt that socialism would have spontaneously “just happened” in Eastern Europe without the Soviet Union’s involvement. Whether what you might term “organic socialism” is the natural successor to capitalism is at best as yet unproven.
I shouldn’t reply on this because it’ll lead to a discussion not proper in here.
In case you’d like such a discussion, please let me know and we’ll take it somewhere else. It could be quite interesting.
Just remember that anarchy is the opposite pole to communism, and communism (as well as nazism and fascism) is hardcore socialism.
My email-adresse is in my profile
I haven’t found the e-mail address, so I’ll just reply here.
There are few things that need to be said:
1 Anarchy isn’t the opposite post to communism, in fact communist and anarchist societies would have almost everything in common.
2 Nazism is not hardcore socialism. It is plain statism in economy and hardcore nationalism.
3 Communism itself was quite popular among the societies of Eastern Europe after the WW2. The process in which these countries fell under control of soviet union is a bit more complicated than you’d suspect. The most significant example is that communism was the system chosen by Czech Republic without the soviet interference.
Enough of this, I wouldn’t like to spoil the kernel flamefest by some insignificant historical rambling.
Edited 2006-05-10 05:46
Click on my name and look at the Contact information. The email contains AT and DOT. It is line #4 from the top.
My fingers are all itchy
Linus is just being practical. I don’t think the people clamouring for Microkernels understand the tradeoffs of developing a plug-in based architecture. Those kinds of architecture are exceedingly complex to design, that almost nobody gets it right the first time, if ever they do. Now bump that challenge up to the scale of a project like the Linux kernel
Sure, on paper you read about how plug-in system and then you say to yourself, this is how every app should be developed. Well, until you are actually begin to write one yourself and then you realise not only are such system much tougher to design, they can be expensive to maintain.
I had the same dilemna with concurrent programming. Got brainwashed by the acadamia about how concurrent programming is the one true way and how apps should be designed in a concurrent manner, etc. It was supposed to make your app faster, better designed, modular etc. Nobody told me debugging the application would be a pain, or locking can be a serious problem, or that you have to be careful with libs that don’t support threading among a slew of other issues. I learnt all these the hard way.
I love micro kernel architecture as much as the next geek, but even I know it will be expensive to design, maintain and will much likely be slower than the monolithic style kernel. Modularity comes at a cost the academia don’t want you to know. It makes your apps slower and consume more system resources. You also have to spend a significant amount of time designing an intelligent core, or manager, and that’s the hard part. It’s hard because you’d spend years trying to get it right (Okay, I’m sure it won’t take that long for experienced and talented kernel hackers like the Linux guys). The benefits of Microkernels only pay of in the long run after making several mistakes and being bitten by the bug called reality.
It sounds fantastic on paper, but my guts tell me it’s going to be bitch to implement correctly. That’s why there are not too many successful micro kernel projects out there. I still like the ideas behind Microkernels and Plug-in like architectures, but I’m well aware of their limitations.
Edited 2006-05-10 00:01
I have only these lines to quote from the Zen of Python:
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
http://www.python.org/dev/peps/pep-0020/
Lets just cancel all algorithmics classes then. Why bother with branch-and-bound, if we can just check out all possible solutions to NP-hard problems? And why use merge-sort or quick-sort when insertion-sort is easier to explain?
I doubt that socialism would have spontaneously “just happened” in Eastern Europe without the Soviet Union’s involvement.
The fact that it happened in Russia first is in itself an anomaly. Marx wrote Das Kapital with two countries in mind: England and Germany. As such, the Soviet Union was never really a “socialist” country, at least using Marx’s description of it, as there was no skilled workforce – Russia was a mostly agrarian society.
Whether what you might term “organic socialism” is the natural successor to capitalism is at best as yet unproven.
Socialism is not necessarily a natural successor to capitalism, but it is a natural reaction to it. Note that socialism is also present in Western democracies as well (in some form). Modern labour laws borrow a lot from its lessons, and our economies are in fact mixed economies because of it (which was inevitable when the 1929 crash showed us that pure capitalism was an unstable system).
You’re right, this isn’t the proper place to discuss this. However…
Just remember that anarchy is the opposite pole to communism, and communism (as well as nazism and fascism) is hardcore socialism.
Actually, that is incorrect. Anarchism (not anarchy) is a social system, and is the opposite of fascism. Nazism is a form of fascism based on a semi-esoteric view of history. Socialism is an economic system, and communism is an utopia.
Amalgamating Socialism to Nazism and Fascism is a famous strawman argument used by the right. It ignores the fact that Nazis executed socialists before they did the same to the jews, and that private enterprise flourishes in fascist states.
Nazism and Fascism have nothing to do with socialism, and are in fact greatly opposed to this economic model.
I suggest you visit this website for a more nuanced view of the political spectrum:
http://www.politicalcompass.org/
Now, since this off-topic, dylan, what do you say we agree to disagree? 🙂
Of course we agree to disagree.
I’d like to add a few things, but as I already stated, this isn’t the right forum. I will restrain myself, but you make it hard. Very hard indeed.
[EDIT:] The Political Compass isn’t that good. I’ve seen better two dimensional political definitions. Personally I prefer three dimensions to define the political space.
Edited 2006-05-10 01:24
you make it hard. Very hard indeed.
That’s what I told my girlfriend last night.
That’s what I told my girlfriend last night.
It’s not what you TELL her. It’s what you SHOW her. ;-p
I would assume that Linus has been working with monolithic kernels for so long that he isn’t fully aware of the possible ways that micro-kernels can be designed.
Firstly, the scheduler and basic memory management doesn’t need to be done by seperate processes, and can be built into a microkernel. To be honest I’ve never seen much point in using seperate processes for these things.
As for complexity (of the OS, not just the kernel), consider any non-trivial device driver. For a monolithic kernel the device driver’s code can be run in the context of any number of processes on any number of CPUs at the same time. This means you must have re-entrancy locking, and all of the deadlock/livelock, fairness, etc problems that come with it. In a micro-kernel you can implement each device driver as a seperate single-threaded process, which implies that it’s impossible for any of it’s code to be running on more than one CPU and all of the re-entrancy issues disappear completely.
This can make a huge difference in performance and scalability…
Consider the Linux boot process – normally it initializes each device driver one at a time. For example, I’ve got a dual CPU server here with a SCSI controller that has a 15 second “disk drive startup” delay, where the entire computer (including both CPUs) does absolutely nothing for the entire 15 seconds. The reason for this is that it’s too complicated for poor Linus to figure out how to reliably initialize device drivers in parallel.
For a well designed micro-kernel, device detection, device driver initialization, file system and networking initialization and GUI startup can all happen in parallel without really adding any extra complexity.
Now consider “run time” – imagine you’re writing a simple text editor. When the text editor starts it needs to load DLLs, load user preferences, build it’s GUI interface (menus, etc), load the text file being edited, etc. For monolithic systems this would all be done one thing at a time – call “fopen”, wait to acquire VFS re-entrancy locks, try to find it in the VFS cache, call the file system, wait to acquire the file system code’s re-entracy locks, wait for hardware delays while reading directory information, etc. For a micro-kernel you could just send an asynchronous “open file” request and continue processing (building menus, sending other requests, etc) until the “open file status” is received – the requests themselves can be handled by processes running on other CPUs in parallel (no unnecessary context switches, no thread blocking, etc).
The problem is that device drivers run in the context of the caller. Of course on a monolithic kernel you could spawn seperate threads to handle each seperate operation. That way your main thread could keep working, but I don’t think this is “simpler” (re-entancy locks, sychronization, etc) and there’s overhead involved with spawning threads.
For the complexity of the “interfaces between components”, Linus is correct – having stable, well defined and well documented interfaces between components is much harder than pulling “ad-hock” creations out of your behind whenever you feel like it. Of course you can have stable, well defined and well documented interfaces between components in a monolithic kernel too, but it’s not required and most programmers don’t do things if they can avoid it.
“In a micro-kernel you can implement each device driver as a seperate single-threaded process, which implies that it’s impossible for any of it’s code to be running on more than one CPU and all of the re-entrancy issues disappear completely.”
No. You still have to do locking, because only one instance of the driver can drive the hardware at the same time. But now you have to do locking between processes, and not between threads, which actually makes it more complicated.
What most microkernel people fail to understand (or avoind mentioning, as it defeats their argumentation) is that turning subsystems into independent processes doesn’t change the fact that they still have to be synchronized somehow. If you can’t share the underlying resources between threads without synchronization, you can’t do it with processes either.
And there is also the stability thing… turning drivers into processes doesn’t make the system more stable, if the driver for the network card crashes, the system may become unusable, just like on a monolithic kernel.
No. You still have to do locking, because only one instance of the driver can drive the hardware at the same time. But now you have to do locking between processes, and not between threads, which actually makes it more complicated.
If there’s multiple instances of a device driver (multiple devices of the same type), then each instance of the device driver would only access it’s own device, and there’d still be no need for locking in the device driver.
What you seem to be describing is multiple instances of a device driver that control the same device. This never happens (except for exo-kernels I guess).
The only case where you would need locking within a device driver is when that device driver is implemented as a multi-threaded process, but then the locks are “process specific” (just like any multi-threaded user-level code).
What most microkernel people fail to understand (or avoind mentioning, as it defeats their argumentation) is that turning subsystems into independent processes doesn’t change the fact that they still have to be synchronized somehow. If you can’t share the underlying resources between threads without synchronization, you can’t do it with processes either.
You’re wrong – there is very little need for any synchonization between device drivers. The things that need sychronization is limited to “shared/global hardware” (PCI configuration space access, PIC and I/O APIC control, legacy ISA DMA controllers) and timing.
For “shared/global hardware”, the device driver is not allowed direct access – either the kernel provides functions for device drivers to use or there’s some form of “device manager”. This provides sychronization and also provides a form of abstraction, such that device drivers don’t need to care which PCI mechanism is being used by the chipset, whether APICs are being used instead of the old PIC chips, etc.
For timing, that is the schedulers problem. In general you need a scheduler that handles “priorities” and has functions like “nanosleep()” and “sleep()”. In addition the scheduler needs to be able to pre-empt lower priority things (like applications) when a higher priority thing (like a device driver) becomes “ready to run”. AFAIK the Linux scheduler is more than adequate for this (if you use it’s “real-time” scheduling and if the “niceness” priority adjustment doesn’t mess everything up).
And there is also the stability thing… turning drivers into processes doesn’t make the system more stable, if the driver for the network card crashes, the system may become unusable, just like on a monolithic kernel.
Here I agree slightly – a simple micro-kernel is no better than a monolithic kernel, unless it includes additional systems to handle failures.
Your networking example is a bad example – all real OS’s (including monolithic OSs) will handle “network service failure” because the network is considered unreliable anyway (i.e. the user could unplug the network cable, the ethernet hub could have problems or your ISP might drop your connection).
A better example would be code (and hardware) that handles swap space. A simple micro-kernel or a monolithic kernel would be entirely screwed if it’s swap space dies, but (with extra work) an “advanced micro-kernel” could provide additional systems to recover (e.g. redundant swap space providers).
The other thing “monolithic people” don’t understand is that finding out what went wrong is very useful for bug fixing. For example, if a device driver is intermittently corrupting some of the kernel’s data it would be extremely difficult to figure out which device driver is faulty or when the data was corrupted. For a micro-kernel you’d get a page fault and you’d know exactly what happened as soon as it happens.
Modern device drivers tend to be composed of a “bottom half” and a “top half” (terminology varies) in which the “bottom half” has to operate with low latency, and so does very little work, mostly in the form of state transition and data grabbing. The bottom half queues up work for the top half on input and the top half queues up work for the bottom half on output. Operations on the queues require synchronization.
Also, drivers require memory, especially storage drivers, and need to obtain it from a memory pool, so drivers have to synchronize with each other and the memory pool manager.
The other thing “monolithic people” don’t understand is that finding out what went wrong is very useful for bug fixing.
Oh yes they do. I doubt anyone who does OS development fails to understand the value in finding the cause of a problem.
For example, if a device driver is intermittently corrupting some of the kernel’s data it would be extremely difficult to figure out which device driver is faulty or when the data was corrupted.
Yes. Amazingly enough, due to shared memory pools, this is difficult to accomplish even when the drivers appear in separate address spaces.
For a micro-kernel you’d get a page fault and you’d know exactly what happened as soon as it happens.
That’s not a function of “micro-kernel”, it’s a function of separating address spaces used for data pools and using the hardware VM’s memory protection. A “microkernel” on a machine without virtual memory isn’t going to have that sort of protection, and a “macrokernel” on a machine that has virtual memory can have it. (See the Brevix paper for a discussion of how it was done on PA-RISC.)
Modern device drivers tend to be composed of a “bottom half” and a “top half” (terminology varies) in which the “bottom half” has to operate with low latency, and so does very little work, mostly in the form of state transition and data grabbing. The bottom half queues up work for the top half on input and the top half queues up work for the bottom half on output. Operations on the queues require synchronization.
That would be implemented as a multi-threaded process, with a very high priority thread (the top half) and another thread (the bottom half). This involves process specific locks, not “inter-process” locks.
Also, drivers require memory, especially storage drivers, and need to obtain it from a memory pool, so drivers have to synchronize with each other and the memory pool manager.
Each process’s virtual address space is independant. It’s like normal applications calling “sbrk()” on *nix – no explicit synchronization needed between the processes.
That’s not a function of “micro-kernel”, it’s a function of separating address spaces used for data pools and using the hardware VM’s memory protection. A “microkernel” on a machine without virtual memory isn’t going to have that sort of protection, and a “macrokernel” on a machine that has virtual memory can have it. (See the Brevix paper for a discussion of how it was done on PA-RISC.)
Sure, but if a monolithic kernel (rather than a “macrokernel”?) on a machine that has virtual memory can have seperate “access spaces” for device drivers then we’re quickly running out of differences between monolithic kernels and micro-kernels.
To be honest I lean towards the original definition of the term “monolithic”, which literally means “single piece, like stone”. I know the term is used “less literally” when it’s used to describe kernels, but at at the rate monolithic kernels are adopting “micro-kernel-ish” attributes we’re going to need to start calling things like QNX monolithic soon (examples include dynamically loaded modules, sandboxing (Nooks), support for user level drivers (Vista), etc).
“Modern device drivers tend to be composed of a “bottom half” and a “top half” (terminology varies) in which the “bottom half” has to operate with low latency, and so does very little work, mostly in the form of state transition and data grabbing. The bottom half queues up work for the top half on input and the top half queues up work for the bottom half on output. Operations on the queues require synchronization.”
That would be implemented as a multi-threaded process, with a very high priority thread (the top half) and another thread (the bottom half). This involves process specific locks, not “inter-process” locks.
I was responding to the claim that If there’s multiple instances of a device driver (multiple devices of the same type), then each instance of the device driver would only access it’s own device, and there’d still be no need for locking in the device driver.
whether the synchronization occurs within a thread, between threads, or between processes is an implementation detail. There is synchronization, to resolve latency issues.
“Also, drivers require memory, especially storage drivers, and need to obtain it from a memory pool, so drivers have to synchronize with each other and the memory pool manager.”
Each process’s virtual address space is independant. It’s like normal applications calling “sbrk()” on *nix – no explicit synchronization needed between the processes.
Storage drivers, especially those that implement things like software raid, or that service the disk cache, even if they are implemented in separate processes, need to have access to a common pool of memory. That definitely requires them to synchronize.
Anyway, you’re trying to have it both ways. Either the driver is implemented as threads in a process, or it’s implemented in pieces in separate processes, it’s not both.
“Microkernel” initially meant a system that had a certain set of attributes, a key one of which was message passing, and another separate address spaces for separate components. So called “hybrid” systems drop both of these, and are indistinguishable from “monolithic” kernels, in the original meaning.
I was responding to the claim that If there’s multiple instances of a device driver (multiple devices of the same type), then each instance of the device driver would only access it’s own device, and there’d still be no need for locking in the device driver.
What I’m trying to say is that if a device driver is implemented as a seperate single-threaded process then it requires no locks at all, and if a device driver is implemented as a multi-threaded process any locks are confined within that process and don’t need to be used by other processes.
Storage drivers, especially those that implement things like software raid, or that service the disk cache, even if they are implemented in separate processes, need to have access to a common pool of memory. That definitely requires them to synchronize.
Need?
I guess it does depends on how the OS is designed (rather than what sort of kernel is used, etc). I use asynchronous messaging, where messages can be large (e.g. 4 MB) rather than tiny (e.g. several dwords). For the “tiny messages” case you probably would need shared data, but it’s completely inappropriate for distributed OSs so I don’t use it.
For me, only one process ever has access to “common pools of memory”. For example, the “VFS process” would have a disk cache that only it has access to. If it needs something that isn’t in this cache it requests the data from the appropriate file system code. When the VFS receives the data it inserts it into it’s disk cache and complete the original request.
I guess it does depends on how the OS is designed (rather than what sort of kernel is used, etc).
Yes. I wasn’t being clear about context. I was limiting my comments to designs not based on message passing.
But even message passing doesn’t entirely relieve the system of synchronization requirements, it merely embeds them in the message model.
For the “tiny messages” case you probably would need shared data, but it’s completely inappropriate for distributed OSs so I don’t use it.
Again, that depends on the type of OS. I’ve done single-address-space distributed OSes that share virtual memory across the distributed system. If properly designed there can be advantages to such an approach, although it’s definitely easier to resolve fault containment in a distributed system by establishing autonomy and relying on messaging.
Is stupid. Edit the article, get rid of it.
You’re a fool to say ‘just because it is difficult to program, does not make it the worse design.’
If it’s DIFFICULT to program, it *is* worse in design. Especially if it’s an Open Source technology!
Should all kernels be written in assembly, just because it’s difficult to program, but potentially more efficient in design? Err.. No.
No. Using the right algorithm for a problem might be more difficult to program, but if the run time is a fraction of the simple solution, it _might_ be a better solution. Linus uses performance as an argument, but sometimes good performance requires complex solutions.
The choice of programming language doesn’t really have anything to do with design.
No. Using the right algorithm for a problem might be more difficult to program, but if the run time is a fraction of the simple solution, it _might_ be a better solution
The problem is that you forgot a very important parameter : the time it takes to implement the algorithm.
And microkernels lose big time here : longer to implement, longer to make them fast.
I’m no expert, I just look at the hard facts.
Linus uses performance as an argument, but sometimes good performance requires complex solutions
Linux already has very good performance.
The choice of programming language doesn’t really have anything to do with design
That’s not true at all. There are procedural, functional, OO programming languages. Each one can greatly change the design of your app.
What baffles me here, is that there’s no problem. There are just people arguing about which is best.
Unfortunately, one camp has a very good implementation, widely used in all situations you can use a kernel.
The other camp has nearly nothing : only some niche situations. So the other camp can’t compare to Linux, just present theorical findings.
So, even if it’s just arguments, I have a hard time being on the side of microkernel proponents, because monolithic kernel people have made sth.
In the other camp, I see people badmouthing people making Linux, but I’ve yet to see all these brilliant people working on the Hurd.
Go help these people to validate your theories, instead of losing your time arguing with Linus, who has nothing to prove anymore.
Aim in the middle! The fact is that pure exo-kernel doesn’t work, because they require personalities. Micro-kernels do have integrated personalities but putting everything in user space is dump too. There is need for user-space driven stuff… like everything that need to be failure-proof or prone to crash. Ex: graphic drivers don’t belongs in the kernel as wrong graphic programmation may take the system down (just think about nvidia’s BSOD under Windows); USB drivers, non-essential block devices.
I say that usualy everything that provide direct services to user mode belong in it. Everything that services the kernel belong in the kernel. And everything that is in between (memory management, scheduler, …) belongs in the kernel in a modular way.
In my own experience, I’ve tried a lot of OS and I can say to date that the best OS I’ve found (in a kernel speaking way and a end-user point of view) are the FreeBSD and QNX, because they both offer a great response time, and doesn’t feel slugish as I sometime get on Linux or Windows. Of course nothing compare to raw access (like DOS) but it doesn’t offer as much of facilities.
First of all to all of those who keep pointing to OS X it is worth pointing out that it is NOT a real microkernel. As I understand it the whole BSD layer runs as part of the kernel in OS X. It starts out with what was a microkernel but then runs it like a monolithic kernel (at least in my understanding).
Ultimately the point is that microkernels can’t, either in principle or in practice, be as efficent as a monolithic kernel and apart from fault isolation they just don’t give any benefits.
This isn’t to say that the microkernel *idea* of seperating things into well defined components that each do a simple task isn’t often a good idea. However, one can always take this idea and implement it as a logical division during development but don’t compile it down into seperate address spaces.
Ultimately the only benefit to microkernels is fault isolation (the bit about restarting that service) because all other benefits can be replicated through appropriate design and language features in a monolithic kernel.
Now I think Linus goes too far in totally dissing any benefits from fault isolation. Some parts of a traditional monolithic kernel can be put out in a seperate address space with little performance impact and serious benefits in terms of stability. The lessons learned from microkernels to enable fast message processing should certainly be adopted by macrokernels to enable this sort of feature.
HOWEVER, for an end user it really isn’t helpful if integral parts of the system can crash without bringing down the kernel. Thus for these parts of the system there is simply no benefit from putting them in a seperate address space and thus any performance hit decides the issue.
“shown to be bull” “is also total crap” “is equally flawed.”
Linus talks just like a 10 years old children …
What Tanenbaum says is perfectly correct.
According to my view, since its a kernel, its design should be planned good.
variable codes(codes which interact with hardware, daily new hardwares appears) Vs fixed codes(or not frequently changing codes and 100% reliable codes and does not deal with hardware)
only fixed codes should be running in kernel space with full priviledges and variable codes should be running in user space.
This should be the first point for a kernel design because it is a KERNEL and it should take care of all the things.if the kernel itself is not safe like monolithic kernel then Isnt that design bad ???
without fullfilling this how one can proceed further in a kernel design.
if IPC, Memory management those which has a complete programming which wont have bugs(since the codes for these may be small and which wont have any frequent code change) only runs in the kernel and everything else(remaining drivers) which might have code change even daily runs in the user-level, will result in a good secured and reliable OS.
regarding performance,
i like to say this…
i had a program which took 15 minutes to complete with a pentium II processor.the same program took 7 mintues to complete with a pentium III processor. and it took only 2 or 3 minutes in a pentium IV processor.
the performance will be increased by the hardware automatically as time goes on.BUT will a kernel safety like microkernel be given by any hardware automatically ???
frankly linux had nothing special when it started.its a just weak kernel which is not at all portable.
the only thing he made which made linux to start is changed its license to GPL and build his kernel with all the GNU utilities like the powerfull GCC and nothing else.since at that time many eager programmers were waiting for a free OS which at that time only GNU/Linux was available, they started to coding this GNU/Linux.
If Linus would have written a microkernel(as suggested by Tanenbaum) even a buggy and not at all portable kernel at that time and joined that with GNU, by now it would have been very great sparkling OS. since he was only a student, he can do only easy coding and that was the reason he wrote linux kernel.
a monolithic kernel is very easy to write.anyone who knows little system programming with kernel concepts can a write a monolithic kernel.but only a good programmer with high creativity can write a microkernel.
The big mistake Tanenbaum has done was he didnt realise the power of GNU and how it will change the future.if he would have joined his hands at that time with GNU, now everyone would have been running an OS with 100% perfection, portable and secured.
another interesting person was Jochen Liedtke who is also a very high creative and talented programmer like Tanenbaum.
i could say very high talented programmer with great creativity are
Tanenbaum, Richard Stallman, Jochen Liedtke
a small ordinary programmer who got his name and fame because of GNU GPL is
Linus Torvalds
Even now if all people starts to code the MINIX code with GNU’s utilities, and concentrate on it, surely within 1 year, the same great OS can appear.its possible.but for that Tanenbaum and Richard Stallman should plan well. and also all the good people.
Hope this happens !!!
I disagree strongly with your views
According to my view, since its a kernel, its design should be planned good.
variable codes Vs fixed codes(or not frequently changing codes and 100% reliable codes and does not deal with hardware)
This is already a huge bad case of over engineering. Your project would be dead before having started.
What you ask for is currently just impossible to do.
This should be the first point for a kernel design because it is a KERNEL and it should take care of all the things.if the kernel itself is not safe like monolithic kernel then Isnt that design bad ???
without fullfilling this how one can proceed further in a kernel design.
Further proof that your project would be dead before having started.
What you want to fullfil (that the kernel is safe) is just impossible to prove (look at your CD courses and Turing), so you will never start anything.
if IPC, Memory management those which has a complete programming which wont have bugs(since the codes for these may be small and which wont have any frequent code change) only runs in the kernel and everything else(remaining drivers) which might have code change even daily runs in the user-level, will result in a good secured and reliable OS
BS. Again, it is impossible to prove that your code is correct (don’t have bugs).
When your code is so small that you can show empirically that it is safe, that means you still have to call it through a function, and there can lie lots of bugs (concurrency and the like).
the performance will be increased by the hardware automatically as time goes on.BUT will a kernel safety like microkernel be given by any hardware automatically ???
Yes, you have to be a good, provable correct algorithm before making it fast. You just forgot the part about “making it fast”.
Depending only on the hardware to be faster means that your kernel will stay in a niche at best, and can never compare to Linux.
frankly linux had nothing special when it started.its a just weak kernel which is not at all portable.
the only thing he made which made linux to start is changed its license to GPL and build his kernel with all the GNU utilities like the powerfull GCC and nothing else.since at that time many eager programmers were waiting for a free OS which at that time only GNU/Linux was available, they started to coding this GNU/Linux
Incorrect. BSD were there and free already. People were waiting fir a free OS that commercial entities could not steal from them instead. Because stealing the kernel would mean also stealing their work. So I strongly believe that yes, the GPL license made a big push, but the fact that the kernel was monolithic too.
If Linus would have written a microkernel(as suggested by Tanenbaum) even a buggy and not at all portable kernel at that time and joined that with GNU, by now it would have been very great sparkling OS. since he was only a student, he can do only easy coding and that was the reason he wrote linux kernel.
I disagree, just look at the HURD. It does not attract the load of people you talk about. Even though it’s GPL too.
a monolithic kernel is very easy to write.anyone who knows little system programming with kernel concepts can a write a monolithic kernel.but only a good programmer with high creativity can write a microkernel
Insulting great minds like those working on the Linux kernel (among which A. Cox) do not make me in your camp.
You sound like Linux is developed by no great people.
The big mistake Tanenbaum has done was he didnt realise the power of GNU and how it will change the future.if he would have joined his hands at that time with GNU, now everyone would have been running an OS with 100% perfection, portable and secured
BS. Nothing guarantees that an OS or kernel is 100 % perfection, portable and secured. You live in a dream world.
And management from Linus was very important to make Linux what it is now. Tanenbaum would have bowed when IBM and others wanted to put their things in the Linux kernel, or would have bowed before proprietary drivers. I say this because of how he licensed Minix.
Even now if all people starts to code the MINIX code with GNU’s utilities, and concentrate on it, surely within 1 year, the same great OS can appear.its possible.but for that Tanenbaum and Richard Stallman should plan well. and also all the good people
BS. RMS has the HURD, and it has already been redesigned at least once. You talk like all this is possible like that. You’re dreaming, wake up !
BS. Again, it is impossible to prove that your code is correct (don’t have bugs).
When your code is so small that you can show empirically that it is safe, that means you still have to call it through a function, and there can lie lots of bugs (concurrency and the like).
The calling function will be running in a user space.so bugs in the calling function wont affect the kernel.
Yes, you have to be a good, provable correct algorithm before making it fast. You just forgot the part about “making it fast”.
Depending only on the hardware to be faster means that your kernel will stay in a niche at best, and can never compare to Linux
i am not saying that only the hardware controls the speed. i just said that performance reduce due to the microkernel approach since its safer, is not that much important in these days or the following days.
Incorrect. BSD were there and free already. People were waiting fir a free OS that commercial entities could not steal from them instead. Because stealing the kernel would mean also stealing their work. So I strongly believe that yes, the GPL license made a big push, but the fact that the kernel was monolithic too.
BSD was available. but the source code of BSD was having a case suit filed by AT&T.
everything is because of GPL is known by everyone. since GNU/Linux was a complete free OS which had the complete GNU utilities and since it was usable is the only reason everyone started to add codes. the monolithic kernel approach has made good programmers lazy and made them to change from HURD to Linux kernel.i can say that a test version of GNU/HURD was not released before a test version of GNU/Linux was released.
I disagree, just look at the HURD. It does not attract the load of people you talk about. Even though it’s GPL too.
HURD was GPL too, but at that time it was developed by a small group. Peoples code other than that small group were not allowed to get add in the HURD project due to the finalization of design of kernel.
Insulting great minds like those working on the Linux kernel (among which A. Cox) do not make me in your camp.
You sound like Linux is developed by no great people.
i accept that they were good programmers. Linus made them lazy by starting a fun monolithic kernel.
this is clearly proved because linus itself told in his first newsgroup message about the release of linux that the next year HURD will be ready. until that everyone can play with my kernel.he never planned to create a very good futuristic kernel.he just created a easy playable kernel and due to GPL and everyone are allowed to add codes to Linux kernel and not like HURD at that time which didnt allow anyone to add codes to the main project, everyone added codes to the linux kernel. since its slowly gained popular , Linus cunningly changed his voice and he saw many programmers turned their faces to easy monolithic kernel. he then started to act like as if he designed the linux kernel to be highly reliable.
BS. Nothing guarantees that an OS or kernel is 100 % perfection, portable and secured. You live in a dream world.
And management from Linus was very important to make Linux what it is now. Tanenbaum would have bowed when IBM and others wanted to put their things in the Linux kernel, or would have bowed before proprietary drivers. I say this because of how he licensed Minix
all linus wants now is that no programmers should turn to microkernel side as he fears that microkernel might change the future and it will.
BS. RMS has the HURD, and it has already been redesigned at least once. You talk like all this is possible like that. You’re dreaming, wake up !
nowadays system programmers and researchers have become very less. thats the big problem. all good programmers please turn to microkernel side and start growing your creativity.
“just because it is difficult to program, does not make it the worse design.”
I dissagree. While a difficult solution might be technically superior, I would always go for the simpler solution if possible. You have to consider the huge benefits of high maintainability, speed of development, and the numbers of possible bugs.
“Microkernel” is a label for an implementation techinque. It gives you no more modularity in design than any other design approach, although it can be used to enforce modularity, at the expense of interaction complexity and performance.
Anyone who had the misfortune of dealing with the abominatinon that was OSF-1 has direct first hand experience with just how non-modular a “microkernel” based system can be.
“Microkernel” is also more a marketing term than a technical term anymore. We find Microsoft drawing a box around their vm/scheduler and calling it a “microkernel”. We find people using the term “hybrid” to excuse things that have no microkernel in them as if they were somehow “microkernel” based, and now we have people confusing “microkernel” with modular.
I want to mod you up again.
This ongoing microkernel “debate” is really exposing many people for fools.
Creating this “controversy” out of thin air is only dragging down the site.
Linus’ argument against Microkernels (as written in ‘Just For Fun’) is that the smaller you make every module, the more code you have to write connecting those modules.
So the intended simplicity of design is actually a false simlicity because you have simple modules, but very sophisticated communication between modules.
The point is mute anyway considering how many kernel modules are being replaced by user-mode daemons. Clearly, there’s room for both concepts even in a single project.
I think one of the most important design consideration when dealing with a free os kernel, such as Linux, is flexibillity.
The system must be able to evolve freely in unpredictable directions.
A microkernel-based architecture may accomplish this to some extent. Regardles of what theoretical model is the best, we know one thing: As more and more people want to force the Linux kernel to serve their purposes, the overall architechture will evolve into something to support this flexibillity. Wheter this will be a microkernel design, or not, is of academic interest at best.
Edited 2006-05-10 06:42
here: http://fred.cambridge.ma.us/c.o.r.flame/msg00025.html
Linus says building a microkernel makes all your algorithms become distributed. What I don’t get is how that’s gonna happen. The biggest part of a (monolithic) kernel are the device drivers. I am not a kernel programmer, but I allways thought most device drivers are there just to send bits of data from userspace to the device and back, and that doesn’t sound very ‘distributed’ to me. Of course you need synchronization if several processes try to access the same device, but that can be implemented in the same driver, so that’s no more distributed than in monolithic kernels nowadays.
If we take a driver for a simple device file supporting read and write, what kind of distributed state does that require? All I can think about is that the application assumes the driver still remembers the file was opened and something was already written to it. If the driver was restarted, an attempt of the app to do something with the device again would most likely fail, and the app would need to handle that failure correctly.
All that is needed, as far as I can see, is a mechanism for telling applications a certain driver they were talking to was restarted, so they need to begin their conversation anew. This does imply some extra overhead on the applications side, but this overhead is there just to support a new feature, ie surviving a crashed driver. And any new feature requires new code. Even if this was not implemented, a crashed driver would just take the apps down with it that were using it at that moment, and not the whole system.
Of course, there are probably all kinds of complex kernel systems which do become distributed algorithms, but no one says everything has to be implemented in userspace. What I’m missing is how userspace implementation is going to be a problem for the common case.
I’ve played a lot with microkernels -Mach 2.0- in the past, and the truth is that both Andy & Linus say a lot of truths about the issue, but neither solution is the perfect one. Microkernels & Pico/cache kernels look great on paper but have their disavantages, as well as true monolithic ones, not just performace, complexity or stability.
The real solution is something in the middle, a compromise between both, something the linux kernel does to a certain degree -it’s kernel modularization is similar in some ways to those of microkernel-. That let’s for example get a bigger set of features in kernelspace and avoid many switches to/from userspace that are so heavily penalized on certain platforms -x86 for example-.
The monolithic vs microkernel debate is almost 20 years old and the pros and cons of each solution have been exhaustively discussed over that period. Since no solution is perfect, should n’t people just invest time into research of novel solutions to the real problems (resource sharing and process isolation) that kernels try to solve? For example, why have isolated process, context switches and the like when modern languages offer memory protection by default? What exactly are the advantages of writting system code in C and not some type safe language?
Just speaking my mind out…
Then are you talking about an OS written in a’memory safe’ language like Java? Are you talking about the Singularity project by Microsoft using C# and is variants?
Then are you talking about an OS written in a’memory safe’ language like Java? Are you talking about the Singularity project by Microsoft using C# and is variants?
Yes, I am talking about operating systems not based on consepts (and misconseptions) discovered 40-50 years ago. I am bored of stupid conversations about how superior AmigaOS was 20 years ago (granted, it was) or whether microkernels are modular or slow (yes ,they are both). Isn’t this a high time to move our thoughts forward and leave all this micro-mono-hybrid-kernel blah blah to the dust? People should just take a look in the Jnode OS code to get a feeling of inovation in practice (which of course has already happened in theory)
>I am bored of stupid conversations about how superior AmigaOS was 20 years ago (granted, it was)
Depends on how you measure superiority, having one application crashing could crash the whole OS if memory serves, I hardly call this superior.
Indeed, but wasn’t that because the AmigaOS originally came out for release on the 68000 processor which didn’t have the supporting hardware to support the initially developed Predecessor to the released AmigaOS?
The 68000 was a pretty basic CPU.
Then are you talking about an OS written in a’memory safe’ language like Java? Are you talking about the Singularity project by Microsoft using C# and is variants?
Yes, I am talking about operating systems not based on consepts (and misconseptions) discovered 40-50 years ago.
Burroughs wrote ‘memory safe’ operating systems in type safe languages forty years ago. They even designed processor architectures to support them.
And the fact that nobody remembers it show quite clearly that writing in a type safe language is not necessarily such a big advantage over competitors.
For any new OS, compatibility with the installed base is necessary, except for niche products of course.
Mach was (a microkernel based OS), and I suppose Darwin is. (I’m too lazy to look at the Darwin source code.) That’s pretty much it in desktop OS land.
from http://www.usenix.org/publications/library/proceedings/bsdcon02/ful… : At the heart of Darwin is its kernel, xnu. xnu is a monolithic kernel based on sources from the OSF/mk Mach Kernel, the BSD-Lite2 kernel source, as well as source that was developed at NeXT … xnu is not a traditional microkernel as its Mach heritage might imply … the kernel is in fact monolithic.
So not even OSX is microkernel based. There is pretty much no microkernel on the desktop today.
a small ordinary programmer who got his name and fame because of GNU GPL is Linus Torvalds – sathishmls
deja vu anyone? http://www.osnews.com/permalink.php?news_id=14532&comment_id=121594 I guess it’s cool to copy/paste your own (longish) post from a different thread when you still have the same opinion
We Have Hurd It All Before.
I was thinking the other day that a microkernel would be ideally suited for a cpu like the cell. The kernel takes up a single processing element and uses the channels for it’s communications with the other processes reducing the work load of handling IPC a very small amount and providing the kernel all the resource it needs. Assuming that the memory for the processing element is enough to run a full macrokernel there will be no paging for the kernel and the memory is already protected. The Cells current state means that it isn’t possible to implement as I don’t believe it would be possible to get direct access to hardware from one of the SPE’s neither would interrupts be accessible but an interesting idea still.
The whole ‘microkernels are simpler’ argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins.
I’m a bit disappointed to see that kind of disingenuous comment from someone like Linus Torvalds. As a BeOS user, I’d probably be a hypocrite if I took a firm stance on either side of the micro/monlithic argument – but I don’t see why Torvalds would assume that “simpler” would automatically mean “less development time.” In many cases, simple is much harder than complex – it seems counter-intuitive, unless you have experience trying to simplify something that’s inherently complex.
There’s a well-known anecdote among journalists, about the rookie writer who submits an article by dropping a half-foot stack of paper on his editor’s desk and saying “I would have made it shorter, but I didn’t have the time.”
As much as I respect Linus Torvalds, some people here talk about him like he is some kind of God. He may be wrong you know? He is only a human…
My humble opinion: a Microkernel is generaly more stable/secure, a Monolithic kernel is generaly more fast.
Sorry my poor english.
Of course he’s God!
Kidding. You’re right.
And your English is fine 🙂
Tell me which Operating Systems have you analysed and what criteria you chose for testing stability. QNX is the only major OS that uses a pure microkernel. All other OS’s are hybrid or monolithic. And guess what Linux is faster, better and more widely used than QNX even on devices where QNX competes (embedded systems).
The fact that you have made no observations on a microkernel OS about the so-called “stability” flaws your stability/security arguement.
Let’s see : If microkernel was a better design, most OSs today would be microkernel based and guess what most of them are quite successful despite being hybrid or monolithic.
My Take: What’s wrong with the current Linux kernel? Linux is the most popular Free kernel. Linux is fast, stable, secure and popular. Okay I agree: It’s buggy but those bugs are due to other reasons I would not like to go deep into here.
Unless I see a microkernel based OS performing better or giving any advantages to me, I wont vote for one.
more widely used than QNX even on devices where QNX competes (embedded systems).
Anything to back that up? You see, QNX is one of the most widely used embedded operating systems, there’s no way in hell Linux has overtaken QNX in the embedded space. And judging by the state of Linux on my Zaurus, it will take a loooooooooooong time before Linux can beat QNX in the embedded space.
In some sense, the micro-kernel is a deviation from the Unix’s distrust of “One true way.” For a monolithic kernel like Linux, nothing stop you just write a simple stub in kernel space while leave as much part of you driver to user space as possible. In fact there has already been something like user-space file system. If micro-kernel had really superior advantage, majority driver would have adopted that approach. Nothing stop you from doing that. And in a monolithic kernel you will reach the best balance as you wish.
The discussion between monolithic vs microkernel goes on because no one has realized the problem lies in the CPU: modern CPUs are very fast, but they do not offer anything in the modularization department.
There is a very easy way to provide modularization. The Motorola 68020 had a CALLM instruction that saved the current module in the stack and loaded a new module from the destination address. This mechanism could very easily be adapted to 80×86, since Intel CPUs already have a segmentation model: each procedure entry point could contain the new value for the CS register, and a special CALLM instruction could push CS on the stack then load the new CS from the destination.
And software wouldn’t have to be modified at all: the O/S linker would patch exported module procedures and invocations of those procedures.
Thats very interesting…
Maybe a complete overhall of the CPU design is required. Instead of working down to thinking of a better Kernel at the bottom of the OS stack, maybe CPUs could be designed differently to support modularisation and message passing and certain kind of simple pseudo-kernel interface calls, wrapped in an exokernel or microkernel on top.
Maybe a complete overhall of the CPU design is required. Instead of working down to thinking of a better Kernel at the bottom of the OS stack, maybe CPUs could be designed differently to support modularisation and message passing and certain kind of simple pseudo-kernel interface calls, wrapped in an exokernel or microkernel on top.
It has been done. For a uniprocessor or shared-memory multiprocessor, even a NUMA system, you don’t want true message passing, because it stresses what is already a weak spot in system performance, memory bandwidth.
What you do want is separation of addressability from accessability in the VM design and very fast “VM context” switching, ala the PID approach in processors like the PA-RISC.
Anyway, the majority of problems in OS design come from periphreal interfacing and not CPU architecture. If you really wanted to simplify OS design by simplifying system design, you’d concentrate on the i/o architecture of the system. (IBM 360 channel controllers, anyone?)
The discussion between monolithic vs microkernel goes on because no one has realized the problem lies in the CPU: modern CPUs are very fast, but they do not offer anything in the modularization department.
Sure they do. see, for instance, the PID register in the PA-RISC architecture.
I repeat again: there are no microkernels based oses because there is no market space for another os. The “missing driver” problem. Let’s try again when virtualization has gain more popularity.
Plus I add hypocrisy: people hates microkernels for 3% of performance loss but they happily use all bloated software without complain…
I work as a programmer in the financial software and I see each days it is better having lots of modules completely indipendent that communicates to well defined interfaces. At least if you want to be sure that your bank account is right each morning.