Right now, Google ad URLs are relatively straightforward to recognize and decode. If Google
sees this as a real threat, they may start obfuscating them and using elaborate gimmickry with Javascript, like the stuff one sees in hostile web pages. Then they'll be much tougher to deal with. The easy approaches to ad blocking will stop working.
We recognize Google ad URLs in AdRater, which is a Firefox plug-in, and we put a translucent rating icon atop each ad. Google ad links are currently rather straightforward to decode, so we don't have to follow them, just examine them. For some of Google's competitors, you can't tell where the ad link is going without clicking on it. We've considered a plug-in which follows encoded ad links in the browser, but it would look like click fraud, even though it has a legitimate purpose. So far, we've refrained from doing that. If Google tries obfuscating their ad URLs, we'll have to actually traverse them to find the advertiser site for rating purposes. That increases everyone's overhead.
Iceland has far worse problems. This is a very minor issue.
Iceland's entire economy has collapsed. At one point, food imports stopped and grocery stores were empty because the country was too broke to pay for food. All the major banks and most of the major businesses have gone bankrupt.
Most of the "guest workers" have gone back to their home countries. A third of the population is considering emigrating to another country.
That some Microsoft resellers are in trouble is a minor issue. If they bought in dollars and sold in krona, without hedging against currency risk, they were currency speculators.
A similar problem exists with the SR-71's engines: some key documentation was destroyed in the interests of secrecy, which has greatly complicated maintenance work on the remaining aircraft.
Actually, the Museum of Flight, at Boeing Field in Seattle, not only has a Blackbird with a Tagboard drone, they have the engineering documentation for it. You can make an appointment and read if you like.
The reviewer seems to have a "make Israel look good" agenda. I've read the book, and didn't get the impression that it was anti-Israel. In the book, Israel is a minor side issue.
NSA did have serious problems, the most serious being irrelevancy. NSA was set up to deal with the USSR, a large, slow-moving opponent. NSA's expertise classically was in radio interception and cryptanalysis, with the main target being the USSR's military and intelligence operations. After the USSR went down, the NSA downsized. Running a vast effort to obtain basic information about what the Soviet Union was doing was no longer necessary. You could go to Murmansk and look at the nuclear submarines.
NSA's approach wasn't that helpful in dealing with small-scale non-state actors, which was the problem after 9/11. There were frantic efforts to repurpose NSA, which are well-covered in the book. These efforts were driven by the Cheney crowd, who were more concerned about accumulating power than actually dealing with real terrorists. That's well-covered too.
There's been progress. At one time, Google blurred the roof of the White House. That was just silly, and that stopped some time ago. The entire U.S. Naval Observatory area in Washington was blurred while Cheney lived there, but it's not blurred as much now. In fact, there's even a marker for "One Observatory Circle". There remains some blurring, though, and it ends just outside Observatory Circle.
The big change is that StreetView is now available for the Washington area.
But what ever happened to Moore's law? Are we already outside of its prediction? Has the chain been broken?
Effectively, yes. The problem is not cost per gate and wafer real estate per gate, which continue to decrease. It's heat dissipation per unit area. I've been to semiconductor talks where there are charts of increasing heat dissipation with lines marked "room temperature", "soldering iron", "nuclear reactor", and "surface of sun". The trend is clear and not encouraging.
The effect is that computers of equivalent power continue to get cheaper (basically, a computer now costs $299 or less) but performance is leveling off.
At the high end, a few years ago there was talk of a cyrogenic petaflop supercomputer, but the justification wasn't there. That thing would have dissipated 4KW at liquid helium temperatures, with very elaborate cooling. Just getting signals out of the liquid helium without letting heat in is tough; the I/O has to be optical.
Density continues to improve for devices that don't use much power, like flash memory. But for CPUs, we're reaching the limits.
Some fundamental limits, like the size of atoms, are not that far away, but those haven't been hit yet. There's about an order of magnitude to go.
3D devices, with more layers, are promising in terms of density, but they're not cheaper, and the heat problem gets worse.
Actually, the first digital tape drive was a custom job for Arlington Hall / National Security Agency.
There's a book on early cryptographic equipment which mentions this, but I don't have the reference handy.
I've seen a UNIVAC I in full operation, and I still have some reels of UNIVAC metal tape.
I also once had the opportunity to paw through a junked UNIVAC I in a surplus store.
The original UNISERVO used Mcintosh tube audio amplifiers to power the tape reel motors.
Actually, Bill Joy was successful because he had Government funding to give software away. Before "vi", there was the RAND Editor, which was better, but had a substantial per-seat cost.
Before Joy did a TCP implementation, there were three others, but two of them (BBN and 3COM) cost several thousand dollars per machine. It's great when you can buy market share with Government money.
Java was successful because Sun spent $20 million launching a free product. Nobody had ever done that before for a programming tool.
With read() specifically, the pointer is not necessarily to the start of the buffer.
Right. But the answer to that is not general pointer arithmetic. It's providing syntax for array slices. In newer languages, you can write something like "tab[10:20]", if you want to talk about a piece of an array. (Even the current version of FORTRAN has array slices.) That expresses what's really meant, is cheap to implement, and is checkable if desired. Pointer arithmetic is a legacy of an era when the computers were too small to support a compiler that did strength reduction. (C pointer arithmetic is almost exactly what the hardware of a PDP-11 supports.)
To my name you will find blogs praising the developments of my work area, you will find how I spend time teaching in my spare time, you will find how I am the best buddy of important figures in the field.
That can backfire. I got an e-mail from from someone who referred to "my good friend, Guy Kawasaki". So I wrote to Guy, and he wrote back "I don't even know who he is." Oops.
This isn't about "out of copyright" works. It's about works that are still under copyright, but out of print. Google effectively just bought the rights to all out of print books.
The settlement, if Court-approved, will authorize Google to scan
in-copyright Books and Inserts in the United States, and maintain
an electronic database of Books. For out-of-print Books and,
if permitted by Rightsholders of in-print Books, Google will
be able to sell access to individual Books and institutional
subscriptions to the database, place advertisements on any page
dedicated to a Book, and make other commercial uses of Books.
At any time, Rightsholders can change instructions to Google
regarding any of those uses. Through a Book Rights Registry
("Registry") established by the settlement, Google will pay
Rightsholders 63% of all revenues from these uses.
A useful way to think about troubles in language design is to ask the question "When do you have to lie to the language?" Most of the major languages have some situations in which you have to lie to the language, and that's usually a cause of bugs.
The classic example is C's "array = pointer" ambiguity. Consider
int read(int fd, char* buf, size_t len);
Think hard about "char* buf". That's not a pointer to a character. It's a pass of an array by reference. The programmer had to lie to the language because the language doesn't have a way to talk about what the programmer needed to say. That should have been
int read(int fd, byte& buf[len], size_t len);
Now the interface is correctly defined. The caller is passing an array of known size by reference.
Notice also the distinction between "byte" and "char". C and C++ lack a "byte" type, one that indicates binary data with no interpretation attached to it. Python used to be that way too, but the problem was eventually fixed; Python 3K has "unicode", "str" (ASCII text only, 0..127, no "upper code pages"), and "bytes" (uninterpreted binary data). C and C++ are still stuck with a 1970s approach to the problem.
The problem with NULL is related. Some functions accept NULL pointers, some don't, and many languages don't have syntax for the distinction. C doesn't; C++ has references, but due to backwards compatibility problems with C, they're not well handled. ("this", for example,
should have been a reference; Strostrup admits he botched that one.)
C++ supposedly disallows null references (as opposed to null pointers), but doesn't check. C++ ought to raise an exception when a null pointer is converted to a reference.
SQL does this right. A field may or may not allow NULL, and you have to specify.
Look for holes like this in language design. Where are you unable to say what you really meant? Those are language design faults and sources of bugs.
Some of the Stanford AI crowd in the 1980s were talking up a proposal for a long-term project to build robots capable of building a moon base by the year 2000. I commented at the time "How soon can you do it in Arizona?" This yielded some embarrassment.
NASA robotics efforts have had an overall negative effect on robotics as a field. They take forever, they produce one-off devices, and they suck smart people out of useful areas. JPL's rovers are really rather simple-minded devices, and are mostly teleoperated. They're just well engineered. Robotics efforts out of the NASA "centers" have generally been embarrassing.
I've read Google's paper, and I'm reasonably impressed. Basically, they've defined a little operating system, with 42 system calls, the same on all platforms, and defined a subset of 32-bit x86 machine code which can't modify itself and can't make calls to the regular OS. This requires using the seldom-used x86 segmentation hardware, which is quite clever and rarely used. But 64-bit mode has no segment machinery, so this approach doesn't translate to the current generation of 64-bit CPUs.
The biggest headache with Google's model is that they have to use a sort of interpreter to check all "ret" instructions, so someone can't clobber the stack and cause a branch to an arbitrary location. What's really needed is a CPU with a separate return point stack, accessed only by "call" and "ret" instructions, so return points are stored someplace that code can't clobber. (Machines have been built with such hardware, but there was never a compelling reason for it before.) Google has to emulate that in software. This adds a few percent of overhead.
Note that you can't use graphics hardware Google's OS. Conceptually, they could add a way to talk to OpenGL, which is reasonably secureable. But they haven't done that. They
have a Quake port, but the main CPU is doing the rendering.
Interestingly, it would be quite possible to make a very minimal operating system which ran Google's little OS directly. You don't need the gigabytes of baggage of Windows or Linux.
It would also be possible to develop an x86 variant which enforced in hardware the rules of Google's restricted code model. That would be useful. Most of the things Google's model prohibits, you don't want to do anyway. (I know, somebody who thinks they're "l33t" will have some argument that they need to do some of the stuff Google prohibits. Just say no.)
The main question is whether the implementers will have the guts to say "no" to things that people really, really want to do, but are insecure. The Java people wimped out on this; Java applets could have been secure, but in practice they trust too much library, and library bugs can be exploited.
NSA Secure Linux has a similar problem. If you turn on mandatory security and don't put any exceptions in the rules, the security is quite good. But your users will whine and applications will have to be revised to conform to the rules.
Incidentally, the people who talk about "undecidability" and "Turing completeness" in this context have no clue. It's quite possible to define a system which is both useful and decidable. (Formally, any deterministic system with finite memory is decidable; eventually you either repeat a previous state or loop. For many systems, decidability may be "hard", but that's a separate issue. If termination checking is "hard" for a loop, just add a runaway loop counter that limits the number of iterations, and termination becomes decidable again. Realistically, if you have an algorithm complex enough that termination is tough to decide, you need something like that anyway. Formal methods for this sort of thing are used routinely in modern hardware design. Anyway, none of this applies to Google's approach, which merely restricts code to a specific well-formed subset which has certain well-behaved properties.)
Everyone is so hot for Facebook these days, but a year or two ago it was all anyone could do to not jizz themselves over MySpace. These things come and go, websites get hot, then fade away.
It's not web sites, but social networks which behave like that. As I've pointed out before, social networking sites have a life cycle, just like nightclubs. They open, they may become cool and grow, they become popular, the losers move in, the cool people move out, and they decline. Has-been social networks include AOL, GeoCities, EZboard, Friendster, Salon, Nerve, Tribe, and MySpace. Alexa traffic stats bear this out; most of those peaked years ago; Myspace peaked in Q1 2008.
From an investment perspective, social networking sites have to pay off within a small number of years, or they're toast. Facebook might have gone public several years ago; now it's too late. There were, I think, two tech IPOs in 2008, and those were early in the year.
I expect that almost all the money-losing free services will disappear, or go into zombie mode like Tribe (two employees left) before the end of the year.
Zombie mode, incidentally, is the fate of many venture-funded startups. They can't make anywhere near enough money to pay off their investors, but, after shrinking, they can generate enough cash to cover their current bills.
Amusingly, nightclubs come and go, but strip clubs are forever. Similarly, dating sites have very long lives, much longer than social networks.
Definitely spin control. I remember when SCEA had to gut their research department to put all their smart people on trying to get the PS3 to do something useful.
The fundamental problem with the PS3 is that each Cell CPU only has 256K of local memory. That's not enough for a frame, not enough for the local geometry, and not enough to really get anything done. This forces you to treat the Cell processors like DSPs, pumping a sequential stream of data in one end and out the other. The Cell CPUs can sort of "random access" main memory, but that's not cached and really slow, so you don't do it much. Most accesses to main memory from a Cell are bulk DMA-like (channels, really) sequential transfers. So the whole game has to be architected as an sequential assembly-line operation, with as little cross-coupling as possible. The audio guys love this, because their problem works that way, and they get a dedicated CPU on which to do their transforms. Everybody else hates it.
If each Cell had, say, 16MB, it would be a whole different ball game.
In many PS3 games, the main PowerPC chip and the nVidia graphics chip are doing most of the work, while the Cell processors are performing output-end functions that don't feed into the game engine, like audio, particles, and such.
He's right. As an approach to volume production of hydrogen, this sucks, because the aluminum is consumed in the reaction. Remember, hydrogen and oxygen are uphill energetically from water; you're going to have to put something in to get hydrogen out. One would like that "something" to be the minimum amount of heat or electricity required to dissociate the water molecules, rather than an expensive material you have to replace.
The Slashdot story links to a blog, which links to a press release, which links to a dead link that was supposed to explain the actual chemistry. Lame.
Any group of lawyers will cost $300-500 just to talk to, as they'll have to do a conflict of interest check against their current client base, get the legal papers in line, and start the process.
You don't use a big-name law firm for routine stuff like this. There's a whole tier of lawyers who handle employment matters, domestic stuff, and minor litigation for modest fees.
Contact an employment lawyer, and have them write a "lawyer letter" along the lines of "In response to your threat to provide unfavorable references unless our client agreed not to leave your employment on (date), our client is leaving your employment immediately. Any action on your part to defame the character of our client will be dealt with appropriately". Should cost you about $100.
One of the standard legal services is writing such letters. Basically, you can pay a lawyer to write what you want in legal language and send it on the lawyer's letterhead for a modest fee. This is useful when faced with annoying threats or recalcitrant vendors.
The death of the newspaper is getting close. As the article says, is that "newspapers are fundamentally an advertising-supported medium", and they're not a very good advertising-delivery medium. They're not targeted, and they're not searchable. Classified advertising is dying.
But nobody is taking over general news reporting. Blogs don't have real reporters, just pundits. TV covers the big stories, but there's no depth.
Only a few services aimed at the investment community do real reporting and make money by selling their content.
The Wall Street Journal makes most of its money from subscriptions, not ads.
Dow Jones (the WSJ's parent) makes more revenue on line than from the print edition.
The future of news reporting is Bloomberg. Bloomberg is entirely on line, has more reporters than any newspaper in the US, and to get the good stuff in real time, hundreds of thousands of traders pay serious money. After some delay, Bloomberg puts out summaries for free.
There's still noise about "micropayments", but having watched everybody from Digicash to Cybercoin to Beenz go down, I doubt micropayments on the Internet will ever catch on. Phone-based systems, though...
Also, "crowdsourcing" a movie is a fantasy. Every once in a great while, somebody produces a good movie on a low budget, but that's rare. Roger Corman could do it, but nobody else seems to be able to bring it off.
There are successful people on LinkedIn. There's also an army of annoying losers, called
"LIONs", trolling for friend requests. These are mostly consultants and marketeers trying to use LinkedIn to spam. They get really annoyed if you click "I don't know this person", because a few of those actions turns off their ability to spam.
LinkedIn has a overreaching EULA like Facebook tried, but that's less of an issue because one can't upload much to LinkedIn.
Too many vendors are dealing with their bloated program load times by trying to make their program permanently resident in memory. Microsoft started this with IE, and it's now in Firefox, Microsoft Word, Adobe's PDF viewer, OpenOffice, and now Java. You can lose most of your RAM to bloatware that way. If you let all that stuff install, performance is worse than with none of it. Instead of loading delays, you now get paging delays and boot delays.
We need more restrictive installers. Installers for "applications" shouldn't be allowed to install a service. Windows installers for applications should be restricted to writing into "Program Files/appname" and registry keys in "HKEY_LOCAL_MACHINE/appname".
Does this thing have to be aimed at the sun? In 1D or 2D? If it needs 2 pointing axes, it's too complex. 1D, maybe; there are trough-like concentrators at Mojave which are driven to move with the sun.
Slashdot Mirror
Much as I like Adbusters, this is a headache.
Right now, Google ad URLs are relatively straightforward to recognize and decode. If Google sees this as a real threat, they may start obfuscating them and using elaborate gimmickry with Javascript, like the stuff one sees in hostile web pages. Then they'll be much tougher to deal with. The easy approaches to ad blocking will stop working.
We recognize Google ad URLs in AdRater, which is a Firefox plug-in, and we put a translucent rating icon atop each ad. Google ad links are currently rather straightforward to decode, so we don't have to follow them, just examine them. For some of Google's competitors, you can't tell where the ad link is going without clicking on it. We've considered a plug-in which follows encoded ad links in the browser, but it would look like click fraud, even though it has a legitimate purpose. So far, we've refrained from doing that. If Google tries obfuscating their ad URLs, we'll have to actually traverse them to find the advertiser site for rating purposes. That increases everyone's overhead.
has the first plants operating in 2048.
Now it's 40 years away. I remember when it was only 20 years away, around 1960.
Iceland has far worse problems. This is a very minor issue.
Iceland's entire economy has collapsed. At one point, food imports stopped and grocery stores were empty because the country was too broke to pay for food. All the major banks and most of the major businesses have gone bankrupt. Most of the "guest workers" have gone back to their home countries. A third of the population is considering emigrating to another country.
That some Microsoft resellers are in trouble is a minor issue. If they bought in dollars and sold in krona, without hedging against currency risk, they were currency speculators.
A similar problem exists with the SR-71's engines: some key documentation was destroyed in the interests of secrecy, which has greatly complicated maintenance work on the remaining aircraft.
Actually, the Museum of Flight, at Boeing Field in Seattle, not only has a Blackbird with a Tagboard drone, they have the engineering documentation for it. You can make an appointment and read if you like.
The reviewer seems to have a "make Israel look good" agenda. I've read the book, and didn't get the impression that it was anti-Israel. In the book, Israel is a minor side issue.
NSA did have serious problems, the most serious being irrelevancy. NSA was set up to deal with the USSR, a large, slow-moving opponent. NSA's expertise classically was in radio interception and cryptanalysis, with the main target being the USSR's military and intelligence operations. After the USSR went down, the NSA downsized. Running a vast effort to obtain basic information about what the Soviet Union was doing was no longer necessary. You could go to Murmansk and look at the nuclear submarines.
NSA's approach wasn't that helpful in dealing with small-scale non-state actors, which was the problem after 9/11. There were frantic efforts to repurpose NSA, which are well-covered in the book. These efforts were driven by the Cheney crowd, who were more concerned about accumulating power than actually dealing with real terrorists. That's well-covered too.
There's been progress. At one time, Google blurred the roof of the White House. That was just silly, and that stopped some time ago. The entire U.S. Naval Observatory area in Washington was blurred while Cheney lived there, but it's not blurred as much now. In fact, there's even a marker for "One Observatory Circle". There remains some blurring, though, and it ends just outside Observatory Circle.
The big change is that StreetView is now available for the Washington area.
But what ever happened to Moore's law? Are we already outside of its prediction? Has the chain been broken?
Effectively, yes. The problem is not cost per gate and wafer real estate per gate, which continue to decrease. It's heat dissipation per unit area. I've been to semiconductor talks where there are charts of increasing heat dissipation with lines marked "room temperature", "soldering iron", "nuclear reactor", and "surface of sun". The trend is clear and not encouraging.
The effect is that computers of equivalent power continue to get cheaper (basically, a computer now costs $299 or less) but performance is leveling off.
At the high end, a few years ago there was talk of a cyrogenic petaflop supercomputer, but the justification wasn't there. That thing would have dissipated 4KW at liquid helium temperatures, with very elaborate cooling. Just getting signals out of the liquid helium without letting heat in is tough; the I/O has to be optical.
Density continues to improve for devices that don't use much power, like flash memory. But for CPUs, we're reaching the limits.
Some fundamental limits, like the size of atoms, are not that far away, but those haven't been hit yet. There's about an order of magnitude to go.
3D devices, with more layers, are promising in terms of density, but they're not cheaper, and the heat problem gets worse.
Actually, the first digital tape drive was a custom job for Arlington Hall / National Security Agency. There's a book on early cryptographic equipment which mentions this, but I don't have the reference handy.
I've seen a UNIVAC I in full operation, and I still have some reels of UNIVAC metal tape. I also once had the opportunity to paw through a junked UNIVAC I in a surplus store. The original UNISERVO used Mcintosh tube audio amplifiers to power the tape reel motors.
Actually, Bill Joy was successful because he had Government funding to give software away. Before "vi", there was the RAND Editor, which was better, but had a substantial per-seat cost. Before Joy did a TCP implementation, there were three others, but two of them (BBN and 3COM) cost several thousand dollars per machine. It's great when you can buy market share with Government money.
Java was successful because Sun spent $20 million launching a free product. Nobody had ever done that before for a programming tool.
With read() specifically, the pointer is not necessarily to the start of the buffer.
Right. But the answer to that is not general pointer arithmetic. It's providing syntax for array slices. In newer languages, you can write something like "tab[10:20]", if you want to talk about a piece of an array. (Even the current version of FORTRAN has array slices.) That expresses what's really meant, is cheap to implement, and is checkable if desired. Pointer arithmetic is a legacy of an era when the computers were too small to support a compiler that did strength reduction. (C pointer arithmetic is almost exactly what the hardware of a PDP-11 supports.)
To my name you will find blogs praising the developments of my work area, you will find how I spend time teaching in my spare time, you will find how I am the best buddy of important figures in the field.
That can backfire. I got an e-mail from from someone who referred to "my good friend, Guy Kawasaki". So I wrote to Guy, and he wrote back "I don't even know who he is." Oops.
This isn't about "out of copyright" works. It's about works that are still under copyright, but out of print. Google effectively just bought the rights to all out of print books.
Here's the Author's Guild description of the deal. Authors can opt out, but only have until May 9 to do so.
These are the actual terms:
The settlement, if Court-approved, will authorize Google to scan in-copyright Books and Inserts in the United States, and maintain an electronic database of Books. For out-of-print Books and, if permitted by Rightsholders of in-print Books, Google will be able to sell access to individual Books and institutional subscriptions to the database, place advertisements on any page dedicated to a Book, and make other commercial uses of Books. At any time, Rightsholders can change instructions to Google regarding any of those uses. Through a Book Rights Registry ("Registry") established by the settlement, Google will pay Rightsholders 63% of all revenues from these uses.
A useful way to think about troubles in language design is to ask the question "When do you have to lie to the language?" Most of the major languages have some situations in which you have to lie to the language, and that's usually a cause of bugs.
The classic example is C's "array = pointer" ambiguity. Consider
int read(int fd, char* buf, size_t len);
Think hard about "char* buf". That's not a pointer to a character. It's a pass of an array by reference. The programmer had to lie to the language because the language doesn't have a way to talk about what the programmer needed to say. That should have been
int read(int fd, byte& buf[len], size_t len);
Now the interface is correctly defined. The caller is passing an array of known size by reference. Notice also the distinction between "byte" and "char". C and C++ lack a "byte" type, one that indicates binary data with no interpretation attached to it. Python used to be that way too, but the problem was eventually fixed; Python 3K has "unicode", "str" (ASCII text only, 0..127, no "upper code pages"), and "bytes" (uninterpreted binary data). C and C++ are still stuck with a 1970s approach to the problem.
The problem with NULL is related. Some functions accept NULL pointers, some don't, and many languages don't have syntax for the distinction. C doesn't; C++ has references, but due to backwards compatibility problems with C, they're not well handled. ("this", for example, should have been a reference; Strostrup admits he botched that one.) C++ supposedly disallows null references (as opposed to null pointers), but doesn't check. C++ ought to raise an exception when a null pointer is converted to a reference.
SQL does this right. A field may or may not allow NULL, and you have to specify.
Look for holes like this in language design. Where are you unable to say what you really meant? Those are language design faults and sources of bugs.
Some of the Stanford AI crowd in the 1980s were talking up a proposal for a long-term project to build robots capable of building a moon base by the year 2000. I commented at the time "How soon can you do it in Arizona?" This yielded some embarrassment.
NASA robotics efforts have had an overall negative effect on robotics as a field. They take forever, they produce one-off devices, and they suck smart people out of useful areas. JPL's rovers are really rather simple-minded devices, and are mostly teleoperated. They're just well engineered. Robotics efforts out of the NASA "centers" have generally been embarrassing.
I've read Google's paper, and I'm reasonably impressed. Basically, they've defined a little operating system, with 42 system calls, the same on all platforms, and defined a subset of 32-bit x86 machine code which can't modify itself and can't make calls to the regular OS. This requires using the seldom-used x86 segmentation hardware, which is quite clever and rarely used. But 64-bit mode has no segment machinery, so this approach doesn't translate to the current generation of 64-bit CPUs.
The biggest headache with Google's model is that they have to use a sort of interpreter to check all "ret" instructions, so someone can't clobber the stack and cause a branch to an arbitrary location. What's really needed is a CPU with a separate return point stack, accessed only by "call" and "ret" instructions, so return points are stored someplace that code can't clobber. (Machines have been built with such hardware, but there was never a compelling reason for it before.) Google has to emulate that in software. This adds a few percent of overhead.
Note that you can't use graphics hardware Google's OS. Conceptually, they could add a way to talk to OpenGL, which is reasonably secureable. But they haven't done that. They have a Quake port, but the main CPU is doing the rendering.
Interestingly, it would be quite possible to make a very minimal operating system which ran Google's little OS directly. You don't need the gigabytes of baggage of Windows or Linux.
It would also be possible to develop an x86 variant which enforced in hardware the rules of Google's restricted code model. That would be useful. Most of the things Google's model prohibits, you don't want to do anyway. (I know, somebody who thinks they're "l33t" will have some argument that they need to do some of the stuff Google prohibits. Just say no.)
The main question is whether the implementers will have the guts to say "no" to things that people really, really want to do, but are insecure. The Java people wimped out on this; Java applets could have been secure, but in practice they trust too much library, and library bugs can be exploited.
NSA Secure Linux has a similar problem. If you turn on mandatory security and don't put any exceptions in the rules, the security is quite good. But your users will whine and applications will have to be revised to conform to the rules.
Incidentally, the people who talk about "undecidability" and "Turing completeness" in this context have no clue. It's quite possible to define a system which is both useful and decidable. (Formally, any deterministic system with finite memory is decidable; eventually you either repeat a previous state or loop. For many systems, decidability may be "hard", but that's a separate issue. If termination checking is "hard" for a loop, just add a runaway loop counter that limits the number of iterations, and termination becomes decidable again. Realistically, if you have an algorithm complex enough that termination is tough to decide, you need something like that anyway. Formal methods for this sort of thing are used routinely in modern hardware design. Anyway, none of this applies to Google's approach, which merely restricts code to a specific well-formed subset which has certain well-behaved properties.)
Everyone is so hot for Facebook these days, but a year or two ago it was all anyone could do to not jizz themselves over MySpace. These things come and go, websites get hot, then fade away.
It's not web sites, but social networks which behave like that. As I've pointed out before, social networking sites have a life cycle, just like nightclubs. They open, they may become cool and grow, they become popular, the losers move in, the cool people move out, and they decline. Has-been social networks include AOL, GeoCities, EZboard, Friendster, Salon, Nerve, Tribe, and MySpace. Alexa traffic stats bear this out; most of those peaked years ago; Myspace peaked in Q1 2008.
From an investment perspective, social networking sites have to pay off within a small number of years, or they're toast. Facebook might have gone public several years ago; now it's too late. There were, I think, two tech IPOs in 2008, and those were early in the year.
I expect that almost all the money-losing free services will disappear, or go into zombie mode like Tribe (two employees left) before the end of the year.
Zombie mode, incidentally, is the fate of many venture-funded startups. They can't make anywhere near enough money to pay off their investors, but, after shrinking, they can generate enough cash to cover their current bills.
Amusingly, nightclubs come and go, but strip clubs are forever. Similarly, dating sites have very long lives, much longer than social networks.
Definitely spin control. I remember when SCEA had to gut their research department to put all their smart people on trying to get the PS3 to do something useful.
The fundamental problem with the PS3 is that each Cell CPU only has 256K of local memory. That's not enough for a frame, not enough for the local geometry, and not enough to really get anything done. This forces you to treat the Cell processors like DSPs, pumping a sequential stream of data in one end and out the other. The Cell CPUs can sort of "random access" main memory, but that's not cached and really slow, so you don't do it much. Most accesses to main memory from a Cell are bulk DMA-like (channels, really) sequential transfers. So the whole game has to be architected as an sequential assembly-line operation, with as little cross-coupling as possible. The audio guys love this, because their problem works that way, and they get a dedicated CPU on which to do their transforms. Everybody else hates it.
If each Cell had, say, 16MB, it would be a whole different ball game.
In many PS3 games, the main PowerPC chip and the nVidia graphics chip are doing most of the work, while the Cell processors are performing output-end functions that don't feed into the game engine, like audio, particles, and such.
He's right. As an approach to volume production of hydrogen, this sucks, because the aluminum is consumed in the reaction. Remember, hydrogen and oxygen are uphill energetically from water; you're going to have to put something in to get hydrogen out. One would like that "something" to be the minimum amount of heat or electricity required to dissociate the water molecules, rather than an expensive material you have to replace.
The Slashdot story links to a blog, which links to a press release, which links to a dead link that was supposed to explain the actual chemistry. Lame.
Any group of lawyers will cost $300-500 just to talk to, as they'll have to do a conflict of interest check against their current client base, get the legal papers in line, and start the process.
You don't use a big-name law firm for routine stuff like this. There's a whole tier of lawyers who handle employment matters, domestic stuff, and minor litigation for modest fees.
There's a lawyer who writes "lawyer letters" for $49.95.
Leave immediately and never go back.
Contact an employment lawyer, and have them write a "lawyer letter" along the lines of "In response to your threat to provide unfavorable references unless our client agreed not to leave your employment on (date), our client is leaving your employment immediately. Any action on your part to defame the character of our client will be dealt with appropriately". Should cost you about $100.
One of the standard legal services is writing such letters. Basically, you can pay a lawyer to write what you want in legal language and send it on the lawyer's letterhead for a modest fee. This is useful when faced with annoying threats or recalcitrant vendors.
The death of the newspaper is getting close. As the article says, is that "newspapers are fundamentally an advertising-supported medium", and they're not a very good advertising-delivery medium. They're not targeted, and they're not searchable. Classified advertising is dying.
But nobody is taking over general news reporting. Blogs don't have real reporters, just pundits. TV covers the big stories, but there's no depth.
Only a few services aimed at the investment community do real reporting and make money by selling their content. The Wall Street Journal makes most of its money from subscriptions, not ads. Dow Jones (the WSJ's parent) makes more revenue on line than from the print edition. The future of news reporting is Bloomberg. Bloomberg is entirely on line, has more reporters than any newspaper in the US, and to get the good stuff in real time, hundreds of thousands of traders pay serious money. After some delay, Bloomberg puts out summaries for free.
There's still noise about "micropayments", but having watched everybody from Digicash to Cybercoin to Beenz go down, I doubt micropayments on the Internet will ever catch on. Phone-based systems, though...
Also, "crowdsourcing" a movie is a fantasy. Every once in a great while, somebody produces a good movie on a low budget, but that's rare. Roger Corman could do it, but nobody else seems to be able to bring it off.
There are successful people on LinkedIn. There's also an army of annoying losers, called "LIONs", trolling for friend requests. These are mostly consultants and marketeers trying to use LinkedIn to spam. They get really annoyed if you click "I don't know this person", because a few of those actions turns off their ability to spam.
LinkedIn has a overreaching EULA like Facebook tried, but that's less of an issue because one can't upload much to LinkedIn.
Too many vendors are dealing with their bloated program load times by trying to make their program permanently resident in memory. Microsoft started this with IE, and it's now in Firefox, Microsoft Word, Adobe's PDF viewer, OpenOffice, and now Java. You can lose most of your RAM to bloatware that way. If you let all that stuff install, performance is worse than with none of it. Instead of loading delays, you now get paging delays and boot delays.
We need more restrictive installers. Installers for "applications" shouldn't be allowed to install a service. Windows installers for applications should be restricted to writing into "Program Files/appname" and registry keys in "HKEY_LOCAL_MACHINE/appname".
Does this thing have to be aimed at the sun? In 1D or 2D? If it needs 2 pointing axes, it's too complex. 1D, maybe; there are trough-like concentrators at Mojave which are driven to move with the sun.
Some well-known sites are just hanging on, with almost no staff. Tribe is down to two employees.
The most active "tribe" is "Tribe.net bug reports".