The Singularity project at MSR looked at this problem in a different way. What if each piece of software carries a protocol specification? What services it will require, in what order?
Then you can do various clever things involving proving that the system won't do anything malicious. If the software tries to do something outside of its specified protocol, then zappo, it's gone. This has the nice side effect that you don't need to rely on hardware memory protection and therefore you don't have to pay context switches. Singularity's process startup and kill times leave everyone else for dead.
But Singularity only works because of language features and requires you to do everything in a conforming language (Spec#). Probably the most meaningful predecessor was Oberon.
Minix has a better chance of working in the "real world" because it takes a less all-or-nothing approach to the problem. For instance, Minix3 is coded in C, which is fast but unsafe. But Minix supports a lot of POSIX and could conceivably add Linux emulation as a module, whereas Singularity requires you to rewrite everything to enjoy the guarantees.
Tanenbaum makes the further point that no matter what you prove, software has bugs. If you isolate the bugs you reduce their cost. If you simplify recovery from failure you reduce their cost still further. A microkernel approach does just these things and so would presumably be more reliable on a per-line-of-code basis than a monolithic kernel.
I'd recommend people take a look at the source code for Minix 3. It's actually pretty easy to wrap your head around, even for a C-phobic person like I am.
Again, no. The microwaves don't interact with organic matter, they pass through. You're not getting cancer from TV broadcasts or mobile phone towers either.
Note that I didn't say "bug free" - take three different architectures, and have three different teams write the code for them. Connect them in a "majority rules" redundant configuration. The odds of two of them experiencing bugs at the same time (or of having a hardware failure) producing the same result at the same time is pretty, well, astronomical...
Boeing tested this hypothesis -- it's called N-Version Programming -- and it doesn't work as nicely as we'd like. If you assume that the distribution of bugs is evenly random then yes, it's a great idea. But bugs don't do that, they tend to be clustered in particular modules and sections of code.
Boeing's study showed that multiple teams tended to have bugs in the same, complex areas. It was more cost-effective to do one implementation and spend more on it -- formal inspections, formal method proofs etc -- than to try N-Version Programming.
Sorry that I don't have a citation -- I think I saw it discussed in one of Steve McConnell's books.
Orbital solar has the direct benefit that it's much easier to sell. "Microwave" is slightly less scary than "nuclear" in the mind of the general public. The former gets the nod for thousands of mobile phone towers, but the latter has been stalled for decades.
The long-term side advantage of orbital solar is that it gives us an industrial foothold in space. That's important.
People basically don't know how staggeringly vast the resources are in our own solar system. There are lakes on Titan with more hydrocarbons than we've ever burnt or discovered on Earth. The planetoid Ceres has more fresh water than the Earth. There's enough minerals to... well, you get the idea.
More to the point, you have effectively unlimited energy. Need 20, 30 or 100 gigawatts to perform massive industrial chemistry? No problem, build more panels, there's plenty of room.
True, but I don't find many folks bringing up simcity experiences in discussions about nuclear power. But mention orbital solar and somebody busts out a joke about the beam going off course and dispatching fire trucks.
The trick to remember is that the Earth is actually quite a small part of the sky when seen from a satellite in geostationary orbit. It seems big to us, but it's just a pale blue dot after all.
I believe it falls into an available part of the spectrum that's not being used or which could be made available.
I suppose you could try to use it for some sort of electronic warfare, but again it's a James Bond way to go about it. Too much money for a very limited, very easy to destroy platform. 200MW is not that much to work with.
So, like above, if you have rocketry and aviation you can achieve disruption of that sort in better, cheaper ways.
Pretty much any time orbital solar gets discussed on Slashdot, there's a bunch of jokes about Sim City, somebody wonders if it can be weaponised and somebody else thinks we're all going to be cooked. It makes me grind my teeth, orbital solar is one of my areas of interest. Usually I'm too late to add to the discussion, but not this time!:D
Still, for a bunch of geeks, Slashdot users sometimes seem to know very little about space.:/
1. Orbital solar platforms cannot be used as weapons unless you are trying to drop them on someone (which is true of anything in orbit). The energy they put out is the wrong frequency; it doesn't interact with human biology at all.
2. If you can build 25 ton to LEO heavy lifters, James Bondesque schemes are a waste of time. Better to lob nukes. Heck, even throwing a 25 ton block of concrete on a ballistic course would be more far, far more dangerous than 100 years of orbital solar power transmissions.
1. Very expensive way to perform geoengineering. There are cheaper proposals (iron seeding, spray boats, atmospheric particles etc) around.
2. Sunlight exerts pressure, so if it's not in an orbit, it will soon be on its way out of the solar system. There was a proposal to build fresnel lenses instead.
You've misread me. I said it does not interact with water.
The point is that if you want to transmit power, you want to minimise power losses. If you choose a frequency that does not interact with atmospheric gasses -- including water vapour -- then you minimise those losses.
It does not interact with water, including the water which makes up your person.
There are a number of points you can choose that are geostationary and in shadow less than 2% of the time (as I recall the 1970s proposal). Other schemes call for having multiple satellites that hand off to each other. This proposal is I think of the former variety.
Plus in space solar power is available constantly, rather than being affected by night time, winter hours and weather. As they point out you don't have to pay for the real estate, just the trip to get there.
And it gives more consistent power because you don't get dust settling on the panels. I realise that sounds stupid, but dust can reduce efficiency by a lot in a few years; your costs go up because you have to pay people to be cleaning acres and acres of solar panels.
Slashdot Mirror
The Singularity project at MSR looked at this problem in a different way. What if each piece of software carries a protocol specification? What services it will require, in what order?
Then you can do various clever things involving proving that the system won't do anything malicious. If the software tries to do something outside of its specified protocol, then zappo, it's gone. This has the nice side effect that you don't need to rely on hardware memory protection and therefore you don't have to pay context switches. Singularity's process startup and kill times leave everyone else for dead.
But Singularity only works because of language features and requires you to do everything in a conforming language (Spec#). Probably the most meaningful predecessor was Oberon.
Minix has a better chance of working in the "real world" because it takes a less all-or-nothing approach to the problem. For instance, Minix3 is coded in C, which is fast but unsafe. But Minix supports a lot of POSIX and could conceivably add Linux emulation as a module, whereas Singularity requires you to rewrite everything to enjoy the guarantees.
Tanenbaum makes the further point that no matter what you prove, software has bugs. If you isolate the bugs you reduce their cost. If you simplify recovery from failure you reduce their cost still further. A microkernel approach does just these things and so would presumably be more reliable on a per-line-of-code basis than a monolithic kernel.
I'd recommend people take a look at the source code for Minix 3. It's actually pretty easy to wrap your head around, even for a C-phobic person like I am.
Australia's own Chairman Rudd, on the other hand, might see it as a sort of backhanded compliment.
No. When you're that far away, the Earth is actually a small part of the sky. You're only in the shade for a few hours each year.
It's a pretty useless deathray. It could cause about as much death as a giant orbiting frowny face.
Well said. I'm not an expert, just an interested layperson.
Because it won't cause cancer, because it doesn't work like Sim City.
Has he got a little list?
Big rock candy orbits.
Again, no. The microwaves don't interact with organic matter, they pass through. You're not getting cancer from TV broadcasts or mobile phone towers either.
Note that I didn't say "bug free" - take three different architectures, and have three different teams write the code for them. Connect them in a "majority rules" redundant configuration. The odds of two of them experiencing bugs at the same time (or of having a hardware failure) producing the same result at the same time is pretty, well, astronomical...
Boeing tested this hypothesis -- it's called N-Version Programming -- and it doesn't work as nicely as we'd like. If you assume that the distribution of bugs is evenly random then yes, it's a great idea. But bugs don't do that, they tend to be clustered in particular modules and sections of code.
Boeing's study showed that multiple teams tended to have bugs in the same, complex areas. It was more cost-effective to do one implementation and spend more on it -- formal inspections, formal method proofs etc -- than to try N-Version Programming.
Sorry that I don't have a citation -- I think I saw it discussed in one of Steve McConnell's books.
There are alternative proposals where you have a fleet of satellites in closer orbit, continuously "handing off" to different receiver sites.
Orbital solar has the direct benefit that it's much easier to sell. "Microwave" is slightly less scary than "nuclear" in the mind of the general public. The former gets the nod for thousands of mobile phone towers, but the latter has been stalled for decades.
The long-term side advantage of orbital solar is that it gives us an industrial foothold in space. That's important.
People basically don't know how staggeringly vast the resources are in our own solar system. There are lakes on Titan with more hydrocarbons than we've ever burnt or discovered on Earth. The planetoid Ceres has more fresh water than the Earth. There's enough minerals to ... well, you get the idea.
More to the point, you have effectively unlimited energy. Need 20, 30 or 100 gigawatts to perform massive industrial chemistry? No problem, build more panels, there's plenty of room.
True, but I don't find many folks bringing up simcity experiences in discussions about nuclear power. But mention orbital solar and somebody busts out a joke about the beam going off course and dispatching fire trucks.
I've yet to meet anyone who thinks the moon shines out of their arse.
The trick to remember is that the Earth is actually quite a small part of the sky when seen from a satellite in geostationary orbit. It seems big to us, but it's just a pale blue dot after all.
I believe it falls into an available part of the spectrum that's not being used or which could be made available.
I suppose you could try to use it for some sort of electronic warfare, but again it's a James Bond way to go about it. Too much money for a very limited, very easy to destroy platform. 200MW is not that much to work with.
So, like above, if you have rocketry and aviation you can achieve disruption of that sort in better, cheaper ways.
Will it leave a narrow trail of roasted humans across California?
No. The microwaves are the wrong frequency, they don't interact with water and will pass straight through any living creature.
Pretty much any time orbital solar gets discussed on Slashdot, there's a bunch of jokes about Sim City, somebody wonders if it can be weaponised and somebody else thinks we're all going to be cooked. It makes me grind my teeth, orbital solar is one of my areas of interest. Usually I'm too late to add to the discussion, but not this time! :D
Still, for a bunch of geeks, Slashdot users sometimes seem to know very little about space. :/
1. Orbital solar platforms cannot be used as weapons unless you are trying to drop them on someone (which is true of anything in orbit). The energy they put out is the wrong frequency; it doesn't interact with human biology at all.
2. If you can build 25 ton to LEO heavy lifters, James Bondesque schemes are a waste of time. Better to lob nukes. Heck, even throwing a 25 ton block of concrete on a ballistic course would be more far, far more dangerous than 100 years of orbital solar power transmissions.
1. Very expensive way to perform geoengineering. There are cheaper proposals (iron seeding, spray boats, atmospheric particles etc) around.
2. Sunlight exerts pressure, so if it's not in an orbit, it will soon be on its way out of the solar system. There was a proposal to build fresnel lenses instead.
You've misread me. I said it does not interact with water.
The point is that if you want to transmit power, you want to minimise power losses. If you choose a frequency that does not interact with atmospheric gasses -- including water vapour -- then you minimise those losses.
It does not interact with water, including the water which makes up your person.
There are a number of points you can choose that are geostationary and in shadow less than 2% of the time (as I recall the 1970s proposal). Other schemes call for having multiple satellites that hand off to each other. This proposal is I think of the former variety.
It depends on what sort of arse you have. There are some who believe that they can generate anal solar power.
Plus in space solar power is available constantly, rather than being affected by night time, winter hours and weather. As they point out you don't have to pay for the real estate, just the trip to get there.
And it gives more consistent power because you don't get dust settling on the panels. I realise that sounds stupid, but dust can reduce efficiency by a lot in a few years; your costs go up because you have to pay people to be cleaning acres and acres of solar panels.