Oh, this one again. I've seen this claim made for neural nets back in the 1980s, and for DNA computers in the 2000s. It's bogus.
The guaranteed-optimum solution to the TSP is NP-hard. The "gets to the optimum 99% of the time and close to it all the time" solution is easy. It was developed at Bell Labs in the 1960s. Here it is:
Link all the nodes in some arbitrary path.
Pick two random links, and cut the path into three pieces by cutting those links.
Try reassembling the three paths in all possible ways (there are 3*2*2*2*2/2 = 24 different paths) and measure the length of each. Pick the shortest.
If the path length hasn't improved in some reasonable number of iterations, stop. Otherwise go back to step 2.
This is a particularly efficient way to do it. I once coded this for a PC/AT, and it took less than a second for N=50. Almost any scheme which randomly breaks links and tries to improve the path will eventually converge on a near-optimum solution.
A big problem with shell programming is that the error information coming back is so limited. You get back a numeric status code, if you're lucky, or maybe a "broken pipe" signal. It's difficult to handle errors gracefully. This is a killer in production applications.
Here's an example. The original article talks about reading a million pages with "wget". I doubt the author of the article has actually done that. Our sitetruth.com system does in fact read a million web pages or so a month. Blindly getting them with "wget" won't work. All of the following situations come up routinely:
There's a network error. A retry in an hour or so needs to be scheduled.
There's an HTTP error. That has to be analyzed. Some errors mean "give up", and some mean "try again later".
The site's HTML contains a redirect, which needs to be followed. "wget" won't notice a redirect at the HTML level.
The site's "robots.txt" file says we shouldn't read the file from a bulk process. "wget" does not obey "robots.txt".
The site is really, really slow. Some sites will take half an hour to feed out a page. Maybe they're overloaded. Maybe their denial of service detection software has tripped and is metering out bytes very slowly in defense. You don't want this to hold up the entire operation. Last week, for some reason, "orbitz.com" did that.
The site doesn't return data at all. Some British university sites have a network implementation which, if asked for a HTTPS connection, does part of the SSL connection handshake and then just stops, leaving the TCP connection open but sending nothing.
This requires a special timeout.
The site doesn't like too many simultaneous connections from the same IP address. We limit our system to three simultaneous connections to a given site, so as not to overload it.
That's just reading the page text. More things can go wrong in parsing.
Even routine reading of some known data page requires some effort to get it right. We read PhishTank's entire XML list of phishing sites every three hours. Doing this reliably is non-trivial. PhishTank just overwrites their file when they update, rather than replacing it with a new one. (This is one of the design errors of UNIX, as Stallman once pointed out. Yes, there are workarounds they could do.) So we have to read the file twice, a minute apart, and wait until we get two identical copies. Then we have to check for 1) an empty file, 2) a file with proper XML structure but no data records, and 3) an improperly terminated XML file, all of which we've encountered. Then we pump the data into a MySQL database, prepared to roll back the changes if some error is detected.
The clowns who try to do stuff like this with shell scripts and cron jobs spend a big fraction of their time dealing manually with the failures. If you do it right, it just keeps working. One of my other sites, "downside.com", has been updating itself daily from SEC filings for over a decade now. About once a month, something goes wrong with the nightly update, and it's corrected automatically the next night.
A video that shows a second or two before the payload broke loose yields more information. It looks like the crane truck was starting a left turn, pulling against the balloon, when the pull from the balloon broke the attachment to the truck. The previous video made it look like the balloon was pulling the crane boom sideways, and the boom snapped back after release. But no. The truck was doing a left turn (they had to do something, they'd reached the perimeter fence) while the balloon pulled it to the right. That's where the big stress came from.
If the plate on the crane holding the cable to the balloon (safety factor 1.3, far too small, as later computed by NASA) hadn't failed, the launch team would have been able to hold the balloon and save the payload. They'd had failed launches before, and knew the truck was heavy enough to hold the balloon. So one can see why they held off on an abort. They might have been able to back the truck out and try the launch again. But their crane rigging wasn't built for sizable side loads.
In retrospect, they should have aborted sooner. The payload is the valuable part; it's normally recovered by parachute. An abort would have saved the payload and lost the balloon. The balloon is a consumable. But, as NASA's critique points out, they didn't have formal abort criteria, and tried an ad-hoc fix to get out of the mess they were in. If the bolts on the crane's attachment plate had been stronger, it would have worked.
I just tried the Suzette chatterbot. Even if I talk about the things it wants to talk about, it's very dumb:
Hi John !
[ Af:0 At:10 Sp:0] Welcome back, john. Type "help" if you need it.
John - So what do you think of the Giant's chances?
[ Af:0 At:10 Sp:0] It doesn't concern me.
John - Are you into sports.
[ Af:0 At:10 Sp:0] Sports is not my cup of tea. I prefer intellectual challenges like Go.
John - Who's the world Go champion.
[ Af:0 At:10 Sp:0] Sorry. I can't help you. A celebrity of some sort?
John - Do you play chess?
[ Af:0 At:10 Sp:0] I don't play any games except Go.
John - Can we play Go on here?
[ Af:0 At:10 Sp:0] About playing... Does it make sense to you that we reward athletes more than scientists?
John - Television coverage makes that possible.
[ Af:0 At:10 Sp:0] It's a free market economy. And people value entertainment more than serious things like science and education.
John - And your point is?
(No reply)
John - Are you there?
[ Af:0 At:10 Sp:0] Who's the sexiest person in the world?
This isn't much better than Eliza. It drives the conversation into talking about Go, and then it doesn't have anything to say on the subject.
After reading through the whole report, the most surprising thing is the design of the launch mechanism. The basic setup was that the launch was done from a moving crane truck. The truck was equipped with special outrigger wheels, so it could handle some side load without rolling over, and a platform for the "launch director", who was supposed to release the payload by yanking on a strap attached to a cable, pulley, and pin. The launch setup is that the balloon is inflated, allowed to rise, and then the crane truck. which is carrying the payload, tries to get under the balloon, chasing the balloon if necessary. When the payload is in position, the launch director yanks the strap and releases the payload.
This is obviously a setup which is highly dependent on what the wind does during the launch process. Some of the time, the wind is not going to cooperate, and an abort will be required. That's to be expected. But this time, they didn't abort until it was far too late.
During the process of chasing the balloon, the stresses on the restraint system were about 3x higher than at rest. It would have taken a 300 pound pull to release the pin; this was tested after the event. The guy who was supposed to pull the strap, while standing on a moving platform atop the crane truck, wasn't even wearing gloves. There was no backup system for releasing the payload. The payload eventually released when the crane truck reached the airport perimeter fence and had to stop. The wind forces from the balloon were then great enough to tear off a mounting plate on the truck, releasing the payload, which plowed through the fence and wiped out an SUV.
They didn't have an explosive bolt system to release the payload. The launch system used remote controlled pyrotechnics for releasing the balloon's restraining ring, and for the balloon-release abort system, so they already had all the systems and procedures in place for using pyrotechnics. But the main launch function was a guy pulling a strap.
There's clear video of the incident. This is useful to watch. When the payload tears loose from the crane, the crane truck is facing 90 degrees from the wind direction and stuck at the fence line. The crane boom is under high sideways stress. The abort system should have been triggered when the truck got into that situation, but it wasn't. (An abort prior to release loses the balloon and saves the expensive payload.) But the person with the abort button (the "campaign manager") and the guy trying to pull the release strap (the "launch director") were in different places and not coordinated, so when things went wrong, the abort didn't happen until after the payload had come loose and wiped out the perimeter fence and an SUV.
The day may come when individual possession of a hard drive may be illegal, as a "piracy device". How many people generate enough data of their own in their lifetime to fill a 1 TB drive?
Google Voice is useful and fun, but its interface with the telephone network remains flaky. See "Can't send text message from sprint phone to my Google voice number" and "Google number not callable from certain numbers" Google Voice seems to have an ongoing problem keeping their blocks of phone numbers properly visible to other carriers. Troubles have been reported with Sprint, Verizon, and T-Mobile numbers for over a year now. There are also some limitations on calling into and out of Google Voice from VoIP systems.
The problems may stem from the fact that Google didn't implement Google Voice. It's just "Grand Central", acquired and re-branded. It's not a "telco quality" system. It's not ready for prime time as your main phone system for a business.
In manufacturing, the Walkman was notable for its construction. It was designed for automated vertical assembly. In vertical assembly, all components are inserted by simple robots which move straight down to add a part to the base. The base is designed to support and align the parts so that this simple approach to assembly will work. It's fast, cheap, and fully automated.
Apple tried vertical assembly briefly. The Macintosh IIci was designed for vertical assembly. The power supply went in vertically and clicked into the motherboard. No internal cables. Then they went over to outsourced manual assembly with cheap labor. Swatch watches also used vertical assembly. Simpler cell phones are often assembled in this way.
If the CPU utilization is that low, it's an I/O scheduling problem. See Linux I/O scheduling.
The CFQ scheduler is supposed to be a fair queuing system across processes, so you shouldn't have a starvation problem. Are you thrashing the virtual memory system? How much I/O is going into swapping. (Really, today you shouldn't have any swapping; RAM is too cheap and disk is too slow.)
At the time, XNS, the Xerox protocol for Ethernet networks, was in use. It had 24 bits for the network number, and 24 bits for the device ID. Thinking at the time was that each network would be a local LAN, and "internetworking" would interconnect LANs. Xerox was thinking of this as a business system, with multiple machines on each LAN.
So XNS had a 48-bit address spade. That's what we call a "MAC address" today.
The telephony people were pushing X.25 and TP4, which used phone numbers for addressing. Back then, phone numbers were very hierarchical; the area code and exchange parts of the number determined the routing to the final switch. "Number portability", where all the players have huge tables, was a long way off.
The problem with a big address space is that memory was too expensive in those days to deal with huge address tables. A big issue was locative vs non-locative address spaces. In a locative address space, there's a hierarchy - you can take some part of the address and make a local decision about what direction to go, even if you don't have enough detailed information to get to the final destination. IP was originally organized like that - routers looked up class A, B, and C networks. A huge, flat address space implemented using multi-level caches was way beyond what you could do in a router back then. Routers used to be dinky machines, with less than one MIPS and maybe 256K of RAM.
There was a lot of worry about packet overhead. Each key press on a terminal sends 41 bytes over a TCP/IP network. That was a big deal when companies had long-haul links in the 9600 to 56Kb/s range. Adding another 24 bytes to each packet to allow for future expansion seemed grossly excessive. Especially since the X.25 people had far less overhead.
So there were good reasons not to overdesign the system. I don't blame Cerf for that.
The foot-dragging on IPv6 is excessive. The big deployment problem was getting it into everyone's Windows desktop. That's been done.
Ricochet did this in the 900MHz band using spread spectrum a decade ago, for wireless Internet access. They put up little nodes on street light poles, using a deal where the municipality got free data access. It worked fine, but only delivered dial-up speeds, so it was overrun by DSL and cable. Even back then, getting around narrowband interference was no big deal.
Tesla has the advantage of taking over the NUMMI plant in Fremont, CA, a big, successful auto plant shut down for the 2008 recession, when Toyota, for the first time, had to close plants. They're only using a fraction of the plant, but they own all the buildings (although not all the land; they didn't buy all the parking lots). There are plenty of laid-off auto workers living nearby, so a workforce is available.
The cost differential with China has narrowed. It turns out that once wages in China reach a quarter of the US level, China manufacturing stops being competitive. The transport costs, the delays, and the quality problems make outsourcing manufacturing less attractive. With wages rising in the coastal provinces in China, (and wages dropping in the US) that wage level has been reached in some industries.
Also, with all the foreclosures, bay area house prices have dropped. Maybe by a factor of 2.
Operating in Detroit has its own problems. The weather is harsh. Crime is high. Most of the people with competence and ambition moved out when the jobs did.
Don't worry about the rare earth supply problem. Mountain Pass, California is already coming back on line.
One for stationary use could be simpler. The mobile units have a full GPS/inertial/compass setup, so they know where to aim as the vehicle moves. A stationary unit doesn't need all that. It can just scan around after installation, find the desired sats, and store the direction.
What Android seems to need is a formal spec and a tough set of compatibility tests. That's how you deal with interoperability problems.
I used to be in aerospace. In that industry, if A and B don't interoperate, you go to the spec. If A isn't compliant, A is wrong. If B isn't compliant, B is wrong. If you can't tell, the spec is wrong. That's why you can unplug a Rolls-Royce engine from a Boeing 747, plug in a Pratt and Whitney engine, and go fly. Many years ago, in the early 1980s, I applied that reasoning to TCP/IP interoperability, and I was instrumental in pounding implementations into conforming to the published spec. At the time, it was a radical concept that completely different computers from different vendors with different implementations should talk to each other. Berkeley TCP originally did not play well with others. They felt it was only necessary to interoperate with other Berkeley UNIX systems. They were pounded on by their DoD funding agency until they got with the program.
Google needs to apply some of that hardass attitude to get cross-platform compatibility.
Olivetti used to have a fascination with industrial design. Their machines are on display in in art museums. But they just weren't that good. It's not about case design.
Jobs's strength is that he focuses on the end to end user experience. This is rare. Even most retailers don't get it. One of the few that does is The Gap. In a Gap store, there's no checkout area clutter, and large, clear counter surfaces for doing the sale. Most retailers put vast amounts of impulse-buy junk near the checkout. (Visit a Bed, Bath, and Beyond to see the worst case.) It provides some marginal revenue, but it constricts the flow of customers and money, and cheapens the perceived value of the real products. The Gap avoids that, and checkout flow is smooth. That's the end to end user experience.
This is why Amazon's "one-click buy" was such a successful innovation. This is why iTunes is successful. This is why well designed icons matter. Read "Flow: The Psychology of Optimal Experience", for a pop-culture analysis of the subject.
The end to end user experience is an issue in software. Microsoft sort of gets it, and they mostly have Word right. OpenOffice does not get it. Maya gets it. Blender doesn't get it. Autodesk Inventor gets it. SolidWorks doesn't get it.
even today's mainstream cpus are far more powerful than what our everyday tasks involve.
Usually that's true. But today I was using Autodesk Inventor, which is a parametric CAD solid modeling system. That's one of the few desktop applications that can usefully use gigabytes of memory and a dozen CPUs.
(I worked on the development of AutoCAD in the early 1980s, when the problem was cramming usefully sized drawings into 640K of RAM, a 20MB hard drive, and an 0.25 MIPS CPU. It was a tough cramming job. I used to dream about the day when we could have a CAD system with real-time solid modeling, automatically connected to CNC machine tools, running on a desktop computer. It took four or five more orders of magnitude in CPU power to make it work, and it's here. I'm glad I got to see it happen.)
Another minor bit of progress in materials science being blown up into a revolutionary advance. We get about one of these every two weeks.
Right now, these guys have a one-bit device that consumes more power than DRAM. They really should hold off on the press releases until they're further along. Maybe this will be useful, and maybe it won't be.
It's stuff like this that gives nanotechnology a bad name.
Microsoft didn't kill desktop Linux. The newer OSs for mobile devices did.
A decade ago, Linux was in the #2 position. The Mac wasn't going anywhere, phones didn't run applications, and the PDA world wasn't very relevant. Linux had a window of opportunity when Windows XP was late.
Linux isn't in the #2 position any more.
All the growth is in the the mobile devices sector, where ease of use is paramount. Even though some mobile devices have a Linux kernel underneath, that's not what the user sees, or what developers write apps for. The Mac has made a comeback. The "netbook" and "tablet" industry tried Linux, and didn't like it. Linux on desktops has become irrelevant.
Sumatra - it's so dumb that the Adobe exploits don't work. No forms. No plug-ins. No cut and paste. No networking. All it does is display PDFs in a separate window. Which, 99.9% of the time, is all you want.
I don't even have Adobe Reader installed on my Windows 7 machine.
Of course. Human civilizations are about 3000 years old, but industrial civilization is only 200 years old. Only in the past 100 years has large-scale resource extraction, large enough to make a big dent in potential supply, been feasible.
The really rich ores, like veins of copper with over 1% metal, are long gone.
Over the next century, lots of stuff is going to run out. Oil production peaked in 2005. There hasn't been a major new energy source in the last half century; just improvements on previous ones.
The "free market will solve all problems" crowd was insisting that peak oil would never happen. But it did. The price of oil has tripled without an increase in supply.
The "Silicon Valley Leadership Group" is kind of a joke. It used to be the "Silicon Valley Manufacturing Group", the lobby for the semiconductor industry, but after most of the semiconductor plants closed, it lost focus.
Slashdot Mirror
Oh, this one again. I've seen this claim made for neural nets back in the 1980s, and for DNA computers in the 2000s. It's bogus.
The guaranteed-optimum solution to the TSP is NP-hard. The "gets to the optimum 99% of the time and close to it all the time" solution is easy. It was developed at Bell Labs in the 1960s. Here it is:
This is a particularly efficient way to do it. I once coded this for a PC/AT, and it took less than a second for N=50. Almost any scheme which randomly breaks links and tries to improve the path will eventually converge on a near-optimum solution.
A big problem with shell programming is that the error information coming back is so limited. You get back a numeric status code, if you're lucky, or maybe a "broken pipe" signal. It's difficult to handle errors gracefully. This is a killer in production applications.
Here's an example. The original article talks about reading a million pages with "wget". I doubt the author of the article has actually done that. Our sitetruth.com system does in fact read a million web pages or so a month. Blindly getting them with "wget" won't work. All of the following situations come up routinely:
That's just reading the page text. More things can go wrong in parsing.
Even routine reading of some known data page requires some effort to get it right. We read PhishTank's entire XML list of phishing sites every three hours. Doing this reliably is non-trivial. PhishTank just overwrites their file when they update, rather than replacing it with a new one. (This is one of the design errors of UNIX, as Stallman once pointed out. Yes, there are workarounds they could do.) So we have to read the file twice, a minute apart, and wait until we get two identical copies. Then we have to check for 1) an empty file, 2) a file with proper XML structure but no data records, and 3) an improperly terminated XML file, all of which we've encountered. Then we pump the data into a MySQL database, prepared to roll back the changes if some error is detected.
The clowns who try to do stuff like this with shell scripts and cron jobs spend a big fraction of their time dealing manually with the failures. If you do it right, it just keeps working. One of my other sites, "downside.com", has been updating itself daily from SEC filings for over a decade now. About once a month, something goes wrong with the nightly update, and it's corrected automatically the next night.
A video that shows a second or two before the payload broke loose yields more information. It looks like the crane truck was starting a left turn, pulling against the balloon, when the pull from the balloon broke the attachment to the truck. The previous video made it look like the balloon was pulling the crane boom sideways, and the boom snapped back after release. But no. The truck was doing a left turn (they had to do something, they'd reached the perimeter fence) while the balloon pulled it to the right. That's where the big stress came from.
If the plate on the crane holding the cable to the balloon (safety factor 1.3, far too small, as later computed by NASA) hadn't failed, the launch team would have been able to hold the balloon and save the payload. They'd had failed launches before, and knew the truck was heavy enough to hold the balloon. So one can see why they held off on an abort. They might have been able to back the truck out and try the launch again. But their crane rigging wasn't built for sizable side loads.
In retrospect, they should have aborted sooner. The payload is the valuable part; it's normally recovered by parachute. An abort would have saved the payload and lost the balloon. The balloon is a consumable. But, as NASA's critique points out, they didn't have formal abort criteria, and tried an ad-hoc fix to get out of the mess they were in. If the bolts on the crane's attachment plate had been stronger, it would have worked.
I just tried the Suzette chatterbot. Even if I talk about the things it wants to talk about, it's very dumb:
Hi John !
[ Af:0 At:10 Sp:0] Welcome back, john. Type "help" if you need it.
John - So what do you think of the Giant's chances?
[ Af:0 At:10 Sp:0] It doesn't concern me.
John - Are you into sports.
[ Af:0 At:10 Sp:0] Sports is not my cup of tea. I prefer intellectual challenges like Go.
John - Who's the world Go champion.
[ Af:0 At:10 Sp:0] Sorry. I can't help you. A celebrity of some sort?
John - Do you play chess?
[ Af:0 At:10 Sp:0] I don't play any games except Go.
John - Can we play Go on here?
[ Af:0 At:10 Sp:0] About playing... Does it make sense to you that we reward athletes more than scientists?
John - Television coverage makes that possible.
[ Af:0 At:10 Sp:0] It's a free market economy. And people value entertainment more than serious things like science and education.
John - And your point is?
(No reply)
John - Are you there?
[ Af:0 At:10 Sp:0] Who's the sexiest person in the world?
This isn't much better than Eliza. It drives the conversation into talking about Go, and then it doesn't have anything to say on the subject.
After reading through the whole report, the most surprising thing is the design of the launch mechanism. The basic setup was that the launch was done from a moving crane truck. The truck was equipped with special outrigger wheels, so it could handle some side load without rolling over, and a platform for the "launch director", who was supposed to release the payload by yanking on a strap attached to a cable, pulley, and pin. The launch setup is that the balloon is inflated, allowed to rise, and then the crane truck. which is carrying the payload, tries to get under the balloon, chasing the balloon if necessary. When the payload is in position, the launch director yanks the strap and releases the payload.
This is obviously a setup which is highly dependent on what the wind does during the launch process. Some of the time, the wind is not going to cooperate, and an abort will be required. That's to be expected. But this time, they didn't abort until it was far too late.
During the process of chasing the balloon, the stresses on the restraint system were about 3x higher than at rest. It would have taken a 300 pound pull to release the pin; this was tested after the event. The guy who was supposed to pull the strap, while standing on a moving platform atop the crane truck, wasn't even wearing gloves. There was no backup system for releasing the payload. The payload eventually released when the crane truck reached the airport perimeter fence and had to stop. The wind forces from the balloon were then great enough to tear off a mounting plate on the truck, releasing the payload, which plowed through the fence and wiped out an SUV.
They didn't have an explosive bolt system to release the payload. The launch system used remote controlled pyrotechnics for releasing the balloon's restraining ring, and for the balloon-release abort system, so they already had all the systems and procedures in place for using pyrotechnics. But the main launch function was a guy pulling a strap.
There's clear video of the incident. This is useful to watch. When the payload tears loose from the crane, the crane truck is facing 90 degrees from the wind direction and stuck at the fence line. The crane boom is under high sideways stress. The abort system should have been triggered when the truck got into that situation, but it wasn't. (An abort prior to release loses the balloon and saves the expensive payload.) But the person with the abort button (the "campaign manager") and the guy trying to pull the release strap (the "launch director") were in different places and not coordinated, so when things went wrong, the abort didn't happen until after the payload had come loose and wiped out the perimeter fence and an SUV.
The day may come when individual possession of a hard drive may be illegal, as a "piracy device". How many people generate enough data of their own in their lifetime to fill a 1 TB drive?
Google Voice is useful and fun, but its interface with the telephone network remains flaky. See "Can't send text message from sprint phone to my Google voice number" and "Google number not callable from certain numbers" Google Voice seems to have an ongoing problem keeping their blocks of phone numbers properly visible to other carriers. Troubles have been reported with Sprint, Verizon, and T-Mobile numbers for over a year now. There are also some limitations on calling into and out of Google Voice from VoIP systems.
The problems may stem from the fact that Google didn't implement Google Voice. It's just "Grand Central", acquired and re-branded. It's not a "telco quality" system. It's not ready for prime time as your main phone system for a business.
In manufacturing, the Walkman was notable for its construction. It was designed for automated vertical assembly. In vertical assembly, all components are inserted by simple robots which move straight down to add a part to the base. The base is designed to support and align the parts so that this simple approach to assembly will work. It's fast, cheap, and fully automated.
Apple tried vertical assembly briefly. The Macintosh IIci was designed for vertical assembly. The power supply went in vertically and clicked into the motherboard. No internal cables. Then they went over to outsourced manual assembly with cheap labor. Swatch watches also used vertical assembly. Simpler cell phones are often assembled in this way.
If the CPU utilization is that low, it's an I/O scheduling problem. See Linux I/O scheduling.
The CFQ scheduler is supposed to be a fair queuing system across processes, so you shouldn't have a starvation problem. Are you thrashing the virtual memory system? How much I/O is going into swapping. (Really, today you shouldn't have any swapping; RAM is too cheap and disk is too slow.)
The amusing thing is that China Daily has an iPad app.
At the time, XNS, the Xerox protocol for Ethernet networks, was in use. It had 24 bits for the network number, and 24 bits for the device ID. Thinking at the time was that each network would be a local LAN, and "internetworking" would interconnect LANs. Xerox was thinking of this as a business system, with multiple machines on each LAN. So XNS had a 48-bit address spade. That's what we call a "MAC address" today.
The telephony people were pushing X.25 and TP4, which used phone numbers for addressing. Back then, phone numbers were very hierarchical; the area code and exchange parts of the number determined the routing to the final switch. "Number portability", where all the players have huge tables, was a long way off.
The problem with a big address space is that memory was too expensive in those days to deal with huge address tables. A big issue was locative vs non-locative address spaces. In a locative address space, there's a hierarchy - you can take some part of the address and make a local decision about what direction to go, even if you don't have enough detailed information to get to the final destination. IP was originally organized like that - routers looked up class A, B, and C networks. A huge, flat address space implemented using multi-level caches was way beyond what you could do in a router back then. Routers used to be dinky machines, with less than one MIPS and maybe 256K of RAM.
There was a lot of worry about packet overhead. Each key press on a terminal sends 41 bytes over a TCP/IP network. That was a big deal when companies had long-haul links in the 9600 to 56Kb/s range. Adding another 24 bytes to each packet to allow for future expansion seemed grossly excessive. Especially since the X.25 people had far less overhead.
So there were good reasons not to overdesign the system. I don't blame Cerf for that.
The foot-dragging on IPv6 is excessive. The big deployment problem was getting it into everyone's Windows desktop. That's been done.
This is either total crap or Nobel Prize material. I'm not qualified to say which. Who's endorsing this paper?
Ricochet did this in the 900MHz band using spread spectrum a decade ago, for wireless Internet access. They put up little nodes on street light poles, using a deal where the municipality got free data access. It worked fine, but only delivered dial-up speeds, so it was overrun by DSL and cable. Even back then, getting around narrowband interference was no big deal.
Tesla has the advantage of taking over the NUMMI plant in Fremont, CA, a big, successful auto plant shut down for the 2008 recession, when Toyota, for the first time, had to close plants. They're only using a fraction of the plant, but they own all the buildings (although not all the land; they didn't buy all the parking lots). There are plenty of laid-off auto workers living nearby, so a workforce is available.
The cost differential with China has narrowed. It turns out that once wages in China reach a quarter of the US level, China manufacturing stops being competitive. The transport costs, the delays, and the quality problems make outsourcing manufacturing less attractive. With wages rising in the coastal provinces in China, (and wages dropping in the US) that wage level has been reached in some industries.
Also, with all the foreclosures, bay area house prices have dropped. Maybe by a factor of 2.
Operating in Detroit has its own problems. The weather is harsh. Crime is high. Most of the people with competence and ambition moved out when the jobs did.
Don't worry about the rare earth supply problem. Mountain Pass, California is already coming back on line.
All I got was some site that played video ads, tried to set Flash cookies, and displayed popups. Is this a spam article?
You can get a phased-array receive antenna now, to receive satellite TV on your SUV or RV while driving. This has been a common military technology for decades.
One for stationary use could be simpler. The mobile units have a full GPS/inertial/compass setup, so they know where to aim as the vehicle moves. A stationary unit doesn't need all that. It can just scan around after installation, find the desired sats, and store the direction.
What Android seems to need is a formal spec and a tough set of compatibility tests. That's how you deal with interoperability problems.
I used to be in aerospace. In that industry, if A and B don't interoperate, you go to the spec. If A isn't compliant, A is wrong. If B isn't compliant, B is wrong. If you can't tell, the spec is wrong. That's why you can unplug a Rolls-Royce engine from a Boeing 747, plug in a Pratt and Whitney engine, and go fly. Many years ago, in the early 1980s, I applied that reasoning to TCP/IP interoperability, and I was instrumental in pounding implementations into conforming to the published spec. At the time, it was a radical concept that completely different computers from different vendors with different implementations should talk to each other. Berkeley TCP originally did not play well with others. They felt it was only necessary to interoperate with other Berkeley UNIX systems. They were pounded on by their DoD funding agency until they got with the program.
Google needs to apply some of that hardass attitude to get cross-platform compatibility.
Olivetti used to have a fascination with industrial design. Their machines are on display in in art museums. But they just weren't that good. It's not about case design.
Jobs's strength is that he focuses on the end to end user experience. This is rare. Even most retailers don't get it. One of the few that does is The Gap. In a Gap store, there's no checkout area clutter, and large, clear counter surfaces for doing the sale. Most retailers put vast amounts of impulse-buy junk near the checkout. (Visit a Bed, Bath, and Beyond to see the worst case.) It provides some marginal revenue, but it constricts the flow of customers and money, and cheapens the perceived value of the real products. The Gap avoids that, and checkout flow is smooth. That's the end to end user experience.
This is why Amazon's "one-click buy" was such a successful innovation. This is why iTunes is successful. This is why well designed icons matter. Read "Flow: The Psychology of Optimal Experience", for a pop-culture analysis of the subject.
The end to end user experience is an issue in software. Microsoft sort of gets it, and they mostly have Word right. OpenOffice does not get it. Maya gets it. Blender doesn't get it. Autodesk Inventor gets it. SolidWorks doesn't get it.
The Linux community totally does not get this.
even today's mainstream cpus are far more powerful than what our everyday tasks involve.
Usually that's true. But today I was using Autodesk Inventor, which is a parametric CAD solid modeling system. That's one of the few desktop applications that can usefully use gigabytes of memory and a dozen CPUs.
(I worked on the development of AutoCAD in the early 1980s, when the problem was cramming usefully sized drawings into 640K of RAM, a 20MB hard drive, and an 0.25 MIPS CPU. It was a tough cramming job. I used to dream about the day when we could have a CAD system with real-time solid modeling, automatically connected to CNC machine tools, running on a desktop computer. It took four or five more orders of magnitude in CPU power to make it work, and it's here. I'm glad I got to see it happen.)
Another minor bit of progress in materials science being blown up into a revolutionary advance. We get about one of these every two weeks. Right now, these guys have a one-bit device that consumes more power than DRAM. They really should hold off on the press releases until they're further along. Maybe this will be useful, and maybe it won't be.
It's stuff like this that gives nanotechnology a bad name.
Microsoft didn't kill desktop Linux. The newer OSs for mobile devices did.
A decade ago, Linux was in the #2 position. The Mac wasn't going anywhere, phones didn't run applications, and the PDA world wasn't very relevant. Linux had a window of opportunity when Windows XP was late.
Linux isn't in the #2 position any more. All the growth is in the the mobile devices sector, where ease of use is paramount. Even though some mobile devices have a Linux kernel underneath, that's not what the user sees, or what developers write apps for. The Mac has made a comeback. The "netbook" and "tablet" industry tried Linux, and didn't like it. Linux on desktops has become irrelevant.
Sumatra - it's so dumb that the Adobe exploits don't work. No forms. No plug-ins. No cut and paste. No networking. All it does is display PDFs in a separate window. Which, 99.9% of the time, is all you want.
I don't even have Adobe Reader installed on my Windows 7 machine.
The link in the article leads to a spam link page with a big timed Flash ad. The actual Wall Street Journal article mentioned is here.
Of course. Human civilizations are about 3000 years old, but industrial civilization is only 200 years old. Only in the past 100 years has large-scale resource extraction, large enough to make a big dent in potential supply, been feasible. The really rich ores, like veins of copper with over 1% metal, are long gone. Over the next century, lots of stuff is going to run out. Oil production peaked in 2005. There hasn't been a major new energy source in the last half century; just improvements on previous ones.
The "free market will solve all problems" crowd was insisting that peak oil would never happen. But it did. The price of oil has tripled without an increase in supply.
The "Silicon Valley Leadership Group" is kind of a joke. It used to be the "Silicon Valley Manufacturing Group", the lobby for the semiconductor industry, but after most of the semiconductor plants closed, it lost focus.