As I recall comments from the initial announcement, Google had grown enough that they had to start filing stuff with the SEC like a publicly traded company (which costs lots of money in overhead) anyway, so they decided they might as well go the whole nine yards and raise some money too. Or at least that was one hypothesis.
Well, I guess it's "about the GPL" in the sense that it's the lack of the GPL as a defense that will doom SCO. What it's not about is proving the other, more important (IMHO) side of the GPL: that redistributors are required to make the source (with any changes) available. IBM's not in a position to argue that, since that's exactly what SCO was doing. Hence it's unlikely that this MSJ, at least, will touch on the core issue of the GPL--freedom of the code--which is what most people seem to be interpreting "enforce the GPL" as.
It turns out that in the Memorandum in Support, IBM does invoke part of the GPL--specifically, the part that says "no relicensing":
63. The GPL and LGPL provide that a person may rely on the GPL or LGPL as a license or grant of permission (to copy, modify or distribute code covered by the GPL or LGPL) only if the person abides by the terms of the GPL or LGPL. The GPL and LGPL expressly provide that any attempt otherwise to copy, modify, sublicense, or distribute the code licensed under the GPL or LGPL "is void, and will automatically terminate your rights under this License".
66. SCO has . . . attempted to copy, modify, sublicense, or distribute the code licensed under the GPL or LGPL other than as "expressly provided under [the GPL or LGPL]". [list of 14 violations follows]
So while it's not the whole shebang, it looks like we can at least expect part of the GPL to be discussed.
If you read the MSJ closely, IBM is actually saying: (emphasis added)
As a result of SCO's copying and distribution of IBM's code, SCO has unlawfully exercised IBM's rights to its works and therefore
infringed IBM's copyrights.
So this isn't really about the GPL--it's a simple copyright infringement issue. They're saying to the judge, "we own this code and SCO is distributing it without permission, so stop them".
On the other hand, they do go on to add:
Although IBM's contributions to Linux are copyrighted, they are permitted to be copied, modified and distributed by others under the terms of the GNU General Public License ("GPL") or the GNU Lesser General Public License ("LGPL") (collectively, the "GPL"). However, SCO has renounced, disclaimed and breached the GPL and therefore the GPL does not give SCO permission or a license to copy and distribute IBM's copyrighted works.
So if SCO is going to mount a defense to this MSJ, they'll have to argue for the GPL, essentially countering their own earlier claims that the GPL is invalid and forcing them to tell the judge "uh, we were wrong". This isn't about IBM "testing" the GPL, it's about them grabbing two big boulders and squishing SCO between them. (:
If the GPL did end up being ruled on by the judge, about the only ruling I could see is that the GPL is valid and therefore SCO has not infringed IBM's copyrights--but IANAL, so what do I know?
It's just a dumbed-down way of saying "energy stored in used coolant water is transferred to cold water from the lake". If you look at the diagram in the article, it's pretty clear: they run the cooling water alongside the lakewater to bleed (is that the right term?) the heat out, then send the heated lakewater out to the city as tap water--in essence "extracting the cold" from the lakewater and "storing" it in the cooling system.
And its wonderful dictionary, with words like ninnyish. I lost in my 6th grade school finals on that, and I'm still pissed about it. They could have at least picked words that exist!
On newer CF cards they have an internal microprocessor that constantly remaps the logical addresses of the drive to different physical addresses [...] So even though the OS thinks it's writing the FAT to that same spot on the drive, the drive is really moving that spot around to maximize the life of the drive.
Wow. So forget trying to shred files on those. (Yes, mods, I realize it would still work at the filesystem level--that won't stop someone who cracks the case open and reads straight off the chips.)
And what about the memory where the logical-to-physical map is stored? Even if you rewrite the same sector to 10,000 different places, you'll have to rewrite the same map entry 10,000 times. Or is that part of the memory designed to withstand rewriting better?
According to the earlier/. article, the patent in question is on run-length coding, and was issued in 1987. Unless it was submarined for a really long time, there's got to be prior art all over the place. If nothing else, the Amiga's IFF ILBM image format uses RLC, and it's been around since 1985, at least.
Unfair Trade Practices, subsection 13: Restrictive Conditions on Trade - Placing unfair restrictions on trade with or other business activities of a trading partner.
That's because they weren't designed to be useful--they were designed to gather data for the purpose of eventually building useful ones. This particular article is light on details, but the report I saw on the news here had someone from JAXA explicitly saying they are in a preliminary data-collection stage.
That's exactly the point, though. If using software to do X isn't patentable, that means, conversely, that a patent can't protect against a product that uses software to do X.
That's not what I'm saying, or at least not what I was trying to say. If X is patented, then it's patented regardless of whether it's implemented mechanically or in software. Using the Simplex lock example, if the patent is for "a device which prevents a door from being opened unless the correct sequence of buttons on a 5-button panel is pressed", it doesn't matter whether the box behind the panel consists of a bunch of levers and switches or a microprocessor with pressure sensors; both are covered by the patent. Of course, if the patent is for "a device using levers and switches" then you're SOL, but that's always been the case.
So it's not that "nothing using software should be patentable", it's that "no software (itself) should be patentable". Simply designing logic that makes a microprocessor respond to sensors isn't worthy of a patent; it's when that software is used in a device--which meets the innovation/non-obviousness standards for patents, of course--that the entire device (or rather the idea, as you correctly point out) deserves a patent.
I'll admit that the difference between "software" and "device" is growing thinner as technology pervades society, but the answer to that with respect to patents should be "let's give serious thought to how patents will and should affect modern society", not "this is too confusing, we give up, patent whatever you want".
As far as I can tell, that only lets you read memory, which doesn't let you root anything. In fact, I tried the test and though it claimed to have worked, all I got was/proc/mtrr followed 64MB of zeros, which seems odd since my machine's been up long enough that all my physical memory should have been stomped on at some point.
So yes, these are both serious problems, but they still don't boost Linux up into that vaunted "rootable group". (:
There are damn few inventions you can make that can't be implemented at least partly in software.
This is a fascinating idea you propose. Perhaps you could enlighten me on how one would perform the following in software:
Generate photons (e.g. light bulb)
Accelerate a mass (e.g. steam engine)
Secure a building (e.g. door lock)
I can already see you responding "just write software to actuate X", but that leaves the question: where does the X come from? The argument against software patents is just that--the "write software to actuate X" is easy and obvious, and therefore shouldn't be patentable. It's the X itself that should get the patent.
any software can be implemented purely in a mechanism that performs the same steps
Yes, it could, and you (ideally) still wouldn't be able to patent it, because the method of using a mechanism to perform the computations would already be common knowledge.
Spoken like someone who sounds like he did a little "home schooling" for his typing. How many words can you type a minute?
I'm not the PP, but I could say the same as he--I learned my typing through several megabytes of trial and error--and I can type around 100 WPM. Good enough for you?
Yes, you can learn on your own, but some techniques (usually the ones you learn in school) are much faster. There is a reason why the home-row is taught as the starting place.
To ensure a continuing revenue stream for doctors and medical firms treating RSI?
Seriously, I've tried "home row", as in "ASDFJKL;", and it's incredibly hard on my hands compared to my self-taught method, which is something vaguely approximating "AERGHIO;". I can type faster with the latter too, though I'd be willing to grant that that's just the result of longer use. And no, I didn't have any home-row typing classes before I settled on that layout. (I did have one later, which is where my home-row typing experience comes from.)
Besides, being able to type fast isn't nearly as important as being able to type fast enough. If someone can type 60 WPM with two fingers, for example, what's wrong with that? 60 WPM is reasonably fast by any standard. Or maybe they can only do 30 WPM on general text, but 99% of their typing is entering numbers and they can do (the equivalent of) 100 WPM on the ten-key pad; again, their skills are more than sufficient. Not everyone needs to be a world-class touch-typist, after all.
When I changed jobs recently, this was one of the top things on my mind. So I negotiated with the company to get the following clause into my contract (translated from Japanese):
All rights to inventions, technology, software, etc. ("IP") developed by Employee as a direct result of work for Employer ("Work-Related IP") belong to Employer.
All rights to IP developed by Employee not as a direct result of work for Employer ("Personal IP") belong to Employee.
Rights to Work-Related IP derived from or otherwise containing Personal IP are to be decided in discussions between Employer and Employee.
Employer and Employee agree to execute any documents, assignations, etc. necessary to confirm IP rights.
Employer agrees to pay Employee a portion of any profits made from Employee's Work-Related IP based on Employee's amount of contribution to said profits.
Admittedly, I had the advantage that the company I work for now called me instead of me applying for a job, which gave me a fairly good bargaining position. But at least for smaller companies, where the company isn't too strangled in rules and standard procedures, something like the above shouldn't be too hard to work out--if you try.
I am aghast at the some of the remarks to this news.
Damn, I wish I had saved some mod points so I could mark this Overrated.
This is going to end up mostly Redundant anyway, but come on . . . are we all supposed to end up moping around like it's the end of the world? Like TFA says, he's over the cancer, and expected to fully recover. Yes, it was a close call, and yes, things could have turned out much worse, in which case I expect even Slashdot would have been in a more somber mood. But things didn't turn out worse, and what I see is Slashdot expressing its relief through humor--and there's nothing wrong with that.
And think about it--if it was you lying in a hospital bed, would you really want the rest of the world to stop enjoying life for your sake? Would that really make you, or your family, relatives and friends, feel better? I expect that if I ever found myself in a similar condition, I'd feel horrible if other people got depressed over it, and I'd probably do my best to inject some humor myself.
It's a shame... $80 was fine. $200 isn't. Not for a home user who isn't making a living off of the product.
Bah. I had no problems paying the $300 for 3.x plus the $150(?) for the upgrade to 4.x. Granted, if you don't have a job or if you spend all day flipping burgers to make ends meet, then maybe it's a little tough--but it still probably costs less than the $x00 you just spent to upgrade your system for Doom 3;)
The standard prefixes kibi, mebi, gibi, tebi, etc. mean the exact same thing when applied to ANY measure. That's the entire point of a standard, and the standard says 2^10, 2^20, 2^30, and 2^40, respectively.
So exactly what measures, other than units of computer storage, are you intending to apply these prefixes to?
If the answer is "none", then it's not a standard, it's a kludge.
However, that's more of an argument for why it won't be used, rather than why it shouldn't -- which was where I was coming from.
I don't think they're quite as separable as that. Your argument is a good one, as far as it goes--and it certainly made me think hard about my own opinions, which is always a Good Thing--but it assumes that the only relevant factor is the number of accidents that occur. I disagree: while that's certainly a significant factor (and I don't doubt that computers will eventually be better at avoiding accidents than humans), it's also necessary to consider the impact on and response of humans and human society. I would find it hard to call it an "improvement" if fear of being hit by a crazy driver was simply replaced by fear of being hit by a buggy machine.
The way I see it, humans aren't very good at this anyway. If we were, then there wouldn't be nearly as many accidents as there are. Yes, a computer may make a mistake -- but I think that it's obvious that they could do a better job in many situations than a human.
Of course, such improvements would only come at the cost of inconvenience to the driver^Wrider. Take the narrow streets I mentioned: a human driver could make eye contact with a pedestrian and squeeze by on one edge of the street while the pedestrian presses up against the opposite wall, but a computer designed for safety would never be able to pass because it would always see the pedestrian as a potential obstruction. I don't think computers would qualify as an improvement in that situation.
On the other hand, doing away with cars entirely (at least in such residential areas) could be a viable option.
By itself, a single engine failure in a multi-engine plane rarely results in an accident or fatality.
True, that may not have been the best example. I think the point still holds, though, that given an accident, cars have a higher survival rate. (How about a car rear-ending another car vs. a plane rear-ending another plane?)
I contend that at some point in the future, the benefits of having a computer in control will far outweigh the risks, and at that point we would be wise to use them instead of foolishly trusting our human superiority.
Nobody ever said the human race was wise.
Seriously, even when we reach this point, there will still be major obstacles to actually implementing such automated control. One is refusal (emotional, but no less real for being so) to accept a machine's decisions; as another poster pointed out, "Sorry, ma'am, the computer decided your kid was expendable" won't be well received.
But a larger issue is predicting human behavior. While I don't drive myself, I personally wouldn't accept computer-controlled cars on any street I might be walking on, regardless of how accurate those computers might be. Why? Because I can understand, subconsciously, what a human will do, how a human will react, while I can't do that with a computer--particularly not with one as complex as it would have to be to handle the task of driving safely, and which could easily have bugs (or worse, deliberate hacks). Computers, likewise, cannot "comprehend" what humans or other animals might do. Certainly, control software could be programmed with the physical limits of the human body, and avoid or brake whenever such an autonomous object gets within range of being able to cause an accident--but that would pretty much rule out even sidewalks, much less people walking on the street itself. (If that sounds like a stupid thing to do, come to Japan sometime and see the narrow streets with no sidewalks lined with fences or walls that we have to walk on.) And you know people would start jumping out into the street just to watch the cars swerve and brake to avoid them.
I do think computer-controlled automobiles will be useful--in closed situations, where outside objects cannot enter the roadway. But the human/computer divide is too fundamental to overcome so easily (if at all); who can understand how we think better than we ourselves can? Trusting in our "superiority" is not foolish to the extent we really are superior.
In the USA at least, commercial airline travel is much much safer than riding in a conventional automobile.
And yet people don't care. [...] People want contro and don't actually care about safety.
While I accept your point, I don't think you're making the right argument for it. One major reason for being concerned about air travel safety is failure modes: if an accident does happen, you're much more likely to be able to walk away (or at least be carried away) from a car accident at 100km/h on the ground than from an exploded engine at 1000km/h several thousand meters up in the air. Also keep in mind that statistics like yours are primarily applicable when you're talking about large groups, and not so much to individuals; if a meteor falls on your head, the extreme improbability of such an event won't reduce your level of deadness.
Besides, air and road travel are, for the most part, used in disjoint sets of situations--you wouldn't take a plane to go grocery shopping, for example. Planes are inconvenient, too, which probably drives away a lot more people than concerns about safety do. (Here in Japan, I prefer trains to planes for exactly this reason--even if it takes a couple hours longer, you don't have to go all the way out to the airport, you don't have to arrive early to make it through the check-in lines, and you don't have to swallow your pocketknife just for the privilege of blasting through the upper atmosphere in a pressurized metal tube.)
Slashdot Mirror
I don't understand WHY Google IPO'ed.
As I recall comments from the initial announcement, Google had grown enough that they had to start filing stuff with the SEC like a publicly traded company (which costs lots of money in overhead) anyway, so they decided they might as well go the whole nine yards and raise some money too. Or at least that was one hypothesis.
This is about GPL, because this is how GPL works.
Well, I guess it's "about the GPL" in the sense that it's the lack of the GPL as a defense that will doom SCO. What it's not about is proving the other, more important (IMHO) side of the GPL: that redistributors are required to make the source (with any changes) available. IBM's not in a position to argue that, since that's exactly what SCO was doing. Hence it's unlikely that this MSJ, at least, will touch on the core issue of the GPL--freedom of the code--which is what most people seem to be interpreting "enforce the GPL" as.
It turns out that in the Memorandum in Support, IBM does invoke part of the GPL--specifically, the part that says "no relicensing":
So while it's not the whole shebang, it looks like we can at least expect part of the GPL to be discussed.
If you read the MSJ closely, IBM is actually saying: (emphasis added)
So this isn't really about the GPL--it's a simple copyright infringement issue. They're saying to the judge, "we own this code and SCO is distributing it without permission, so stop them".
On the other hand, they do go on to add:
So if SCO is going to mount a defense to this MSJ, they'll have to argue for the GPL, essentially countering their own earlier claims that the GPL is invalid and forcing them to tell the judge "uh, we were wrong". This isn't about IBM "testing" the GPL, it's about them grabbing two big boulders and squishing SCO between them. (:
If the GPL did end up being ruled on by the judge, about the only ruling I could see is that the GPL is valid and therefore SCO has not infringed IBM's copyrights--but IANAL, so what do I know?
It's just a dumbed-down way of saying "energy stored in used coolant water is transferred to cold water from the lake". If you look at the diagram in the article, it's pretty clear: they run the cooling water alongside the lakewater to bleed (is that the right term?) the heat out, then send the heated lakewater out to the city as tap water--in essence "extracting the cold" from the lakewater and "storing" it in the cooling system.
don't forget the National Spelling Bee
And its wonderful dictionary, with words like ninnyish. I lost in my 6th grade school finals on that, and I'm still pissed about it. They could have at least picked words that exist!
So who writes pron with a '0' now anymore??
Everybody! That's a lower-case zero, you dolt!
(-:
On newer CF cards they have an internal microprocessor that constantly remaps the logical addresses of the drive to different physical addresses [...] So even though the OS thinks it's writing the FAT to that same spot on the drive, the drive is really moving that spot around to maximize the life of the drive.
Wow. So forget trying to shred files on those. (Yes, mods, I realize it would still work at the filesystem level--that won't stop someone who cracks the case open and reads straight off the chips.)
And what about the memory where the logical-to-physical map is stored? Even if you rewrite the same sector to 10,000 different places, you'll have to rewrite the same map entry 10,000 times. Or is that part of the memory designed to withstand rewriting better?
According to the earlier /. article, the patent in question is on run-length coding, and was issued in 1987. Unless it was submarined for a really long time, there's got to be prior art all over the place. If nothing else, the Amiga's IFF ILBM image format uses RLC, and it's been around since 1985, at least.
Antimonopoly Act, section 19: Businesses may not make use of unfair trade practices.
Unfair Trade Practices, subsection 13: Restrictive Conditions on Trade - Placing unfair restrictions on trade with or other business activities of a trading partner.
These solar sails are pretty useless.
That's because they weren't designed to be useful--they were designed to gather data for the purpose of eventually building useful ones. This particular article is light on details, but the report I saw on the news here had someone from JAXA explicitly saying they are in a preliminary data-collection stage.
That's exactly the point, though. If using software to do X isn't patentable, that means, conversely, that a patent can't protect against a product that uses software to do X.
That's not what I'm saying, or at least not what I was trying to say. If X is patented, then it's patented regardless of whether it's implemented mechanically or in software. Using the Simplex lock example, if the patent is for "a device which prevents a door from being opened unless the correct sequence of buttons on a 5-button panel is pressed", it doesn't matter whether the box behind the panel consists of a bunch of levers and switches or a microprocessor with pressure sensors; both are covered by the patent. Of course, if the patent is for "a device using levers and switches" then you're SOL, but that's always been the case.
So it's not that "nothing using software should be patentable", it's that "no software (itself) should be patentable". Simply designing logic that makes a microprocessor respond to sensors isn't worthy of a patent; it's when that software is used in a device--which meets the innovation/non-obviousness standards for patents, of course--that the entire device (or rather the idea, as you correctly point out) deserves a patent.
I'll admit that the difference between "software" and "device" is growing thinner as technology pervades society, but the answer to that with respect to patents should be "let's give serious thought to how patents will and should affect modern society", not "this is too confusing, we give up, patent whatever you want".
As far as I can tell, that only lets you read memory, which doesn't let you root anything. In fact, I tried the test and though it claimed to have worked, all I got was /proc/mtrr followed 64MB of zeros, which seems odd since my machine's been up long enough that all my physical memory should have been stomped on at some point.
So yes, these are both serious problems, but they still don't boost Linux up into that vaunted "rootable group". (:
The problem with this is that it's bullshit.
Careful with that flamethrower . . .
There are damn few inventions you can make that can't be implemented at least partly in software.
This is a fascinating idea you propose. Perhaps you could enlighten me on how one would perform the following in software:
I can already see you responding "just write software to actuate X", but that leaves the question: where does the X come from? The argument against software patents is just that--the "write software to actuate X" is easy and obvious, and therefore shouldn't be patentable. It's the X itself that should get the patent.
any software can be implemented purely in a mechanism that performs the same steps
Yes, it could, and you (ideally) still wouldn't be able to patent it, because the method of using a mechanism to perform the computations would already be common knowledge.
Spoken like someone who sounds like he did a little "home schooling" for his typing. How many words can you type a minute?
I'm not the PP, but I could say the same as he--I learned my typing through several megabytes of trial and error--and I can type around 100 WPM. Good enough for you?
Yes, you can learn on your own, but some techniques (usually the ones you learn in school) are much faster. There is a reason why the home-row is taught as the starting place.
To ensure a continuing revenue stream for doctors and medical firms treating RSI?
Seriously, I've tried "home row", as in "ASDFJKL;", and it's incredibly hard on my hands compared to my self-taught method, which is something vaguely approximating "AERGHIO;". I can type faster with the latter too, though I'd be willing to grant that that's just the result of longer use. And no, I didn't have any home-row typing classes before I settled on that layout. (I did have one later, which is where my home-row typing experience comes from.)
Besides, being able to type fast isn't nearly as important as being able to type fast enough. If someone can type 60 WPM with two fingers, for example, what's wrong with that? 60 WPM is reasonably fast by any standard. Or maybe they can only do 30 WPM on general text, but 99% of their typing is entering numbers and they can do (the equivalent of) 100 WPM on the ten-key pad; again, their skills are more than sufficient. Not everyone needs to be a world-class touch-typist, after all.
When I changed jobs recently, this was one of the top things on my mind. So I negotiated with the company to get the following clause into my contract (translated from Japanese):
Admittedly, I had the advantage that the company I work for now called me instead of me applying for a job, which gave me a fairly good bargaining position. But at least for smaller companies, where the company isn't too strangled in rules and standard procedures, something like the above shouldn't be too hard to work out--if you try.
I am aghast at the some of the remarks to this news.
Damn, I wish I had saved some mod points so I could mark this Overrated.
This is going to end up mostly Redundant anyway, but come on . . . are we all supposed to end up moping around like it's the end of the world? Like TFA says, he's over the cancer, and expected to fully recover. Yes, it was a close call, and yes, things could have turned out much worse, in which case I expect even Slashdot would have been in a more somber mood. But things didn't turn out worse, and what I see is Slashdot expressing its relief through humor--and there's nothing wrong with that.
And think about it--if it was you lying in a hospital bed, would you really want the rest of the world to stop enjoying life for your sake? Would that really make you, or your family, relatives and friends, feel better? I expect that if I ever found myself in a similar condition, I'd feel horrible if other people got depressed over it, and I'd probably do my best to inject some humor myself.
I wish S.J. a speedy recovery
As do we all.
It's a shame... $80 was fine. $200 isn't. Not for a home user who isn't making a living off of the product.
Bah. I had no problems paying the $300 for 3.x plus the $150(?) for the upgrade to 4.x. Granted, if you don't have a job or if you spend all day flipping burgers to make ends meet, then maybe it's a little tough--but it still probably costs less than the $x00 you just spent to upgrade your system for Doom 3 ;)
Okay, this is about as far off topic as you can get, but WTF is it with this ugly color scheme?
Oh, I know--they're trying to subtly convince me to get back to work . . .
What do you call overloading the decimal prefixes with contradictory meanings and using them ambiguously?
Also a kludge.
The standard prefixes kibi, mebi, gibi, tebi, etc. mean the exact same thing when applied to ANY measure. That's the entire point of a standard, and the standard says 2^10, 2^20, 2^30, and 2^40, respectively.
So exactly what measures, other than units of computer storage, are you intending to apply these prefixes to?
If the answer is "none", then it's not a standard, it's a kludge.
However, that's more of an argument for why it won't be used, rather than why it shouldn't -- which was where I was coming from.
I don't think they're quite as separable as that. Your argument is a good one, as far as it goes--and it certainly made me think hard about my own opinions, which is always a Good Thing--but it assumes that the only relevant factor is the number of accidents that occur. I disagree: while that's certainly a significant factor (and I don't doubt that computers will eventually be better at avoiding accidents than humans), it's also necessary to consider the impact on and response of humans and human society. I would find it hard to call it an "improvement" if fear of being hit by a crazy driver was simply replaced by fear of being hit by a buggy machine.
The way I see it, humans aren't very good at this anyway. If we were, then there wouldn't be nearly as many accidents as there are. Yes, a computer may make a mistake -- but I think that it's obvious that they could do a better job in many situations than a human.
Of course, such improvements would only come at the cost of inconvenience to the driver^Wrider. Take the narrow streets I mentioned: a human driver could make eye contact with a pedestrian and squeeze by on one edge of the street while the pedestrian presses up against the opposite wall, but a computer designed for safety would never be able to pass because it would always see the pedestrian as a potential obstruction. I don't think computers would qualify as an improvement in that situation.
On the other hand, doing away with cars entirely (at least in such residential areas) could be a viable option.
By itself, a single engine failure in a multi-engine plane rarely results in an accident or fatality.
True, that may not have been the best example. I think the point still holds, though, that given an accident, cars have a higher survival rate. (How about a car rear-ending another car vs. a plane rear-ending another plane?)
I contend that at some point in the future, the benefits of having a computer in control will far outweigh the risks, and at that point we would be wise to use them instead of foolishly trusting our human superiority.
Nobody ever said the human race was wise.
Seriously, even when we reach this point, there will still be major obstacles to actually implementing such automated control. One is refusal (emotional, but no less real for being so) to accept a machine's decisions; as another poster pointed out, "Sorry, ma'am, the computer decided your kid was expendable" won't be well received.
But a larger issue is predicting human behavior. While I don't drive myself, I personally wouldn't accept computer-controlled cars on any street I might be walking on, regardless of how accurate those computers might be. Why? Because I can understand, subconsciously, what a human will do, how a human will react, while I can't do that with a computer--particularly not with one as complex as it would have to be to handle the task of driving safely, and which could easily have bugs (or worse, deliberate hacks). Computers, likewise, cannot "comprehend" what humans or other animals might do. Certainly, control software could be programmed with the physical limits of the human body, and avoid or brake whenever such an autonomous object gets within range of being able to cause an accident--but that would pretty much rule out even sidewalks, much less people walking on the street itself. (If that sounds like a stupid thing to do, come to Japan sometime and see the narrow streets with no sidewalks lined with fences or walls that we have to walk on.) And you know people would start jumping out into the street just to watch the cars swerve and brake to avoid them.
I do think computer-controlled automobiles will be useful--in closed situations, where outside objects cannot enter the roadway. But the human/computer divide is too fundamental to overcome so easily (if at all); who can understand how we think better than we ourselves can? Trusting in our "superiority" is not foolish to the extent we really are superior.
In the USA at least, commercial airline travel is much much safer than riding in a conventional automobile. And yet people don't care. [...] People want contro and don't actually care about safety.
While I accept your point, I don't think you're making the right argument for it. One major reason for being concerned about air travel safety is failure modes: if an accident does happen, you're much more likely to be able to walk away (or at least be carried away) from a car accident at 100km/h on the ground than from an exploded engine at 1000km/h several thousand meters up in the air. Also keep in mind that statistics like yours are primarily applicable when you're talking about large groups, and not so much to individuals; if a meteor falls on your head, the extreme improbability of such an event won't reduce your level of deadness.
Besides, air and road travel are, for the most part, used in disjoint sets of situations--you wouldn't take a plane to go grocery shopping, for example. Planes are inconvenient, too, which probably drives away a lot more people than concerns about safety do. (Here in Japan, I prefer trains to planes for exactly this reason--even if it takes a couple hours longer, you don't have to go all the way out to the airport, you don't have to arrive early to make it through the check-in lines, and you don't have to swallow your pocketknife just for the privilege of blasting through the upper atmosphere in a pressurized metal tube.)