When you are a little fish . . . run to your lawyer, then together make yourselves the very best friends that the FBI ever had.
Yes, run. It is official Justice Department policy that only the first conspirator to report a criminal conspiracy gets off:. "(the) Division frequently encounters situations where a company approaches the government within days, and in some cases less than one business day, after one of its co-conspirators has secured its position as first in line for amnesty. Of course, only the first company to qualify receives amnesty. "
If you've followed the details of the Madoff scandal, it was obvious that it required substantial computer support.
Each month, Madoff's investors got statements which showed fictitious trades and fictitious profits. The phony trades were for real stocks, with prices which were (almost) real. But the trades were chosen retrospectively, which is like betting on a race after it's run. So superficially reasonable statements came out.
This was all generated on an AS-400 that had been in use for this for several decades.
The software wasn't very good. If they'd been better at it, they could have generated statements which showed trades which exactly matched real trades of others (from the "tape"; trades are public but traders are anonymous), delivered trade confirmations every day, and still shown phony profits just by picking trades randomly distributed around the 75% of each day's trades. That would survive external examination, but not a real audit. Close looks at Madoff statements show trades which could not possibly have occurred; the price is outside the day's trading range. Sloppy.
The problem isn't pushing the bits across the wire. Major sites that load slowly today (like Slashdot) typically do so because they have advertising code that blocks page display until the ad loads. The ad servers are the bottleneck. Look at the lower left of the Mozilla window and watch the "Waiting for..." messages.
Even if you're blocking ad images, there's still the delay while successive "document.write" operations take place.
Then there are the sites that load massive amounts of canned CSS and Javascript. (Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)
Then there are the sites that load a skeletal page which then makes multiple requests for XML for the actual content.
So most of these scam networks block Northern California, to prevent Facebook HQ from seeing them? So that's why I don't see them.
I'm a few miles from Facebook HQ. I've completely missed this phenomenon.
I'd applied SiteTruth to Google ads, trying to warn users about the "bottom feeders" with no identifiable legitimate business behind the ad.
Myspace is mostly Google ads, so that's covered. Google ads in general are about 35% "bottom feeders" (we track this), but on Myspace, the percentage is much higher. From the article, Facebook has a similar problem, but it's mostly in the form
of Facebook-specific ads, games, etc. We're not catching those.
Actually, you can. See Microsoft Managed C++. But it's not happy. Destructors and garbage collection do not play well together. Calling destructors from the garbage collector introduces a kind of concurrency which leads to difficulties if the destructor does something non-trivial, like close a window or a file.
There's general agreement in the industry that we're near peak oil. The peak may have happened already, in 2006-2008. The most optimistic view is that the peak will be around 2020. That's not far away.
Prices aren't that good an indicator of availability. Because supply and demand are both relatively inelastic and change slowly. So small variations in supply or demand produce big changes in price. The worldwide recession has cut demand a bit, which brought the price way down. Supply did not increase.
Then there's France. Back in the 1970s, France decided to go nuclear. France has 59 nuclear power plants and exports electricity. It's good to plan ahead.
Actually, you don't need pointer arithmetic for a "systems language". Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath. You need the ability to explicitly place arrays in memory as a form of privileged hardware access, but it's not something that's used in most code.
Garbage collection, though, implies there's a layer of software underneath your code. Garbage collectors either freeze the whole program, or need some help from the MMU to track pages altered while the collector is running. Hard real time and reference counts do not play well together.
Reference counted systems don't inherently have that problem, and if the compiler optimizes out reference count updates they can be efficient. But most reference counted systems are slow and dumb.
It's sad to see yet another C++ alternative that can't actually replace C++. We need a C++ replacement. C++ has stagnated. C++ is the only major language to have hiding ("abstraction") without memory safety, a bad combination never tried again. Strostrup is in denial about this being a problem, and the C++ standards committee is of in template la-la land, fussing over features few care about and fewer will use correctly.
The previous poster is right, though. This is a language for writing applications to run on servers. Google needs something less painful than C++ and faster than Python. (Python is a reasonably good language held back by an archaic naive-interpreter implementation. Making Python fast is hard, though, because the compiler has to do type inference to figure out the variable type information the user isn't asked to provide. ShedSkin shows that can work, but that project only has one person on it.)
It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?
One could do worse. There was a language called "C+@" developed at Bell Labs. It's derived from C, with classes, dynamism, and safety, much like Java. It predates Java by a few years. Try to find it.
He's a god damned idiot. Or an attention whore. Or both.
Like him or not, Murdoch is not dumb. Nor, for someone who owns upwards of 175 newspapers, several TV networks, and a direct broadcast satellite system, does he indulge in much self-publicity.
MySQL matters. NetBeans, not so much. Most of the web runs on MySQL. There aren't that many good open-source alternatives. (Oracle owns BerkeleyDB, too.)
PostgreSQL is about it, and because that's Berkeley-licensed code, not GPL, it can be forked and the open version abandoned.
Oracle has to dump something. I'm surprised they kept the SPARC line alive. It just doesn't seem to be necessary any more, and it was a money drain for Sun.
This has been done before, and better, in California. See Demo 97.
There's considerable military interest in follow-the-leader systems for convoys. The military routinely drives trucks around in big groups.
The US Army has a system in test where the lead vehicle (usually armored) leads a group of driverless trucks. That's to reduce casualties, not labor.
The fundamental problem with most automated driving schemes is that they address driving on freeways, which people don't mind all that much. Automatically retrieving your car from a parking garage or lot and bringing it to you would actually sell.
That's nothing. Fuller proposed a dome over Manhattan. Now that would have been something.
Domes have a bad reputation, for the wrong reasons. Domes with factory-manufactured parts protected big radar antennas in the Arctic for decades. Those worked fine. "Hippie domes" made of "natural materials" didn't. The bad rep comes from the Domebook 1 and 2 people. Their idea of a dome was a frame covered with shingles on the outside and wallboard on the inside, like a wood-framed house. Trying to make flat components to fit a dome on site was a disaster.
Fuller had the right idea; you make all the parts in a factory, where you can hold tolerances, and assemble on site.
The way small domes should have worked is with triangular standardized inserts - windows, solid walls, vents, wall sections with utility ducts, etc. The sections would be several inches thick, with proper insulation and gaskets. Once the frame was up (the easy part) assembly would consist of putting the inserts into the dome's triangles. You need enough volume to support the manufacturing needed to do this. That's the problem the amateurs ran into.
Domes still have the problem that much of the volume is unusable, but there's no reason they can't be constructed reliably.
Right. A big problem is that 75% of US utilities use a protocol called DNP, which has been around since 1990 and has no security whatsoever. DNP is often transported over IP networks, ones which are hopefully not connected to the Internet. There's a secure version of DNP, with cryptographic authentication (not encryption) but it was only standardized last year and is still in test.
DNP is a master/slave system; there's a "master station" which makes all the decisions, and slave devices which report and obey. It's not really very distributed. That's a relatively simple situation to secure, and even that isn't widely implemented. Systems where there are multiple nodes making decisions don't fit the DNP security model well.
Here's a worrisome diagram. Windows machines on a LAN which can get to a power company's SCADA network, connected to the Internet through McAfee Firewall Enterprise Edition boxes.
AOL settled with the National Organization for the Blind on that one, agreeing to make their client more "accessible". That was in 2000, when AOL's web client mattered.
Target settled their online ADA lawsuit in 2008. But that was related to Target's having physical stores subject to the ADA, and the web site being related to the stores.
The ADA only applies to "commercial speech", where the intent is to sell. In the US, the First Amendment preempts the ADA for non-commercial speech by non-government parties. It would be "forced speech", prohibited by the First Amendment, to require "accessible content" for non-commerce web sites and for content delivered through non-monopoly-regulated channels.
I was just using the iPhone as an example. I just need an API that accesses Google Voice for SMS. "pygooglevoice" has the right functionality, but once I got it working, I realized that underneath, the efficiency is awful.
Eventually Google's developers will figure this out, and either block programmable clients or add an API.
Google inherited this thing from Grand Central, which never had that many users, and it needs some rework for scaleup.
Several commercial SMS gateways deliver SMS messages to web sites by making an HTTP request of the customer's web site. That's a form of "push". RSS polling wouldn't be expensive to support if done right. "No traffic" polls are cheap, especially if the information that user N has no new traffic is in RAM.
Well, they have to keep up the whole SMS racket. If each SMS message went through as one IP packet, how could they charge $0.20 each?
Putting SMS on the Internet can be botched. though. Google just did it. Google Voice supports SMS send and receive. Google's site can be queried for SMS in XML and JSON. There's a Python library for this. All this works. But Google's returned XML has so much useless dreck in it that each poll returns about 100K of data, even if there's no new SMS traffic. Thus, if you poll every 30 seconds and get no new messages, you use a quarter of a gigabyte a day of bandwidth just polling. So don't do that in an iPhone app to save on SMS charges.
Google needs to put Google Voice on something like RSS, where there's a way to cheaply poll to find out if anything changed.
When polling RSS, you send back the ID from the previous poll reply. If you get a 304 status and no data, nothing changed. It would also help if they got the RSS implementation right. Some RSS servers return a new unique ID every time, even when nothing changed. (Twitter, I'm looking at you here.)
There are thus some widely used services which waste vast amounts of bandwidth trying to do by pull and poll what can be cheaply done by push.
Graphics systems used to have huge numbers of controls. Evans and Sutherland had a workstation with eight knobs, a trackball, a joystick, and a tablet. There's some justification for this in 3D CAD and animation programs - for example, it's really useful to be able to zoom while you're dragging, resizing, or drawing something. Mouse wheels were a big win in 3D work - at last, you could get that capability without nonstandard hardware. People who do character animation often have a knob or slider box on a MIDI port, driving the character's joints. Some shops make up a jointed model as an input device. In 3D work, you're trying to control so many interrelated adjustments that you need all the help you can get.
But for an office program, it's just silly.
OpenOffice does need UI help; it's hugely inferior to Microsoft's products in that area.
Shockwave is a real 3D system usable as a decent game engine. At one time, it even had the Havok physics engine, but Adobe didn't keep up the payments and had to take that out. Try BMX Street Rider, which is a reasonably decent free-play game in a modest sized city. It's way ahead of the proposed hacks for doing 3D with Javascript.
What killed Shockwave for trivial applications is "LOADING..." problems. Flash can start before all the content has been loaded, because Flash has two interleaved streams, a timeline and assets. As soon as you have enough assets for the stuff needed by the timeline so far, Flash can go. So you can write Flash that starts fast and loads assets in the background.
PayPal calls this WebSite Payments Pro. They don't use the world "Open", at least not to developers.
What they are offering is essentially the same thing banks offer as "merchant accounts" that connect to "shopping cart" programs. But, this being PayPal, without all the consumer protections that banks are required to provide. I've been reading through the documentation, and there's no sign of all the security requirements Visa imposes on merchants.
(Well, actually there is - under "Legal Agreements, Exhibit A". But there's no sign of technical requirements to back them up.)
Technically, the IEC power connector, as found on the back of most computers, is one of the best. You usually see a chassis-mount IEC male connector and a cord-mount female connector, but the reverse forms are available.IEC "wall sockets" are sometimes found in rackmount server outlet strips. The plug is shrouded, and the socket has an enclosing slot for the shroud, so at no time are energized pins exposed. The shroud engages the enclosing slot before the pins make contact. That's a key safety feature. It allows a smaller plug; if exposed pins are energized while the plug is being plugged in, the plug has to be made larger to keep fingers away from the pins.
IEC is a flat-pin design, which is good. Getting a large contact area on round pins is hard, so round-pin connectors of a given size usually carry less current. Flat-pin contacts just slide between two flat spring-loaded blades, which can accommodate wear on both surfaces. The split-cylinder contacts of round-pin female connectors have to match closely, so as they wear, the inside radius of the cylinder increases and no longer properly matches the pin.
Round pins vs. flat contact blades are sometimes used; they wear better, but the the contact area is small.
The older round-pin European connectors are only rated for 10A, sometimes only 7.5A. At 240V, this is adequate. IEC connectors are rated for 15A, and there's a 20A form.
Today we expect connectors to just work, but it took considerable engineering to get to that point. As late as 1980, computers had serious problems with connector unreliability.
The trouble with the OLPC is that it's mostly a vehicle so that Negroponte can hang out with heads of state and such.
Actually shipping product is secondary. It's all about national-level deals.
Remember when OLPC had a "buy 2, get 1, give 1" program, and they botched basic order fulfillment?
Those things should be in bubble-packs alongside the graphing calculators, with the price down to the original $99 by now. They don't need a fancier model. They need a cheaper model. They're being run over by the netbook industry. Netbooks are down to $100 if you buy in bulk from China. Look on Alibaba.
When you watch the precision [youtube.com] of the people flying Predators and Reapers, one wonders what would be the incentive to give the machines more autonomy.
Because they land better semi-autonomously. The USAF flies the things manually with remote officer pilots in the US. The Army uses autoland and enlisted controllers located with the using units. The USAF has a much higher crash rate than the Army.
Slashdot Mirror
When you are a little fish . . . run to your lawyer, then together make yourselves the very best friends that the FBI ever had.
Yes, run. It is official Justice Department policy that only the first conspirator to report a criminal conspiracy gets off:. "(the) Division frequently encounters situations where a company approaches the government within days, and in some cases less than one business day, after one of its co-conspirators has secured its position as first in line for amnesty. Of course, only the first company to qualify receives amnesty. "
If you've followed the details of the Madoff scandal, it was obvious that it required substantial computer support.
Each month, Madoff's investors got statements which showed fictitious trades and fictitious profits. The phony trades were for real stocks, with prices which were (almost) real. But the trades were chosen retrospectively, which is like betting on a race after it's run. So superficially reasonable statements came out. This was all generated on an AS-400 that had been in use for this for several decades.
The software wasn't very good. If they'd been better at it, they could have generated statements which showed trades which exactly matched real trades of others (from the "tape"; trades are public but traders are anonymous), delivered trade confirmations every day, and still shown phony profits just by picking trades randomly distributed around the 75% of each day's trades. That would survive external examination, but not a real audit. Close looks at Madoff statements show trades which could not possibly have occurred; the price is outside the day's trading range. Sloppy.
Wait a few years. In five years or so, those addresses will have scrolled off blacklists. It's not a big deal.
The problem isn't pushing the bits across the wire. Major sites that load slowly today (like Slashdot) typically do so because they have advertising code that blocks page display until the ad loads. The ad servers are the bottleneck. Look at the lower left of the Mozilla window and watch the "Waiting for ..." messages.
Even if you're blocking ad images, there's still the delay while successive "document.write" operations take place.
Then there are the sites that load massive amounts of canned CSS and Javascript. (Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)
Then there are the sites that load a skeletal page which then makes multiple requests for XML for the actual content.
Loading the base page just isn't the problem.
"Peak Oil is Still a Cause for Concern, Say 70% of Geologists at Summit"
So most of these scam networks block Northern California, to prevent Facebook HQ from seeing them? So that's why I don't see them. I'm a few miles from Facebook HQ. I've completely missed this phenomenon.
I'd applied SiteTruth to Google ads, trying to warn users about the "bottom feeders" with no identifiable legitimate business behind the ad. Myspace is mostly Google ads, so that's covered. Google ads in general are about 35% "bottom feeders" (we track this), but on Myspace, the percentage is much higher. From the article, Facebook has a similar problem, but it's mostly in the form of Facebook-specific ads, games, etc. We're not catching those.
Maybe it's time to do that.
You cannot shoehorn a GC into C++.
Actually, you can. See Microsoft Managed C++. But it's not happy. Destructors and garbage collection do not play well together. Calling destructors from the garbage collector introduces a kind of concurrency which leads to difficulties if the destructor does something non-trivial, like close a window or a file.
There's general agreement in the industry that we're near peak oil. The peak may have happened already, in 2006-2008. The most optimistic view is that the peak will be around 2020. That's not far away.
Prices aren't that good an indicator of availability. Because supply and demand are both relatively inelastic and change slowly. So small variations in supply or demand produce big changes in price. The worldwide recession has cut demand a bit, which brought the price way down. Supply did not increase.
All the easy places have already been drilled. US oil production peaked in 1970. Look at this list of countries where production has peaked.
Then there's France. Back in the 1970s, France decided to go nuclear. France has 59 nuclear power plants and exports electricity. It's good to plan ahead.
Actually, you don't need pointer arithmetic for a "systems language". Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath. You need the ability to explicitly place arrays in memory as a form of privileged hardware access, but it's not something that's used in most code.
Garbage collection, though, implies there's a layer of software underneath your code. Garbage collectors either freeze the whole program, or need some help from the MMU to track pages altered while the collector is running. Hard real time and reference counts do not play well together. Reference counted systems don't inherently have that problem, and if the compiler optimizes out reference count updates they can be efficient. But most reference counted systems are slow and dumb.
It's sad to see yet another C++ alternative that can't actually replace C++. We need a C++ replacement. C++ has stagnated. C++ is the only major language to have hiding ("abstraction") without memory safety, a bad combination never tried again. Strostrup is in denial about this being a problem, and the C++ standards committee is of in template la-la land, fussing over features few care about and fewer will use correctly.
The previous poster is right, though. This is a language for writing applications to run on servers. Google needs something less painful than C++ and faster than Python. (Python is a reasonably good language held back by an archaic naive-interpreter implementation. Making Python fast is hard, though, because the compiler has to do type inference to figure out the variable type information the user isn't asked to provide. ShedSkin shows that can work, but that project only has one person on it.)
It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?
One could do worse. There was a language called "C+@" developed at Bell Labs. It's derived from C, with classes, dynamism, and safety, much like Java. It predates Java by a few years. Try to find it.
He's a god damned idiot. Or an attention whore. Or both.
Like him or not, Murdoch is not dumb. Nor, for someone who owns upwards of 175 newspapers, several TV networks, and a direct broadcast satellite system, does he indulge in much self-publicity.
MySQL matters. NetBeans, not so much. Most of the web runs on MySQL. There aren't that many good open-source alternatives. (Oracle owns BerkeleyDB, too.) PostgreSQL is about it, and because that's Berkeley-licensed code, not GPL, it can be forked and the open version abandoned.
Oracle has to dump something. I'm surprised they kept the SPARC line alive. It just doesn't seem to be necessary any more, and it was a money drain for Sun.
This has been done before, and better, in California. See Demo 97.
There's considerable military interest in follow-the-leader systems for convoys. The military routinely drives trucks around in big groups. The US Army has a system in test where the lead vehicle (usually armored) leads a group of driverless trucks. That's to reduce casualties, not labor.
The fundamental problem with most automated driving schemes is that they address driving on freeways, which people don't mind all that much. Automatically retrieving your car from a parking garage or lot and bringing it to you would actually sell.
That's nothing. Fuller proposed a dome over Manhattan. Now that would have been something.
Domes have a bad reputation, for the wrong reasons. Domes with factory-manufactured parts protected big radar antennas in the Arctic for decades. Those worked fine. "Hippie domes" made of "natural materials" didn't. The bad rep comes from the Domebook 1 and 2 people. Their idea of a dome was a frame covered with shingles on the outside and wallboard on the inside, like a wood-framed house. Trying to make flat components to fit a dome on site was a disaster. Fuller had the right idea; you make all the parts in a factory, where you can hold tolerances, and assemble on site.
The way small domes should have worked is with triangular standardized inserts - windows, solid walls, vents, wall sections with utility ducts, etc. The sections would be several inches thick, with proper insulation and gaskets. Once the frame was up (the easy part) assembly would consist of putting the inserts into the dome's triangles. You need enough volume to support the manufacturing needed to do this. That's the problem the amateurs ran into.
Domes still have the problem that much of the volume is unusable, but there's no reason they can't be constructed reliably.
Right. A big problem is that 75% of US utilities use a protocol called DNP, which has been around since 1990 and has no security whatsoever. DNP is often transported over IP networks, ones which are hopefully not connected to the Internet. There's a secure version of DNP, with cryptographic authentication (not encryption) but it was only standardized last year and is still in test.
DNP is a master/slave system; there's a "master station" which makes all the decisions, and slave devices which report and obey. It's not really very distributed. That's a relatively simple situation to secure, and even that isn't widely implemented. Systems where there are multiple nodes making decisions don't fit the DNP security model well.
Here's a worrisome diagram. Windows machines on a LAN which can get to a power company's SCADA network, connected to the Internet through McAfee Firewall Enterprise Edition boxes.
AOL settled with the National Organization for the Blind on that one, agreeing to make their client more "accessible". That was in 2000, when AOL's web client mattered.
Target settled their online ADA lawsuit in 2008. But that was related to Target's having physical stores subject to the ADA, and the web site being related to the stores.
The ADA only applies to "commercial speech", where the intent is to sell. In the US, the First Amendment preempts the ADA for non-commercial speech by non-government parties. It would be "forced speech", prohibited by the First Amendment, to require "accessible content" for non-commerce web sites and for content delivered through non-monopoly-regulated channels.
Games aren't usually "commercial speech".
I was just using the iPhone as an example. I just need an API that accesses Google Voice for SMS. "pygooglevoice" has the right functionality, but once I got it working, I realized that underneath, the efficiency is awful.
Eventually Google's developers will figure this out, and either block programmable clients or add an API. Google inherited this thing from Grand Central, which never had that many users, and it needs some rework for scaleup.
Several commercial SMS gateways deliver SMS messages to web sites by making an HTTP request of the customer's web site. That's a form of "push". RSS polling wouldn't be expensive to support if done right. "No traffic" polls are cheap, especially if the information that user N has no new traffic is in RAM.
Well, they have to keep up the whole SMS racket. If each SMS message went through as one IP packet, how could they charge $0.20 each?
Putting SMS on the Internet can be botched. though. Google just did it. Google Voice supports SMS send and receive. Google's site can be queried for SMS in XML and JSON. There's a Python library for this. All this works. But Google's returned XML has so much useless dreck in it that each poll returns about 100K of data, even if there's no new SMS traffic. Thus, if you poll every 30 seconds and get no new messages, you use a quarter of a gigabyte a day of bandwidth just polling. So don't do that in an iPhone app to save on SMS charges.
Google needs to put Google Voice on something like RSS, where there's a way to cheaply poll to find out if anything changed. When polling RSS, you send back the ID from the previous poll reply. If you get a 304 status and no data, nothing changed. It would also help if they got the RSS implementation right. Some RSS servers return a new unique ID every time, even when nothing changed. (Twitter, I'm looking at you here.)
There are thus some widely used services which waste vast amounts of bandwidth trying to do by pull and poll what can be cheaply done by push.
Graphics systems used to have huge numbers of controls. Evans and Sutherland had a workstation with eight knobs, a trackball, a joystick, and a tablet. There's some justification for this in 3D CAD and animation programs - for example, it's really useful to be able to zoom while you're dragging, resizing, or drawing something. Mouse wheels were a big win in 3D work - at last, you could get that capability without nonstandard hardware. People who do character animation often have a knob or slider box on a MIDI port, driving the character's joints. Some shops make up a jointed model as an input device. In 3D work, you're trying to control so many interrelated adjustments that you need all the help you can get.
But for an office program, it's just silly.
OpenOffice does need UI help; it's hugely inferior to Microsoft's products in that area.
Even Adobe can't explain Shockwave properly.
Shockwave is a real 3D system usable as a decent game engine. At one time, it even had the Havok physics engine, but Adobe didn't keep up the payments and had to take that out. Try BMX Street Rider, which is a reasonably decent free-play game in a modest sized city. It's way ahead of the proposed hacks for doing 3D with Javascript.
What killed Shockwave for trivial applications is "LOADING..." problems. Flash can start before all the content has been loaded, because Flash has two interleaved streams, a timeline and assets. As soon as you have enough assets for the stuff needed by the timeline so far, Flash can go. So you can write Flash that starts fast and loads assets in the background.
PayPal calls this WebSite Payments Pro. They don't use the world "Open", at least not to developers.
What they are offering is essentially the same thing banks offer as "merchant accounts" that connect to "shopping cart" programs. But, this being PayPal, without all the consumer protections that banks are required to provide. I've been reading through the documentation, and there's no sign of all the security requirements Visa imposes on merchants.
(Well, actually there is - under "Legal Agreements, Exhibit A". But there's no sign of technical requirements to back them up.)
Technically, the IEC power connector, as found on the back of most computers, is one of the best. You usually see a chassis-mount IEC male connector and a cord-mount female connector, but the reverse forms are available. IEC "wall sockets" are sometimes found in rackmount server outlet strips. The plug is shrouded, and the socket has an enclosing slot for the shroud, so at no time are energized pins exposed. The shroud engages the enclosing slot before the pins make contact. That's a key safety feature. It allows a smaller plug; if exposed pins are energized while the plug is being plugged in, the plug has to be made larger to keep fingers away from the pins.
IEC is a flat-pin design, which is good. Getting a large contact area on round pins is hard, so round-pin connectors of a given size usually carry less current. Flat-pin contacts just slide between two flat spring-loaded blades, which can accommodate wear on both surfaces. The split-cylinder contacts of round-pin female connectors have to match closely, so as they wear, the inside radius of the cylinder increases and no longer properly matches the pin. Round pins vs. flat contact blades are sometimes used; they wear better, but the the contact area is small.
The older round-pin European connectors are only rated for 10A, sometimes only 7.5A. At 240V, this is adequate. IEC connectors are rated for 15A, and there's a 20A form.
Today we expect connectors to just work, but it took considerable engineering to get to that point. As late as 1980, computers had serious problems with connector unreliability.
The trouble with the OLPC is that it's mostly a vehicle so that Negroponte can hang out with heads of state and such. Actually shipping product is secondary. It's all about national-level deals. Remember when OLPC had a "buy 2, get 1, give 1" program, and they botched basic order fulfillment?
Those things should be in bubble-packs alongside the graphing calculators, with the price down to the original $99 by now. They don't need a fancier model. They need a cheaper model. They're being run over by the netbook industry. Netbooks are down to $100 if you buy in bulk from China. Look on Alibaba.
When you watch the precision [youtube.com] of the people flying Predators and Reapers, one wonders what would be the incentive to give the machines more autonomy.
Because they land better semi-autonomously. The USAF flies the things manually with remote officer pilots in the US. The Army uses autoland and enlisted controllers located with the using units. The USAF has a much higher crash rate than the Army.