As "enrichment experiences" for kids go, these don't seem so weird after seeing
"Summer Camp Day" at Hillsdale Mall. About fifty local camps each had a booth. Only a few "camps" actually offered
camping, hiking, or wilderness stuff. There were the expected horse camps,
gymnastic camps, and such. A few sports camps (golf, tennis). And then there
were the others. Computer camp.
Sewing camp. Archeology camp. Kung Fu camp. Paintball camp. Lego camp. Two Lego camps, in fact.
It's been done:
Hooters Air. 2003-2006. Hooters Air was a flop, but that was probably due to the choice of destinations, which included Myrtle Beach SC, Gary IN, Allentown PA, Rockford IL, Baltimore MD and Fort Meyers FL.
In the entire history of electromechanical switching in the Bell System no central office was ever out of action for more than thirty minutes for any reason other than a natural disaster. On the other hand, step-by-step (Strowgear) switches failed to connect about 1% of calls correctly, and crossbar reduced that to about 0.1%. With electronic switching, the failure rate is higher but the error rate is much lower.
This reflects the fact that, in the electromechanical era, the hardware reliability was low enough that the system had to be designed to have a higher reliability than any of its individual units. In the computer era, the component reliability is so high that good error rates can be achieved without redundancy. This is why computer-based networks tend to have common mode failures.
If you're involved in designing highly reliable systems, it's worth understanding how Number 5 Crossbar worked. Here's an oversimplified version.
The biggest component of Number 5 crossbar were the crossbar switches themselves.
Think of them as 10x10 matrices of contacts which could be X/Y addressed and set or cleared. Failure of one crossbar switch could take down only a few lines, and they usually failed one row or column at a time, taking down at most one line.
The crossbars had no smarts of their own; they were told what to do by "markers", the smart part of the central office. Each marker could set up or tear down a call in about 100ms. Markers were duplicated, with half of the marker checking the other half. If the halves disagreed, the transaction aborted. Each central office had multiple markers (not that many, maybe ten in an office with 10,000 lines), and markers were assigned randomly to process calls.
When a phone went off hook, a marker was notified, and set up a "call" to some free "originating register", the unit that understood dial pulses and provided dial tone. The marker was then released, while the user dialed. The originating register received the input dial info, and when its logic detected a complete number, it requested a random marker, and sent the number. The marker set up the call, set and locked in the correct contacts in the crossbars, and was released to do other work.
If the marker failed to set up the call successfully (there was a timeout around 500ms), the originating register got back a fail, and retried, once. One retry is a huge win; if there's a 1% fail rate on the first try, there's an 0.01% fail rate with two tries. This little trick alone made crossbar systems appear very reliable. There's much to be said for doing one retry on anything which might fail transiently. If the second retry fails, unit level retry as a strategy probably isn't working and the problem needs to be kicked up a level.
The pattern of requesting resources from a pool at random was continued throughout the system. Trunks (to other central offices), senders (for sending call data to the next switch), translators (for converting phone numbers into routes), billing punches (for logging call data), and trouble punches (for logging faults) were all assigned on a random, or in some cases a cyclic rotation basis. Units that were busy, faulted, or physically removed for maintenance were just skipped.
That's how the Bell System achieved such good reliability with devices that had moving parts.
Note that this isn't a "switch to backup" strategy. The distribution of work amongst units is part of normal operation, constantly being exercised. So handling a failure doesn't involve special cases. Failures cost you some system capacity, but don't take the whole system down.
We need more of that in the Internet. Some (not all) load balancers for web sites work like this. Some (but not all) packet switches work like this. Think about how you can use that pattern in your own work. It worked for more than half a century for the Bell System.
From the article: "So, we're being throttled by the OS which is forcing us to wait for the next frame time before allowing us to draw again."
Hello? There's no point in redrawing the screen faster than display can refresh it. It won't be displayed. If Firefox's implementation of scrolling does so by redrawing faster than the frame rate, Firefox is doing it wrong.
Apparently this is considered a "problem" because there's some dumb benchmark that measures how fast you can process scroll events when driving scrolling from a script, runs this too many times, and because that benchmark executes during the build process, this "problem" slows up builds.
Some years ago I had a go-round with the NVidia driver developers about this. In an effort to get better Quake benchmarks by not waiting for frame sync, they'd caused major problems for systems running more than one 3D window with OpenGL. That was fixed years ago.
Telcos should be made regulated common carriers again. All they should be allowed to do is run data pipes. Everything else they do, they do badly anyway.
A big question is whether you need a "programming superstar". If you're trying to figure out how to do seismic analysis using a rack of graphics boards, or improve the robustness of 3D SLAM for mobile robots, or make a hair simulator work in underwater scenes, or get better density from an IC layout algorithm, or work on the RF end of cell phones,
you need "programming superstars". If you're writing yet another "Web 2.0" app, you don't.
Most programming today isn't really that difficult as such. Most of the algorithmic problems have been solved. You usually don't need to invent all that much. Difficulty generally lies in understanding some messy and ill-documented thing with which you need to interface. That's not a "superstar" problem, just a big headache.
Most of the security and crime problems associated with the Internet are problems with the client, not the network. In other words, Microsoft Windows is the problem.
If desktop clients ran each browser window in a separate jail, and downloaded programs were constrained by NSA SELinux type mandatory security, or a virtual machine monitor, to stay in their individual compartments, most of the attacks on personal computers would stop working.
If it weren't for those armies of zombie PCs out there, hiding where something unwanted was coming from on the network wouldn't work. Look what's happened to spam. Today, essentially all spam involves compromised machines. Any that doesn't is shut down, fast.
I have an application 12 months into a 30 month queue. In a fast-moving field, this is a huge headache. My previous patents only took about a year to get to first office action.
There's a new express program, though. If you file no more than three claims, file online, and do a more diligent search, the USPTO promises to process the patent in less than a year.
That was just starting when I filed, and I didn't take that option.
The interesting question to me is what layer of abstraction did you have your gear change fix at?
Somewhat off topic, but anyway... Gear changing was abstracted to "change to desired gear" at the Galil motor controller, which is a programmable device interpreting a simple little programming language of its very own. The higher level computers would send it a UDP packet with the desired gear number, and every 50ms, read back the status. During gear changing, it would report "busy", and once gear change was complete, the new gear number would be reported.
We had a GUI for debug, showing various buttons and meters. The transmission was represented with "D", "L", R", and "N" buttons. The current gear showed in green. During a gear change the button turned yellow, then green once gear change was complete.
At the next level up, the "speed server", running on a QNX machine, was responsible for throttle, brakes, and transmission. It handled the interlock conditions for gear changing (vehicle speed zero, brakes locked, RPM at idle). The speed server was basically doing a "cruise control" job. It also handled the "rollback" problem.
The level above that, the "move server", took requests like "advance forward 20m at 3 m/sec with turning radius 30m", and issued commands to the speed server and steering system. The move server understood stopping distance, including hills, and had an input from the simple anti-collision radar to stop if a big obstacle was in range. Move requests were replaced with new ones every 100ms by the map system.
At the level above that, the map server/planner, operating at "back seat driver" level, was in charge of deciding where to drive. It didn't have to worry about vehicle dynamics. It just decided when backing up was necessary, and issued a backwards move. This would result in everything winding down to the vehicle stopped/brakes locked/engine idle condition, a gear change, a brake release, and acceleration.
We lost the Grand Challenge, but the vehicle drove itself and never hit anything. We had about +- 2 degrees of compass noise, and that was enough to get the LIDAR-built map out of sync. The vehicle would stop, rescan, rebuild the map, and recover, but that was too slow. We tried to get by without a $40,000 FOG gyro, heading from dual GPS phase, or SLAM, and that wasn't good enough.
We had problems powering the shift lever in our DARPA Grand Challenge vehicle. The base vehicle was a Polaris ATV. We put a motor driven screw jack with analog feedback on a push-pull cable to drive the shift linkage. Positioning the shifter wasn't enough. We had to position it to the right place, then wiggle it back and forth under computer control with decreasing amounts of wiggle until the transmission fell into gear.
Then there was "rollback" to deal with. Normal procedure was to release the brakes, then rev up the engine. On a hill, this results in a rollback. That had to be dealt with in software. On the first try, the vehicle would release the brakes, roll back a bit, the driveshaft encoder would report backward motion, and the software would jam on the brakes. On the next try, in "hill" mode, the engine was revved up until the tachometer reported enough revs for the transmission to be delivering some power, then the software slowly released the brakes and the vehicle started up the hill.
So, yes, I've actually had to find first gear in my giant robot car.
Stereolithography machines aren't magic. They're a useful way of making plastic shapes in small quantities, expensively. But that's about it. Much of the same work can be done
with a CNC milling machine. Roland makes some nice little desktop CNC mills. They also make 3D "scanners" which work by touch, carefully servoing a tiny stylus with a phonograph pickup like device over the surface of a 3D object. So you can copy existing objects.
All this stuff works fine, but it's a niche market. It's mostly used by people designing small, handheld devices.
Making plastic parts by injection molding, vacuum forming, or hot stamping is incredibly cheap and fast compared to building them up with a stereolithography machine. Making, say, a keyboard key in an injection molding press costs maybe a penny. Making one in a stereolithography machine will cost about $40. Yes, you can make one-offs, but not cheaply.
Realize that most manufactured goods (with the notable exception of wood products) are made by some kind of moulding process involving a master - stamping, casting, injection moulding, blowing and vacuum forming, etc.
That's also true of photolithography, used for ICs and circuit boards.
Building up something in layers or carving it out of a solid block costs orders of magnitude more.
If you want to use a stereolithography machines, and you're in Silicon Valley, sign up with TechShop. They have one of the better ones, plus workstations with the necessary design software. It's not used much. Their laser cutter, which cuts flat sheets, gets much more use.
First, Microsoft would never call it "UNG". Second, Ballmer would not talk about a "UNIX-like environment". Microsoft doesn't need a UNIX-like offering. Ballmer might order Microsoft to develop an easy migration path from Linux servers to Windows servers, but the Linux desktop share is too small to matter.
In the early days of Gmail, Google required a cell phone number, to which they sent your initial password. One Gmail account per phone. Maybe they need to go back to that.
Sure, spammers could buy stacks of SIM cards, but that costs money.
US patents have "maintenance fees" every few years, and they're not cheap. Over the life of the patent, you pay about $8000 in maintenance fees. (There's a discount if you're an individual or a "small entity").
If we had that for copyright, even at a much lower price point, the public domain would be much larger. Unfortunately, the copyright lobby got a "no formalities" rule into the TRIPS agreement, so no country in the WTO can do that.
It sounds so Microsoft. They control the OS and the browser, so they could keep detailed history information about what you've been looking at. But they don't seem to actually be doing that. The Atlas Media Console, which is what this is all about, is just a tool for managing multiple types of ads and reducing the data that comes back as they're viewed.
Microsoft has a point, though. "Advertising doesn't jerk, it pulls" - John Wanamaker. The ad that was clicked on may not have been the primary influence on the buying decision.
For advertisers who have brands with some value, an online presence helps to market the brand. Then when an ad for something for a consumer actually wants is displayed, a sale is more likely. Advertisers can't currently measure that effect.
Many Google ads are, of course, from "bottom-feeders", with no brand of value. They just want the click-through. Anything that improves measurement of return on investment for the actual seller will reduce the value of all those "bottom feeder" ads - the "made for adwords" sites, the spam blogs, and such. It's unclear how much of Google's revenue is generated that way.
Some Google text ads have a form of mouse-over tracking. When you mouse over some Google text ads, nothing appears to happen, but in fact, some Javascript executes and the URL you can click on changes. I'm not yet sure just what they're sending back to the mothership, or if they send anything on mouse-overs without a click.
As for the bottom-feeder problem, we've recently developed some tools for SiteTruth that tell us some things about Google AdWords. SiteTruth rates web site legitimacy, and we have a browser-plug in which displays those ratings alongside each ad. It's striking to see the difference between the quality of ads served on different sites. Slashdot and Linkedin advertisers aren't too bad; Myspace advertiser quality is very low. Remember that Slashdot article about the people who will click on anything? That's the Myspace crowd.
The defendants tried a counterclaim for defamation. The court commented:
Similarly, the statement that Defendants were suspected of fraud and forgery was a
true statement of fact reflecting Plaintiff's belief that Defendants fabricated Zubitskiy and forged
his signature on the 3/19/04 Agreement, which was also fraudulently notarized. Accordingly,
Plaintiff did not engage in deceptive trade practices in violation of Minn. Stat. 325D.44,
...
Defendants' counterclaims against Plaintiff are DISMISSED WITH PREJUDICE.
Reading the decision, it's clear what the judge thought of the defendants. They tried forging a notarized document. They couldn't produce the person whom they claimed took the picture. From then on, it was all downhill for the defendants.
Not only is a one-off do-it-yourself system a headache, what you're proposing slows things down at checkout.
You're proposing an inventory system that doesn't talk to the cash register. That's where things were in low-end retail systems about 10-15 years ago, and it was awful. You'd see a cash register, an inventory terminal, and a credit card terminal at the checkout, not talking to each other. Way too much duplicate data entry. Today, it's expected that a POS system will talk to the credit card system, the inventory system, the scanner, and the cash drawer.
You can buy all the components and the software to run them for well under $2000 from many vendors. A low-end system, Cash Register Express, has a downloadable demo version (200 transactions max). Try something like that to get a sense of what the existing products do. I'm not particularly recommending this one; it just happens to be something with a demo available.
The Bush administration has to be covering up something very embarrassing. Something worse than what we know about already. Otherwise it wouldn't be spending its remaining political capital on this issue.
If the Bush administration really had a national security case for this, they could make it in a classified briefing for the House and Senate intelligence committees with the people at the CIA, NSA and telcos directly involved testifying under oath. They haven't done that.
The Bush administration likes to pretend that the President is the "decider", but he isn't. Congress is. Whenever Congress takes a unified position opposing the President, they win. Even many of the Republicans in Congress are fed up with Bush at this point.
The details will come out under the next administration.
This is the man who put George Bush in the White House, by getting a small number of votes in the closest Presidential election in American history. Nader needs to give it up.
I now have an admission from Wikileaks that they copied my posting above and put their name on it as if they wrote it. That was sloppy journalism on their part. ZDnet, which published the Wikileaks press release, has published a correction.
My concern is to make it clear that I'm neither behind Wikileaks nor copying material from them. I'm writing my own material under my own name, and I stand behind it. "Animats" isn't an anonymous handle; I own "animats.com", and "ANIMATS" is my US registered trademark.
Yes, they have a demo car. But how far can it go? It's straightforward to build something like this that can go a few miles on a tank of air, but the claimed range and speed is far, far higher than one would expect for the power source.
The YouTube video shows it being recharged from a modest-sized air compressor.
If a few kilowatts of air compressor can recharge it in a few minutes, it can only put out a few kilowatts for a few minutes when being driven. This isn't "free energy".
Back in the steam engine era, a few "fireless locomotives" were built. They were charged up with steam by plugging them into a stationary boiler, then run for a half day or so. But they didn't go very far; they were used for switching cars around a factory, or in mines. And they had huge tanks - look at the pictures. Some looked like tank cars.
Is there a drivable prototype of this thing? Has anyone from Motor Trend or Auto Week ever had a good look at it? For any real car, the prototypes precede volume production by several years.
Accusations of fraud are flying between the Air Car people.. Apparently there are two Air Car groups, and they don't get along.
Tata Motors has nothing on their web site about the "air car". They do have a page of their concept cars, and the Air Car isn't on there. They're coming out with the Tata Nano, at $2500. The Tata Nano is conventionally powered. There's an electric version of the Tata Ace mini-truck, and those should be coming to the US this year. But there is no Air Car or "City Cat" from Tata that I can find.
Slashdot Mirror
In SF, they have the Pirate Store.
As "enrichment experiences" for kids go, these don't seem so weird after seeing "Summer Camp Day" at Hillsdale Mall. About fifty local camps each had a booth. Only a few "camps" actually offered camping, hiking, or wilderness stuff. There were the expected horse camps, gymnastic camps, and such. A few sports camps (golf, tennis). And then there were the others. Computer camp. Sewing camp. Archeology camp. Kung Fu camp. Paintball camp. Lego camp. Two Lego camps, in fact.
It's been done: Hooters Air. 2003-2006. Hooters Air was a flop, but that was probably due to the choice of destinations, which included Myrtle Beach SC, Gary IN, Allentown PA, Rockford IL, Baltimore MD and Fort Meyers FL.
In the entire history of electromechanical switching in the Bell System no central office was ever out of action for more than thirty minutes for any reason other than a natural disaster. On the other hand, step-by-step (Strowgear) switches failed to connect about 1% of calls correctly, and crossbar reduced that to about 0.1%. With electronic switching, the failure rate is higher but the error rate is much lower.
This reflects the fact that, in the electromechanical era, the hardware reliability was low enough that the system had to be designed to have a higher reliability than any of its individual units. In the computer era, the component reliability is so high that good error rates can be achieved without redundancy. This is why computer-based networks tend to have common mode failures.
If you're involved in designing highly reliable systems, it's worth understanding how Number 5 Crossbar worked. Here's an oversimplified version.
The biggest component of Number 5 crossbar were the crossbar switches themselves. Think of them as 10x10 matrices of contacts which could be X/Y addressed and set or cleared. Failure of one crossbar switch could take down only a few lines, and they usually failed one row or column at a time, taking down at most one line.
The crossbars had no smarts of their own; they were told what to do by "markers", the smart part of the central office. Each marker could set up or tear down a call in about 100ms. Markers were duplicated, with half of the marker checking the other half. If the halves disagreed, the transaction aborted. Each central office had multiple markers (not that many, maybe ten in an office with 10,000 lines), and markers were assigned randomly to process calls.
When a phone went off hook, a marker was notified, and set up a "call" to some free "originating register", the unit that understood dial pulses and provided dial tone. The marker was then released, while the user dialed. The originating register received the input dial info, and when its logic detected a complete number, it requested a random marker, and sent the number. The marker set up the call, set and locked in the correct contacts in the crossbars, and was released to do other work.
If the marker failed to set up the call successfully (there was a timeout around 500ms), the originating register got back a fail, and retried, once. One retry is a huge win; if there's a 1% fail rate on the first try, there's an 0.01% fail rate with two tries. This little trick alone made crossbar systems appear very reliable. There's much to be said for doing one retry on anything which might fail transiently. If the second retry fails, unit level retry as a strategy probably isn't working and the problem needs to be kicked up a level.
The pattern of requesting resources from a pool at random was continued throughout the system. Trunks (to other central offices), senders (for sending call data to the next switch), translators (for converting phone numbers into routes), billing punches (for logging call data), and trouble punches (for logging faults) were all assigned on a random, or in some cases a cyclic rotation basis. Units that were busy, faulted, or physically removed for maintenance were just skipped.
That's how the Bell System achieved such good reliability with devices that had moving parts.
Note that this isn't a "switch to backup" strategy. The distribution of work amongst units is part of normal operation, constantly being exercised. So handling a failure doesn't involve special cases. Failures cost you some system capacity, but don't take the whole system down.
We need more of that in the Internet. Some (not all) load balancers for web sites work like this. Some (but not all) packet switches work like this. Think about how you can use that pattern in your own work. It worked for more than half a century for the Bell System.
From the article: "So, we're being throttled by the OS which is forcing us to wait for the next frame time before allowing us to draw again."
Hello? There's no point in redrawing the screen faster than display can refresh it. It won't be displayed. If Firefox's implementation of scrolling does so by redrawing faster than the frame rate, Firefox is doing it wrong.
Apparently this is considered a "problem" because there's some dumb benchmark that measures how fast you can process scroll events when driving scrolling from a script, runs this too many times, and because that benchmark executes during the build process, this "problem" slows up builds.
Some years ago I had a go-round with the NVidia driver developers about this. In an effort to get better Quake benchmarks by not waiting for frame sync, they'd caused major problems for systems running more than one 3D window with OpenGL. That was fixed years ago.
Telcos should be made regulated common carriers again. All they should be allowed to do is run data pipes. Everything else they do, they do badly anyway.
A big question is whether you need a "programming superstar". If you're trying to figure out how to do seismic analysis using a rack of graphics boards, or improve the robustness of 3D SLAM for mobile robots, or make a hair simulator work in underwater scenes, or get better density from an IC layout algorithm, or work on the RF end of cell phones, you need "programming superstars". If you're writing yet another "Web 2.0" app, you don't.
Most programming today isn't really that difficult as such. Most of the algorithmic problems have been solved. You usually don't need to invent all that much. Difficulty generally lies in understanding some messy and ill-documented thing with which you need to interface. That's not a "superstar" problem, just a big headache.
Most of the security and crime problems associated with the Internet are problems with the client, not the network. In other words, Microsoft Windows is the problem.
If desktop clients ran each browser window in a separate jail, and downloaded programs were constrained by NSA SELinux type mandatory security, or a virtual machine monitor, to stay in their individual compartments, most of the attacks on personal computers would stop working.
If it weren't for those armies of zombie PCs out there, hiding where something unwanted was coming from on the network wouldn't work. Look what's happened to spam. Today, essentially all spam involves compromised machines. Any that doesn't is shut down, fast.
Ir's all Microsoft's fault.
I have an application 12 months into a 30 month queue. In a fast-moving field, this is a huge headache. My previous patents only took about a year to get to first office action.
There's a new express program, though. If you file no more than three claims, file online, and do a more diligent search, the USPTO promises to process the patent in less than a year. That was just starting when I filed, and I didn't take that option.
The interesting question to me is what layer of abstraction did you have your gear change fix at?
Somewhat off topic, but anyway... Gear changing was abstracted to "change to desired gear" at the Galil motor controller, which is a programmable device interpreting a simple little programming language of its very own. The higher level computers would send it a UDP packet with the desired gear number, and every 50ms, read back the status. During gear changing, it would report "busy", and once gear change was complete, the new gear number would be reported.
We had a GUI for debug, showing various buttons and meters. The transmission was represented with "D", "L", R", and "N" buttons. The current gear showed in green. During a gear change the button turned yellow, then green once gear change was complete.
At the next level up, the "speed server", running on a QNX machine, was responsible for throttle, brakes, and transmission. It handled the interlock conditions for gear changing (vehicle speed zero, brakes locked, RPM at idle). The speed server was basically doing a "cruise control" job. It also handled the "rollback" problem.
The level above that, the "move server", took requests like "advance forward 20m at 3 m/sec with turning radius 30m", and issued commands to the speed server and steering system. The move server understood stopping distance, including hills, and had an input from the simple anti-collision radar to stop if a big obstacle was in range. Move requests were replaced with new ones every 100ms by the map system.
At the level above that, the map server/planner, operating at "back seat driver" level, was in charge of deciding where to drive. It didn't have to worry about vehicle dynamics. It just decided when backing up was necessary, and issued a backwards move. This would result in everything winding down to the vehicle stopped/brakes locked/engine idle condition, a gear change, a brake release, and acceleration.
We lost the Grand Challenge, but the vehicle drove itself and never hit anything. We had about +- 2 degrees of compass noise, and that was enough to get the LIDAR-built map out of sync. The vehicle would stop, rescan, rebuild the map, and recover, but that was too slow. We tried to get by without a $40,000 FOG gyro, heading from dual GPS phase, or SLAM, and that wasn't good enough.
You gotta find first gear in your giant robot car
I've dealt with that problem.
We had problems powering the shift lever in our DARPA Grand Challenge vehicle. The base vehicle was a Polaris ATV. We put a motor driven screw jack with analog feedback on a push-pull cable to drive the shift linkage. Positioning the shifter wasn't enough. We had to position it to the right place, then wiggle it back and forth under computer control with decreasing amounts of wiggle until the transmission fell into gear.
Then there was "rollback" to deal with. Normal procedure was to release the brakes, then rev up the engine. On a hill, this results in a rollback. That had to be dealt with in software. On the first try, the vehicle would release the brakes, roll back a bit, the driveshaft encoder would report backward motion, and the software would jam on the brakes. On the next try, in "hill" mode, the engine was revved up until the tachometer reported enough revs for the transmission to be delivering some power, then the software slowly released the brakes and the vehicle started up the hill.
So, yes, I've actually had to find first gear in my giant robot car.
Stereolithography machines aren't magic. They're a useful way of making plastic shapes in small quantities, expensively. But that's about it. Much of the same work can be done with a CNC milling machine. Roland makes some nice little desktop CNC mills. They also make 3D "scanners" which work by touch, carefully servoing a tiny stylus with a phonograph pickup like device over the surface of a 3D object. So you can copy existing objects.
All this stuff works fine, but it's a niche market. It's mostly used by people designing small, handheld devices.
Making plastic parts by injection molding, vacuum forming, or hot stamping is incredibly cheap and fast compared to building them up with a stereolithography machine. Making, say, a keyboard key in an injection molding press costs maybe a penny. Making one in a stereolithography machine will cost about $40. Yes, you can make one-offs, but not cheaply.
Realize that most manufactured goods (with the notable exception of wood products) are made by some kind of moulding process involving a master - stamping, casting, injection moulding, blowing and vacuum forming, etc. That's also true of photolithography, used for ICs and circuit boards. Building up something in layers or carving it out of a solid block costs orders of magnitude more.
If you want to use a stereolithography machines, and you're in Silicon Valley, sign up with TechShop. They have one of the better ones, plus workstations with the necessary design software. It's not used much. Their laser cutter, which cuts flat sheets, gets much more use.
First, Microsoft would never call it "UNG". Second, Ballmer would not talk about a "UNIX-like environment". Microsoft doesn't need a UNIX-like offering. Ballmer might order Microsoft to develop an easy migration path from Linux servers to Windows servers, but the Linux desktop share is too small to matter.
In the early days of Gmail, Google required a cell phone number, to which they sent your initial password. One Gmail account per phone. Maybe they need to go back to that.
Sure, spammers could buy stacks of SIM cards, but that costs money.
US patents have "maintenance fees" every few years, and they're not cheap. Over the life of the patent, you pay about $8000 in maintenance fees. (There's a discount if you're an individual or a "small entity").
If we had that for copyright, even at a much lower price point, the public domain would be much larger. Unfortunately, the copyright lobby got a "no formalities" rule into the TRIPS agreement, so no country in the WTO can do that.
OK, what's the IP address of the ad site they send you to? Add that to block lists.
It sounds so Microsoft. They control the OS and the browser, so they could keep detailed history information about what you've been looking at. But they don't seem to actually be doing that. The Atlas Media Console, which is what this is all about, is just a tool for managing multiple types of ads and reducing the data that comes back as they're viewed.
Microsoft has a point, though. "Advertising doesn't jerk, it pulls" - John Wanamaker. The ad that was clicked on may not have been the primary influence on the buying decision. For advertisers who have brands with some value, an online presence helps to market the brand. Then when an ad for something for a consumer actually wants is displayed, a sale is more likely. Advertisers can't currently measure that effect.
Many Google ads are, of course, from "bottom-feeders", with no brand of value. They just want the click-through. Anything that improves measurement of return on investment for the actual seller will reduce the value of all those "bottom feeder" ads - the "made for adwords" sites, the spam blogs, and such. It's unclear how much of Google's revenue is generated that way.
Some Google text ads have a form of mouse-over tracking. When you mouse over some Google text ads, nothing appears to happen, but in fact, some Javascript executes and the URL you can click on changes. I'm not yet sure just what they're sending back to the mothership, or if they send anything on mouse-overs without a click.
As for the bottom-feeder problem, we've recently developed some tools for SiteTruth that tell us some things about Google AdWords. SiteTruth rates web site legitimacy, and we have a browser-plug in which displays those ratings alongside each ad. It's striking to see the difference between the quality of ads served on different sites. Slashdot and Linkedin advertisers aren't too bad; Myspace advertiser quality is very low. Remember that Slashdot article about the people who will click on anything? That's the Myspace crowd.
The defendants tried a counterclaim for defamation. The court commented:
...
Similarly, the statement that Defendants were suspected of fraud and forgery was a true statement of fact reflecting Plaintiff's belief that Defendants fabricated Zubitskiy and forged his signature on the 3/19/04 Agreement, which was also fraudulently notarized. Accordingly, Plaintiff did not engage in deceptive trade practices in violation of Minn. Stat. 325D.44,
Defendants' counterclaims against Plaintiff are DISMISSED WITH PREJUDICE.
Reading the decision, it's clear what the judge thought of the defendants. They tried forging a notarized document. They couldn't produce the person whom they claimed took the picture. From then on, it was all downhill for the defendants.
Not only is a one-off do-it-yourself system a headache, what you're proposing slows things down at checkout.
You're proposing an inventory system that doesn't talk to the cash register. That's where things were in low-end retail systems about 10-15 years ago, and it was awful. You'd see a cash register, an inventory terminal, and a credit card terminal at the checkout, not talking to each other. Way too much duplicate data entry. Today, it's expected that a POS system will talk to the credit card system, the inventory system, the scanner, and the cash drawer.
You can buy all the components and the software to run them for well under $2000 from many vendors. A low-end system, Cash Register Express, has a downloadable demo version (200 transactions max). Try something like that to get a sense of what the existing products do. I'm not particularly recommending this one; it just happens to be something with a demo available.
The Bush administration has to be covering up something very embarrassing. Something worse than what we know about already. Otherwise it wouldn't be spending its remaining political capital on this issue.
If the Bush administration really had a national security case for this, they could make it in a classified briefing for the House and Senate intelligence committees with the people at the CIA, NSA and telcos directly involved testifying under oath. They haven't done that.
The Bush administration likes to pretend that the President is the "decider", but he isn't. Congress is. Whenever Congress takes a unified position opposing the President, they win. Even many of the Republicans in Congress are fed up with Bush at this point.
The details will come out under the next administration.
Do you really need to go?
I gave up plane travel years ago.
This is the man who put George Bush in the White House, by getting a small number of votes in the closest Presidential election in American history. Nader needs to give it up.
I now have an admission from Wikileaks that they copied my posting above and put their name on it as if they wrote it. That was sloppy journalism on their part. ZDnet, which published the Wikileaks press release, has published a correction.
My concern is to make it clear that I'm neither behind Wikileaks nor copying material from them. I'm writing my own material under my own name, and I stand behind it. "Animats" isn't an anonymous handle; I own "animats.com", and "ANIMATS" is my US registered trademark.
John Nagle (nagle@animats.com)
Yes, they have a demo car. But how far can it go? It's straightforward to build something like this that can go a few miles on a tank of air, but the claimed range and speed is far, far higher than one would expect for the power source.
The YouTube video shows it being recharged from a modest-sized air compressor. If a few kilowatts of air compressor can recharge it in a few minutes, it can only put out a few kilowatts for a few minutes when being driven. This isn't "free energy".
Back in the steam engine era, a few "fireless locomotives" were built. They were charged up with steam by plugging them into a stationary boiler, then run for a half day or so. But they didn't go very far; they were used for switching cars around a factory, or in mines. And they had huge tanks - look at the pictures. Some looked like tank cars.
Is there a drivable prototype of this thing? Has anyone from Motor Trend or Auto Week ever had a good look at it? For any real car, the prototypes precede volume production by several years.
Accusations of fraud are flying between the Air Car people.. Apparently there are two Air Car groups, and they don't get along.
Tata Motors has nothing on their web site about the "air car". They do have a page of their concept cars, and the Air Car isn't on there. They're coming out with the Tata Nano, at $2500. The Tata Nano is conventionally powered. There's an electric version of the Tata Ace mini-truck, and those should be coming to the US this year. But there is no Air Car or "City Cat" from Tata that I can find.
This looks like vaporware.
Can I log in and see everything myself? And can I see the list of everyone who ever accessed my records? If not, it's no good.