Computer Space coin op, 1972, in Philadephia. That thing had an fibreglas arcade cabinet with speckles embedded in the resin.
Cooler than anything seen since.
I also played the original Galaxy Game at Tressider Union at Stanford, but that was a few years later.
Quickly, and without making a big deal of it, fire Federal employees known to have participated in any type of coverup. In particular, anybody implicated in harassing a whistleblower is out. Word will get around. After that, information flow about problems will start to work again.
Put OMB on a one month cycle. Every month, each agency is evaluated for progress against its milestones. The information cycle can't be slower than a month if anything is to work.
Also, get some competent people in the various Inspector General offices. Get people with forensic audit and investigative reporting experience. And make it clear that IGs have authority to look at anything; anybody who refuses to turn over records gets suspended or fired.
Bring in some top people to turn around key agencies. Maybe Guilani for Justice, Brandon for FBI. Gus Pagonis would be great for FEMA, but he's too old; get him to find someone.
Domestic policy.
Push for tax rates about where they were at the end of the Reagan administration. Those rates worked for the 1990s, so it's hard to complain they're bad for business.
Beef up IRS enforcement against non-filers, and against high-income people paying unusually low taxes.
Emphasize median per-capita income for wage earners as the primary policy number. That's the number that needs to increase. Worry less about the DJIA.
Accept that there's been a housing bubble, and now the air has to come out.
Push on medical cures for addiction. Don't expect near-term results.
Raise the minimum wage for undocumented workers a few dollars above the normal minimum wage. Only workers who can legally work in the US can be paid minimum wage. Enforcement in small claims courts, with triple damages. Under the table employment creates a presumption in favor of the employee. This discourages employers from hiring undocumented workers to save on wages. Get a national system for easily verifying identity during hiring up and running.
Energy.
Keep the ethanol subsidy, but deduct all fuel inputs. The full subsidy only applies if the extraction plants and the tractors are ethanol-powered, and the ethanol consumed in producing ethanol isn't subsidized.
Solar power goal: air-conditioning in the Sunbelt must be solar powered within ten years. New construction within three years, then large commercial properties, then residences.
Foreign policy.
Worry more about the new nuclear powers: N. Korea, Pakistan, and Iran. Worry less about terrorism.
Go to Fort Leavenworth. Get together the five or ten best field grade officers from the School of Advanced Military Studies. (That's where the top Army officers study strategy, after they've already been out at the killing end.) Have them come up with a plan for Iraq and Afghanistan. Implement it. It may or may not work, but you can't do better than that.
Get along better with Europe and Japan. Keep pushing on China to lighten up, but don't expect much. Work towards some vague understanding that when China catches up with Taiwan economically, they might want to merge. Encourage EU diplomats to push in that direction; they're used to running a multinational area that countries want to join. Meet with Russian leaders, but don't expect much more than detente. Bear in mind that when per capita income passes around $4K/$7K (2000) per year, democracy tends to kick in whether the leadership wants it or not. (This doesn't work for oil states, because the money flows down, not up.)
There are two fundamental problems with flying cars. First, reciprocating engines aren't quite powerful enough, and small turbojets cost too much. Second, they're unstable. Both problems could be solved, yielding an expensive but workable flying car.
The engine is the big problem. People have been trying to downsize jet engines for decades. Small ones can be built, but once you get below small bizjet size, they don't get much cheaper.
That's why general aviation is still running on pistons.
A flying car in the $2 million range is probably feasible, but the market is limited and the engineering costs are high.
Stability is partly a control system problem and partly an actuator problem. How do you exert attitude control in hover? Adjusting the fan speed of multiple fans is too slow.
Adjusting blade pitch cyclically, like a helicopter, requires cramming all the machinery of a helicopter hub into each fan hub. VTOL jet fighters have been successful, sort of.
The Harrier diverts about 10% of its jet thrust to attitude jets in hover, which yields quick control, but the Harrier has plenty of jet thrust to play with. The F-35 fighter has a steerable nozzle in the tail, a lift fan in the middle, slats under the fan, pitch nozzles in the wings, roll nozzles in the nose, doors to cover all this gear, and enough computer power to manage it. Even with all that, it's a marginal VTOL craft.
The USSR tried several VTOL fighter designs over the years, but none of them worked very well. The Harrier variants are the only real success to date.
The Sky Commuter was an exercise in weight reduction; it weighs about 400 pounds. That's one approach, but it didn't work.
It's a type of bug more common back when memory was limited. Classically, it was a spreadsheet bug. The dumb way to evaluate a spreadsheet is to start at the upper left, evaluating the formula (if any) for each cell. If any formula refers to a value that's to the right or below the cell being evaluated, the spreadsheet values will be wrong. Each time you hit the recalculate key, the values propagate through one more wrong-direction dependency. Once you've hit "recalc" enough times, the values stabilize. Unless the spreadsheet actually has a dependency loop, in which case they continue to change with every recalc.
All the early desktop spreadsheet programs (VisiCalc, etc.) used this dumb algorithm. The correct way to do it was known, but had been patented in 1969.
It's also much more complicated to do it right; you have to build graphs, sort them by dependencies, and detect loops. It's so simple to do it with two nested FOR loops, and most of the time the complex algorithm yields the same answer as the dumb one.
Anything that has in-place updates of a grid of cells with arbitrary dependencies on other cells potentially has this problem. So it crops up in games, in image processing algorithms, and in simulations now and then.
Space travel with chemical fuels just barely works. The energy density just isn't there.
No matter what you do, your vehicle is almost all fuel tank. That's why we need multistage rockets, weight-reduced to the point they're very fragile, to put dinky payloads in orbit at huge costs. There's been no fundamental improvement in big rockets in forty years. Arguably, rocketry peaked with the Saturn V.
Forty years is a long time. Aviation went from the Sopwith Camel to the Boeing 707 in 40 years. Computers went from the UNIVAC I to the Pentium in 40 years. Rocketry, well..
Unless we figure out some other way to launch, we're stuck.
Probably because they borrowed some of the code from SimAnt, which had less ant growth towards the upper left due to a processing order issue in the updating algorithm. It's one of those problems where step N+1 is computed incrementally from the current state, rather than from a frozen copy of step N.
Searching for phrases in news stories sometimes brings up bottom-feeder ad sites. Take a headline from The Register, search it in Google, and see what comes back. I noticed this a few days ago when we got a writeup in The Register, and the bottom-feeder ad sites not only ranked above the real story, they pushed the real story to the second page. This only lasted for a few days; it looks like the bottom-feeders put up the latest stories.
Instead of the current typical 200amp service, everybody gets a 20amp service that is "always on", and a 200 amp service that's subject to rolling blackouts.
Israel had something like that several decades ago. Houses had two meters, with different rates, and the power company could turn off the cheaper supply during peak periods.
This is a street tram switching system similar to the Elektroline system. It's not a full signalling system with interlocking. The tram driver is in control, and has an RF transmitter which can control switches.
The current generation, the "TRAMVYS 6K", is an RF transmitter on 433.9 or 868.35 MHz.
Normal range is very short, about 2M, with the transmitter down on the front truck of the tram and the receiver buried in the road. But it could probably be triggered by someone
at the side of the street with a suitable transmitter. This system is interlocked so that the switch can't change position underneath a tram.
That's current technology. Older systems are much dumber. Some of this stuff is at the garage-door-opener level of RF devices. The Lodz tram system dates from 1898, so they have lots of legacy trackwork.
SpeedTree already does this, and does a very nice job. Try their free downloads. SpeedTree has smooth level of detail processing, so you can draw very large forests in real time. One of their demos is a "million tree forest". Every tree is different; they're generated procedurally from a set of parameters. You can use their tree library, with about 1000 different varieties of tree, or design your own trees.
What we need is a FTC rule that says that any business or financial institution that uses an SSN as a password is prima facie liable for any fraudulent transaction facilitated thereby. Plus a penalty of $500 or so.
SSNs shouldn't have to be a secret. Since they're fixed for life, they're terrible passwords, anyway.
It could be worse. Back when the FBI was taking down the New York Mafia, the FBI didn't pay the bill on some of their wiretaps. The billing software then billed the other party on the connection, the Mafia guys being wiretapped. It's in Guliani's book about that operation.
Wiretaps are a billable service. See this DoJ document. Search for "Wiretap Fees" in the document. A typical 30-day wiretap costs from $250 to $2600.
There are base wiretap fees, monthly maintenance fees, per switch set-up fees, additional switch fees, uninterrupted continuation fees, call-bridging fees, "pinging" fees, extension fees, and fees for activity reports. Prosecutors can't challenge the fees in civil court because the wiretap orders are sealed by a criminal court.
90% of all wiretap requests now involve mobile phones, according to DoJ.
Nobody talks about Helio, but they did most of the iPhone things before the iPhone, and better.
3G networking - Helio has it, Apple doesn't.
Social networking integration - Helio has it ("Myspace integration"), Apple doesn't.
GPS/map/social networking Helio has it ("Buddy Beacon"), Apple doesn't even have GPS.
Video camera Helio has it, Apple doesn't.
Music downloads Helio does them over the air, Apple doesn't.
They both have music, video, phone, camera, etc.
Helio also has much more Web integration (IM, POP email, RSS, etc.) than the iPhone. The problem is that they had to put a pop-out QWERTY keyboard in the thing to deal with all the web stuff.
As I pointed out previously, there were at least three companies demonstrating wireless charging systems.
This new article lists two more, Powercast and Fulton Innovation.
Short-range systems using long-wave near-field RF are probably the way to go. Power ratings can be quite high. The GM EV-1 charger used an inductive paddle operating at 400KHz, and could transfer kilowatts across about half an inch at 90%+ efficiency. The MIT system operates in the 4-10 MHz band.
No, tube manufacture was mechanized by the 1950s. You're looking at an outfit that makes tubes that sell for $600 each, for sale to audio nuts. Here's a 1952 article on a CRT assembly line. Vacuum tubes were made on machinery similar to that used to make light bulbs.
Did that, worked OK. Network Solutions will blacklist WHOIS queries that seem to come from a program or are too numerous. If you need bulk WHOIS data, you either have to become a registrar, make a deal with one, or buy services from "domaintools.com".
One of the basic requirements of SiteTruth is that a web site that's selling or promoting something must have an identifiable name and address on the web site. A "contact us" form isn't good enough. Legitimate sites selling something usually have a valid name and address on the site. Commercial sites without business names and addresses are generally "bottom-feeders". They may or may not be fraudulent, but there's no way to tell, so we down-rate them and move them down in our search results. It's illegal in many jurisdictions to run a business without disclosing an address (California and EU law are quite explicit on this), and so that's a good first filter.
This filters out the bottom-feeders who aren't willing to go all the way to using a phony address. That's a felony (wire fraud or identity theft), so most sites with even a pretense of legitimacy don't go there. Those guys are crooks; no question about that. We have some blacklists to check for that sort of thing; it's usually phishing-related.
So there are three general categories - legitimate, bottom-feeder, and felony crook.
The bottom-feeders are the ones Cutts is talking about. If they hadn't done some "search engine optimization", they wouldn't rank high enough in a search engine that anyone would see them. Some of the bottom-feeders are annoying, but not illegal; those are the ones that are page farms, but at least on-topic page farms. Then there are those who just have pages of irrelevant links and ads. Their natural habitat is celebrity name searches. Since they're probably violating false advertising laws, they are misdemeanor-level crooks.
When bottom-feeders go bad, it's usually via downloading hostile software as an "affiliate". See, for example, Zango. That's an ongoing problem, and McAfee's SiteAdvisor filters out those sites. Even Google is finally checking for most of the usual suspects there.
Amusingly, the bottom-feeders can't go legitimate and give a name and address without losing search engine positioning. If the same name and address shows up on a huge number of sites, Google picks that up and down-rates the sites for duplicate content. One large bottom-feeder actually has a link to a common "about" page on each of their several hundred thousand sites, but uses the "robots.txt" file to keep Google from finding it. Our SiteTruth system won't read the page in violation of the "robots.txt" file, so we downrate them for lacking a business address. They just can't win.
This is starting to look like the history of spam. In the early days of spam, as some may remember, it was viewed as a bottom-feeder marketing medium, and reasonably legitimate companies used it. The CAN-SPAM act was enacted in a form that pleased the Direct Marketing Association, but had an effect unexpected by both the DMA and anti-spam workers. The CAN-SPAM act allows spam, but only if the sender and subject are identified properly. So any "legitimate" spam is easily filtered out by spam filters. As a result, today, spam is entirely a criminal activity. We never hear about the DMA in spam discussions any more. Now it's about putting people in jail.
The same thing is happening on the web. As the filters get better, the marginal bottom-feeders don't get through, and only the out and out crooks are left. As with spam, in time we'll get rid of most of the bottom-feeders, leaving only the crooks. As the ambiguity goes away, the job of law enforcement becomes easier. That's happened with spam. There's a high-profile arrest every month or two now. Alan Ralsky just went down.
Time for ICANN to issue a policy under the registrar agreement to enforce section 3.7.9: "Registrar shall abide by any ICANN adopted specifications or policies prohibiting or restricting warehousing of or speculation in domain names by registrars."
The real issue in programming languages is "what do you have to worry about?" They all have, in theory, equivalent power. But some languages fully handle some parts of the problem for you, and some don't. The trouble spots in different languages vary considerably.
When programming C, one has to obsess on pointer management. Storage allocation is
completely manual and arrays are not only unchecked, but ambiguous in size. Most C errors are related to pointers. The language also offers almost no help in dealing with concurrency.
Java does a good job of dealing with pointers. Arrays are checked and memory is garbage-collected. So Java generally doesn't have pointer problems. The language knows
a little about concurrency, but not quite enough. Java programmers can stop worrying about pointer management, but still have to worry about race conditions. Most of the problems in Jave programming relate to interfaces with large, troublesome libraries.
Ada deals well with array size issues, but storage allocation is still manual. Concurrency is addressed in a rigorous way. Ada programmers have to worry about how to structure their problem within Ada's constraints. More of the problems in Ada are at the front end in design; once the basic structure of the program is right, the pieces tend to go together well. This does not map well to "extreme programming" or "agile programming".
C++ is in the unique position of providing hiding (or "abstraction") without memory safety. No language before C++ had that combination, and no language since has had it. C++ has the same problems as C, but there's a layer of wallpaper over them. Memory errors in C++ tend to be fewer than in C, but more obscure when they occur. C++ tends to be a ritual/taboo programming language; there are many things which one must not do, and those things are not obvious.
That's a more useful way to think about the problem. Ask the question "in what ways do programs in this language break?"
Ignoring the language issue, the authors raise the question of how much math and theory should programmers have. That's worth exploring.
I'm a programmer with a strong theoretical background. I have an MSCS from Stanford, I've built a automated proof of correctness system, and I've done a physically based animation system which required building solvers for stiff systems of non-linear differential equations. I've done hard real time programming for mobile robots, network protocol design, assembly language programming, and logic board design. So I've actually used most of that theory.
Most programmers don't. If you're just doing web site back ends, you don't need all that stuff. I'm not even using much theory any more.
There's also the question of what theory to teach. I got too much discrite math and not enough number-crunching. Automata theory isn't very useful, but Bayesian statistics is. Academics can guess wrong on this. In the mid-80s, Stanford had a program to train "knowledge engineers", who were trained to write rules for expert systems. Where are they now?
There are only about 20,000 real computer science jobs in the US outside of academia. That's not the mainstream part of the field. The other 500,000 programmers don't need that much theory. Teach them Java and Python and how to work on a big project, not number theory.
I had to learn big-project work by spending years as a maintenance programmer for mainframe operating systems. Didn't get any training in school on that at all. That was a lack. Once I got that, I was able to use the theory on hard problems. I needed both kinds of training.
Here's a plan for solar power for California that could actually work.
Goal: power 100% of Southern California's air conditioning load from solar energy within eight years.
Why Southern California? Because there's enough sunlight for solar power to work well.
Why air conditioning? Because peak air conditioning load and peak solar power output happen at the same time. Peak power load for all of California is about 42 gigawatts, and about a quarter of that is Southern California air conditioning. So we need about 12GW of solar panel capacity.
Technical approach.
Applied Materials says they're ready to build the first "gigawatt" solar panel plant. By that they mean a plant that produces in one year enough panels to generate a gigawatt of peak power.
Two such plants can make enough panels to do the job in six years. No new technology is necessary.
Paying for it
Raise electric rates on hot summer afternoons. Anything bigger than a 3-bedroom house has to have time-of-day metering.
The first three results from Wikia search are all from the domain "visit-tampa-bay.com". That's one of those bottom-feeder ad link sites. The site is supposed to redirect traffic to Orbitz, but doesn't even do that right. Very disappointing result. Could they have been spammed already?
Trying "Tampa hotels" in Google gets us "travel.yahoo.com" for the top two results, which indicates that Google isn't biasing their search against their biggest competitor. Next is "traveladvisor.com". Those are OK results; you'd be able to get a hotel room that way.
Trying "Tampa hotels" in Yahoo search gets us a page from one of Yahoo's special cases. Yahoo knows about "hotels", so we get a list of hotels and prices from Yahoo, and three sponsored results. The top organic result is "tripadvisor.com", which is at least a big-name travel site, followed by "visittampabay.com" (not to be confused with "visit-tampa-bay.com"), the site for the local Convention and Visitor's Bureau. Yahoo certainly tries hard for hotel searches, and seems to be doing OK.
Trying "Tampa hotels" in MSN search gets results that look much like Yahoo's, but with lower result quality. MSN understands hotels as a special case. There are three sponsored results, and addresses and phone numbers for three real hotels. The first three organic search results are Yahoo Travel, "tampa-hotels.net" (an ad-laden landing page), and "tampa-hotels-discounts.net" (a bottom-feeder generic landing page that isn't even on topic.) Poor results.
Trying our own SiteTruth the top result is "all-hotels.com", which has a list of hotels with pictures and a reservation interface. The second result is Yahoo Travel, and the third is Expedia. We're sorting Yahoo results on business legitimacy, so that's not surprising. OK here.
So there's where Wikia is today, on their recommended demo search.
We've heard this before. There's a presentation in AFIPS 1966 in which someone from Control Data was saying that each metropolitan area would have one giant, shared supercomputer.
"Grid computing" was a flop commercially, once the vendors started charging for it. Sun's service is still around, but they don't talk about it much any more. That was more like an effort to find something to do with their unsold server inventory. ResPower Render Farm has a real but very specialized business, quietly rendering 3D frames for the film industry.
Amazon has been making some noise lately, but they don't promise much: "Without limitation to Section 11.5, we shall have no liability whatsoever for any damage, liabilities, losses (including any loss of data or profits) or any other consequences that you may incur as a result of any Service Suspension." Clearly they're not serious about offering a service to businesses.
There are successful services, like Salesforce, but those offer more than raw compute power.
Slashdot Mirror
Computer Space coin op, 1972, in Philadephia. That thing had an fibreglas arcade cabinet with speckles embedded in the resin. Cooler than anything seen since.
I also played the original Galaxy Game at Tressider Union at Stanford, but that was a few years later.
Domestic policy.
Energy.
Foreign policy.
There are two fundamental problems with flying cars. First, reciprocating engines aren't quite powerful enough, and small turbojets cost too much. Second, they're unstable. Both problems could be solved, yielding an expensive but workable flying car.
The engine is the big problem. People have been trying to downsize jet engines for decades. Small ones can be built, but once you get below small bizjet size, they don't get much cheaper. That's why general aviation is still running on pistons. A flying car in the $2 million range is probably feasible, but the market is limited and the engineering costs are high.
Stability is partly a control system problem and partly an actuator problem. How do you exert attitude control in hover? Adjusting the fan speed of multiple fans is too slow. Adjusting blade pitch cyclically, like a helicopter, requires cramming all the machinery of a helicopter hub into each fan hub. VTOL jet fighters have been successful, sort of. The Harrier diverts about 10% of its jet thrust to attitude jets in hover, which yields quick control, but the Harrier has plenty of jet thrust to play with. The F-35 fighter has a steerable nozzle in the tail, a lift fan in the middle, slats under the fan, pitch nozzles in the wings, roll nozzles in the nose, doors to cover all this gear, and enough computer power to manage it. Even with all that, it's a marginal VTOL craft. The USSR tried several VTOL fighter designs over the years, but none of them worked very well. The Harrier variants are the only real success to date.
The Sky Commuter was an exercise in weight reduction; it weighs about 400 pounds. That's one approach, but it didn't work.
It's a type of bug more common back when memory was limited. Classically, it was a spreadsheet bug. The dumb way to evaluate a spreadsheet is to start at the upper left, evaluating the formula (if any) for each cell. If any formula refers to a value that's to the right or below the cell being evaluated, the spreadsheet values will be wrong. Each time you hit the recalculate key, the values propagate through one more wrong-direction dependency. Once you've hit "recalc" enough times, the values stabilize. Unless the spreadsheet actually has a dependency loop, in which case they continue to change with every recalc.
All the early desktop spreadsheet programs (VisiCalc, etc.) used this dumb algorithm. The correct way to do it was known, but had been patented in 1969. It's also much more complicated to do it right; you have to build graphs, sort them by dependencies, and detect loops. It's so simple to do it with two nested FOR loops, and most of the time the complex algorithm yields the same answer as the dumb one.
Anything that has in-place updates of a grid of cells with arbitrary dependencies on other cells potentially has this problem. So it crops up in games, in image processing algorithms, and in simulations now and then.
Space travel with chemical fuels just barely works. The energy density just isn't there. No matter what you do, your vehicle is almost all fuel tank. That's why we need multistage rockets, weight-reduced to the point they're very fragile, to put dinky payloads in orbit at huge costs. There's been no fundamental improvement in big rockets in forty years. Arguably, rocketry peaked with the Saturn V.
Forty years is a long time. Aviation went from the Sopwith Camel to the Boeing 707 in 40 years. Computers went from the UNIVAC I to the Pentium in 40 years. Rocketry, well..
Unless we figure out some other way to launch, we're stuck.
Either go nuclear or go home.
left of the city center
Probably because they borrowed some of the code from SimAnt, which had less ant growth towards the upper left due to a processing order issue in the updating algorithm. It's one of those problems where step N+1 is computed incrementally from the current state, rather than from a frozen copy of step N.
More than half in the first few pages are the scum-sucking lowlife advertising sites. Clearly what they're doing is monitoring the "hot Google searches" and then googlepimping© their own sites to match those searches.
Searching for phrases in news stories sometimes brings up bottom-feeder ad sites. Take a headline from The Register, search it in Google, and see what comes back. I noticed this a few days ago when we got a writeup in The Register, and the bottom-feeder ad sites not only ranked above the real story, they pushed the real story to the second page. This only lasted for a few days; it looks like the bottom-feeders put up the latest stories.
Instead of the current typical 200amp service, everybody gets a 20amp service that is "always on", and a 200 amp service that's subject to rolling blackouts.
Israel had something like that several decades ago. Houses had two meters, with different rates, and the power company could turn off the cheaper supply during peak periods.
This is a street tram switching system similar to the Elektroline system. It's not a full signalling system with interlocking. The tram driver is in control, and has an RF transmitter which can control switches. The current generation, the "TRAMVYS 6K", is an RF transmitter on 433.9 or 868.35 MHz. Normal range is very short, about 2M, with the transmitter down on the front truck of the tram and the receiver buried in the road. But it could probably be triggered by someone at the side of the street with a suitable transmitter. This system is interlocked so that the switch can't change position underneath a tram.
That's current technology. Older systems are much dumber. Some of this stuff is at the garage-door-opener level of RF devices. The Lodz tram system dates from 1898, so they have lots of legacy trackwork.
SpeedTree already does this, and does a very nice job. Try their free downloads. SpeedTree has smooth level of detail processing, so you can draw very large forests in real time. One of their demos is a "million tree forest". Every tree is different; they're generated procedurally from a set of parameters. You can use their tree library, with about 1000 different varieties of tree, or design your own trees.
What we need is a FTC rule that says that any business or financial institution that uses an SSN as a password is prima facie liable for any fraudulent transaction facilitated thereby. Plus a penalty of $500 or so.
SSNs shouldn't have to be a secret. Since they're fixed for life, they're terrible passwords, anyway.
It could be worse. Back when the FBI was taking down the New York Mafia, the FBI didn't pay the bill on some of their wiretaps. The billing software then billed the other party on the connection, the Mafia guys being wiretapped. It's in Guliani's book about that operation.
Wiretaps are a billable service. See this DoJ document. Search for "Wiretap Fees" in the document. A typical 30-day wiretap costs from $250 to $2600. There are base wiretap fees, monthly maintenance fees, per switch set-up fees, additional switch fees, uninterrupted continuation fees, call-bridging fees, "pinging" fees, extension fees, and fees for activity reports. Prosecutors can't challenge the fees in civil court because the wiretap orders are sealed by a criminal court.
90% of all wiretap requests now involve mobile phones, according to DoJ.
Nobody talks about Helio, but they did most of the iPhone things before the iPhone, and better.
-
3G networking - Helio has it, Apple doesn't.
-
Social networking integration - Helio has it ("Myspace integration"), Apple doesn't.
-
GPS/map/social networking Helio has it ("Buddy Beacon"), Apple doesn't even have GPS.
-
Video camera Helio has it, Apple doesn't.
-
Music downloads Helio does them over the air, Apple doesn't.
They both have music, video, phone, camera, etc.Helio also has much more Web integration (IM, POP email, RSS, etc.) than the iPhone. The problem is that they had to put a pop-out QWERTY keyboard in the thing to deal with all the web stuff.
As I pointed out previously, there were at least three companies demonstrating wireless charging systems. This new article lists two more, Powercast and Fulton Innovation.
Short-range systems using long-wave near-field RF are probably the way to go. Power ratings can be quite high. The GM EV-1 charger used an inductive paddle operating at 400KHz, and could transfer kilowatts across about half an inch at 90%+ efficiency. The MIT system operates in the 4-10 MHz band.
Being a bank in Second Life isn't very attractive to real banks, because they can't create money in Second Life, like they can in the real world.
No, tube manufacture was mechanized by the 1950s. You're looking at an outfit that makes tubes that sell for $600 each, for sale to audio nuts. Here's a 1952 article on a CRT assembly line. Vacuum tubes were made on machinery similar to that used to make light bulbs.
Did that, worked OK. Network Solutions will blacklist WHOIS queries that seem to come from a program or are too numerous. If you need bulk WHOIS data, you either have to become a registrar, make a deal with one, or buy services from "domaintools.com".
Since we run a system for filtering bottom-feeders out of search results, I've had to look at this issue.
One of the basic requirements of SiteTruth is that a web site that's selling or promoting something must have an identifiable name and address on the web site. A "contact us" form isn't good enough. Legitimate sites selling something usually have a valid name and address on the site. Commercial sites without business names and addresses are generally "bottom-feeders". They may or may not be fraudulent, but there's no way to tell, so we down-rate them and move them down in our search results. It's illegal in many jurisdictions to run a business without disclosing an address (California and EU law are quite explicit on this), and so that's a good first filter.
This filters out the bottom-feeders who aren't willing to go all the way to using a phony address. That's a felony (wire fraud or identity theft), so most sites with even a pretense of legitimacy don't go there. Those guys are crooks; no question about that. We have some blacklists to check for that sort of thing; it's usually phishing-related.
So there are three general categories - legitimate, bottom-feeder, and felony crook. The bottom-feeders are the ones Cutts is talking about. If they hadn't done some "search engine optimization", they wouldn't rank high enough in a search engine that anyone would see them. Some of the bottom-feeders are annoying, but not illegal; those are the ones that are page farms, but at least on-topic page farms. Then there are those who just have pages of irrelevant links and ads. Their natural habitat is celebrity name searches. Since they're probably violating false advertising laws, they are misdemeanor-level crooks.
When bottom-feeders go bad, it's usually via downloading hostile software as an "affiliate". See, for example, Zango. That's an ongoing problem, and McAfee's SiteAdvisor filters out those sites. Even Google is finally checking for most of the usual suspects there.
Amusingly, the bottom-feeders can't go legitimate and give a name and address without losing search engine positioning. If the same name and address shows up on a huge number of sites, Google picks that up and down-rates the sites for duplicate content. One large bottom-feeder actually has a link to a common "about" page on each of their several hundred thousand sites, but uses the "robots.txt" file to keep Google from finding it. Our SiteTruth system won't read the page in violation of the "robots.txt" file, so we downrate them for lacking a business address. They just can't win.
This is starting to look like the history of spam. In the early days of spam, as some may remember, it was viewed as a bottom-feeder marketing medium, and reasonably legitimate companies used it. The CAN-SPAM act was enacted in a form that pleased the Direct Marketing Association, but had an effect unexpected by both the DMA and anti-spam workers. The CAN-SPAM act allows spam, but only if the sender and subject are identified properly. So any "legitimate" spam is easily filtered out by spam filters. As a result, today, spam is entirely a criminal activity. We never hear about the DMA in spam discussions any more. Now it's about putting people in jail.
The same thing is happening on the web. As the filters get better, the marginal bottom-feeders don't get through, and only the out and out crooks are left. As with spam, in time we'll get rid of most of the bottom-feeders, leaving only the crooks. As the ambiguity goes away, the job of law enforcement becomes easier. That's happened with spam. There's a high-profile arrest every month or two now. Alan Ralsky just went down.
Just looked up Network-solutions-antitrust-violation-demo.com. and Network Solutions registered it.
Time for ICANN to issue a policy under the registrar agreement to enforce section 3.7.9: "Registrar shall abide by any ICANN adopted specifications or policies prohibiting or restricting warehousing of or speculation in domain names by registrars."
The real issue in programming languages is "what do you have to worry about?" They all have, in theory, equivalent power. But some languages fully handle some parts of the problem for you, and some don't. The trouble spots in different languages vary considerably.
When programming C, one has to obsess on pointer management. Storage allocation is completely manual and arrays are not only unchecked, but ambiguous in size. Most C errors are related to pointers. The language also offers almost no help in dealing with concurrency.
Java does a good job of dealing with pointers. Arrays are checked and memory is garbage-collected. So Java generally doesn't have pointer problems. The language knows a little about concurrency, but not quite enough. Java programmers can stop worrying about pointer management, but still have to worry about race conditions. Most of the problems in Jave programming relate to interfaces with large, troublesome libraries.
Ada deals well with array size issues, but storage allocation is still manual. Concurrency is addressed in a rigorous way. Ada programmers have to worry about how to structure their problem within Ada's constraints. More of the problems in Ada are at the front end in design; once the basic structure of the program is right, the pieces tend to go together well. This does not map well to "extreme programming" or "agile programming".
C++ is in the unique position of providing hiding (or "abstraction") without memory safety. No language before C++ had that combination, and no language since has had it. C++ has the same problems as C, but there's a layer of wallpaper over them. Memory errors in C++ tend to be fewer than in C, but more obscure when they occur. C++ tends to be a ritual/taboo programming language; there are many things which one must not do, and those things are not obvious.
That's a more useful way to think about the problem. Ask the question "in what ways do programs in this language break?"
Ignoring the language issue, the authors raise the question of how much math and theory should programmers have. That's worth exploring.
I'm a programmer with a strong theoretical background. I have an MSCS from Stanford, I've built a automated proof of correctness system, and I've done a physically based animation system which required building solvers for stiff systems of non-linear differential equations. I've done hard real time programming for mobile robots, network protocol design, assembly language programming, and logic board design. So I've actually used most of that theory.
Most programmers don't. If you're just doing web site back ends, you don't need all that stuff. I'm not even using much theory any more.
There's also the question of what theory to teach. I got too much discrite math and not enough number-crunching. Automata theory isn't very useful, but Bayesian statistics is. Academics can guess wrong on this. In the mid-80s, Stanford had a program to train "knowledge engineers", who were trained to write rules for expert systems. Where are they now?
There are only about 20,000 real computer science jobs in the US outside of academia. That's not the mainstream part of the field. The other 500,000 programmers don't need that much theory. Teach them Java and Python and how to work on a big project, not number theory.
I had to learn big-project work by spending years as a maintenance programmer for mainframe operating systems. Didn't get any training in school on that at all. That was a lack. Once I got that, I was able to use the theory on hard problems. I needed both kinds of training.
Here's a plan for solar power for California that could actually work.
Goal: power 100% of Southern California's air conditioning load from solar energy within eight years.
Why Southern California? Because there's enough sunlight for solar power to work well. Why air conditioning? Because peak air conditioning load and peak solar power output happen at the same time. Peak power load for all of California is about 42 gigawatts, and about a quarter of that is Southern California air conditioning. So we need about 12GW of solar panel capacity.
Technical approach. Applied Materials says they're ready to build the first "gigawatt" solar panel plant. By that they mean a plant that produces in one year enough panels to generate a gigawatt of peak power. Two such plants can make enough panels to do the job in six years. No new technology is necessary.
Paying for it Raise electric rates on hot summer afternoons. Anything bigger than a 3-bedroom house has to have time-of-day metering.
Wales was quoted recently complaining about Google's results for "Tampa hotels", and talking about how Wikia was going to be better. So I searched Wikia for "Tampa hotels".
The first three results from Wikia search are all from the domain "visit-tampa-bay.com". That's one of those bottom-feeder ad link sites. The site is supposed to redirect traffic to Orbitz, but doesn't even do that right. Very disappointing result. Could they have been spammed already?
Trying "Tampa hotels" in Google gets us "travel.yahoo.com" for the top two results, which indicates that Google isn't biasing their search against their biggest competitor. Next is "traveladvisor.com". Those are OK results; you'd be able to get a hotel room that way.
Trying "Tampa hotels" in Yahoo search gets us a page from one of Yahoo's special cases. Yahoo knows about "hotels", so we get a list of hotels and prices from Yahoo, and three sponsored results. The top organic result is "tripadvisor.com", which is at least a big-name travel site, followed by "visittampabay.com" (not to be confused with "visit-tampa-bay.com"), the site for the local Convention and Visitor's Bureau. Yahoo certainly tries hard for hotel searches, and seems to be doing OK.
Trying "Tampa hotels" in MSN search gets results that look much like Yahoo's, but with lower result quality. MSN understands hotels as a special case. There are three sponsored results, and addresses and phone numbers for three real hotels. The first three organic search results are Yahoo Travel, "tampa-hotels.net" (an ad-laden landing page), and "tampa-hotels-discounts.net" (a bottom-feeder generic landing page that isn't even on topic.) Poor results.
Trying our own SiteTruth the top result is "all-hotels.com", which has a list of hotels with pictures and a reservation interface. The second result is Yahoo Travel, and the third is Expedia. We're sorting Yahoo results on business legitimacy, so that's not surprising. OK here.
So there's where Wikia is today, on their recommended demo search.
That's so lame. If they actually leased the software, there'd be a potential tax advantage for the buyer. But no...
We've heard this before. There's a presentation in AFIPS 1966 in which someone from Control Data was saying that each metropolitan area would have one giant, shared supercomputer.
"Grid computing" was a flop commercially, once the vendors started charging for it. Sun's service is still around, but they don't talk about it much any more. That was more like an effort to find something to do with their unsold server inventory. ResPower Render Farm has a real but very specialized business, quietly rendering 3D frames for the film industry.
Amazon has been making some noise lately, but they don't promise much: "Without limitation to Section 11.5, we shall have no liability whatsoever for any damage, liabilities, losses (including any loss of data or profits) or any other consequences that you may incur as a result of any Service Suspension." Clearly they're not serious about offering a service to businesses.
There are successful services, like Salesforce, but those offer more than raw compute power.