I have an old (circa 1980) roll of rosin-core eutectic solder, that I don't use any more because of the lead.
I also have a recently purchased some mgchemicals 4900-112G, it is 96.3Sn, 0.7Cu, 3Ag, with a "no clean" flux.
It works ok with my old soldering ironing, flows nicely, no idea how it does with tin whiskers.
I'm not getting a lot of trouble with cold joints, and I do push my luck (lots of free-hand work, for instance, in-place soldering of LEDs for under-cabinet lights).
Cooling the earth for a few billion dollars is chickenfeed. What if some large country (us, China, India, Brazil, just for example) decides that they'd like a little extra cooling? Too bad for Canada, eh?
If this (or any similar "cheap" cooling technology) works and is deployed, it will make for some interesting negotiations.
even though riding in cars and on bicycles is vastly more dangerous
Where the largest danger presented by the car (20x the danger of the bike!) is that you will become (more) unfit and die from some disease of the fat. But, people prefer to drive, because "biking's dangerous".
If your employer covers you with health insurance (as mine does) or if your spouse has insurance that covers, you then you need not purchase insurance.
It's much cheaper to buy a house here than in California.
The weather's worse, not much to be done about that, but you can avoid the non-compete's here by working for a California company. And yes, some I've negotiated, some I've signed, and one I turned down after failing to get anywhere negotiating.
According to this article
it is possible to "frame" IP addresses using the bittorrent protocol, and convince
the RIAA that a non-infringing IP address (for example, a networked printer) is hosting
their precious music.
If worm-compromised hosts can be automatically identified (say, the originator of every piece of spam that I get), why not frame them, and then RIAA will send take-down notices to their ISPs? Either this forces the RIAA to work a little harder before harrassing people, or a bunch of worm hosts get knocked offline (or both).
If I get to assume a fantasy world, Comcast isn't caching, because they've gone out of business. You can theorize about your fantasy world, I'll theorize about mine.
If they were caching, it would be useless, because (almost) everyone with Comcast/Cox is already encrypting P2P to try to avoid throttling. The encrypted bits are only useful in a single connection, never again. It's exactly the sort of data that you don't ever want in a cache. C/C apparently decided that degrading service was a better choice than caching or adding capacity.
There's no caching, because to get anything at all through Comcast, you need to encrypt the connections (to obfuscate them). Not sure if that trick works now, but it did for a while. For the time being, I've given up P2P, but the INSTANT I have a choice, I am switching.
By-the-way, if you only get basic cable from Comcast, try broadcast HDTV -- I get pretty good reception, in a place that never got good analog reception.
Can't, my ass. It's a lifestyle choice, not an impossibility.
The median commute distance is around 10 miles. I've been Googling, it's well less than that in Canada, it's around that in Silicon Valley (http://www.cities21.org/BABPC/). If you choose to, you can do that on a bicycle, 52 weeks a year, in Boston, even if you are a late-40s overweight guy with a bad attitude. You can do it in the snow, you can do it in the rain. You can haul one kid to school and to soccer afterwards. You can carry groceries home (I ride a bike of unusual size). It does take appropriate clothing. It takes about 45 minutes on the bike, versus 25 in the car, but the bike timing is predictable, and there's no need to spend any other time on exercise, and (statistically speaking) you'll live longer for doing this instead of driving.
For the cost of two tanks of fuel oil (yeesh!) you can add an electric motor assist to the bike that will give you better speed while using very little additional energy.
There's some people way out on the tail of the commute distribution; they'll need to move, change jobs, telecommute, or find some other way to make things work, but most people could do their commute on a bicycle. There's plenty of "reasons" not to ride your bike, but most of them turn out to be bogus once you actually do it. Probably the biggest impediment for me is that people driving cars don't see too well in the dim and dark that we get in the winter, and they aren't looking for bikes.
Got my resusable bags at Ikea, I think they were $1.50 each, I've probably gotten about 100 uses out of them so far (2x/week, for about a year).
And all y'all eco-conscious people, are of course walking or biking to the grocery store, right? Those thin plastic bags that they give you if you don't bring your own, very likely weigh less than the gas that you burn to get to the store and back.
I don't mean to be too contrary, but how-do-you-know that the proprietary code should be easier to have altered? The possibility that many eyes could look at open source code (carefully, not casually) does not mean that it happens. Proprietary code also goes past many eyes, and employees come and go, and they poke around code that isn't "theirs" (at least, I do, when I have the chance). If people just assume that the open source stuff is ok because people could be looking at it, well, we all know about ass-u-me.
Someone injecting code into any piece of software would need to be very careful to ensure that (1) it doesn't cause any anomalies in code coverage (because then someone would look at it, carefully) and (2) it is not located near any code implicated or suspected of causing any bug (because then someone would look at it, carefully). They also need to ensure that it won't raise a red flag in some future proof-checking or anomaly-detecting tool. It's a little hard to ensure control of not only the someone who wrote it, but also the someones who do code coverage and bug fixing. More someones = greater risk of disclosure.
I won't say "it doesn't happen" -- an intentionally weak cryptosystem is one obvious possibility -- but it's a little interesting that nothing's turned up anywhere that we know of. All that said, open source does provide a lot more confidence that if you were that paranoid, you could do something about it.
Verifying hardware, that's a problem. Sun open-sourced their test vectors (right? I work for them, but I'm not king), which would impose many more constraints on any hack.
[disclaimer - I work for Sun, and I KNOW that some of my friends have worked for the NSA, and I KNOW that I have relatives with security clearances. Who knows what's going on that I don't know.]
As has been pointed out elsewhere, if the NSA wanted to insert backdoors in software, it is not likely that they would announce it loudly. Ditto for anyone other country's version of the NSA. There is a legitimate national security reason that the NSA would be interested in plugging holes in software that is widely-used within the US -- as bad as worms/spam etc might be, imagine how it would turn out if a nation decided to launch some sort of a cyber attack, concurrent with who knows what other action. That's bad news that we just don't need to hear.
As far as the compiler goes, ab-so-lutely, be wary.
Indoors, but when we were trying to pick the right color LED light, it was the only light. I was comparing colors spec'd as "bright, cool, neutral, warm" -- actually "daylight", the brightest and bluest, never even made it. We were checking a known paint color, skin color, that sort of thing.
Here's bright vs. cool, according to a camera. Hard to tell by camera, but up close our eyes had no problem at all. The photo is 3 and 3 of each.
I'm guessing that it's not just relative, but saturation of receptors in bright sunlight. I remember sailing in Florida as a kid, without sunglasses, and alternating between my two eyes because it was too bright. And when I would switch, all the colors would change -- all the blue had dropped out of the now-tired eye, if I recall correctly. Further, our rods (low-light receptors) are skewed a bit to the blue -- they peak at cyan, not green (I learned this researching best colors for an LED bike light -- green did not make the cut, because of the green-go association). Think about how moonlight looks blueish --- that's just reflected sunlight, at a much reduced intensity.
I think you want to be careful with "just like sunlight". When I have seen "6000K light", it looks like it is lit by a welding arc. Sunlight is somewhat mediated by passage through our atmosphere, and it is also very intense. I think we perceive it as less blue than it is, at its normal intensity.
While playing with color-temperature-spec'd LED arrays, what I find is that the ones that look more normal at interior brightnesses have color temperatures of 4100K or 3500K. "Daylight" looks darn blue.
how-ev-er, while carpooling back from a kid-ski-trip with a physicist, we got to discussing LEDs and lighting in general, and he said that many of the phosphors are wavelength doublers -- there's got to be a load of UV in that light, if it's really 6KK, and it ought to be doubled down, which would even things out a bit.
Latest LEDs available (now) go as high as about 90 lumens/watt (Luxeon Rebel, at 350mA, if properly heat sinked). I read, somewhere, that Nichia has demoed an LED at 130 lumens/watt.
However, their light, much like the light of this light, looks an awful lot like the light from a welder. You have to be careful about the pursuit of the almighty lumen -- it's a human-tweaked measure, not a physical measure, and lights score best by dumping all of their light into green. We probably don't want our homes to be lit by exclusively green light.
One thing to note is that there is wide spectrum (true 6000K, this new light), wide spectrum (white LEDs, a relatively smooth blob in the optical frequencies), and wide spectrum (a strategically chosen selection single frequencies, in fluorescent lights). This new bulb should produce very nice looking like, but it might benefit from some of the same phosphors used in white LEDs to down-convert the higher frequencies.
Properly run LEDs are claimed to have lifetimes in the range of 70,000 to 100,000 hours of use, and are not affected by rapid cycling (in fact, the recommended method for dimming them is to switch them on and off very quickly).
and want to hit them in the pocketbook, ever so slightly, get (try) an HDTV TV or converter. I got one, we get all the channels we care about, perhaps clearer than the cable, plus some optional channels (sort of a PBS extravaganza).
There's also a coupon you can request from the federal government to get $40 off you converter, arrives by snail mail, though it takes them weeks to process the request.
That's my plan, anyway. Still don't have any choices for internet besides them, but I'm jumping ship the instant the opportunity presents itself.
Notice, also, that Verizon seems to be making nice with at least some torrent servers. It would suck for Comcast, if Verizon managed to get people interested in a service that Comcast was incapable of providing because they invested all their money in blocking access, instead of expanding bandwidth.
I thought it was a little unusual that the EETimes article didn't even mention Sun, seeing as how we've been shipping "32" and "64"-way multicores for a while now (scare quotes because of how the 32 and 64 are implemented -- it's N cores, each time-sliced M ways to cover operation and memory latency). And yes, we're working on the problem, and so are (to my knowledge) Intel, IBM, and Microsoft, and I'm pretty sure we're all supporting (money and/or equipment) researchers at universities (I know Sun is) to work on it. The graphics card companies have a different take on it; arguably they've been doing mass-market multicore (for funny-looking cores) longer than anyone. I don't know that we started soon enough, and people need to understand that Moore's law is now about number of processors, not clock rates -- imagine, if you will, quadrupling the per-chip processor count every four years.
And I was once hissed for this remark while speaking in public, but people should took a long, serious look at functional programming languages.
That's useless. EMusic is not Apple, and they have reached some sort of agreement with quite a few smaller labels/artists. I'm genuinely curious how both the values and the shares of the various royalties compare.
I'm just curious, because as long as I diligently download my 40 songs per month, I pay $.25 per song. How is that quarter carved up, or are they actually losing money on me?
Actually, yes. Delay, Abramoff, and that crowd were pretty much in the business of trading earmarks (lots of earmarks) for votes on bills. The Democrats aren't saints (I post from MA), but when the Republicans got control, they went very bad very fast.
There's also the small issue of pretty much the entire Republican Party, with the exception of Ron Paul and John McCain, being pretty much ok with actions that, in previous wars, were called torture. Translated from the original German, "Enhanced Interrogation Techniques".
The elderly woman at the crosswalk. Will she see or hear you coming?
Not a problem, because vehicle code everywhere says that you stop. She neither needs to see your nor hear you. You cannot be driving so fast that you are unable to stop after seeing her, because vehicle code says that would be unsafe for conditions.
Humans fail these two tests all the time. When my previous car got very old, I decided I would experimentally, letter-of-the-law, stop for any pedestrian with his or her toe in the crosswalk on my side. I was rear-ended twice by drivers not capable of making significant inferences.
And the bouncy ball, or the dog, or the cat, you stop for that too. What's the big cost in stopping?
but if their liability is limited, then GM has a reduced incentive to build a safe car. As part of their fiduciary duty to their shareholders, they should cut corners.
There has to be some cost feedback for safety defects. The usual sources of such feedback are lawsuit, regulation, or market. Because market penalties are disorganized and far in the future, I think they tend to be discounted.
I don't think bad-ass algorithms are required. As near as I can tell, most accidents can be avoided simply by slowing down, if you are paying attention (and that is what the computer is supposed to do without fail) and decelerate at the appropriate time. In my own driving I try to make a point of maintaining a prudent spacing behind the car in front of me, and to spot nearby cars who aren't especially steady in their lane. Boring, but apparently safe, with no stunt-car driving necessary.
It is not a panacea, but cars aren't either.
Cargo bike plusses include:
Door-to-door service (usually better than cars; no walk across the parking lot).
Can carry loads of stuff (I've done 100lbs easily, 50 lbs no-hands).
VERY predictable travel times (slower than cars, but unaffected by traffic jams, and more able to take "alternate" routes, including trains, subways, ferries, and some busses).
Much easier and cheaper to customize than a car.
Makes good use of existing infrastructure, does not wear it out.
In the US, at least, odds are good that you need the exercise; another way of putting this is that
cars make me fat, raise my blood pressure, screw up my blood chemistry, and make my knees hurt.
Statistically, extends your expected lifetime (the year gained from increased fitness are
estimated to outweigh those lost to accidents by 10-20x -- Google "Mayer Hillman" for details)
Safe for other people. Lower speeds, lower mass, smaller frontal area, much better visibility, means that you are less likely to hit someone else, and less likely to hurt them seriously if you do.
No requirement to be social, though most of the other cyclists I meet seem nice enough.
Before you respond with "but you can't..." consider what I already do (this, from an overweight guy approaching 50 years old). I do all my planned grocery shopping on my bike. I pick up and drop off the child who is not embarrassed to be seen with me, on my bike. I ride in Boston winters now, including on ice ("customized" with snow tires and 5 watts of alternator-driven LEDs, using an utterly unoriginal circuit of my own design). Growing up, I rode my bike in Florida summers. I've gone riding in rain and snowstorms; the main impediment is fear of how badly some people in cars drive under those conditions. When the Loma Prieta quake (1989) took out all the traffic signals, those of us who had bike-commuted that day rode home unimpeded. Bikes excel at short trips, especially to places with rotten parking (Cambridge, grocery store the day before a snowstorm).
There are also choices for the less able. Tricycles (either upright or recumbent) do away with the need for good balance. Electric assists help you if you are weak, or have difficult hills on your daily route.
Bikes, for me, lose most badly on three points: I can't lock up my stuff up, they're too slow for "long" trips (> 15 miles, for me), and I don't feel safe in Very Bad Traffic (downtown Boston -- strictly speaking, this is not the fault of the bike, but the fault of careless people in cars, but human carelessness is a given).
And, to return somewhat to the point of the article, I would not necessarily expect this technology to make loads of money for GM. Once the car is automated, as several other posters have pointed out, why not have the robot run your errands for you? And, why should it be your dedicated robot? Why not a robot delivery service? And following that, the cheapest robots, from the POV of production, maintenance, energy, and liability risk, are the lighter ones -- robot tricycles, most likely. That's not GM's business, and it's not necessarily a large business, either; no need for all the bells and whistles that get added to your typical car. They'll built them in China, using mostly bicycle parts and technology, with an itty-bitty brain to drive them, and they'll be dirt cheap, compared to cars.
Well, product names, I am especially clueless. I have few clues about other things.
Seriously, when I ran a workstealing benchmark (which is all about interprocessor synchronization) it ran just as fast at 32 threads as it did at 1. The 1-thread performance is nothing to shout about, but at 16, it's suddenly kicking the ass of every other computer I can get my hands on (because of all the synchronization) and it can do that all the way out to 32. I have heard, through the grapevine, that the Niagara 1 (and perhaps the 2) provides spectacular GUPS/watt performance (GUPS is a random-access general update benchmark).
The "interesting times" part of this much multicore is that it is now possible to run out of all sorts of stuff -- should you devote chip area to floating point, or to store buffers, or to L2 cache, or to one more core? People are studying scheduling algorithms where they actually (sometimes) shut down a core to reduce resource thrashing on chip, for loads that thrash.
Slashdot Mirror
I have an old (circa 1980) roll of rosin-core eutectic solder, that I don't use any more because of the lead.
I also have a recently purchased some mgchemicals 4900-112G, it is 96.3Sn, 0.7Cu, 3Ag, with a "no clean" flux. It works ok with my old soldering ironing, flows nicely, no idea how it does with tin whiskers. I'm not getting a lot of trouble with cold joints, and I do push my luck (lots of free-hand work, for instance, in-place soldering of LEDs for under-cabinet lights).
Cooling the earth for a few billion dollars is chickenfeed. What if some large country (us, China, India, Brazil, just for example) decides that they'd like a little extra cooling? Too bad for Canada, eh? If this (or any similar "cheap" cooling technology) works and is deployed, it will make for some interesting negotiations.
Where the largest danger presented by the car (20x the danger of the bike!) is that you will become (more) unfit and die from some disease of the fat. But, people prefer to drive, because "biking's dangerous".
If your employer covers you with health insurance (as mine does) or if your spouse has insurance that covers, you then you need not purchase insurance.
It's much cheaper to buy a house here than in California.
The weather's worse, not much to be done about that, but you can avoid the non-compete's here by working for a California company. And yes, some I've negotiated, some I've signed, and one I turned down after failing to get anywhere negotiating.
According to this article it is possible to "frame" IP addresses using the bittorrent protocol, and convince the RIAA that a non-infringing IP address (for example, a networked printer) is hosting their precious music.
If worm-compromised hosts can be automatically identified (say, the originator of every piece of spam that I get), why not frame them, and then RIAA will send take-down notices to their ISPs? Either this forces the RIAA to work a little harder before harrassing people, or a bunch of worm hosts get knocked offline (or both).
Step 3: PROFIT!
If I get to assume a fantasy world, Comcast isn't caching, because they've gone out of business. You can theorize about your fantasy world, I'll theorize about mine.
If they were caching, it would be useless, because (almost) everyone with Comcast/Cox is already encrypting P2P to try to avoid throttling. The encrypted bits are only useful in a single connection, never again. It's exactly the sort of data that you don't ever want in a cache. C/C apparently decided that degrading service was a better choice than caching or adding capacity.
There's no caching, because to get anything at all through Comcast, you need to encrypt the connections (to obfuscate them). Not sure if that trick works now, but it did for a while. For the time being, I've given up P2P, but the INSTANT I have a choice, I am switching. By-the-way, if you only get basic cable from Comcast, try broadcast HDTV -- I get pretty good reception, in a place that never got good analog reception.
can't afford transportation
Can't, my ass. It's a lifestyle choice, not an impossibility.
The median commute distance is around 10 miles. I've been Googling, it's well less than that in Canada, it's around that in Silicon Valley (http://www.cities21.org/BABPC/). If you choose to, you can do that on a bicycle, 52 weeks a year, in Boston, even if you are a late-40s overweight guy with a bad attitude. You can do it in the snow, you can do it in the rain. You can haul one kid to school and to soccer afterwards. You can carry groceries home (I ride a bike of unusual size). It does take appropriate clothing. It takes about 45 minutes on the bike, versus 25 in the car, but the bike timing is predictable, and there's no need to spend any other time on exercise, and (statistically speaking) you'll live longer for doing this instead of driving.
For the cost of two tanks of fuel oil (yeesh!) you can add an electric motor assist to the bike that will give you better speed while using very little additional energy.
There's some people way out on the tail of the commute distribution; they'll need to move, change jobs, telecommute, or find some other way to make things work, but most people could do their commute on a bicycle. There's plenty of "reasons" not to ride your bike, but most of them turn out to be bogus once you actually do it. Probably the biggest impediment for me is that people driving cars don't see too well in the dim and dark that we get in the winter, and they aren't looking for bikes.
And all y'all eco-conscious people, are of course walking or biking to the grocery store, right? Those thin plastic bags that they give you if you don't bring your own, very likely weigh less than the gas that you burn to get to the store and back.
(Like so)
Someone injecting code into any piece of software would need to be very careful to ensure that (1) it doesn't cause any anomalies in code coverage (because then someone would look at it, carefully) and (2) it is not located near any code implicated or suspected of causing any bug (because then someone would look at it, carefully). They also need to ensure that it won't raise a red flag in some future proof-checking or anomaly-detecting tool. It's a little hard to ensure control of not only the someone who wrote it, but also the someones who do code coverage and bug fixing. More someones = greater risk of disclosure.
I won't say "it doesn't happen" -- an intentionally weak cryptosystem is one obvious possibility -- but it's a little interesting that nothing's turned up anywhere that we know of. All that said, open source does provide a lot more confidence that if you were that paranoid, you could do something about it.
Verifying hardware, that's a problem. Sun open-sourced their test vectors (right? I work for them, but I'm not king), which would impose many more constraints on any hack.
[disclaimer - I work for Sun, and I KNOW that some of my friends have worked for the NSA, and I KNOW that I have relatives with security clearances. Who knows what's going on that I don't know.] As has been pointed out elsewhere, if the NSA wanted to insert backdoors in software, it is not likely that they would announce it loudly. Ditto for anyone other country's version of the NSA. There is a legitimate national security reason that the NSA would be interested in plugging holes in software that is widely-used within the US -- as bad as worms/spam etc might be, imagine how it would turn out if a nation decided to launch some sort of a cyber attack, concurrent with who knows what other action. That's bad news that we just don't need to hear. As far as the compiler goes, ab-so-lutely, be wary.
Here's bright vs. cool, according to a camera. Hard to tell by camera, but up close our eyes had no problem at all. The photo is 3 and 3 of each.
I'm guessing that it's not just relative, but saturation of receptors in bright sunlight. I remember sailing in Florida as a kid, without sunglasses, and alternating between my two eyes because it was too bright. And when I would switch, all the colors would change -- all the blue had dropped out of the now-tired eye, if I recall correctly. Further, our rods (low-light receptors) are skewed a bit to the blue -- they peak at cyan, not green (I learned this researching best colors for an LED bike light -- green did not make the cut, because of the green-go association). Think about how moonlight looks blueish --- that's just reflected sunlight, at a much reduced intensity.
While playing with color-temperature-spec'd LED arrays, what I find is that the ones that look more normal at interior brightnesses have color temperatures of 4100K or 3500K. "Daylight" looks darn blue.
how-ev-er, while carpooling back from a kid-ski-trip with a physicist, we got to discussing LEDs and lighting in general, and he said that many of the phosphors are wavelength doublers -- there's got to be a load of UV in that light, if it's really 6KK, and it ought to be doubled down, which would even things out a bit.
However, their light, much like the light of this light, looks an awful lot like the light from a welder. You have to be careful about the pursuit of the almighty lumen -- it's a human-tweaked measure, not a physical measure, and lights score best by dumping all of their light into green. We probably don't want our homes to be lit by exclusively green light.
One thing to note is that there is wide spectrum (true 6000K, this new light), wide spectrum (white LEDs, a relatively smooth blob in the optical frequencies), and wide spectrum (a strategically chosen selection single frequencies, in fluorescent lights). This new bulb should produce very nice looking like, but it might benefit from some of the same phosphors used in white LEDs to down-convert the higher frequencies.
Properly run LEDs are claimed to have lifetimes in the range of 70,000 to 100,000 hours of use, and are not affected by rapid cycling (in fact, the recommended method for dimming them is to switch them on and off very quickly).
There's also a coupon you can request from the federal government to get $40 off you converter, arrives by snail mail, though it takes them weeks to process the request.
That's my plan, anyway. Still don't have any choices for internet besides them, but I'm jumping ship the instant the opportunity presents itself.
Notice, also, that Verizon seems to be making nice with at least some torrent servers. It would suck for Comcast, if Verizon managed to get people interested in a service that Comcast was incapable of providing because they invested all their money in blocking access, instead of expanding bandwidth.
I thought it was a little unusual that the EETimes article didn't even mention Sun, seeing as how we've been shipping "32" and "64"-way multicores for a while now (scare quotes because of how the 32 and 64 are implemented -- it's N cores, each time-sliced M ways to cover operation and memory latency). And yes, we're working on the problem, and so are (to my knowledge) Intel, IBM, and Microsoft, and I'm pretty sure we're all supporting (money and/or equipment) researchers at universities (I know Sun is) to work on it. The graphics card companies have a different take on it; arguably they've been doing mass-market multicore (for funny-looking cores) longer than anyone. I don't know that we started soon enough, and people need to understand that Moore's law is now about number of processors, not clock rates -- imagine, if you will, quadrupling the per-chip processor count every four years.
And I was once hissed for this remark while speaking in public, but people should took a long, serious look at functional programming languages.
That's useless. EMusic is not Apple, and they have reached some sort of agreement with quite a few smaller labels/artists. I'm genuinely curious how both the values and the shares of the various royalties compare.
I'm just curious, because as long as I diligently download my 40 songs per month, I pay $.25 per song. How is that quarter carved up, or are they actually losing money on me?
Actually, yes. Delay, Abramoff, and that crowd were pretty much in the business of trading earmarks (lots of earmarks) for votes on bills. The Democrats aren't saints (I post from MA), but when the Republicans got control, they went very bad very fast. There's also the small issue of pretty much the entire Republican Party, with the exception of Ron Paul and John McCain, being pretty much ok with actions that, in previous wars, were called torture. Translated from the original German, "Enhanced Interrogation Techniques".
Not a problem, because vehicle code everywhere says that you stop. She neither needs to see your nor hear you. You cannot be driving so fast that you are unable to stop after seeing her, because vehicle code says that would be unsafe for conditions.
Humans fail these two tests all the time. When my previous car got very old, I decided I would experimentally, letter-of-the-law, stop for any pedestrian with his or her toe in the crosswalk on my side. I was rear-ended twice by drivers not capable of making significant inferences.
And the bouncy ball, or the dog, or the cat, you stop for that too. What's the big cost in stopping?
but if their liability is limited, then GM has a reduced incentive to build a safe car. As part of their fiduciary duty to their shareholders, they should cut corners. There has to be some cost feedback for safety defects. The usual sources of such feedback are lawsuit, regulation, or market. Because market penalties are disorganized and far in the future, I think they tend to be discounted.
I don't think bad-ass algorithms are required. As near as I can tell, most accidents can be avoided simply by slowing down, if you are paying attention (and that is what the computer is supposed to do without fail) and decelerate at the appropriate time. In my own driving I try to make a point of maintaining a prudent spacing behind the car in front of me, and to spot nearby cars who aren't especially steady in their lane. Boring, but apparently safe, with no stunt-car driving necessary.
Before you respond with "but you can't..." consider what I already do (this, from an overweight guy approaching 50 years old). I do all my planned grocery shopping on my bike. I pick up and drop off the child who is not embarrassed to be seen with me, on my bike. I ride in Boston winters now, including on ice ("customized" with snow tires and 5 watts of alternator-driven LEDs, using an utterly unoriginal circuit of my own design). Growing up, I rode my bike in Florida summers. I've gone riding in rain and snowstorms; the main impediment is fear of how badly some people in cars drive under those conditions. When the Loma Prieta quake (1989) took out all the traffic signals, those of us who had bike-commuted that day rode home unimpeded. Bikes excel at short trips, especially to places with rotten parking (Cambridge, grocery store the day before a snowstorm).
There are also choices for the less able. Tricycles (either upright or recumbent) do away with the need for good balance. Electric assists help you if you are weak, or have difficult hills on your daily route.
Bikes, for me, lose most badly on three points: I can't lock up my stuff up, they're too slow for "long" trips (> 15 miles, for me), and I don't feel safe in Very Bad Traffic (downtown Boston -- strictly speaking, this is not the fault of the bike, but the fault of careless people in cars, but human carelessness is a given).
And, to return somewhat to the point of the article, I would not necessarily expect this technology to make loads of money for GM. Once the car is automated, as several other posters have pointed out, why not have the robot run your errands for you? And, why should it be your dedicated robot? Why not a robot delivery service? And following that, the cheapest robots, from the POV of production, maintenance, energy, and liability risk, are the lighter ones -- robot tricycles, most likely. That's not GM's business, and it's not necessarily a large business, either; no need for all the bells and whistles that get added to your typical car. They'll built them in China, using mostly bicycle parts and technology, with an itty-bitty brain to drive them, and they'll be dirt cheap, compared to cars.
Well, product names, I am especially clueless. I have few clues about other things.
Seriously, when I ran a workstealing benchmark (which is all about interprocessor synchronization) it ran just as fast at 32 threads as it did at 1. The 1-thread performance is nothing to shout about, but at 16, it's suddenly kicking the ass of every other computer I can get my hands on (because of all the synchronization) and it can do that all the way out to 32. I have heard, through the grapevine, that the Niagara 1 (and perhaps the 2) provides spectacular GUPS/watt performance (GUPS is a random-access general update benchmark).
The "interesting times" part of this much multicore is that it is now possible to run out of all sorts of stuff -- should you devote chip area to floating point, or to store buffers, or to L2 cache, or to one more core? People are studying scheduling algorithms where they actually (sometimes) shut down a core to reduce resource thrashing on chip, for loads that thrash.