Most of the remaining MPEG LA patents that matter run out in Q1 2014. They have others, but most of them are on features added to MPEG-4 late, ones that aren't needed in a browser's decoder, such as interlace support and decoding of images with errors.
While I am all for automation, Kiva is about as dehumanizing a system as I could imagine possible.
Agreed. Kiva is one of the most blatant examples of "Machines should think, people should work". The intelligence in the system is in computers. All the humans do is reach into the bin the laser pointer
points to, take out an item, wave it under a bar code scanner, and put it in the output bin which has a light on. It takes 15 minutes to learn the job (really, about 90 seconds, but you get a little faster with practice). There's no hope of promotion, and it's only a temporary job until the picking robots are developed.
This should be very effective if it works. Which it should. Automated manufacturing usually takes a lot of startup time. Production lines have to be designed, fabricated, and carefully installed with everything aligned properly.
There's already a big success in this area - Kiva Systems. They make those little mobile robots used for order processing. Kiva already is handling about 20% of online orders, and Amazon bought the company recently. Setting up a warehouse for Kiva is simple - all you really need is a big flat floor. You put down markers for robot guidance, bring in the shelving units, the charging stations, and the human order-picking stations, which are all standard components, hook everything up to the servers, and go. No need to fabricate and install complex conveyor systems. No need for on-site robot repair techs - all the Kiva robots are interchangeable, so you have spares, and you can just send them back to Kiva HQ (which is small) for repairs.
Having once written for HyperCard, I'm glad it's gone. It had some syntax in common with COBOL. ADD 1 TO N is valid COBOL and valid HyperTalk. The data access in Hypercard (put the second word of name into last_names) was worse than COBOL.
If you used card names instead of card numbers, the program ran much slower.
The cited article is interesting, but he never gets into Bitcoin's "contract" capabiilty. There have been proposals to add mechanisms to Bitcoin so that you could send Bitcoins to someone, but they couldn't spend them until the sender committed the transaction. This provides a way to insure you get the goods when you order something.
So far, that's a future feature, not a usable one. This is why Bitcoin remains the scammer's paradise - anonymous, irrevocable remote money transfer. There's little risk of annoying lawsuits, cops, or armies of angry customers with pitchforks coming after you.
As a result, more than half of Bitcoin "exchanges" have gone under, usually taking customer funds with them.
Most alternative reactor designs have some major flaw. Sodium reactors have sodium fires. Pebble-bed reactors have pebble jams. (An experimental one in Germany is such a mess there's no way to fully decommission it.) Helium gas-cooled reactors leak helium. (Fort St. Vrain was converted from nuclear to natural gas because of that.) One of the painful lessons of long-life nuclear power plants is that what goes on inside the reactor vessel has to be really, really simple. Anything complex in there will break. It's being shot full of holes at the atomic level, after all. (See "hydrogen embrittlement").
Pressurized water reactors and boiling water reactors at least have only water to deal with. The fuel rods are solid rods. The thing is basically simple, although the plumbing gets insanely complex. Even then, big accidents have happened.
Some of the fancier reactor designs require an associated chemical plant to reprocess the materials. This is a pain if you're in the power generation business, and a source of leaks and risks.
Show me someone building an airplane. Oh sorry, you need an FAA license for that...
Check out the Experimental Aircraft Association. Visit the Oshkosh Fly-In. FAA regulations on experimental aircraft are quite lenient. You can't carry passengers or fly over heavily populated areas, which is reasonable enough. For flight test, there's the Mojave Air and Space Port. "My job is to give people permission. Every day in the skies over Mojave and on the ground at Mojave Air & Space Port, people take enormous risks, which someday will yield great things for all humanity."
-- Stuart Witt, CEO, Mojave Air & Space Port.
How about a rocket?
"You want to test a rocket engine? This is a place where you can do that." -- Board of Directors, Mojave Air and Space Port. SpaceShip One and various X-Prize trials have launched from Mojave. Rotary Rocket flew from there, although not very far. I know people at TechShop building upper stage engines for orbital insertion.
Flying car? Forget it...
There are several ultralight helicopter kits. Quadrotors seem to get bigger each year. Thrust-type VTOLs need a lot of power, which usually means jet engines, which means a flying car will cost about as much as a small bizjet, which limits the market. Paul Moller built a flying car; it doesn't work, but that's Moller's problem, for which he's been making excuses for 40 years. I had some hopes for Urban Aeronautics out of Israel, which was showing a non-flying mockup in 2010, but they never made it fly.
Government is not preventing you from doing any of these things.
Did this guy just reinvent spreadsheets?
There's something to be said for this, but having written in Prolog, which works that way, the 'reactive programming' people have to make a better case than the article does.
On the other hand, one of the big problems in databases is change notification. Microsoft at one point had a research project on this. The concept was that you could make a request to be notified when something of interest changed in the database. This was expressed as an SQL SELECT statement. When some change was made that would affect the output of your pending SELECT, you'd be notified. The problem was to figure out some efficient way to do this with thousands or millions of pending SELECT statements.
Finance people use notifications like that all the time. Limits on stocks, limits on combinations of stocks, changes in key ratios, that sort of thing. But the systems for that are specialized, a special case of a more general problem. The most general form of the problem is that B wants to know when something has changed at A. Most of the solutions for this have problems. Polling is either inefficient or slow. B relying on A to message them on a change has a failure problem. Both approaches can result in overloading A with checks for events that aren't happening.
The point to take away here is that you can generally avoid being charged with "bad faith" by not doing specific bad things. The standard in the bill is much more ambiguous.
On the other side, an infinger can be charged triple damages for "willful infringement". A recent court decision raised that standard to "willful and reckless", which is almost impossible to prove.
There's a 12-volt lead-acid battery in the thing to power the auxiliary systems. It's the same size as a regular automotive battery, but apparently is a sealed type, intended to last the life of the vehicle. Since it doesn't need to provide cranking power, a high-current battery isn't necessary.
Tesla owners have been reporting 12 volt battery failures for months. Usually the charging system reports "12 volt battery failure", but apparently a partial failure is possible, where the aux battery is an energy drain but still functional.
It's my understanding, and the GP who read the whole thing states, that the plaintiff pays the defendant's fees only if the sued IN BAD FAITH.
Close, but not quite. "Bad faith" has a specific meaning in law. It requires malicious intent. The burden of proof is on the party claiming bad faith, and it's hard to prove intent.
That language was fought over and amended. Originally, it was loser pays almost all the time. Here's what passed the House:
(a) Award- The court shall award, to a prevailing party, reasonable fees and other expenses incurred by that party in connection with a civil action in which any party asserts a claim for relief arising under any Act of Congress relating to patents, unless the court finds that the position and conduct of the nonprevailing party or parties were reasonably justified in law and fact or that special circumstances (such as severe economic hardship to a named inventor) make an award unjust.
That's a presumption that the loser pays, but the loser can try to convince the judge that their position was "reasonably justified in law and fact". The burden of proof is on the loser. and there's no requirement of bad intent. It's quite possible to start an infringement case and find out during litigation that the position taken was not "reasonably justified in fact".
The effect is to place inventors at risk of losing several milion dollars should they try to assert patent rights against a big company. It's all about making inventors afraid.
About ten years ago, I went to a talk at Stanford where someone showed that the increasing costs of wafer fabs would make this happen around 2013. We're right on schedule.
Storage can still get cheaper. We can look forward to a few more generations of flash devices. Those don't have to go faster.
Picasa acquired by Google - New York Times, 2004. "'They came to the conclusion that it would be easier to buy this business than to build it themselves. It's the type of acquisition you can expect Google to do more of in the future.'' The self-driving car technology was acquired from Stanford, along with Sebastian Thrun. Google did do a lot with language translation in-house; that's probably the most innovative area. Most of Google's big-name products, though, came from elsewhere.
Google is good at scaling, and yes, many of the acquired products had to be rewritten to scale up. Still, Google Earth today looks a lot like the Keyhole Earth Viewer I had in 2003.
I've read the current language of the bill and there is nothing there that harms small inventors. Everything there makes large-scale patent trolling less attractive as a business model.
The worst part is the remnant of the "loser pays" provision. If you try to enforce a patent against a big company, if you lose you have a good chance of being hit with the big guy's legal bills. There's no cap on that. That provision was amended, which made it "slightly less awful", as one congressman put it. After the amendment, the new language now means you get to litigate over the legal fees. Statistically, the patent holder wins about 40% of the time, and even with a good case, it's easy to make a mistake and lose.
The Leahy bill is better. It's more narrowly directed towards bulk-type patent enforcement operations, doesn't have a loser-pays provision, and proposes a small claims court for smaller patent cases.
This isn't an anti-patent troll bill. It's an anti-small inventor bill. It's designed to make it more expensive to enforce patents. That won't affect Google vs Apple vs Microsoft, etc. It just makes it harder for a little company to enforce a patent against a big one. That was the intention. (The Leahy bill in the Senate isn't that bad, but the Goodlatte bill that just passed the House is awful.)
This bill has been pushed through by a hate campaign against inventors. It's a well-funded campaign, and it's suckered in many people.
The money is coming from Google and Facebook, who are hiding behind front organizations such as the Application Developers Association and the Electronic Frontier Foundation.
The EFF's effort is funded by Google and Facebook, with $2 million laundered through a clever legal trick.
There are very few real "patent trolls". The EFF has tried to identify every one they can, and they only found 15. They started a campaign to attack "trolled patents" in court and at the USPTO, and and they only found one. There are a few other broad patents being enforced aggressively, notably Ultramercial. That's about it.
Using that thin basis, the "patent troll" problem has been hyped as a major threat. There are hate sites aimed at inventors:
"Trolling Effects" (EFF) "Trolling Effects is a resource for those who have been targeted by patent trolls. Here you can learn more about these bad actors."
The American Association of Advertising Agencies: "These are not companies in the traditional sense that employ workers or create, market and distribute products or services; rather, they are legal entities whose sole purpose is to threaten with patent claims and then secure expedient - and lucrative - settlements based on these claims."
Application Developers Alliance: "Even the worst and least-expensive old patents are used like extortionist sledge hammers."
I used to respect the EFF, but once they took Google's money, they, too, turned to the dark side.
The big push was from Google. Google, along with Facebook and Twitter (but not Apple) sponsors the Application Developers Alliance, which is a lobbying group against "patent trolls".
To understand why this matters to Google, look at where Google's products came from.
Google, despite their reputation for innovation, has obtained most of
their technology through acquisitions of smaller companies. Google
has acquired 131 smaller companies over the years. Since the original search engine, almost all successful Google products came from the outside.
YouTube, AdSense (DoubleClick), Google Earth (Keyhole), Blogger (Genius
Labs), Android, Google Docs (Upstartle), Google Analytics (Urchin), Google Talk (Grand Central)
etc. all came from acquisitions. In house, Google developed Google
Wave and Google Buzz.
As a net buyer of IP, it's in Google's interest to keep the value
of patents down. They don't want a small company to be
able to say no to Google.
All the highway autonomous vehicle projects got as far as freeway driving. BMW, Cadillac, and Mercedes have all demonstrated this level of automatic driving. Then it gets hard.
This is about as far as you can go before entering the "deadly valley", where the vehicle can drive autonomously but isn't smart enough to recognize when it shoudn't. Google is further along; they can drive around on suburban streets.
Most of the technology needed to automate electronics manufacturing has been available for years, if not decades. See "The Macintosh Factory", showing Apple's factory in Fremont over 20 years ago. Robot assembly, mobile robots, very few people doing direct labor. Products were designed for cheap automated assembly. The Macintosh II family was noted for that - everything, including the power supply, was inserted into the case with a simple straight-down move. Everything snapped together. No wiring harnesses. "Design for manufacture" was big back then.
So what went wrong? Outsourcing for cheap labor.
"If your orders decrease, you can lay off workers. You can't lay off robots." - Tim Li, Quanta Computer. It's not so much that people are cheaper. It's that they are disposable. So are subcontractors. Everybody in the supply chain is working on low cost margins with no guarantee of future orders, so they can't invest in automation.
The "organic visualization" thing and its jargon are described in this thesis done at the MIT Media Lab. This is what happens when postmodernists try to improve on Tufte. Some of it is pretentious bullshit. But there may be the genesis of some new phone apps in there.
Here's a good, but unrelated, example of "organic visualization": BitListen This is a little HTML5/JavaScript page which depicts transactions on the Bitcoin block chain. An older example is Muckety. This can be done well, but most attempts in this direction are duds.
Drones are a solution to getting from the truck to the door (or window landing stage). The truck stops, drones fan out to deliver packages nearby, and the drones return to the truck for a quick recharge before the next delivery. In a few years, the trucks will be self-driving, Amazon warehouses will have Kiva robots, and very few people will be necessary.
Right. This is simply that it's easier to move a shipboard steam/incineration plant to where the toxics are than to move the toxics to an existing plant.
There aren't many such plants. The U.S. Army had a chemical weapons disposal plant until July 2013. It was closed, after it had been used to destroy the US's old stockpiles of chemical weapons. Demolition of the plant is underway.
Google here has the power, should they decide to use it, to extract any data they want from any page or form in Healthcare.gov by downloading a suitable tracker. Whether you think this is evil depends on how much you trust Google.
It's even worse than that. Those little bits of "tracker" code being injected are written and controlled by each tracking service. So not just Google, but CrazyEgg or ChartBeat staff could upload spyware into HealthCare.gov's site.
Google does a little checking on the injected code, mostly to make sure it won't crash the page with bad Javascript syntax. Each snippet of tracking code is enclosed in a try-block, so one tracker won't abort the other trackers. But there's no indication that Google takes any steps to limit the intrusiveness of the tracking.
CrazyEgg collects every click on every page. This is used to generate a "heat map" of web page usage, and can be misused to find out which check boxes and buttons someone used when signing up for health insurance.
Of course, all these parties claim they won't do bad stuff.
No ads are being loaded, just trackers.
Abine's DoNotTrackPlus caught CrazyEgg, Google Analytics, Doubleclick, and ChartBeat, but not Google Tag Manager itself.
The Tag Manager system has a whole API for snooping on what the user is doing and sending the data back to Google or another server. "For example, you may want to fire a conversion tracking tag when a user clicks the Submit button". The tracker can also grab information from a form being submitted and send it to Google's tag manager server.
Optimizely is a complicated scheme for serving slightly different versions of a site to different people and seeing what that does to usage patterns. This allows testing different advertising approaches, or field-testing new versions of a site to a fraction of the user base. It's not inherently evil.
DoubleClick code is being loaded because HealthCare.gov uses the Google Tag Manager. ("Tag" in this context means "web bug", not "hashtag".) Google Tag Manager is a system for managing sites that have so much web tracking that they need a management system to keep it all straight. The Tag Manager itself doesn't track anything; it just loads other code that does, based on an configuration stored on Google servers. Each tracking code source has its very own privacy policy and intrusiveness. HealthCare.gov is trying (at least for me) to load CrazyEgg, Google Analytics, Doubleclick, and ChartBeat. Which trackers are loaded is controlled by Google's config. Google generates a page of Javascript for each site and injects all the tracking code. This replaces the old approach of putting tracking code directly into web pages. Here's what it injects into Healthcare.gov. (Minified Javascript, not easy to read.)
Google here has the power, should they decide to use it, to extract any data they want from any page or form in Healthcare.gov by downloading a suitable tracker. Whether you think this is evil depends on how much you trust Google.
Slashdot Mirror
Most of the remaining MPEG LA patents that matter run out in Q1 2014. They have others, but most of them are on features added to MPEG-4 late, ones that aren't needed in a browser's decoder, such as interlace support and decoding of images with errors.
While I am all for automation, Kiva is about as dehumanizing a system as I could imagine possible.
Agreed. Kiva is one of the most blatant examples of "Machines should think, people should work". The intelligence in the system is in computers. All the humans do is reach into the bin the laser pointer points to, take out an item, wave it under a bar code scanner, and put it in the output bin which has a light on. It takes 15 minutes to learn the job (really, about 90 seconds, but you get a little faster with practice). There's no hope of promotion, and it's only a temporary job until the picking robots are developed.
Welcome to the future.
This should be very effective if it works. Which it should. Automated manufacturing usually takes a lot of startup time. Production lines have to be designed, fabricated, and carefully installed with everything aligned properly.
There's already a big success in this area - Kiva Systems. They make those little mobile robots used for order processing. Kiva already is handling about 20% of online orders, and Amazon bought the company recently. Setting up a warehouse for Kiva is simple - all you really need is a big flat floor. You put down markers for robot guidance, bring in the shelving units, the charging stations, and the human order-picking stations, which are all standard components, hook everything up to the servers, and go. No need to fabricate and install complex conveyor systems. No need for on-site robot repair techs - all the Kiva robots are interchangeable, so you have spares, and you can just send them back to Kiva HQ (which is small) for repairs.
Having once written for HyperCard, I'm glad it's gone. It had some syntax in common with COBOL. ADD 1 TO N is valid COBOL and valid HyperTalk. The data access in Hypercard (put the second word of name into last_names) was worse than COBOL.
If you used card names instead of card numbers, the program ran much slower.
The cited article is interesting, but he never gets into Bitcoin's "contract" capabiilty. There have been proposals to add mechanisms to Bitcoin so that you could send Bitcoins to someone, but they couldn't spend them until the sender committed the transaction. This provides a way to insure you get the goods when you order something.
So far, that's a future feature, not a usable one. This is why Bitcoin remains the scammer's paradise - anonymous, irrevocable remote money transfer. There's little risk of annoying lawsuits, cops, or armies of angry customers with pitchforks coming after you.
As a result, more than half of Bitcoin "exchanges" have gone under, usually taking customer funds with them.
Most alternative reactor designs have some major flaw. Sodium reactors have sodium fires. Pebble-bed reactors have pebble jams. (An experimental one in Germany is such a mess there's no way to fully decommission it.) Helium gas-cooled reactors leak helium. (Fort St. Vrain was converted from nuclear to natural gas because of that.) One of the painful lessons of long-life nuclear power plants is that what goes on inside the reactor vessel has to be really, really simple. Anything complex in there will break. It's being shot full of holes at the atomic level, after all. (See "hydrogen embrittlement").
Pressurized water reactors and boiling water reactors at least have only water to deal with. The fuel rods are solid rods. The thing is basically simple, although the plumbing gets insanely complex. Even then, big accidents have happened.
Some of the fancier reactor designs require an associated chemical plant to reprocess the materials. This is a pain if you're in the power generation business, and a source of leaks and risks.
Show me someone building an airplane. Oh sorry, you need an FAA license for that...
Check out the Experimental Aircraft Association. Visit the Oshkosh Fly-In. FAA regulations on experimental aircraft are quite lenient. You can't carry passengers or fly over heavily populated areas, which is reasonable enough. For flight test, there's the Mojave Air and Space Port. "My job is to give people permission. Every day in the skies over Mojave and on the ground at Mojave Air & Space Port, people take enormous risks, which someday will yield great things for all humanity." -- Stuart Witt, CEO, Mojave Air & Space Port.
How about a rocket?
"You want to test a rocket engine? This is a place where you can do that." -- Board of Directors, Mojave Air and Space Port. SpaceShip One and various X-Prize trials have launched from Mojave. Rotary Rocket flew from there, although not very far. I know people at TechShop building upper stage engines for orbital insertion.
Flying car? Forget it...
There are several ultralight helicopter kits. Quadrotors seem to get bigger each year. Thrust-type VTOLs need a lot of power, which usually means jet engines, which means a flying car will cost about as much as a small bizjet, which limits the market. Paul Moller built a flying car; it doesn't work, but that's Moller's problem, for which he's been making excuses for 40 years. I had some hopes for Urban Aeronautics out of Israel, which was showing a non-flying mockup in 2010, but they never made it fly.
Government is not preventing you from doing any of these things.
Did this guy just reinvent spreadsheets? There's something to be said for this, but having written in Prolog, which works that way, the 'reactive programming' people have to make a better case than the article does.
On the other hand, one of the big problems in databases is change notification. Microsoft at one point had a research project on this. The concept was that you could make a request to be notified when something of interest changed in the database. This was expressed as an SQL SELECT statement. When some change was made that would affect the output of your pending SELECT, you'd be notified. The problem was to figure out some efficient way to do this with thousands or millions of pending SELECT statements.
Finance people use notifications like that all the time. Limits on stocks, limits on combinations of stocks, changes in key ratios, that sort of thing. But the systems for that are specialized, a special case of a more general problem. The most general form of the problem is that B wants to know when something has changed at A. Most of the solutions for this have problems. Polling is either inefficient or slow. B relying on A to message them on a change has a failure problem. Both approaches can result in overloading A with checks for events that aren't happening.
The point to take away here is that you can generally avoid being charged with "bad faith" by not doing specific bad things. The standard in the bill is much more ambiguous.
On the other side, an infinger can be charged triple damages for "willful infringement". A recent court decision raised that standard to "willful and reckless", which is almost impossible to prove.
There's a 12-volt lead-acid battery in the thing to power the auxiliary systems. It's the same size as a regular automotive battery, but apparently is a sealed type, intended to last the life of the vehicle. Since it doesn't need to provide cranking power, a high-current battery isn't necessary.
Tesla owners have been reporting 12 volt battery failures for months. Usually the charging system reports "12 volt battery failure", but apparently a partial failure is possible, where the aux battery is an energy drain but still functional.
It's my understanding, and the GP who read the whole thing states, that the plaintiff pays the defendant's fees only if the sued IN BAD FAITH.
Close, but not quite. "Bad faith" has a specific meaning in law. It requires malicious intent. The burden of proof is on the party claiming bad faith, and it's hard to prove intent.
That language was fought over and amended. Originally, it was loser pays almost all the time. Here's what passed the House:
(a) Award- The court shall award, to a prevailing party, reasonable fees and other expenses incurred by that party in connection with a civil action in which any party asserts a claim for relief arising under any Act of Congress relating to patents, unless the court finds that the position and conduct of the nonprevailing party or parties were reasonably justified in law and fact or that special circumstances (such as severe economic hardship to a named inventor) make an award unjust.
That's a presumption that the loser pays, but the loser can try to convince the judge that their position was "reasonably justified in law and fact". The burden of proof is on the loser. and there's no requirement of bad intent. It's quite possible to start an infringement case and find out during litigation that the position taken was not "reasonably justified in fact".
The effect is to place inventors at risk of losing several milion dollars should they try to assert patent rights against a big company. It's all about making inventors afraid.
About ten years ago, I went to a talk at Stanford where someone showed that the increasing costs of wafer fabs would make this happen around 2013. We're right on schedule.
Storage can still get cheaper. We can look forward to a few more generations of flash devices. Those don't have to go faster.
Picasa acquired by Google - New York Times, 2004. "'They came to the conclusion that it would be easier to buy this business than to build it themselves. It's the type of acquisition you can expect Google to do more of in the future.'' The self-driving car technology was acquired from Stanford, along with Sebastian Thrun. Google did do a lot with language translation in-house; that's probably the most innovative area. Most of Google's big-name products, though, came from elsewhere.
Google is good at scaling, and yes, many of the acquired products had to be rewritten to scale up. Still, Google Earth today looks a lot like the Keyhole Earth Viewer I had in 2003.
I've read the current language of the bill and there is nothing there that harms small inventors. Everything there makes large-scale patent trolling less attractive as a business model.
The worst part is the remnant of the "loser pays" provision. If you try to enforce a patent against a big company, if you lose you have a good chance of being hit with the big guy's legal bills. There's no cap on that. That provision was amended, which made it "slightly less awful", as one congressman put it. After the amendment, the new language now means you get to litigate over the legal fees. Statistically, the patent holder wins about 40% of the time, and even with a good case, it's easy to make a mistake and lose.
The Leahy bill is better. It's more narrowly directed towards bulk-type patent enforcement operations, doesn't have a loser-pays provision, and proposes a small claims court for smaller patent cases.
This isn't an anti-patent troll bill. It's an anti-small inventor bill. It's designed to make it more expensive to enforce patents. That won't affect Google vs Apple vs Microsoft, etc. It just makes it harder for a little company to enforce a patent against a big one. That was the intention. (The Leahy bill in the Senate isn't that bad, but the Goodlatte bill that just passed the House is awful.)
This bill has been pushed through by a hate campaign against inventors. It's a well-funded campaign, and it's suckered in many people. The money is coming from Google and Facebook, who are hiding behind front organizations such as the Application Developers Association and the Electronic Frontier Foundation. The EFF's effort is funded by Google and Facebook, with $2 million laundered through a clever legal trick.
There are very few real "patent trolls". The EFF has tried to identify every one they can, and they only found 15. They started a campaign to attack "trolled patents" in court and at the USPTO, and and they only found one. There are a few other broad patents being enforced aggressively, notably Ultramercial. That's about it.
Using that thin basis, the "patent troll" problem has been hyped as a major threat. There are hate sites aimed at inventors:
I used to respect the EFF, but once they took Google's money, they, too, turned to the dark side.
Who were the corporate sponsors of this bill?
The big push was from Google. Google, along with Facebook and Twitter (but not Apple) sponsors the Application Developers Alliance, which is a lobbying group against "patent trolls".
To understand why this matters to Google, look at where Google's products came from. Google, despite their reputation for innovation, has obtained most of their technology through acquisitions of smaller companies. Google has acquired 131 smaller companies over the years. Since the original search engine, almost all successful Google products came from the outside. YouTube, AdSense (DoubleClick), Google Earth (Keyhole), Blogger (Genius Labs), Android, Google Docs (Upstartle), Google Analytics (Urchin), Google Talk (Grand Central) etc. all came from acquisitions. In house, Google developed Google Wave and Google Buzz.
As a net buyer of IP, it's in Google's interest to keep the value of patents down. They don't want a small company to be able to say no to Google.
would it be possible to generalize this design to drive an array, of -- say -- 10 or 20 RGB LEDs ?
Sure. Addressable LED strings are cheap, and widely used for annoying blinking holiday decorations. If you don't want to solder, here's an assembled USB light string controller.
All the highway autonomous vehicle projects got as far as freeway driving. BMW, Cadillac, and Mercedes have all demonstrated this level of automatic driving. Then it gets hard.
This is about as far as you can go before entering the "deadly valley", where the vehicle can drive autonomously but isn't smart enough to recognize when it shoudn't. Google is further along; they can drive around on suburban streets.
Most of the technology needed to automate electronics manufacturing has been available for years, if not decades. See "The Macintosh Factory", showing Apple's factory in Fremont over 20 years ago. Robot assembly, mobile robots, very few people doing direct labor. Products were designed for cheap automated assembly. The Macintosh II family was noted for that - everything, including the power supply, was inserted into the case with a simple straight-down move. Everything snapped together. No wiring harnesses. "Design for manufacture" was big back then.
So what went wrong? Outsourcing for cheap labor. "If your orders decrease, you can lay off workers. You can't lay off robots." - Tim Li, Quanta Computer. It's not so much that people are cheaper. It's that they are disposable. So are subcontractors. Everybody in the supply chain is working on low cost margins with no guarantee of future orders, so they can't invest in automation.
This is not a technical problem.
The "organic visualization" thing and its jargon are described in this thesis done at the MIT Media Lab. This is what happens when postmodernists try to improve on Tufte. Some of it is pretentious bullshit. But there may be the genesis of some new phone apps in there.
Here's a good, but unrelated, example of "organic visualization": BitListen This is a little HTML5/JavaScript page which depicts transactions on the Bitcoin block chain. An older example is Muckety. This can be done well, but most attempts in this direction are duds.
Drones are a solution to getting from the truck to the door (or window landing stage). The truck stops, drones fan out to deliver packages nearby, and the drones return to the truck for a quick recharge before the next delivery. In a few years, the trucks will be self-driving, Amazon warehouses will have Kiva robots, and very few people will be necessary.
Right. This is simply that it's easier to move a shipboard steam/incineration plant to where the toxics are than to move the toxics to an existing plant.
There aren't many such plants. The U.S. Army had a chemical weapons disposal plant until July 2013. It was closed, after it had been used to destroy the US's old stockpiles of chemical weapons. Demolition of the plant is underway.
Google here has the power, should they decide to use it, to extract any data they want from any page or form in Healthcare.gov by downloading a suitable tracker. Whether you think this is evil depends on how much you trust Google.
It's even worse than that. Those little bits of "tracker" code being injected are written and controlled by each tracking service. So not just Google, but CrazyEgg or ChartBeat staff could upload spyware into HealthCare.gov's site.
Google does a little checking on the injected code, mostly to make sure it won't crash the page with bad Javascript syntax. Each snippet of tracking code is enclosed in a try-block, so one tracker won't abort the other trackers. But there's no indication that Google takes any steps to limit the intrusiveness of the tracking.
CrazyEgg collects every click on every page. This is used to generate a "heat map" of web page usage, and can be misused to find out which check boxes and buttons someone used when signing up for health insurance.
Of course, all these parties claim they won't do bad stuff.
AdBlock didn't catch anything
No ads are being loaded, just trackers. Abine's DoNotTrackPlus caught CrazyEgg, Google Analytics, Doubleclick, and ChartBeat, but not Google Tag Manager itself.
If a site signs up for Google Tag Manager, it gets DoubleClick tracking whether the site owner wants it or not. Here's what DoubleClick knows about you.
The Tag Manager system has a whole API for snooping on what the user is doing and sending the data back to Google or another server. "For example, you may want to fire a conversion tracking tag when a user clicks the Submit button". The tracker can also grab information from a form being submitted and send it to Google's tag manager server.
WTF?
Optimizely is a complicated scheme for serving slightly different versions of a site to different people and seeing what that does to usage patterns. This allows testing different advertising approaches, or field-testing new versions of a site to a fraction of the user base. It's not inherently evil.
DoubleClick code is being loaded because HealthCare.gov uses the Google Tag Manager. ("Tag" in this context means "web bug", not "hashtag".) Google Tag Manager is a system for managing sites that have so much web tracking that they need a management system to keep it all straight. The Tag Manager itself doesn't track anything; it just loads other code that does, based on an configuration stored on Google servers. Each tracking code source has its very own privacy policy and intrusiveness. HealthCare.gov is trying (at least for me) to load CrazyEgg, Google Analytics, Doubleclick, and ChartBeat. Which trackers are loaded is controlled by Google's config. Google generates a page of Javascript for each site and injects all the tracking code. This replaces the old approach of putting tracking code directly into web pages. Here's what it injects into Healthcare.gov. (Minified Javascript, not easy to read.)
Google here has the power, should they decide to use it, to extract any data they want from any page or form in Healthcare.gov by downloading a suitable tracker. Whether you think this is evil depends on how much you trust Google.