The braking from supersonic phase is going to be interesting.
Ordinary parachuting maxes out around 200km/h. Back in the 1960s, the last time a 100,000+ foot jump was tried, someone hit 998km/h. They did not have an easy ride down.
It seems late to be going to Google to do research. Five years ago, yes. Today, no. Google's innovations lately all seem to involve more intrusive advertising.
I hope Google keeps funding the automatic driving effort. At least until some auto manufacturer picks it up. They're getting close to something usable. Now they need to switch from that rotating car-top Velodyne kludge LIDAR to multiple flash LIDARs like Advanced Scientific Concepts makes, and get the size and price down.
Is there any reliable source of data that rates company policies against some objective criterion? Something that's not just an unsorted collection of complaints or anecdotes? There's EULAlyzer, which tries to do this by recognizing stock phrases. Anything else?
Incidentally, Netflix won't even let you read their EULA unless you let them plant a cookie. That's tacky,
If I could find something like that, I'd put it in SiteTruth, and have it appear when you mouse over a link or search result. Currently we report the location of the business and, when available, the annual revenue and number of employees, with links to SEC and BBB reports. The goal is to provide consumers with data that allows them to tell how legitimate the company is. Data that doesn't come from the company. (Or from their social spammers. Most favorable crowd-sourced "reviews" are now solicited, if not outright fake.)
Donald Knuth made this point in 1971, in his Empircal Study of Fortran Programs - virtually none of most programs has any significant effect on performance.
That's much less true than it used to be. In batch number-crunching programs (which is what people wrote in FORTRAN), there are typically inner loops that use most of the CPU time. However, a browser, a window system, a parser, an OS, or a GUI application usually has a much flatter profile. Then the speed of the language matters.
Says the guy whose whole life is tied up in the language, and whose project, at Google, to speed it up, crashed and burned.
Python is slow because von Rossum refuses to cut loose the boat-anchor of "anything can change anything at any time". The straightforward implementation of Python, CPython, boxes all numbers (everything is a CObject, including an int or a float) and looks up functions, attributes, and such in a dictionary for every reference. And only one thread is allowed to run at a time. This allows one thread to dynamically patch the objects and code of another thread. Which is cool, but useless. 99.99+% of the time, there's no need for a dynamic lookup. Most program dynamism is shortly after program startup - once things are running, they don't change much. If, sometime shortly after startup, the program said "OK, done with self-modification", at which point a JIT compiler did its thing, the language would be much faster. But no. That's "un-Pythonic".
PyPy, the newer Python implementation, uses two interpreters and a JIT compiler to try to handle the dynamism with less overhead. They're making progress, but they need a very complex implementation to do it, and they're many years behind schedule.
Python, as a language, is very usable. But it's too slow for volume production. That's not inherent in the basic language. Python could remain declaration-free if there were just a few more restrictions on unexpected dynamism. By this is meant ways the program can change itself that aren't obvious from looking at the source code. For example, if a module or class could only be modified from outside itself if it contained explicit self-modification code (like a relevant "setattr" call) most modules and classes could be nailed down as fixed, "slotted" objects at compile time. The other big win is using enough type inference to decide if a variable can always be represented as a machine type (int, float, char, bool, etc.). That's a huge performance win.
Claiming that the "slow parts" should be rewritten in C is a cop-out. It makes the program more fragile, since C code can break Python's memory safety. Except for number-crunching, or glue code for existing libraries, it's seldom done.
(I have a Python program running right now which will run for over a week, parsing the street address of every business in the US into a standard format. The parser is complex enough that rewriting it in C would be a big job. There's no "inner loop".)
"Java was supposed to be the programming language of the Web." - Given that most enterprise applications have web interfaces, it's not a real miss.
Sun was thinking client-side Java. "Applets", running in the browser. Then they were thinking desktop Java, with user applications written in Java. Server side Java came much later.
That's why Java has that whole byte-code interpreter thing. Java is a hard-compilable language; there's a GCC implementation that generates machine code. The whole point of the byte-code thing was to make the downloads to the user's browser fast and processor-independent. "Write once, run everywhere" is a client side issue, not a server side issue.
Google created an invisible form on a web page and then simulated a click on to bypass Safari's privacy controls. That didn't happen by accident. That's hostile code.
Safari treated a "submit" action as permission for the site to plant a cookie. It's hard to stop that in the browser without breaking some legitimate forms. As a result of this, all web forms which want to trigger a cookie event may have to have explicit "submit" buttons.
Java succeeded because Sun 1) gave it away, and 2) threw money at giving it away. Remember "applets"? Java was supposed to be the programming language of the Web. That didn't work out. It ended up being the new COBOL, which was not Sun's intent.
Some languages fail, or get stuck, because the designer is in love with their own implementation. That happened to Pascal and Python. Wirth's own Pascal implementation was a cute little recursive-descent compiler that generated RPN byte codes, like a Java compiler. Wirth resisted changes to the language that would allow programming in the large. ISO Pascal reflects his biases. So Pascal became stuck in an educational niche. The original Macintosh software was all written in an extended Pascal, as was much '80s software. But everybody had a different dialect - there was Turbo Pascal, Clascal, and a few others. They never merged.
Modula, Wirth's second try, was also crippled in certain ways. Modula 2 was better. Modula 3 was good enough to be used to write an operating system kernel. Unfortunately, Modula 3 was only used with DEC, which died after being acquired by Compaq.
Python has some of the same problems. The feature set of Python reflects what it's easy to implement in a naive interpreter, like von Rossum's CPython. Internally, everything is an object, even integers and floats, and object access involves dictionary lookups. This makes CPython slow. Every attempt to speed up Python substantially has hit a wall, including Google's "Unladen Swallow" effort. (PyPy is making progress, but it's taken a decade and requires an incredibly complex internal combination of interpreters and compilers.)
The biggest disappointment to me has been that we're still stuck with C. C has two killer bad design decisions - the language doesn't know how big arrays are, and the "pointer=array" thing lies to the language. Both reflect how things are done in assembler, and the fact that the original compiler had to fit in a 128K PDP-11. Most of the millions of buffer overflows and crashes that occur daily can be traced to those two design decisions. (C++, as I point out occasional, tries to paper over these problems with collection classes. But the mold usually seeps through the wallpaper, since most operating system and library calls want raw C pointers.)
Regardless of what the founder believes, Wikipedia should have monetized the website with the "subtle" use of advertising which would have generated billions in revenue over the past decade.
Nah. Wikipedia relies on volunteers. If they were a business, they'd have to pay people. If they ran ads, there would be pressure to suck up to advertisers.
Look at Wikia. It's mostly fancruft, with the Star [Trek|Wars|Gate|Craft] wikis. That's what a pay version of Wikipedia looks like.
Well heaven forbid you actually train someone to do it. That's why you can't find anybody, every company wants instant gratification with no work.
Exactly. Find someone who understands some modern low level electrical interfaces, like USB. Expect them to take about a month to pick up each new one (old one, actually) you need.
(What's 1-wire being used for? Most of the "key" type applications have been superseded by some kind of RFID tag. Anyone still have a Java Button?)
The "transmitter" uses the Fermilab accelerator ring to generate neutrinos. 6km of particle accelerator.
The "receiver" is a neutrino detector the size of a large house.
The data rate is so low that it took 20 minutes to transmit one word.
Neutrinos still interact with other particles very infrequently. These researchers have no way around that. They just used a very powerful beam and a huge detector to pick up the very rare events. It's a stunt, not an advance.
Yes, Google has been sending out notifications encouraging sites to fill more of the screen with Google ads. I'm trying to find the link where someone reported getting a notification that they should put more ads on their page, because they had less than 3 "ad units". That included the "heat map" referenced above. I haven't found that yet, but I found this Google video "Monetize your content". "Ideally, every page on your site should have some form of AdSense on it". Yes, the Google sales rep actually says that.
In related news, Google is dropping their "domain parking" business, where Google hosts ad-filled pages for parked domains. Not because domain parking is evil. They're just outsourcing the hosting. Google suggest using another domain-parking company like Sedo, which serves Google ads.
There aren't too many organizations public or private left in the world, that can replicate Google's indexing capabilities.
It's not necessary to have a company the size of Google to do Google's web search. CPU power and disk space have been increasing faster than the amount of content on the web.
Indexing the web isn't all that big a job any more. Cuil, despite their problems, did it with about $20 million, 50 people and about 1000 servers. Their relevance algorithm was terrible and their crawler hit the same pages too often, and by the time they had those fixed, it was too late for them. But they did index all the pages they could reach.
Common Crawl, which is a modestly sized nonprofit, maintains a crawl of the whole web. So does Archive.org Neither maintains a search engine, though.
The next frontier in web search is to crack the provenance problem - figure out which pages are derived from other pages, and list the original source first. Google is not good at this. There are constant complaints on Google support forums about scraper sites outranking the original source. Google doesn't get this right for video, either. A video search system which found the best copy of something and discarded all the copies with ads, logos and recompression would be far better than what Google provides.
Google can't do that. They make money off AdSense ads on third-party content. Scraper sites are a gold mine for Google. 30% of Google ad revenue is from AdSense. Much of that is from copied content.
Myspace tried that. It didn't work out well for them.
Google's advice to their AdSense advertisers is both funny and pathetic. Google suggests that the content should be a tiny box in the center, surrounded by Google ads on all sides.
Google has actually sent out emails to AdSense advertisers telling them that they should have more ads on their page. That's what Myspace looked like during their screaming dive to irrelevance.
(We give away Ad Limiter which cuts Google ads on Google search results down to one ad per page. Since AdBlock Plus sold out and started allowing ads from their "partners", Ad Limiter is picking up a modest number of users. Or you can use DuckDuckGo, which limits itself to one ad per page.)
It's sad. I used to have a house full of bookshelves, and I'd read all the books when I bought each one. When I moved several years ago, most of the books remained in boxes. I've been going through them, keeping a few, giving some to the local library, selling some to a used bookstore, sending some early technical books to museums, and dumping the rest into the recycling bin. I just dumped all the original Sun Java manuals, finance books like "Bankruptcy 1995" (the author was a CEO, and he thought the US would go bankrupt in the 1990s. Instead, his company did.), and some reasonably good paperback SF. There's just no point in having wall to wall bookshelves any more. I used to have three six-shelf bookcases of technical books in my home office. Now I have three shelves.
I never owned a Brittanica, although I did have the Oxford English Dictionary, the one in tiny type with the magnifying glass.
Borders is gone, Barnes and Noble is in trouble, and Amazon is moving to downloads. When Amazon goes download-only, it will be over for good.
It's striking how unsuccessful Google has been with anything but ads. Google revenue is still 94% ads. As the article points out, it's not for lack of trying.
Many of Google's products (Docs, spreadsheets, etc.) seem to have been intended to cut into Microsoft's revenue. They didn't generate much revenue themselves. Microsoft Office revenue doesn't seem to have dropped.
Google+ was aimed at Facebook, of course, but doesn't seem to have achieved much traction. 3 minutes a day per user?
As I pointed out yesterday, there's a whole business out there spamming Facebook and Google+. One product claims it can generate 250,000 new Google+ profiles a day on a fast connection. That's 7 million fake profiles a month per JetBots user. Google+ added about 10 million profiles a month in late 2011. A big fraction of those have to be fake.
Google tried selling phones directly, which they abandoned when they realized customers expected Google to service them. The whole Android operation doesn't seem to generate significant revenue. It's nice that they're supporting open source, but they're not making much money.
Google has to pay to get people to use their search engine. Google pays $100 million a year to be on the iPhone, and $125 million a year to be on Firefox. That's a problem. Google search isn't demanded by consumers. Most users stay with whatever search engine is set by default in their browser. Most Bing traffic comes from the default in IE.
Google is increasing ad density to boost revenue. More and more screen space on Google sites is devoted to ads. They even send out emails to their AdSense customers if the third party sites don't have enough Google ads. Myspace tried increasing their ad density as revenue slipped. It didn't end well for Myspace.
Google had a really good idea, and ran with it. Then they had a really good idea on advertising, and it paid. Those were the wins. But they were a decade ago. They never found a second profitable product. Google stock peaked in late 2007, before the recession. Google doesn't pay a dividend. Google remains profitable, but investors aren't getting any of those profits. Investors are not happy.
Google has a two-tier stock structure, with the insider stock having 10x the voting power of the publicly traded shares. So Page and Brin can't be fired. If Google didn't have a setup like that, they'd be out by now.
San Jose is a successful city, but the downtown area is unusually dead. For thirty years, the city has tried various initiatives to "get downtown going". They put in light rail. They built a convention center, a sports stadium, some parks, a plaza, and several museums. They encouraged the building of large office buildings.
It hasn't worked. Several of the big office buildings are empty. There's little retail. The "nightclub district" is a row of boarded up storefronts. It's not run down, or even dirty. Just vacant.
Offering free WiFi in the downtown area can't hurt, and it's cheap.
That "16 hour" start-up time is probably bogus. It's not in the article. If it's real at all, it probably refers to how long it takes to drive the thing from some base to the target area. The military often figures response times like that - from when it's called for until it gets there and starts shooting.
There's a smaller version, the Silent Guardian, with only about 250m of range. This is about the size of a WWI tripod-mounted heavy machine gun.
If this technology had been available in the 1960s, the Civil Rights Movement would never have happened.
I've had enough with Microsoft's anti-competitive cheating (essentially), astro-turfing, stomping on competitors.... Google may have their problems, but they have it within their culture to at least try to do the right thing by their user base.
Microsoft is very tough on their competitors. Google's aggressiveness is aimed at their users. This reflects their business models. Microsoft's customers are the people who buy Microsoft software and hardware.
Ad-supported services are a sideline for Microsoft. Google's customers are their advertisers. Google users are a product.
His "Airtight Garage" was the basis for the fantastic architecture of the San Francisco Sony Metreon's original game arcade. (Unfortunately, after years of deterioration and changes in ownership, the Metreon has been torn out and replaced with a Target store.)
The article completely misses the point.
The talk starts out awful, but after about five minutes of blithering, he gets to the point. He's set up an environment where he's running a little Javascript program that draws a picture of a tree with flowers, with mountains in the background. As he edits the code, the picture changes. There's a nice user interface which allows selecting a number in the code and then changing it with a slider. This immediately affects the picture. There's an autocomplete feature which, when code typing has reached a limited number of possible choices, offers options like drawCircle, drawRect, etc. Mousing over the selections changes the picture.
It makes sense if you're drawing pictures with programs. Something like this should be in editors for Renderman shaders and Maya programs, and maybe for some game engines. It also makes sense for HTML editors, and there are HTML editors which do that. Beyond that, it may not be too useful.
That's just for refueling access. For decommissioning, the entire reactor compartment has to come out. For a submarine, that's the whole hull section containing the reactor. A lid is welded on each end, and the old reactor compartments are then neatly lined up in a big open space at 46.566488,-119.517712. When the space is full, a berm will be built around it and filled in.
Sadly, it has to be scrapped. Removing the reactors requires cutting out decks from the flight deck down to all eight nuclear reactor compartments. The hull gets towed to Bremerton, WA for disposal. The reactors, less fuel, go to a trench in Hanford, Washington.
Slashdot Mirror
The original poster works at google (like me).
I am not, nor have I ever been, a Google employee.
The braking from supersonic phase is going to be interesting.
Ordinary parachuting maxes out around 200km/h. Back in the 1960s, the last time a 100,000+ foot jump was tried, someone hit 998km/h. They did not have an easy ride down.
It's probably because Google pays more.
It seems late to be going to Google to do research. Five years ago, yes. Today, no. Google's innovations lately all seem to involve more intrusive advertising.
I hope Google keeps funding the automatic driving effort. At least until some auto manufacturer picks it up. They're getting close to something usable. Now they need to switch from that rotating car-top Velodyne kludge LIDAR to multiple flash LIDARs like Advanced Scientific Concepts makes, and get the size and price down.
Is there any reliable source of data that rates company policies against some objective criterion? Something that's not just an unsorted collection of complaints or anecdotes? There's EULAlyzer, which tries to do this by recognizing stock phrases. Anything else?
Incidentally, Netflix won't even let you read their EULA unless you let them plant a cookie. That's tacky,
If I could find something like that, I'd put it in SiteTruth, and have it appear when you mouse over a link or search result. Currently we report the location of the business and, when available, the annual revenue and number of employees, with links to SEC and BBB reports. The goal is to provide consumers with data that allows them to tell how legitimate the company is. Data that doesn't come from the company. (Or from their social spammers. Most favorable crowd-sourced "reviews" are now solicited, if not outright fake.)
Donald Knuth made this point in 1971, in his Empircal Study of Fortran Programs - virtually none of most programs has any significant effect on performance.
That's much less true than it used to be. In batch number-crunching programs (which is what people wrote in FORTRAN), there are typically inner loops that use most of the CPU time. However, a browser, a window system, a parser, an OS, or a GUI application usually has a much flatter profile. Then the speed of the language matters.
Says the guy whose whole life is tied up in the language, and whose project, at Google, to speed it up, crashed and burned.
Python is slow because von Rossum refuses to cut loose the boat-anchor of "anything can change anything at any time". The straightforward implementation of Python, CPython, boxes all numbers (everything is a CObject, including an int or a float) and looks up functions, attributes, and such in a dictionary for every reference. And only one thread is allowed to run at a time. This allows one thread to dynamically patch the objects and code of another thread. Which is cool, but useless. 99.99+% of the time, there's no need for a dynamic lookup. Most program dynamism is shortly after program startup - once things are running, they don't change much. If, sometime shortly after startup, the program said "OK, done with self-modification", at which point a JIT compiler did its thing, the language would be much faster. But no. That's "un-Pythonic".
PyPy, the newer Python implementation, uses two interpreters and a JIT compiler to try to handle the dynamism with less overhead. They're making progress, but they need a very complex implementation to do it, and they're many years behind schedule.
Python, as a language, is very usable. But it's too slow for volume production. That's not inherent in the basic language. Python could remain declaration-free if there were just a few more restrictions on unexpected dynamism. By this is meant ways the program can change itself that aren't obvious from looking at the source code. For example, if a module or class could only be modified from outside itself if it contained explicit self-modification code (like a relevant "setattr" call) most modules and classes could be nailed down as fixed, "slotted" objects at compile time. The other big win is using enough type inference to decide if a variable can always be represented as a machine type (int, float, char, bool, etc.). That's a huge performance win.
Claiming that the "slow parts" should be rewritten in C is a cop-out. It makes the program more fragile, since C code can break Python's memory safety. Except for number-crunching, or glue code for existing libraries, it's seldom done.
(I have a Python program running right now which will run for over a week, parsing the street address of every business in the US into a standard format. The parser is complex enough that rewriting it in C would be a big job. There's no "inner loop".)
"Java was supposed to be the programming language of the Web." - Given that most enterprise applications have web interfaces, it's not a real miss.
Sun was thinking client-side Java. "Applets", running in the browser. Then they were thinking desktop Java, with user applications written in Java. Server side Java came much later.
That's why Java has that whole byte-code interpreter thing. Java is a hard-compilable language; there's a GCC implementation that generates machine code. The whole point of the byte-code thing was to make the downloads to the user's browser fast and processor-independent. "Write once, run everywhere" is a client side issue, not a server side issue.
Google created an invisible form on a web page and then simulated a click on to bypass Safari's privacy controls. That didn't happen by accident. That's hostile code.
Safari treated a "submit" action as permission for the site to plant a cookie. It's hard to stop that in the browser without breaking some legitimate forms. As a result of this, all web forms which want to trigger a cookie event may have to have explicit "submit" buttons.
Java succeeded because Sun 1) gave it away, and 2) threw money at giving it away. Remember "applets"? Java was supposed to be the programming language of the Web. That didn't work out. It ended up being the new COBOL, which was not Sun's intent.
Some languages fail, or get stuck, because the designer is in love with their own implementation. That happened to Pascal and Python. Wirth's own Pascal implementation was a cute little recursive-descent compiler that generated RPN byte codes, like a Java compiler. Wirth resisted changes to the language that would allow programming in the large. ISO Pascal reflects his biases. So Pascal became stuck in an educational niche. The original Macintosh software was all written in an extended Pascal, as was much '80s software. But everybody had a different dialect - there was Turbo Pascal, Clascal, and a few others. They never merged.
Modula, Wirth's second try, was also crippled in certain ways. Modula 2 was better. Modula 3 was good enough to be used to write an operating system kernel. Unfortunately, Modula 3 was only used with DEC, which died after being acquired by Compaq.
Python has some of the same problems. The feature set of Python reflects what it's easy to implement in a naive interpreter, like von Rossum's CPython. Internally, everything is an object, even integers and floats, and object access involves dictionary lookups. This makes CPython slow. Every attempt to speed up Python substantially has hit a wall, including Google's "Unladen Swallow" effort. (PyPy is making progress, but it's taken a decade and requires an incredibly complex internal combination of interpreters and compilers.)
The biggest disappointment to me has been that we're still stuck with C. C has two killer bad design decisions - the language doesn't know how big arrays are, and the "pointer=array" thing lies to the language. Both reflect how things are done in assembler, and the fact that the original compiler had to fit in a 128K PDP-11. Most of the millions of buffer overflows and crashes that occur daily can be traced to those two design decisions. (C++, as I point out occasional, tries to paper over these problems with collection classes. But the mold usually seeps through the wallpaper, since most operating system and library calls want raw C pointers.)
Regardless of what the founder believes, Wikipedia should have monetized the website with the "subtle" use of advertising which would have generated billions in revenue over the past decade.
Nah. Wikipedia relies on volunteers. If they were a business, they'd have to pay people. If they ran ads, there would be pressure to suck up to advertisers.
Look at Wikia. It's mostly fancruft, with the Star [Trek|Wars|Gate|Craft] wikis. That's what a pay version of Wikipedia looks like.
Well heaven forbid you actually train someone to do it. That's why you can't find anybody, every company wants instant gratification with no work.
Exactly. Find someone who understands some modern low level electrical interfaces, like USB. Expect them to take about a month to pick up each new one (old one, actually) you need.
(What's 1-wire being used for? Most of the "key" type applications have been superseded by some kind of RFID tag. Anyone still have a Java Button?)
Some crucial details were left out.
The "transmitter" uses the Fermilab accelerator ring to generate neutrinos. 6km of particle accelerator.
The "receiver" is a neutrino detector the size of a large house.
The data rate is so low that it took 20 minutes to transmit one word.
Neutrinos still interact with other particles very infrequently. These researchers have no way around that. They just used a very powerful beam and a huge detector to pick up the very rare events. It's a stunt, not an advance.
Yes, Google has been sending out notifications encouraging sites to fill more of the screen with Google ads. I'm trying to find the link where someone reported getting a notification that they should put more ads on their page, because they had less than 3 "ad units". That included the "heat map" referenced above. I haven't found that yet, but I found this Google video "Monetize your content". "Ideally, every page on your site should have some form of AdSense on it". Yes, the Google sales rep actually says that.
In related news, Google is dropping their "domain parking" business, where Google hosts ad-filled pages for parked domains. Not because domain parking is evil. They're just outsourcing the hosting. Google suggest using another domain-parking company like Sedo, which serves Google ads.
There aren't too many organizations public or private left in the world, that can replicate Google's indexing capabilities.
It's not necessary to have a company the size of Google to do Google's web search. CPU power and disk space have been increasing faster than the amount of content on the web. Indexing the web isn't all that big a job any more. Cuil, despite their problems, did it with about $20 million, 50 people and about 1000 servers. Their relevance algorithm was terrible and their crawler hit the same pages too often, and by the time they had those fixed, it was too late for them. But they did index all the pages they could reach.
Common Crawl, which is a modestly sized nonprofit, maintains a crawl of the whole web. So does Archive.org Neither maintains a search engine, though.
The next frontier in web search is to crack the provenance problem - figure out which pages are derived from other pages, and list the original source first. Google is not good at this. There are constant complaints on Google support forums about scraper sites outranking the original source. Google doesn't get this right for video, either. A video search system which found the best copy of something and discarded all the copies with ads, logos and recompression would be far better than what Google provides.
Google can't do that. They make money off AdSense ads on third-party content. Scraper sites are a gold mine for Google. 30% of Google ad revenue is from AdSense. Much of that is from copied content.
Google has gone nuts with the ads.
Myspace tried that. It didn't work out well for them.
Google's advice to their AdSense advertisers is both funny and pathetic. Google suggests that the content should be a tiny box in the center, surrounded by Google ads on all sides. Google has actually sent out emails to AdSense advertisers telling them that they should have more ads on their page. That's what Myspace looked like during their screaming dive to irrelevance.
(We give away Ad Limiter which cuts Google ads on Google search results down to one ad per page. Since AdBlock Plus sold out and started allowing ads from their "partners", Ad Limiter is picking up a modest number of users. Or you can use DuckDuckGo, which limits itself to one ad per page.)
It's sad. I used to have a house full of bookshelves, and I'd read all the books when I bought each one. When I moved several years ago, most of the books remained in boxes. I've been going through them, keeping a few, giving some to the local library, selling some to a used bookstore, sending some early technical books to museums, and dumping the rest into the recycling bin. I just dumped all the original Sun Java manuals, finance books like "Bankruptcy 1995" (the author was a CEO, and he thought the US would go bankrupt in the 1990s. Instead, his company did.), and some reasonably good paperback SF. There's just no point in having wall to wall bookshelves any more. I used to have three six-shelf bookcases of technical books in my home office. Now I have three shelves.
I never owned a Brittanica, although I did have the Oxford English Dictionary, the one in tiny type with the magnifying glass.
Borders is gone, Barnes and Noble is in trouble, and Amazon is moving to downloads. When Amazon goes download-only, it will be over for good.
It's striking how unsuccessful Google has been with anything but ads. Google revenue is still 94% ads. As the article points out, it's not for lack of trying.
Many of Google's products (Docs, spreadsheets, etc.) seem to have been intended to cut into Microsoft's revenue. They didn't generate much revenue themselves. Microsoft Office revenue doesn't seem to have dropped.
Google+ was aimed at Facebook, of course, but doesn't seem to have achieved much traction. 3 minutes a day per user? As I pointed out yesterday, there's a whole business out there spamming Facebook and Google+. One product claims it can generate 250,000 new Google+ profiles a day on a fast connection. That's 7 million fake profiles a month per JetBots user. Google+ added about 10 million profiles a month in late 2011. A big fraction of those have to be fake.
Google tried selling phones directly, which they abandoned when they realized customers expected Google to service them. The whole Android operation doesn't seem to generate significant revenue. It's nice that they're supporting open source, but they're not making much money.
Google has to pay to get people to use their search engine. Google pays $100 million a year to be on the iPhone, and $125 million a year to be on Firefox. That's a problem. Google search isn't demanded by consumers. Most users stay with whatever search engine is set by default in their browser. Most Bing traffic comes from the default in IE.
Google is increasing ad density to boost revenue. More and more screen space on Google sites is devoted to ads. They even send out emails to their AdSense customers if the third party sites don't have enough Google ads. Myspace tried increasing their ad density as revenue slipped. It didn't end well for Myspace.
Google had a really good idea, and ran with it. Then they had a really good idea on advertising, and it paid. Those were the wins. But they were a decade ago. They never found a second profitable product. Google stock peaked in late 2007, before the recession. Google doesn't pay a dividend. Google remains profitable, but investors aren't getting any of those profits. Investors are not happy.
Google has a two-tier stock structure, with the insider stock having 10x the voting power of the publicly traded shares. So Page and Brin can't be fired. If Google didn't have a setup like that, they'd be out by now.
San Jose is a successful city, but the downtown area is unusually dead. For thirty years, the city has tried various initiatives to "get downtown going". They put in light rail. They built a convention center, a sports stadium, some parks, a plaza, and several museums. They encouraged the building of large office buildings.
It hasn't worked. Several of the big office buildings are empty. There's little retail. The "nightclub district" is a row of boarded up storefronts. It's not run down, or even dirty. Just vacant.
Offering free WiFi in the downtown area can't hurt, and it's cheap.
That "16 hour" start-up time is probably bogus. It's not in the article. If it's real at all, it probably refers to how long it takes to drive the thing from some base to the target area. The military often figures response times like that - from when it's called for until it gets there and starts shooting.
There's a smaller version, the Silent Guardian, with only about 250m of range. This is about the size of a WWI tripod-mounted heavy machine gun.
If this technology had been available in the 1960s, the Civil Rights Movement would never have happened.
I've had enough with Microsoft's anti-competitive cheating (essentially), astro-turfing, stomping on competitors.... Google may have their problems, but they have it within their culture to at least try to do the right thing by their user base.
Microsoft is very tough on their competitors. Google's aggressiveness is aimed at their users. This reflects their business models. Microsoft's customers are the people who buy Microsoft software and hardware. Ad-supported services are a sideline for Microsoft. Google's customers are their advertisers. Google users are a product.
All they have to do is push a download that turns on the Playstation Eye of people they don't like.
His "Airtight Garage" was the basis for the fantastic architecture of the San Francisco Sony Metreon's original game arcade. (Unfortunately, after years of deterioration and changes in ownership, the Metreon has been torn out and replaced with a Target store.)
The article completely misses the point. The talk starts out awful, but after about five minutes of blithering, he gets to the point. He's set up an environment where he's running a little Javascript program that draws a picture of a tree with flowers, with mountains in the background. As he edits the code, the picture changes. There's a nice user interface which allows selecting a number in the code and then changing it with a slider. This immediately affects the picture. There's an autocomplete feature which, when code typing has reached a limited number of possible choices, offers options like drawCircle, drawRect, etc. Mousing over the selections changes the picture.
It makes sense if you're drawing pictures with programs. Something like this should be in editors for Renderman shaders and Maya programs, and maybe for some game engines. It also makes sense for HTML editors, and there are HTML editors which do that. Beyond that, it may not be too useful.
That's just for refueling access. For decommissioning, the entire reactor compartment has to come out. For a submarine, that's the whole hull section containing the reactor. A lid is welded on each end, and the old reactor compartments are then neatly lined up in a big open space at 46.566488,-119.517712. When the space is full, a berm will be built around it and filled in.
Sadly, it has to be scrapped. Removing the reactors requires cutting out decks from the flight deck down to all eight nuclear reactor compartments. The hull gets towed to Bremerton, WA for disposal. The reactors, less fuel, go to a trench in Hanford, Washington.