Linked by Thom Holwerda on Tue 9th May 2006 21:25 UTC, submitted by luzr
OSNews, Generic OSes 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.
Order by: Score:
My Take
by vitae on Tue 9th May 2006 21:38 UTC
vitae
Member since:
2006-02-20

Is a tradition Eugenia need not have started.

Reply Score: 5

RE: My Take
by dr_gonzo on Tue 9th May 2006 23:23 UTC in reply to "My Take"
dr_gonzo Member since:
2005-07-06

At least he's stopped saying 'boys and girls' ;)

Reply Score: 5

RE: My Take
by Rodrigo on Wed 10th May 2006 09:43 UTC in reply to "My Take"
Rodrigo Member since:
2005-07-06

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.

Reply Score: 2

RE[2]: My Take
by StephenBeDoper on Wed 10th May 2006 15:30 UTC in reply to "RE: My Take"
StephenBeDoper Member since:
2005-07-06

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.

Reply Score: 1

RE: My Take
by Sphinx on Wed 10th May 2006 13:21 UTC in reply to "My Take"
Sphinx Member since:
2005-07-09

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.

Reply Score: 2

axilmar Member since:
2006-03-20

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.

Reply Score: 1

RE: My Take
by fretinator on Wed 10th May 2006 16:15 UTC in reply to "My Take"
fretinator Member since:
2005-07-06

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.

Reply Score: 3

Pardon?
by segedunum on Tue 9th May 2006 21:43 UTC
segedunum
Member since:
2005-07-06

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

Reply Score: 5

RE: Pardon?
by Mapou on Tue 9th May 2006 22:51 UTC in reply to "Pardon?"
Mapou Member since:
2006-05-09

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.

Reply Score: 0

RE[2]: Pardon?
by egarland on Wed 10th May 2006 04:55 UTC in reply to "RE: Pardon?"
egarland Member since:
2005-08-05

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.

Reply Score: 3

Communism
by tmack on Tue 9th May 2006 21:45 UTC
tmack
Member since:
2006-04-11

Microkernels are like communism.

Great idea on paper, but basically impossible to succesfully implement for a plethora of reasons.

Reply Score: 5

RE: Communism
by dylansmrjones on Tue 9th May 2006 21:50 UTC in reply to "Communism"
dylansmrjones Member since:
2005-10-02

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.

Reply Score: 1

RE[2]: Communism
by sappyvcv on Wed 10th May 2006 16:19 UTC in reply to "RE: Communism"
sappyvcv Member since:
2005-07-06

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.

Reply Score: 1

RE: Communism
by ebasconp on Tue 9th May 2006 23:04 UTC in reply to "Communism"
ebasconp Member since:
2006-05-09

"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

Reply Score: 1

RE[2]: Communism
by tmack on Wed 10th May 2006 01:58 UTC in reply to "RE: Communism"
tmack Member since:
2006-04-11

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.

Reply Score: 3

RE[3]: Communism
by haugland on Wed 10th May 2006 11:19 UTC in reply to "RE[2]: Communism"
haugland Member since:
2005-07-07

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!

Reply Score: 2

RE[4]: Communism
by rcsteiner on Wed 10th May 2006 15:39 UTC in reply to "RE[3]: Communism"
rcsteiner Member since:
2005-07-12

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?

Reply Score: 0

RE[5]: Communism
by rcsteiner on Wed 10th May 2006 22:34 UTC in reply to "RE[4]: Communism"
rcsteiner Member since:
2005-07-12

My apologies for not including a large red sign warning "sarcasm". I guess the moderators didn't get it. :-)

Reply Score: 1

RE[4]: Communism
by sappyvcv on Wed 10th May 2006 16:25 UTC in reply to "RE[3]: Communism"
sappyvcv Member since:
2005-07-06

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.

Reply Score: 1

RE: Communism
by dr_gonzo on Tue 9th May 2006 23:26 UTC in reply to "Communism"
dr_gonzo Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: Communism
by ma_d on Tue 9th May 2006 23:39 UTC in reply to "RE: Communism"
ma_d Member since:
2005-06-29

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

Reply Score: 1

RE[2]: Communism
by sdeber on Wed 10th May 2006 07:06 UTC in reply to "RE: Communism"
sdeber Member since:
2005-07-06

These people either got their brains washed or they have no idea of their own at all.

Reply Score: 1

v RE: Communism
by Duffman on Wed 10th May 2006 04:26 UTC in reply to "Communism"
RE[2]: Communism
by Gunblade on Thu 11th May 2006 00:40 UTC in reply to "Communism"
Gunblade Member since:
2005-07-21

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!

Reply Score: 1

Ding ding ding
by JMcCarthy on Tue 9th May 2006 21:46 UTC
JMcCarthy
Member since:
2005-08-12

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

Reply Score: 4

RE: Ding ding ding
by Cloudy on Wed 10th May 2006 05:06 UTC in reply to "Ding ding ding "
Cloudy Member since:
2006-02-15

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.

Reply Score: 1

Abstraction
by saterdaies on Tue 9th May 2006 21:48 UTC
saterdaies
Member since:
2005-07-07

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.

Reply Score: 4

RE: Abstraction
by luzr on Tue 9th May 2006 21:58 UTC in reply to "Abstraction"
luzr Member since:
2005-11-20

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

Reply Score: 4

RE[2]: Abstraction
by BryanFeeney on Tue 9th May 2006 22:41 UTC in reply to "RE: Abstraction"
BryanFeeney Member since:
2005-07-06

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

Reply Score: 5

RE[3]: Abstraction
by luzr on Tue 9th May 2006 22:52 UTC in reply to "RE[2]: Abstraction"
luzr Member since:
2005-11-20

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

Reply Score: 3

RE[4]: Abstraction
by BryanFeeney on Tue 9th May 2006 23:06 UTC in reply to "RE[3]: Abstraction"
BryanFeeney Member since:
2005-07-06

Sorry, I thought you were saying the problem was that they were multi-threaded (the dual-core thing threw me off).

Reply Score: 1

v RE[2]: Abstraction
by tummy on Wed 10th May 2006 06:37 UTC in reply to "RE: Abstraction"
RE: Abstraction
by renox on Tue 9th May 2006 22:08 UTC in reply to "Abstraction"
renox Member since:
2005-07-06

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

Reply Score: 5

RE: Abstraction
by BryanFeeney on Tue 9th May 2006 22:37 UTC in reply to "Abstraction"
BryanFeeney Member since:
2005-07-06

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

Reply Score: 5

RE[2]: Abstraction
by twenex on Tue 9th May 2006 22:46 UTC in reply to "RE: Abstraction"
twenex Member since:
2006-04-21

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

Reply Score: 5

RE[3]: Abstraction
by luzr on Tue 9th May 2006 22:54 UTC in reply to "RE[2]: Abstraction"
luzr Member since:
2005-11-20

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

Reply Score: 5

RE[4]: Abstraction
by twenex on Tue 9th May 2006 23:07 UTC in reply to "RE[3]: Abstraction"
twenex Member since:
2006-04-21

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

Reply Score: 3

RE[5]: Abstraction
by michalsc on Wed 10th May 2006 06:44 UTC in reply to "RE[4]: Abstraction"
michalsc Member since:
2006-01-02

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.

Reply Score: 2

RE[6]: Abstraction
by nii_ on Wed 10th May 2006 14:25 UTC in reply to "RE[5]: Abstraction"
nii_ Member since:
2005-07-11

The AmigaOS was very slick how ever the hardware and 680x0 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 ?

Reply Score: 1

RE[5]: Abstraction
by agnus on Wed 10th May 2006 08:47 UTC in reply to "RE[4]: Abstraction"
agnus Member since:
2006-05-10

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.

Reply Score: 2

RE[6]: Abstraction
by twenex on Wed 10th May 2006 13:07 UTC in reply to "RE[5]: Abstraction"
twenex Member since:
2006-04-21

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? ;)

Reply Score: 1

modularity
by viton on Wed 10th May 2006 16:47 UTC in reply to "RE: Abstraction"
viton Member since:
2005-08-09

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.

Reply Score: 1

RE: modularity
by gilboa on Wed 10th May 2006 20:43 UTC in reply to "modularity"
gilboa Member since:
2005-07-06

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.

Reply Score: 1

RE: modularity
by gilboa on Wed 10th May 2006 20:53 UTC in reply to "modularity"
gilboa Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: modularity
by gilboa on Wed 10th May 2006 20:54 UTC in reply to "RE: modularity"
gilboa Member since:
2005-07-06

Eeek... Edit doesn't work. Sorry for the bold.

Reply Score: 1

RE[2]: modularity
by viton on Thu 11th May 2006 10:28 UTC in reply to "RE: modularity"
viton Member since:
2005-08-09

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 =]

Reply Score: 1

RE[3]: modularity
by gilboa on Thu 11th May 2006 11:41 UTC in reply to "RE[2]: modularity"
gilboa Member since:
2005-07-06

... You didn't insult me. Your comment was just, err, out of place.

Reply Score: 1

RE: Abstraction
by theGrump on Tue 9th May 2006 22:51 UTC in reply to "Abstraction"
theGrump Member since:
2005-11-11

"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?

Reply Score: 1

RE: Abstraction
by d a v i d on Wed 10th May 2006 00:39 UTC in reply to "Abstraction"
d a v i d Member since:
2005-07-06

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.

Reply Score: 0

RE[2]: Abstraction
by hobgoblin on Wed 10th May 2006 08:07 UTC in reply to "RE: Abstraction"
hobgoblin Member since:
2005-07-06

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

Reply Score: 1

RE[3]: Abstraction
by Bending Unit on Wed 10th May 2006 09:23 UTC in reply to "RE[2]: Abstraction"
Bending Unit Member since:
2005-07-06

Except that many use oo to handle complexity.

Reply Score: 1

RE[3]: Abstraction
by Jack Burton on Wed 10th May 2006 09:57 UTC in reply to "RE[2]: Abstraction"
Jack Burton Member since:
2005-07-06

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

Reply Score: 1

RE[4]: Abstraction
by Cloudy on Wed 10th May 2006 16:19 UTC in reply to "RE[3]: Abstraction"
Cloudy Member since:
2006-02-15

"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++)

Reply Score: 2

RE: Abstraction
by shulud on Thu 11th May 2006 09:06 UTC in reply to "Abstraction"
shulud Member since:
2006-05-11

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

Reply Score: 1

Hybrid design is the middle ground
by Jody on Tue 9th May 2006 21:52 UTC
Jody
Member since:
2005-06-30

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.

Reply Score: 5

RE: My Take
by setuid_w00t on Tue 9th May 2006 22:06 UTC
setuid_w00t
Member since:
2005-10-22

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

Reply Score: 5

RE[2]: My Take
by vitae on Tue 9th May 2006 22:17 UTC in reply to "RE: My Take"
vitae Member since:
2006-02-20

Thom tolerates no criticism.

Reply Score: 5

Thom
by Dark Leth on Tue 9th May 2006 22:10 UTC
Dark Leth
Member since:
2005-07-06

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.

Reply Score: 3

Gotta Love Linus
by segedunum on Tue 9th May 2006 22:12 UTC
segedunum
Member since:
2005-07-06

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.

Reply Score: 4

RE: Gotta Love Linus
by twenex on Tue 9th May 2006 22:29 UTC in reply to "Gotta Love Linus"
twenex Member since:
2006-04-21

Stole my thunder! I was about to ask Linux to tell us what he REALLY thinks! :-)

Reply Score: 1

RE[2]: Gotta Love Linus
by hobgoblin on Wed 10th May 2006 08:20 UTC in reply to "RE: Gotta Love Linus"
hobgoblin Member since:
2005-07-06

ask the kernel? and do kernel's have gender's?

Reply Score: 2

RE[3]: Gotta Love Linus
by twenex on Wed 10th May 2006 15:18 UTC in reply to "RE[2]: Gotta Love Linus"
twenex Member since:
2006-04-21

Kernels have feelings, too (but perhaps not genders) ;-)

Reply Score: 1

RE[4]: Gotta Love Linus
by AlexandreAM on Wed 10th May 2006 16:12 UTC in reply to "RE[3]: Gotta Love Linus"
AlexandreAM Member since:
2006-02-06

If kernels have no genders I cannot understand how come we ended up with "Hybrid" Kernels...

Gee... Kernel sex is a strange concept...

Reply Score: 3

RE[5]: Gotta Love Linus
by twenex on Wed 10th May 2006 16:36 UTC in reply to "RE[4]: Gotta Love Linus"
twenex Member since:
2006-04-21

If kernels DO have genders, do microkernels get PMS?

Reply Score: 1

RE: Gotta Love Linus
by diegocg on Tue 9th May 2006 23:04 UTC in reply to "Gotta Love Linus"
diegocg Member since:
2005-07-08

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

Reply Score: 3

RE: Gotta Love Linus
by haugland on Wed 10th May 2006 11:20 UTC in reply to "Gotta Love Linus"
haugland Member since:
2005-07-07

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?

Reply Score: 1

RE[2]: Gotta Love Linus
by rcsteiner on Wed 10th May 2006 15:43 UTC in reply to "RE: Gotta Love Linus"
rcsteiner Member since:
2005-07-12

(1) It works.

(2) It's free (both libre and gratis)

(3) There aren't many other alternatives which fit #1 and #2.

Reply Score: 1

Agreed
by diegocg on Tue 9th May 2006 22:16 UTC
diegocg
Member since:
2005-07-08

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)

Reply Score: 5

RE: Agreed
by kaiwai on Wed 10th May 2006 04:45 UTC in reply to "Agreed"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: Agreed
by RenatoRam on Wed 10th May 2006 06:56 UTC in reply to "RE: Agreed"
RenatoRam Member since:
2005-11-14

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.

Reply Score: 1

a word from a programmer
by postmodern on Tue 9th May 2006 22:24 UTC
postmodern
Member since:
2006-01-27

"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?

Reply Score: 5

RE: a word from a programmer
by JohnOne on Wed 10th May 2006 02:12 UTC in reply to "a word from a programmer"
JohnOne Member since:
2006-03-25

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

Reply Score: 4

RE[2]: a word from a programmer
by Cloudy on Wed 10th May 2006 05:38 UTC in reply to "RE: a word from a programmer"
Cloudy Member since:
2006-02-15

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.

Reply Score: 2

RE: a word from a programmer
by ebasconp on Wed 10th May 2006 02:38 UTC in reply to "a word from a programmer"
ebasconp Member since:
2006-05-09

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.

Reply Score: 2

RE[2]: a word from a programmer
by Mystilleef on Wed 10th May 2006 02:43 UTC in reply to "RE: a word from a programmer"
Mystilleef Member since:
2005-06-29

Yeah, those are true in theory.

Reply Score: 0

RE[2]: a word from a programmer
by ma_d on Wed 10th May 2006 02:50 UTC in reply to "RE: a word from a programmer"
ma_d Member since:
2005-06-29

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.

Reply Score: 4

RE[2]: a word from a programmer
by flav2000 on Wed 10th May 2006 02:53 UTC in reply to "RE: a word from a programmer"
flav2000 Member since:
2006-02-08

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.

Reply Score: 2

The Hidden Nature of Software
by Mapou on Tue 9th May 2006 22:38 UTC
Mapou
Member since:
2006-05-09

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.

Reply Score: 2

RE: The Hidden Nature of Software
by blahblah on Wed 10th May 2006 00:18 UTC in reply to "The Hidden Nature of Software"
blahblah Member since:
2006-03-23

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!

Reply Score: 2

Mapou Member since:
2006-05-09

ahahaha... Thanks. Any publicity is good publicity.

Reply Score: 1

axilmar Member since:
2006-03-20

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.

Reply Score: 1

nii_ Member since:
2005-07-11

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?

Reply Score: 1

Mapou Member since:
2006-05-09

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.

Reply Score: 2

nii_ Member since:
2005-07-11

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!

Reply Score: 1

Mapou Member since:
2006-05-09

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

Reply Score: 1

Cloudy Member since:
2006-02-15

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

Reply Score: 2

Mapou Member since:
2006-05-09

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.

Reply Score: 1

corentin Member since:
2005-08-08

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

Reply Score: 3

axilmar Member since:
2006-03-20

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.

Reply Score: 1

Cloudy Member since:
2006-02-15

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.

Reply Score: 1

Mapou Member since:
2006-05-09

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

Reply Score: 1

corentin Member since:
2005-08-08

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

Reply Score: 2

rycamor Member since:
2005-07-18

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

Reply Score: 1

Mapou Member since:
2006-05-09

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.

Reply Score: 1

Cloudy Member since:
2006-02-15

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

Reply Score: 3

Cloudy Member since:
2006-02-15

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

Reply Score: 1

RE: The Hidden Nature of Software
by axilmar on Wed 10th May 2006 09:44 UTC in reply to "The Hidden Nature of Software"
axilmar Member since:
2006-03-20

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.

Reply Score: 1

Mapou Member since:
2006-05-09

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.

Reply Score: 1

rycamor Member since:
2005-07-18

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

Reply Score: 2

axilmar Member since:
2006-03-20

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

Reply Score: 1

Mapou Member since:
2006-05-09

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.

Reply Score: 1

Cloudy Member since:
2006-02-15

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.

Reply Score: 1

Mapou Member since:
2006-05-09

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.

Reply Score: 2

Cloudy Member since:
2006-02-15

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.

Reply Score: 1

beyert Member since:
2006-05-10

> 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

Reply Score: 1

renox Member since:
2005-07-06

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

Reply Score: 1

My take: Full of crap!
by aGNUstic on Tue 9th May 2006 22:38 UTC
aGNUstic
Member since:
2005-07-28

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

Reply Score: 2

RE: My take: Full of crap!
by BryanFeeney on Tue 9th May 2006 23:03 UTC in reply to "My take: Full of crap!"
BryanFeeney Member since:
2005-07-06

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.

Reply Score: 2

RE[2]: Communism
by archiesteel on Tue 9th May 2006 23:04 UTC
archiesteel
Member since:
2005-07-02

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.

Reply Score: 1

RE[3]: Communism
by twenex on Tue 9th May 2006 23:11 UTC in reply to "RE[2]: Communism"
twenex Member since:
2006-04-21

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.

Reply Score: 1

RE[3]: Communism
by dylansmrjones on Wed 10th May 2006 00:30 UTC in reply to "RE[2]: Communism"
dylansmrjones Member since:
2005-10-02

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

Reply Score: 1

RE[4]: Communism
by spectator on Wed 10th May 2006 05:41 UTC in reply to "RE[3]: Communism"
spectator Member since:
2006-02-27

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

Reply Score: 1

RE[5]: Communism
by dylansmrjones on Wed 10th May 2006 10:43 UTC in reply to "RE[4]: Communism"
dylansmrjones Member since:
2005-10-02

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

Reply Score: 1

My Take
by Mystilleef on Wed 10th May 2006 00:00 UTC
Mystilleef
Member since:
2005-06-29

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

Reply Score: 2

Zen
by saxiyn on Wed 10th May 2006 00:21 UTC
saxiyn
Member since:
2005-07-08

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/

Reply Score: 3

RE: Zen
by haugland on Wed 10th May 2006 11:35 UTC in reply to "Zen"
haugland Member since:
2005-07-07

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?

Reply Score: 2

RE[4]: Communism
by archiesteel on Wed 10th May 2006 00:36 UTC
archiesteel
Member since:
2005-07-02

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

Reply Score: 2

RE[4]: Communism
by archiesteel on Wed 10th May 2006 00:47 UTC
archiesteel
Member since:
2005-07-02

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

Reply Score: 1

RE[5]: Communism
by dylansmrjones on Wed 10th May 2006 01:05 UTC in reply to "RE[4]: Communism"
dylansmrjones Member since:
2005-10-02

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

Reply Score: 1

RE[6]: Communism
by bryanv on Wed 10th May 2006 17:19 UTC in reply to "RE[5]: Communism"
bryanv Member since:
2005-08-26

you make it hard. Very hard indeed.

That's what I told my girlfriend last night.

Reply Score: 2

RE[7]: Communism
by tomcat on Wed 10th May 2006 18:07 UTC in reply to "RE[6]: Communism"
tomcat Member since:
2006-01-06

That's what I told my girlfriend last night.

It's not what you TELL her. It's what you SHOW her. ;-p

Reply Score: 1

My Take!
by Brendan on Wed 10th May 2006 01:09 UTC
Brendan
Member since:
2005-11-16

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.

Reply Score: 5

RE: My Take!
by CrLf on Wed 10th May 2006 18:54 UTC in reply to "My Take!"
CrLf Member since:
2006-01-03

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

Reply Score: 3

RE[2]: My Take!
by Brendan on Thu 11th May 2006 04:25 UTC in reply to "RE: My Take!"
Brendan Member since:
2005-11-16

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.

Reply Score: 1

RE[3]: My Take!
by Cloudy on Thu 11th May 2006 05:07 UTC in reply to "RE[2]: My Take!"
Cloudy Member since:
2006-02-15

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

Reply Score: 1

RE[4]: My Take!
by Brendan on Thu 11th May 2006 06:40 UTC in reply to "RE[3]: My Take!"
Brendan Member since:
2005-11-16

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

Reply Score: 1

RE[5]: My Take!
by Cloudy on Thu 11th May 2006 08:14 UTC in reply to "RE[4]: My Take!"
Cloudy Member since:
2006-02-15

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

Reply Score: 1

RE[6]: My Take!
by Brendan on Thu 11th May 2006 09:20 UTC in reply to "RE[5]: My Take!"
Brendan Member since:
2005-11-16

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.

Reply Score: 1

RE[7]: My Take!
by Cloudy on Thu 11th May 2006 16:04 UTC in reply to "RE[6]: My Take!"
Cloudy Member since:
2006-02-15

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.

Reply Score: 1

My Take
by Anon on Wed 10th May 2006 02:43 UTC
Anon
Member since:
2006-01-02

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.

Reply Score: 5

RE: My Take
by haugland on Wed 10th May 2006 11:39 UTC in reply to "My Take"
haugland Member since:
2005-07-07

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.

Reply Score: 1

RE[2]: My Take
by Ookaze on Wed 10th May 2006 12:24 UTC in reply to "RE: My Take"
Ookaze Member since:
2005-11-14

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.

Reply Score: 2

Mix them up!
by werfu on Wed 10th May 2006 03:04 UTC
werfu
Member since:
2005-09-15

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.

Reply Score: 1

Abstraction, Microkernels and OS X
by logicnazi on Wed 10th May 2006 03:05 UTC
logicnazi
Member since:
2005-09-21

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.

Reply Score: 3

lol
by Duffman on Wed 10th May 2006 04:24 UTC
Duffman
Member since:
2005-11-23

"shown to be bull" "is also total crap" "is equally flawed."

Linus talks just like a 10 years old children ...

Reply Score: 2

Tanenbaum is right
by sathishmls on Wed 10th May 2006 05:39 UTC
sathishmls
Member since:
2005-11-13

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

Reply Score: 2

RE: Tanenbaum is right
by Ookaze on Wed 10th May 2006 10:15 UTC in reply to "Tanenbaum is right"
Ookaze Member since:
2005-11-14

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 !

Reply Score: 5

RE[2]: Tanenbaum is right
by sathishmls on Wed 10th May 2006 18:35 UTC in reply to "RE: Tanenbaum is right"
sathishmls Member since:
2005-11-13

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.

Reply Score: 1

martinus
Member since:
2005-07-06

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

Reply Score: 4

Confusion reigns
by Cloudy on Wed 10th May 2006 05:45 UTC
Cloudy
Member since:
2006-02-15

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

Reply Score: 5

RE: Confusion reigns
by twenex on Wed 10th May 2006 13:11 UTC in reply to "Confusion reigns"
twenex Member since:
2006-04-21

I want to mod you up again.

Reply Score: 1

Microkernels are killing OSNEWS
by mike hess on Wed 10th May 2006 06:04 UTC
mike hess
Member since:
2005-08-22

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.

Reply Score: 2

Flexibillity
by John Nilsson on Wed 10th May 2006 06:41 UTC
John Nilsson
Member since:
2005-07-06

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

Reply Score: 1

Well, let's see
by ratatask on Wed 10th May 2006 09:48 UTC
ratatask
Member since:
2006-01-28
What I'm missing
by somejan on Wed 10th May 2006 10:16 UTC
somejan
Member since:
2006-05-10

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.

Reply Score: 1

Neither one is the answer
by Windlord on Wed 10th May 2006 10:26 UTC
Windlord
Member since:
2006-01-07

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

Reply Score: 1

Think different
by gousiosg on Wed 10th May 2006 11:00 UTC
gousiosg
Member since:
2006-03-02

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

Reply Score: 1

RE: Think different
by suryad on Wed 10th May 2006 15:36 UTC in reply to "Think different"
suryad Member since:
2005-07-09

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?

Reply Score: 1

RE[2]: Think different
by gousiosg on Wed 10th May 2006 21:10 UTC in reply to "RE: Think different"
gousiosg Member since:
2006-03-02

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)

Reply Score: 1

RE[3]: Think different
by renox on Wed 10th May 2006 21:34 UTC in reply to "RE[2]: Think different"
renox Member since:
2005-07-06

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

Reply Score: 1

RE[4]: Think different
by nii_ on Thu 11th May 2006 13:28 UTC in reply to "RE[3]: Think different"
nii_ Member since:
2005-07-11

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.

Reply Score: 1

RE[3]: Think different
by Cloudy on Wed 10th May 2006 22:26 UTC in reply to "RE[2]: Think different"
Cloudy Member since:
2006-02-15

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.

Reply Score: 4

RE[4]: Think different
by renox on Thu 11th May 2006 07:43 UTC in reply to "RE[3]: Think different"
renox Member since:
2005-07-06

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.

Reply Score: 1

RE[3]: a word from a programmer
by MamiyaOtaru on Wed 10th May 2006 11:25 UTC
MamiyaOtaru
Member since:
2005-11-11

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

Reply Score: 3

We Have Hurd It All Before
by chemical_scum on Wed 10th May 2006 12:10 UTC
chemical_scum
Member since:
2005-11-02

We Have Hurd It All Before.

Reply Score: 4

Linus should know better
by StephenBeDoper on Wed 10th May 2006 15:41 UTC
StephenBeDoper
Member since:
2005-07-06

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

Reply Score: 1

Microkernel on a cell cpu
by stefanpa on Wed 10th May 2006 12:12 UTC
stefanpa
Member since:
2006-01-03

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.

Reply Score: 1

Linus Torvalds may be wrong...
by Governa on Wed 10th May 2006 16:45 UTC
Governa
Member since:
2006-04-09

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.

Reply Score: 1

RE: Linus Torvalds may be wrong...
by twenex on Wed 10th May 2006 17:33 UTC in reply to "Linus Torvalds may be wrong..."
twenex Member since:
2006-04-21

Of course he's God!

Kidding. You're right.

And your English is fine :-)

Reply Score: 2

RE: Linus Torvalds may be wrong...
by silicon on Wed 10th May 2006 19:13 UTC
silicon
Member since:
2005-07-30

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.

Reply Score: 1

Thom_Holwerda Member since:
2005-06-29

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.

Reply Score: 5

Deviation from "No One-True Way" Rule
by middleware on Thu 11th May 2006 00:44 UTC
middleware
Member since:
2006-05-11

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.

Reply Score: 1

axilmar
Member since:
2006-03-20

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 80x86, 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.

Reply Score: 1

nii_ Member since:
2005-07-11

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.

Reply Score: 1

Cloudy Member since:
2006-02-15

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

Reply Score: 1

Cloudy Member since:
2006-02-15

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.

Reply Score: 1

Boring again plus hypocrite
by mgiammarco on Thu 11th May 2006 12:54 UTC
mgiammarco
Member since:
2006-04-25

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.

Reply Score: 1