The assumption here is that the microkernel would mostly protect against a software logic error (aka bug) not faulty hardware. (note though some graphics drivers will protect and try to recover from some of the hardware flaws). So say, the computer in your car would not make your car driveable if all your oil has leaked out. Meaning that the hardware has to work correctly.
Otherwise the main job of the microkernel is to enforce security policies, which means protect exactly against some driver "messing up things". So if there is a way for a driver to lock up the PCI bus by setting the wrong register then the microkernel should be the setting the registers. The way the drivers are written is totally diferent in the microkernel archicture. All the interrupts are processed by the microkernel, not immediatly by the drivers. Some slides about this:
here
Good point, I already switched to using Python and my life because 10x easier. With the help of Psyco and another 512Mb RAM speed can be greatly increased or I use weave to code some of the fast stuff in C. Over the years as I had to look through other people's code I have come to appreciate the value of clear straight forward programming without kewl l33t hacks and Python does enforce that to a cerain extent. Whoever said that in Python "there is only one -- correct -- way to do something" was quite right.
Ok, so then I'll ask, "what are the chances that linux will be DO-178B certified?" And I'll make it easy and answer it for you too -- "Very close to 0."
You don't have to prove it, as long as the microkernel will be able to put the system into a predetermined state, it could for example unload the driver and try another one or just try to relaod it, it could contact you via a pager and so on. As opposed to the whole system freezing because some idiot wrote if(a=1) instead of if(a==1) in the mouse driver. You can only hope that the system that froze was running Doom and Firefox and wasn't flying planes, or administering drugs.
For a 10k lines microkernel it takes up to a year to prove its correctness. (specifically covert channel analysis -- see this paper for more on CCA).
Linux 2.6 has 6 million lines of code. Even assuming a linear increase (in reality it is exponential) it would take at least 600 years on the current hardware. If the time demands are exponential, you can forget it altogether
The microkernel may be more elegant, more pristine in the lab..... but it's slow by design
Today most of the software that is used to fly planes (both fighter jets and passenger) is based on a microkernel architecture. So microkernels are not just lab toys, real and mission critical systems are run by microkernel architectures.
The speed problem can often be solved just buy getting a faster hardware. The main reason Linus rejected microkernels back in the day was because the cost of context switches was prohibitive. Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines.
Also, there is nothing about a microkernel that makes it more inherently provably correct than a monolithic kernel.
Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k. It can already take up to a year to check the correctness of a 8k lines of code microkernel and there will be an exponential demand for resources as the code size increases. So in reality it will not be possible to check the linux kernel for correctness.
Today's pilots actually do very little and are there mostly to handle exceptional situations and for the peace of mind of passengers. Modern passenger planes can take off, fly and land without assistance. There isn't as much AI as you'd think. In other words there are no Neural Nets being trained to make the plane land. There are exact algorithms that do the jobs. The main help is from the radio signals that help determine where the landing strips are and help find the exact position of the plane. Surprisingly it is probably a lot easier to do the automated flying that would be to have automated driving in an arbitrary urban environment.
So the question would still remain if you would get on a plane if someone tells you that it will be flown by Linux 2.6? I would personally trust my life to INTEGRITY-178B from Green Hills -- which does have a microkernel architecture, before I would trust my life to a huge monolithic blob of code such as the Linux kernel.
You seem to completely ignore the main reason for using a microkernel -- the ability to prove (even mathematically) that the kernel is correct. In other words the main advantage is not to make a it "easy" or "fun" for the programmers to program, or make Quake run with 25fps faster,but but to enforce a strict and precise security policy. That is why critical real-time OSes are often based on a microkernel which is only about 4000-8000 lines of code. Even at that size is might take years to prove it does what it is supposed to do.
The analogy of centralisation vs. local autonomy is not totally accurate either. Both the monolithic and the microkernel are centralized, except that in the first case there a large beaurocratic structure and in the second case it just a dictator and a couple of "advisors". If the dictator or the king is chosen well, the system will be more predictable and will work much better. If case of the large beaurocratic system, if some of its members get corrupted [and they will because there are so many of them] the whole system will fail. It is like saying that a small bug in the mouse driver will freeze and crash the system with a monolithic kernel. Good thing if the system was only running Doom at the time and not controlling a reactor, or administering a drug. If the same happens in the microkernel system, the kernel will reload the driver, raise an alarm, or in general -- be able to take the system to a predictable predetermined state. Going back to the analogy is it is like having the dictator execute a corrupted staff member and replace him immediately.
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."
I know as a good and faithful/.-ers we should worship Linus and take all of his words as gospel, but in this case I think he is talking out of his arse. Microkernels are "more secure" and "more stable" because only one component needs to work well -- the microkernel, it's main job is to enforce security policies and that is it. If it works correctly it will be able to bring the system to a certain state during the failure of any of the other components.
Microkernels are used and have been used for a long time in "real" and "serious" operating systems, not just toy examples. Everytime/.-ers fly over the Atlantic it is a microkernel OS in all probability that makes sure they don't crash and burn. The size of those microkernel is kept at no more than 10k lines -- and even so it can take years to prove its correctness. It would be impossible to do it with Linus's kernel. So if Linus and others are so against the microkernel acrhitectures I would want to see them trust their lives to a Linux 2.6 -- put their lives were their mouth (or code) is, so to speak.
Tovarisch Gorshkov, to prove that the program is correct ("covert channel analysis" and such.) might take up to a year and that is only if there are less than 10k lines of code and no more, but that doesn't mean that the program will _run_ slow. The time and methods used to prove correctness don't necessarily say anything about the speed of the program during runtime.
So correct systems will always be better, because you know it is correct and you know the limits (want it to run faster -- just buy faster hardware ). On the other hand, if the program hasn't been been proved to work correctly, even though it might be blazingly fast, one day it might just stop working and your control rods will end up being stuck half way through, all because there is a "off-by-one" error in some stupid serial driver or something like that...
So then let me ask you this: Would you get on a plane that is flown by Linus' latest 2.6 monolithic kernel? Could it be because a bug in one of the hundreds of drivers might lock up the system and you'll crash and die?
Most of the critical RT operating systems will have some kind of a ukernel architecture. velOSity is one such ukernel, it is used by the INTEGRITY OS made by Green Hills. The next time you fly on the plane it will probably be a ukernel that will make sure you land safely, not a monolithic blob that makes it impossible to mathematically prove security policies, which you would want in real important situations.
Linus will obviously defend his architecture choice. I don't see him all of the sudden deciding that ukernels are in any way "better", it is like having Microsoft opening the source code for Windows.
Back in the day the main argument was performance -- the cost of context switches. Today with machines that are probably 10x or 20x faster, context switches won't be such a big hit. So Linus had to come up with some other explanation -- "hard to code". The argument that there are no "real" OSes with microkernels today doesn't hold either.
Linus is a pragmatist. He didn't write Linux for academic purpose. He wanted it to work.
I don't know but an OS that flies thousands of people over the Atlantic every day without a crash is called a "working" OS in my book. And that OS is probably a ukernel.
Well, when Google starts making and shipping its own OS, it can make Google the default search engine for no cost as well. As much as we all hate Microsoft, doesn't it make sense to do what it does? If Google sold an OS, would it make Microsoft or Yahoo the default search engine?...let me guess..."No". Or would/. ers get just as upset at Google for making not so simple to use MSN or Yahoo in this hypothetical "Google OS"?
Most computers out there are probably bought to run office software, do email and browse the Web. The main reason that Windows is so successful is because there is MS Office that goes with it. Recently Openoffice has been getting pretty close to being useful (I switched) so I think the future is coming where the Linux on desktop for "the masses" would be possible.
Only after there is a good office application people will buy/use/learn Linux. Then other software will follow. The more software written for an OS -- the more people will use it. The more people use it -- the more software will be written for it.
Actually the industrial grade CAD/CAE/CAM programs used to be written for SGI, mainly just because they had better hardware for visualization (and pretty good servers too, we had a couple of quad R12000 machines). I used to work on a popular CAD/CAM/CAE application, the full package was millions and millions of lines of C,C++,Fortran, and custom scripting language. The primary customer and development platform was SGI, everyone had a nice SGI workstation on their desk, but we had ports to HP/UX, Solaris and AIX. When SGI started to suck, we decided to jump ship and slowly migrate to NT (Linux was still a toy OS then). It took years to do that and I think they are still working out the issues resulting from that (I left the company).
As another side project I worked with a developer on porting a Pre/Post Processing Visualization program from Windows to Unix using MainWin. The major stuff worked but there were 1000 little annoyances and bugs that never got solved. I don't think we ever sold that specific port.
Bottom line, just like you said -- porting sucks, especially if the original code was not written with portabily in mind...
Good point. The SMART while it looks just like a _smaller_ _smarter_ car handles completely differently during a crash. Typical cars are designed to buckle and bend to absorb the energy of the impact as much as possible. Under average conditions the buckling will hurt the driver too much but at higher speeds it certainly will. You can think of them as the driver sitting in the middle of a large stack of cardboard boxes. Some impact will be absorbed but only up to a point.
The SMART car on the other hand will _not_ buckle to absorb the energy of the impact. There is just not enough material in that little car to absorb even a small amount of energy with an inellastic deformation. The driver here sits in a rigid steel cage. Upon impact the cage will and act as a spring, the car will bounce off to the side. That could be good or bad depending on the location. The car might tollerate well the initial impact but if it is on a bridge it might get thrown off into the water, or fly over the into the incoming traffic, normally it should just bounce off to the side and stop in a ditch. In the case of the truck, if it is just the truck and the SMART car, the SMART car will bounce off to the side and probably out of the way of the truck and the driver will have a better chance of surviving than being in a big ass SUV.
Even though you mentioned terrorism as (half?)-joke, a fast FFT processor would probably be regualated by the govt., what that would mean is that people could just program in software a soffisticated and fast signal decoder that would normally cost tens or hundreds of thousands of dollars to buy as hardware. In a second it could all be reprogrammed into something else. So imagine having a police scanner, an HDTV, FM radio, etc etc all in just a laptop with some kind of a simple RF antenna input and amplifier. That would be quite insane -- decoding algorithms could just be downloaded from the Internet. Check out the GNU Radio project here here
A fast FFT processor, for example, would make the life easier for a lot of Photoshop filters users (with the help of special drivers and plugins), it would also help the GNU Radio quite a bit, as well as other multimedia/signal/data processing applications.
It is not surprising at all that life continues and moves on. According to the known data the topology of the gene network follows the "small world" pattern. That is there are a few genes that connect to many others but on the _average_ the number of genes connected to any one gene is small. So when a mutation occurs it is most likely to occur in the genes that are not "hubs" and thus the regulation (and phenotype) is not severly altered. This means that the genomes of most animals can handle quite a few mutations. But if just one of those critical "hub" genes gets mutated it would result in death.
Since when is the "average" user compiling with gcc and why do they care? The "average" Ubuntu user wants to browse the web, read email, write office documents. If those application have been tested and work fine, why should they care if it is gcc 3.x.x or gcc 99.x.x. As a developer you can probably figure out a way to get the latest/or alternatively older more stable version of gcc if you want.
It seems like the French already figured it out years before. And now are making money selling the electricity from their many nuclear power plants to others (read "Germany" where the Green Peace hippies managed to stop the building of nuclear power plants years ago). Whas is really that hard to predict that nuclear power can be made safe and will be a better option than becoming addicted to overseas oil? Sure Chernobyl happened (I was pretty close to it too) but they should have just looked at it that and said "let's see what they did wrong and fix and move on". Oh, no, they all freaked out: "OMG! Teh nucular power is teh evil -- must burn more oil and coal!".
Interesting. That is exactly what my friend, who is a salesman for Oracle told me. They have got the large contracts with the big industries and that's all they need. Like it or not MySQL is still viewed as a "cute" and "cool" little open source experiment. It might not be true but the perception is still there. We as developers and/.-er think "Wow, open source, kewl!" People who choose database vendors and make other such big IT decisions for companies like GM, Boeing, Wal-Mart and such, think "Open source = toy for the geeks".
Besides, companies don't want to buy just the software application (install, and go). They want to buy a relationship. They want top notch support, perhaps even an Oracle team to be on-site for a couple of months during deployment, they want someone to blame and to complain to when things don't work right. MySQL provides support but it is just not going to be the same quality.
I personally love MySQL. It is fast, I just don't think that Oracle feels threatened by it too much.
" I wonder how much energy did it consume to produce those huge amounts of Hydrogen & Oxygen? Will it be lesser than the power generated by the reaction between them? "
But of course! Now you take the energy generated and then produce more Hydrogen and Oxygen, then put it back in the cells and generate yet even more energy. The world's energy problems are solved at last! And who would have thought -- by a Japanese train and an observant Slashdotter.
But it will take only one crash caused by software in the future to put a major crimp in the acceptance of such "smart cars". This is the same mentality as air crashes. A lot more people die from smoking and car accidents each year, but OMG, air crash! The news goes around the world. Just a couple of days ago I heard of an air crash some place in Brazil -- 19 dead. I would think 100s more died in car accidents just in US, but that's not interesting news, of course. So the news will probably cover the one in 1000 car crash caused by software (or blamed on software -- watch everyone blame their speeding and parking tickets on software!), and everyone will stay away from those cars. Most people don't do research, they just go and shop with their emotions.
Slashdot Mirror
Otherwise the main job of the microkernel is to enforce security policies, which means protect exactly against some driver "messing up things". So if there is a way for a driver to lock up the PCI bus by setting the wrong register then the microkernel should be the setting the registers. The way the drivers are written is totally diferent in the microkernel archicture. All the interrupts are processed by the microkernel, not immediatly by the drivers. Some slides about this: here
Good point, I already switched to using Python and my life because 10x easier. With the help of Psyco and another 512Mb RAM speed can be greatly increased or I use weave to code some of the fast stuff in C. Over the years as I had to look through other people's code I have come to appreciate the value of clear straight forward programming without kewl l33t hacks and Python does enforce that to a cerain extent. Whoever said that in Python "there is only one -- correct -- way to do something" was quite right.
Ok, so then I'll ask, "what are the chances that linux will be DO-178B certified?" And I'll make it easy and answer it for you too -- "Very close to 0."
You don't have to prove it, as long as the microkernel will be able to put the system into a predetermined state, it could for example unload the driver and try another one or just try to relaod it, it could contact you via a pager and so on. As opposed to the whole system freezing because some idiot wrote if(a=1) instead of if(a==1) in the mouse driver. You can only hope that the system that froze was running Doom and Firefox and wasn't flying planes, or administering drugs.
Linux 2.6 has 6 million lines of code. Even assuming a linear increase (in reality it is exponential) it would take at least 600 years on the current hardware. If the time demands are exponential, you can forget it altogether
Today most of the software that is used to fly planes (both fighter jets and passenger) is based on a microkernel architecture. So microkernels are not just lab toys, real and mission critical systems are run by microkernel architectures.
The speed problem can often be solved just buy getting a faster hardware. The main reason Linus rejected microkernels back in the day was because the cost of context switches was prohibitive. Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines.
Also, there is nothing about a microkernel that makes it more inherently provably correct than a monolithic kernel.
Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k. It can already take up to a year to check the correctness of a 8k lines of code microkernel and there will be an exponential demand for resources as the code size increases. So in reality it will not be possible to check the linux kernel for correctness.
So the question would still remain if you would get on a plane if someone tells you that it will be flown by Linux 2.6? I would personally trust my life to INTEGRITY-178B from Green Hills -- which does have a microkernel architecture, before I would trust my life to a huge monolithic blob of code such as the Linux kernel.
The analogy of centralisation vs. local autonomy is not totally accurate either. Both the monolithic and the microkernel are centralized, except that in the first case there a large beaurocratic structure and in the second case it just a dictator and a couple of "advisors". If the dictator or the king is chosen well, the system will be more predictable and will work much better. If case of the large beaurocratic system, if some of its members get corrupted [and they will because there are so many of them] the whole system will fail. It is like saying that a small bug in the mouse driver will freeze and crash the system with a monolithic kernel. Good thing if the system was only running Doom at the time and not controlling a reactor, or administering a drug. If the same happens in the microkernel system, the kernel will reload the driver, raise an alarm, or in general -- be able to take the system to a predictable predetermined state. Going back to the analogy is it is like having the dictator execute a corrupted staff member and replace him immediately.
I know as a good and faithful /.-ers we should worship Linus and take all of his words as gospel, but in this case I think he is talking out of his arse. Microkernels are "more secure" and "more stable" because only one component needs to work well -- the microkernel, it's main job is to enforce security policies and that is it. If it works correctly it will be able to bring the system to a certain state during the failure of any of the other components.
Microkernels are used and have been used for a long time in "real" and "serious" operating systems, not just toy examples. Everytime /.-ers fly over the Atlantic it is a microkernel OS in all probability that makes sure they don't crash and burn. The size of those microkernel is kept at no more than 10k lines -- and even so it can take years to prove its correctness. It would be impossible to do it with Linus's kernel. So if Linus and others are so against the microkernel acrhitectures I would want to see them trust their lives to a Linux 2.6 -- put their lives were their mouth (or code) is, so to speak.
So correct systems will always be better, because you know it is correct and you know the limits (want it to run faster -- just buy faster hardware ). On the other hand, if the program hasn't been been proved to work correctly, even though it might be blazingly fast, one day it might just stop working and your control rods will end up being stuck half way through, all because there is a "off-by-one" error in some stupid serial driver or something like that...
Most of the critical RT operating systems will have some kind of a ukernel architecture. velOSity is one such ukernel, it is used by the INTEGRITY OS made by Green Hills. The next time you fly on the plane it will probably be a ukernel that will make sure you land safely, not a monolithic blob that makes it impossible to mathematically prove security policies, which you would want in real important situations.
Linus will obviously defend his architecture choice. I don't see him all of the sudden deciding that ukernels are in any way "better", it is like having Microsoft opening the source code for Windows.
Back in the day the main argument was performance -- the cost of context switches. Today with machines that are probably 10x or 20x faster, context switches won't be such a big hit. So Linus had to come up with some other explanation -- "hard to code". The argument that there are no "real" OSes with microkernels today doesn't hold either.
Linus is a pragmatist. He didn't write Linux for academic purpose. He wanted it to work. I don't know but an OS that flies thousands of people over the Atlantic every day without a crash is called a "working" OS in my book. And that OS is probably a ukernel.
Well, when Google starts making and shipping its own OS, it can make Google the default search engine for no cost as well. As much as we all hate Microsoft, doesn't it make sense to do what it does? If Google sold an OS, would it make Microsoft or Yahoo the default search engine? ...let me guess..."No". Or would /. ers get just as upset at Google for making not so simple to use MSN or Yahoo in this hypothetical "Google OS"?
Only after there is a good office application people will buy/use/learn Linux. Then other software will follow. The more software written for an OS -- the more people will use it. The more people use it -- the more software will be written for it.
As another side project I worked with a developer on porting a Pre/Post Processing Visualization program from Windows to Unix using MainWin. The major stuff worked but there were 1000 little annoyances and bugs that never got solved. I don't think we ever sold that specific port.
Bottom line, just like you said -- porting sucks, especially if the original code was not written with portabily in mind...
The SMART car on the other hand will _not_ buckle to absorb the energy of the impact. There is just not enough material in that little car to absorb even a small amount of energy with an inellastic deformation. The driver here sits in a rigid steel cage. Upon impact the cage will and act as a spring, the car will bounce off to the side. That could be good or bad depending on the location. The car might tollerate well the initial impact but if it is on a bridge it might get thrown off into the water, or fly over the into the incoming traffic, normally it should just bounce off to the side and stop in a ditch. In the case of the truck, if it is just the truck and the SMART car, the SMART car will bounce off to the side and probably out of the way of the truck and the driver will have a better chance of surviving than being in a big ass SUV.
Even though you mentioned terrorism as (half?)-joke, a fast FFT processor would probably be regualated by the govt., what that would mean is that people could just program in software a soffisticated and fast signal decoder that would normally cost tens or hundreds of thousands of dollars to buy as hardware. In a second it could all be reprogrammed into something else. So imagine having a police scanner, an HDTV, FM radio, etc etc all in just a laptop with some kind of a simple RF antenna input and amplifier. That would be quite insane -- decoding algorithms could just be downloaded from the Internet. Check out the GNU Radio project here here
A fast FFT processor, for example, would make the life easier for a lot of Photoshop filters users (with the help of special drivers and plugins), it would also help the GNU Radio quite a bit, as well as other multimedia/signal/data processing applications.
It is not surprising at all that life continues and moves on. According to the known data the topology of the gene network follows the "small world" pattern. That is there are a few genes that connect to many others but on the _average_ the number of genes connected to any one gene is small. So when a mutation occurs it is most likely to occur in the genes that are not "hubs" and thus the regulation (and phenotype) is not severly altered. This means that the genomes of most animals can handle quite a few mutations. But if just one of those critical "hub" genes gets mutated it would result in death.
God Bless America!
Since when is the "average" user compiling with gcc and why do they care? The "average" Ubuntu user wants to browse the web, read email, write office documents. If those application have been tested and work fine, why should they care if it is gcc 3.x.x or gcc 99.x.x. As a developer you can probably figure out a way to get the latest/or alternatively older more stable version of gcc if you want.
/Sorry, mandatory Patrick Moore link
It seems like the French already figured it out years before. And now are making money selling the electricity from their many nuclear power plants to others (read "Germany" where the Green Peace hippies managed to stop the building of nuclear power plants years ago). Whas is really that hard to predict that nuclear power can be made safe and will be a better option than becoming addicted to overseas oil? Sure Chernobyl happened (I was pretty close to it too) but they should have just looked at it that and said "let's see what they did wrong and fix and move on". Oh, no, they all freaked out: "OMG! Teh nucular power is teh evil -- must burn more oil and coal!".
Besides, companies don't want to buy just the software application (install, and go). They want to buy a relationship. They want top notch support, perhaps even an Oracle team to be on-site for a couple of months during deployment, they want someone to blame and to complain to when things don't work right. MySQL provides support but it is just not going to be the same quality.
I personally love MySQL. It is fast, I just don't think that Oracle feels threatened by it too much.
" I wonder how much energy did it consume to produce those huge amounts of Hydrogen & Oxygen? Will it be lesser than the power generated by the reaction between them? " But of course! Now you take the energy generated and then produce more Hydrogen and Oxygen, then put it back in the cells and generate yet even more energy. The world's energy problems are solved at last! And who would have thought -- by a Japanese train and an observant Slashdotter.