Yes and no. Google AdSense is a way to add ads to any web page, and Google makes a lot of profit on those things. If the search engine were to suddenly disappear tomorrow, Google would be seriously hurting, but they'd still be selling a lot of ads.
If you buy Google search ads, Google tries hard to also sell you ads on other pages. Those are far less valuable than search ads. Search ads appear when a user is actively looking for something, the best time to present an ad. Ads on other pages are just annoyances upon which someone might click, and probably won't buy from.
There are now four or five e-book readers, each with their own incompatible "ecosystem". Until that settles down, don't get one. Most of them are going to fail, and you'll lose your content. Just like the people who signed up for WalMart Music or Microsoft PlaysForSure.
The structure of where things are stored in the registry is also an issue.
Which is the real problem. The use of the thing needs to be more structured if it's to be secure. This means getting applications to conform to some standards on what goes where. Windows applications are terrible at that. There are standards on where programs, application data, and temporary files are supposed to go, but they're not consistently enforced. Security requires some mandatory simplicity for things like this. (This, by the way, is why access control lists aren't very useful. They can express any security model, with enough work, work that never gets done.)
Google doesn't need that many more smart technical people. What they could use some people who could figure out something other than ads that people would actually pay for. Their track record in actual products is awful. The overpriced "Google Search Appliance" isn't doing well.
They do corporate hosted mailboxes, but that's Postini, which they bought.
Google is really an ad agency. That's where the money comes from.
Actually, the Registry is a good concept. The Registry is just a file system for little data items. The trouble is that any application can write to any part of it. It lacks a security model. (Yes, you can attach security restrictions to registry keys, but nobody does this, because Windows 95 didn't have that, and applications didn't have support for it.)
The big problem with Windows security is Microsoft never put a security model in place under the concept of program installation. The way this ought to work is that there should be several classes of things one can install. Call them "applications", "plugins", "middleware", and "system modifications".
Installers of "applications" should be limited to writing to the application's subtrees in Program Files, Documents and Settings, and the Registry. Uninstalling an application consists of removing those subtrees. Applications cannot install anything that runs at startup or runs periodically. Most programs (especially games and entertainment apps) should be applications. Under these restrictions, installation of applications is relatively safe, and should be allowed with Power User privileges.
"Plugins" are sub-applications which affect one application. They go in their own subtree under the appropriate application. The application controls their installation, and they can't do anything the application can't do.
Browser plug-ins fall in this category if the browser is an "application". If the browser is "middleware" (IE is, but Firefox is not), more privileges are required.
"Middleware" is programs run by other programs, like Java. Changing middleware can affect multiple applications, so that requires more privileges. Code signing is appropriate.
"System modifications", which modify the OS itself and may require a reboot, should require both code signing by a clearly identified party and administrator privileges to install.
Of course, if we had something like that, app developers would bitch that they couldn't load their "phone home for update" service or "prelauncher". Tough. You don't really need to know if ZowieApp needs an update until you run ZowieApp again. And if your app needs to be "prelaunched" because it loads slowly, maybe the problem is that it loads slowly.
A 45 year old typewriter looks good on display and most probably still types perfectly well. A 45 year old Dell will be a pile of plastic dust with an exploded lithium battery.
Painfully true. Restoring old computers is incredibly difficult. The sad thing about the Computer Museum in Silicon Valley is that almost nothing works. They've succeeded in restoring two IBM 1401 computers, but they had several of the original design team available. None of the their early personal computers are displayed as working devices.
On the other hand, I have a Teletype Model 15, designed in 1930 and built during WWII, working. I've even interfaced it to RSS and SMS feeds. Those machines were very well designed, overbuilt, and can run for decades if properly maintained. All mine needed was a thorough cleaning and oiling. All the metal is high quality steel. The main frame parts are steel castings, and all stamped parts are from stock at least 1/16 thick. And the machine has over 500 oiling points, ranging from a dozen oil reservoirs with spring-loaded caps to hundreds of points that just need a drop of oil.
Don't overrate mechanical nostalgia, though.
Most consumer mechanical devices of that period were not very good. Many contain "pot metal", with a composition so awful that parts shatter if dropped, or simply with age. Early low-end wiring materials didn't last. Early plastics became brittle with age. Those gadgets were discarded long ago. The ones still around are the good ones.
The USPS should offer RecycleDirect service. With RecycleDirect, you specify which classes of mail are automatically forwarded to the regional mixed paper recycling center nearest the sender. RecycleDirect mail will be diverted at the first sorting post office directly to the recycling center.
Military avionics has had very directed cooling for years. Cool air is a scarce resource in field systems. Here's an engineered cooling system for VME boards. Military PC boards tend to have covers over the components. ("When someone is fixing your system, it's too hot, too cold, too dusty, or too wet, and someone may be shooting at them." - a reminder given military hardware designers.) Those covers can be designed to direct airflow. The covers then plug into an air plenum which feeds air into the covers.
The military designs go much further than civilian ones do. They'll use heavier copper on boards to improve conduction, and mounting rails designed to dissipate heat from the board into the chassis frame. The whole thing is designed so that somebody just slams the module into the rack and turns the locking handle without worrying about this.
I've mentioned the ad bottleneck before. Slashdot is an especially bad offender. Pages use several ad servers, and they use "document.write" to stall the page load until the ad comes up. Even if you have the ad images blocked, some of the junk JavaScript still needs to run.
Some sites are just slow at serving pages. Behind my SiteTruth system there is a specialized web crawler which looks for a business name and address on each web site. It never looks at more than 20 pages, and it's looking for pages like "About", "Contact", and about 40 other words which might plausibly lead to contact info. This process runs about 5-15 seconds for a well-implemented site. I log sites where it takes more than 45 seconds. About 5-10% of sites run overtime. In the last hour, the slowest site is "www.airsmaxkey.com", at 159 seconds to read 10 pages. (Yes, they're a bottom-feeder. Not only is there no business address on the site (a criminal offense in the European Union), they have logos from Verisign, PayPay, Verified by Visa, and MasterCard SecureCode, none of which are actually clickable to do the claimed verification. Nor does their shopping cart checkout use SSL. The whole site may be a scam. SiteTruth gives them a "Do Not Enter" rating.)
Some of the social networking sites have so much Javascript that Firefox will time out. (Facebook had that problem for a while. They fixed it.)
Why this facility isn't included as standard on every system is a mystery to me.
Probably because it makes builds 10% slower when the content isn't in cache.
For many purposes, especially archiving, it would be useful if file systems maintained a hash of each file, at least for "unit files", those written sequentially and never changed without a full rewrite. There was a discussion about a month ago about file systems which merged duplicate files that way. If you could just ask the file system for the hash, instead of reading the whole file to get it, file-has-changed checks would go really fast.
The real problem is the need for excessive weight reduction. This makes big spacecraft too fragile. If the Shuttle could afford the weight of a titanium skin, instead of fragile foam and tiles, it would be far less troublesome.
The best US spacecraft was probably the Gemini, which was Gus Grissom's baby, the Gusmobile. He designed the fighter pilot's spacecraft, the most maneuverable spacecraft to date. A Big Gemini, a 9-passenger version, made it to the mockup stage. If that had been built, the US would have had something comparable to Soyuz. Better, probably. It's striking that the US hasn't had a little spacecraft to send to orbit since the 1960s.
Grissom died in the 1967 pad fire, and nobody else had the clout to push the Gemini program forward after that.
Ask yourself why we have "builds", where everything gets rebuilt. Do I have to have my ICs re-fabbed when I change the PC board design? No. We're still not doing components right.
Historically, the big problem came from C include files. Everything but the kitchen sink is in there. There's no language-enforced separation between interface (the parts clients of the module see and may have to recompile if changed) and implementation (the part the implementations see). Also, you can include files inside include files, even conditionally. So developing the dependency graph of the program is hard.
C++ made things worse, not better. The private methods of a C++ class have to appear in the header file, which exposes more of the internals than is really necessary. Every time you add a new private method, the clients, who can never see or use that private method, have to be recompiled. This not only produces cascading builds, it discourages programmers from adding new private methods rather than bloating existing ones. That's bad for code readability and reliability.
Ada explicitly dealt with this. Ada has a hard separation between interface and implementation. This was considered a headache when Ada came out, but now that everyone has bigger monitors, it's less of an issue.
Java, despite having interfaces, seems to have build and packaging systems of grossly excessive complexity. I'm not really sure why.
The next problem is the "make" mindset, which is built on timestamps. "make" doesn't check what changed; it checks was was "touched". If "make" decided what had changed based on hashes, rather than timestamps, many unnecessary recompiles would be avoided. Something could run "autoconf", produce exactly the same result as last time, and not trigger vast numbers of recompiles.
There's also the tendency to treat "make" as a macro language rather than a dependency graph. This results in makefiles that always recompile, rather than only recompile what's needed.
It would be useful if compilers output, in the object file, a list of every file they read during the compile, with a crypto grade hash (MD5, etc.) of each. A hash of the compile options and the compiler version would also be included. Then you could tell, reliably, if you really needed to rebuild something.
That was a long time ago. And the important part was the "Bell Labs".
I got to see many of the famous great R&D places in their glory days: Bell Labs, Xerox PARC, HP Labs, DEC WRL and SRL, Ford Scientific Research Center, IBM Almaden Research. They're all gone now, or a pale shadow of what they once were. Microsoft and Google still have real R&D operations, but that's about it for big corporate labs in computer science.
I keep being told by.NET people it's really not that heavy and it much more productive etc etc.
I feel the same way about Python. CPython is a naive interpreter, one of the few used for serious programming. Even Javascript has JIT compilers now. Not only that, on a multicore CPU, each CPython process runs slower, due to badly designed fighting over the global interpreter lock.
If CPython didn't suck so bad at performance, Google wouldn't have had to write "Go". Sad.
That's called "simultaneous location and mapping", and in the last five years, good algorithms have been developed and quite a few systems are more or less working. Search for "Visual SLAM".
The Samsung Hauzen vacuum cleaner uses Visual SLAM. There's a video. This is way ahead of the blundering Roomba.
Facebook is also converting over to solid state drives. They will have relatively low power consumption per board. Putting both flash chips and a backup battery on each board makes sense.
The big search engines remain too "soft" on bottom-feeders. Google once took a harder line. In 2004 and 2005, Google sponsored the Web Spam Summit. Then they had a down quarter and turned to the dark side. Since then, from 2006 to 2009, they've sponsored the Search Engine Strategies conference, the web spammer's convention.
Google has to do this to remain profitable. 35% of AdWords advertisers, by domain, are "bottom-feeders" - sites with no identifiable legitimate business behind them. A significant portion of Google's revenue comes from those bottom-feeders, and the AdWords ads on their sites. If Google filtered out all spam blogs, their revenue would decline.
We, of course, run SiteTruth, as a demo to show that search can have less evil. Try putting some of those "bad" sites into SiteTruth and see how it rates them.
(We get some whining, of course. "I wanna run ads on my blog and I don't wanna say who I am." Tough. You're operating a business, and businesses, by law, don't get to be anonymous. Even in the EU. Deal with it.)
An "English-like syntax" won't help. It's been tried, starting with COBOL-60. Things to look up: "The Last One", "ZoomRacks", "HyperCard". The programming language of HyperCard, HyperTalk, was amazingly similar to COBOL-60.
But that's not the right question. The question is, can programming be made easier by having the computer help the user more? Not with command completion or syntax coloring, but with something that has more of a clue about what the user is trying to do.
It's worth realizing that spreadsheets are the predominant "user programming" system. Within their domain, they're straightforward.
I'd be a lot more impressed if there was a button to push for "report fraud", with at least as much effort behind it.
After all, by dollar volume, most crime is on line now. Breaking into houses is so last-cen. (TVs are now either too big to carry or too worthless to bother. Used furniture, clothes, and appliances have near zero value. And who has expensive jewelry any more?) Stealing cars is getting hard; the vehicle electronics won't cooperate and may fight back. Robbing banks just gets you a very short career on TV. But financial fraud is at an all-time high.
Slashdot Mirror
Cartridge World wasn't what I expected. They don' sell ammo.
Yes and no. Google AdSense is a way to add ads to any web page, and Google makes a lot of profit on those things. If the search engine were to suddenly disappear tomorrow, Google would be seriously hurting, but they'd still be selling a lot of ads.
If you buy Google search ads, Google tries hard to also sell you ads on other pages. Those are far less valuable than search ads. Search ads appear when a user is actively looking for something, the best time to present an ad. Ads on other pages are just annoyances upon which someone might click, and probably won't buy from.
There are now four or five e-book readers, each with their own incompatible "ecosystem". Until that settles down, don't get one. Most of them are going to fail, and you'll lose your content. Just like the people who signed up for WalMart Music or Microsoft PlaysForSure.
The structure of where things are stored in the registry is also an issue.
Which is the real problem. The use of the thing needs to be more structured if it's to be secure. This means getting applications to conform to some standards on what goes where. Windows applications are terrible at that. There are standards on where programs, application data, and temporary files are supposed to go, but they're not consistently enforced. Security requires some mandatory simplicity for things like this. (This, by the way, is why access control lists aren't very useful. They can express any security model, with enough work, work that never gets done.)
Google doesn't need that many more smart technical people. What they could use some people who could figure out something other than ads that people would actually pay for. Their track record in actual products is awful. The overpriced "Google Search Appliance" isn't doing well. They do corporate hosted mailboxes, but that's Postini, which they bought.
Google is really an ad agency. That's where the money comes from.
The Registry uses ACLs, just like the file system.
The Windows 95 line didn't have ACLs, and most XP apps have their roots in Windows 95, not Windows NT.
NASA needs to focus. They act like they're the National Science Foundation. They shouldn't be doing general R&D.
Actually, the Registry is a good concept. The Registry is just a file system for little data items. The trouble is that any application can write to any part of it. It lacks a security model. (Yes, you can attach security restrictions to registry keys, but nobody does this, because Windows 95 didn't have that, and applications didn't have support for it.)
The big problem with Windows security is Microsoft never put a security model in place under the concept of program installation. The way this ought to work is that there should be several classes of things one can install. Call them "applications", "plugins", "middleware", and "system modifications".
Installers of "applications" should be limited to writing to the application's subtrees in Program Files, Documents and Settings, and the Registry. Uninstalling an application consists of removing those subtrees. Applications cannot install anything that runs at startup or runs periodically. Most programs (especially games and entertainment apps) should be applications. Under these restrictions, installation of applications is relatively safe, and should be allowed with Power User privileges.
"Plugins" are sub-applications which affect one application. They go in their own subtree under the appropriate application. The application controls their installation, and they can't do anything the application can't do. Browser plug-ins fall in this category if the browser is an "application". If the browser is "middleware" (IE is, but Firefox is not), more privileges are required.
"Middleware" is programs run by other programs, like Java. Changing middleware can affect multiple applications, so that requires more privileges. Code signing is appropriate.
"System modifications", which modify the OS itself and may require a reboot, should require both code signing by a clearly identified party and administrator privileges to install.
Of course, if we had something like that, app developers would bitch that they couldn't load their "phone home for update" service or "prelauncher". Tough. You don't really need to know if ZowieApp needs an update until you run ZowieApp again. And if your app needs to be "prelaunched" because it loads slowly, maybe the problem is that it loads slowly.
I've read through the two links, and I'm amazed at the level of attention spent on the work.
It's just cleaning and oiling, and building some interface electronics. It's not like I had to machine replacement parts.
Now, the steampunk case mod for it - that requires machining parts. I have a membership at TechShop in Menlo Park for that sort of thing.
A 45 year old typewriter looks good on display and most probably still types perfectly well. A 45 year old Dell will be a pile of plastic dust with an exploded lithium battery.
Painfully true. Restoring old computers is incredibly difficult. The sad thing about the Computer Museum in Silicon Valley is that almost nothing works. They've succeeded in restoring two IBM 1401 computers, but they had several of the original design team available. None of the their early personal computers are displayed as working devices.
On the other hand, I have a Teletype Model 15, designed in 1930 and built during WWII, working. I've even interfaced it to RSS and SMS feeds. Those machines were very well designed, overbuilt, and can run for decades if properly maintained. All mine needed was a thorough cleaning and oiling. All the metal is high quality steel. The main frame parts are steel castings, and all stamped parts are from stock at least 1/16 thick. And the machine has over 500 oiling points, ranging from a dozen oil reservoirs with spring-loaded caps to hundreds of points that just need a drop of oil.
Don't overrate mechanical nostalgia, though. Most consumer mechanical devices of that period were not very good. Many contain "pot metal", with a composition so awful that parts shatter if dropped, or simply with age. Early low-end wiring materials didn't last. Early plastics became brittle with age. Those gadgets were discarded long ago. The ones still around are the good ones.
spam is an economic problem
No, it's not. Not since all the ways to do it without committing felonies were stopped. Spamming today is organized crime.
The USPS should offer RecycleDirect service. With RecycleDirect, you specify which classes of mail are automatically forwarded to the regional mixed paper recycling center nearest the sender. RecycleDirect mail will be diverted at the first sorting post office directly to the recycling center.
Military avionics has had very directed cooling for years. Cool air is a scarce resource in field systems. Here's an engineered cooling system for VME boards. Military PC boards tend to have covers over the components. ("When someone is fixing your system, it's too hot, too cold, too dusty, or too wet, and someone may be shooting at them." - a reminder given military hardware designers.) Those covers can be designed to direct airflow. The covers then plug into an air plenum which feeds air into the covers.
The military designs go much further than civilian ones do. They'll use heavier copper on boards to improve conduction, and mounting rails designed to dissipate heat from the board into the chassis frame. The whole thing is designed so that somebody just slams the module into the rack and turns the locking handle without worrying about this.
I've mentioned the ad bottleneck before. Slashdot is an especially bad offender. Pages use several ad servers, and they use "document.write" to stall the page load until the ad comes up. Even if you have the ad images blocked, some of the junk JavaScript still needs to run.
Some sites are just slow at serving pages. Behind my SiteTruth system there is a specialized web crawler which looks for a business name and address on each web site. It never looks at more than 20 pages, and it's looking for pages like "About", "Contact", and about 40 other words which might plausibly lead to contact info. This process runs about 5-15 seconds for a well-implemented site. I log sites where it takes more than 45 seconds. About 5-10% of sites run overtime. In the last hour, the slowest site is "www.airsmaxkey.com", at 159 seconds to read 10 pages. (Yes, they're a bottom-feeder. Not only is there no business address on the site (a criminal offense in the European Union), they have logos from Verisign, PayPay, Verified by Visa, and MasterCard SecureCode, none of which are actually clickable to do the claimed verification. Nor does their shopping cart checkout use SSL. The whole site may be a scam. SiteTruth gives them a "Do Not Enter" rating.)
Some of the social networking sites have so much Javascript that Firefox will time out. (Facebook had that problem for a while. They fixed it.)
Why this facility isn't included as standard on every system is a mystery to me.
Probably because it makes builds 10% slower when the content isn't in cache.
For many purposes, especially archiving, it would be useful if file systems maintained a hash of each file, at least for "unit files", those written sequentially and never changed without a full rewrite. There was a discussion about a month ago about file systems which merged duplicate files that way. If you could just ask the file system for the hash, instead of reading the whole file to get it, file-has-changed checks would go really fast.
The real problem is the need for excessive weight reduction. This makes big spacecraft too fragile. If the Shuttle could afford the weight of a titanium skin, instead of fragile foam and tiles, it would be far less troublesome.
The best US spacecraft was probably the Gemini, which was Gus Grissom's baby, the Gusmobile. He designed the fighter pilot's spacecraft, the most maneuverable spacecraft to date. A Big Gemini, a 9-passenger version, made it to the mockup stage. If that had been built, the US would have had something comparable to Soyuz. Better, probably. It's striking that the US hasn't had a little spacecraft to send to orbit since the 1960s.
Grissom died in the 1967 pad fire, and nobody else had the clout to push the Gemini program forward after that.
Ask yourself why we have "builds", where everything gets rebuilt. Do I have to have my ICs re-fabbed when I change the PC board design? No. We're still not doing components right.
Historically, the big problem came from C include files. Everything but the kitchen sink is in there. There's no language-enforced separation between interface (the parts clients of the module see and may have to recompile if changed) and implementation (the part the implementations see). Also, you can include files inside include files, even conditionally. So developing the dependency graph of the program is hard.
C++ made things worse, not better. The private methods of a C++ class have to appear in the header file, which exposes more of the internals than is really necessary. Every time you add a new private method, the clients, who can never see or use that private method, have to be recompiled. This not only produces cascading builds, it discourages programmers from adding new private methods rather than bloating existing ones. That's bad for code readability and reliability.
Ada explicitly dealt with this. Ada has a hard separation between interface and implementation. This was considered a headache when Ada came out, but now that everyone has bigger monitors, it's less of an issue.
Java, despite having interfaces, seems to have build and packaging systems of grossly excessive complexity. I'm not really sure why.
The next problem is the "make" mindset, which is built on timestamps. "make" doesn't check what changed; it checks was was "touched". If "make" decided what had changed based on hashes, rather than timestamps, many unnecessary recompiles would be avoided. Something could run "autoconf", produce exactly the same result as last time, and not trigger vast numbers of recompiles.
There's also the tendency to treat "make" as a macro language rather than a dependency graph. This results in makefiles that always recompile, rather than only recompile what's needed.
It would be useful if compilers output, in the object file, a list of every file they read during the compile, with a crypto grade hash (MD5, etc.) of each. A hash of the compile options and the compiler version would also be included. Then you could tell, reliably, if you really needed to rebuild something.
That's THE title at Bell Labs.
That was a long time ago. And the important part was the "Bell Labs".
I got to see many of the famous great R&D places in their glory days: Bell Labs, Xerox PARC, HP Labs, DEC WRL and SRL, Ford Scientific Research Center, IBM Almaden Research. They're all gone now, or a pale shadow of what they once were. Microsoft and Google still have real R&D operations, but that's about it for big corporate labs in computer science.
I keep being told by .NET people it's really not that heavy and it much more productive etc etc.
I feel the same way about Python. CPython is a naive interpreter, one of the few used for serious programming. Even Javascript has JIT compilers now. Not only that, on a multicore CPU, each CPython process runs slower, due to badly designed fighting over the global interpreter lock.
If CPython didn't suck so bad at performance, Google wouldn't have had to write "Go". Sad.
That's called "simultaneous location and mapping", and in the last five years, good algorithms have been developed and quite a few systems are more or less working. Search for "Visual SLAM".
The Samsung Hauzen vacuum cleaner uses Visual SLAM. There's a video. This is way ahead of the blundering Roomba.
You're only looking at a very small subset of examples which agree with your conclusion. That's not exactly a convincing argument.
I didn't pick them. Those were simply the first six articles on the "New Pages" list on Wikipedia when I wrote the note.
Facebook is also converting over to solid state drives. They will have relatively low power consumption per board. Putting both flash chips and a backup battery on each board makes sense.
The big search engines remain too "soft" on bottom-feeders. Google once took a harder line. In 2004 and 2005, Google sponsored the Web Spam Summit. Then they had a down quarter and turned to the dark side. Since then, from 2006 to 2009, they've sponsored the Search Engine Strategies conference, the web spammer's convention.
Google has to do this to remain profitable. 35% of AdWords advertisers, by domain, are "bottom-feeders" - sites with no identifiable legitimate business behind them. A significant portion of Google's revenue comes from those bottom-feeders, and the AdWords ads on their sites. If Google filtered out all spam blogs, their revenue would decline.
We, of course, run SiteTruth, as a demo to show that search can have less evil. Try putting some of those "bad" sites into SiteTruth and see how it rates them.
(We get some whining, of course. "I wanna run ads on my blog and I don't wanna say who I am." Tough. You're operating a business, and businesses, by law, don't get to be anonymous. Even in the EU. Deal with it.)
An "English-like syntax" won't help. It's been tried, starting with COBOL-60. Things to look up: "The Last One", "ZoomRacks", "HyperCard". The programming language of HyperCard, HyperTalk, was amazingly similar to COBOL-60.
But that's not the right question. The question is, can programming be made easier by having the computer help the user more? Not with command completion or syntax coloring, but with something that has more of a clue about what the user is trying to do.
It's worth realizing that spreadsheets are the predominant "user programming" system. Within their domain, they're straightforward.
I'd be a lot more impressed if there was a button to push for "report fraud", with at least as much effort behind it. After all, by dollar volume, most crime is on line now. Breaking into houses is so last-cen. (TVs are now either too big to carry or too worthless to bother. Used furniture, clothes, and appliances have near zero value. And who has expensive jewelry any more?) Stealing cars is getting hard; the vehicle electronics won't cooperate and may fight back. Robbing banks just gets you a very short career on TV. But financial fraud is at an all-time high.