Google will provide free WiFi in Mountain View

Google has offered to bring free wireless Internet, or WiFi, connections to Mountain View, the city of its corporate headquarters.

The offer comes about two months after the company offered to do the same for the city of San Francisco.

``This proposal is in the same spirit of making the world's information easily and quickly accessible as our recent San Francisco WiFi bid and is technically comparable to that initiative,'' Google said in a statement released Wednesday. ``Google has no plans at this time to expand our WiFi efforts beyond the Bay Area.''

Google officials approached Mountain View leaders a few weeks ago and offered to hoist 300 transmitters onto the city's 3,000 telephone poles and street lights, according to Mountain View Mayor Matt Neely. Neely said the company could install what he described as softball-sized devices that would transform the whole city into a so-called hotspot.

``It's pretty amazing,'' Neely said. ``What better place than Google's hometown and what better place than Mountain View to have the whole city connected on WiFi?''

WiFi service could be installed as early as the first few months of 2006, Neely said. ``Google -- they move,'' he said. ``This will be happening in the very near future.''

Mountain View, a mid-Peninsula city of 12 square miles and about 72,000 residents, is also home to the NASA/Ames Research Center at Moffett Field, where Google is building a research complex. There, it will collaborate with the space agency scientists.

If Google's proposal for Mountain View mirrors its suggestions for San Francisco, it could likely entail installation of a network of transmitters that would parlay data, via invisible radio waves, back and forth between people's computers and the Internet.

Mountain View is expected to make the Google proposal public today in advance of the Tuesday city council meeting where it will be discussed. Unlike in San Francisco, Mountain View city leaders have not launched a formal call for companies to compete to bring affordable wireless Internet connections to the city.

Google traffic breakdown

Bill Tancer from Hitwise gave a percentage breakdown of traffic to all Google sites for a one week period ending Nov. 5. The summary is below (rounded to the nearest tenth of a percent for all visits, except those below a tenth of a percent):

1. Google Web Search: 79.9 percent


2. Google Image Search: 9.2 percent


3. Google Mail/Gmail: 5.6 percent


4. Google News: 1.6 percent


5. Google Maps: 0.8 percent


6. Froogle: 0.7 percent


7. Google Scholar: 0.6 percent


8. Google Groups/Groups 2 Beta: 0.5 percent


9. Google Print: 0.4 percent


10. Google Earth: 0.3 percent


11. Google Directory: 0.2 percent


12. Google Local: 0.1 percent


13. Google Answers: 0.1 percent


14. Google AdWords: 0.06 percent


15. Google Desktop Search: 0.04 percent


16. Google Talk: 0.02 percent

From: Search Engine Watch

Google vs Yahoo vs MSN vs AOL

An interesting comparison between Google, Yahoo, MSN and AOL shows that there are many areas where Google doesn't have any offerings and the others do.

Google does innovate in some spaces but has largely innovated in order to gain entry in markets that already existed. As a rule of thumb, they've been very smart at breathing new innovations in those markets. However, their competitors are generally quick to notice and are catching up.

In terms of future offerings, the following products may come from Google over the next few months:
* An audio search engine, which will include a podcasting component (and possibly a podcast authoring component via blogger)
* A strategic partnership with Wikipedia or some other encyclopedia
Some type of clustered search offering
* A calendar product, which will probably inject new life in that space
* An auction offering, tied with an internal payment system
* A web hosting service that will scale from small entities to large ones and will include Gmail as part of the email offering
* Some type of access service, probably using their WiFi solution

Google Local Mobile

Google launched a mobile version of its Google Local service that will allow users to search for businesses or services in a specific geographical location and view the search results plotted on a map. Google Local for mobile works with most new Java-enabled (J2ME) mobile phones.

While Google’s focus will be on expanding its services for mobile phone users such as the Google Local and Google Maps services, Yahoo is also hoping to increase its presence in the mobile phone industry with the announcement that it will be releasing a Yahoo Mobile phone next year the Wall Street Journal reported on Monday.

More: Google and Yahoo strengthen mobile offering

Yahoo and the evolution of search

The chief technology officer, Farzad Nazem, said that Google now had the exciting sheen of being "the newest kid on the block" and the fastest-growing company. "I know all about that, because that's how it was for us back in '99, 2000," he said. "We sneezed; it was like it was from God. I understand the whole thing."

But Mr. Nazem and everyone else really wanted to discuss what lay beyond these keyword searches of the entire Web. "You can look at the evolution of search as a play in three acts," said Jeff Weiner, the senior vice president for search and marketing. "The first is the 'public' Web, where if different people type the same query they'll all get the same results." The second, he said, was purely personal search - finding a file or photo, usually on your own machine.

"The third is the one that we are very interested in," Mr. Weiner said. This is "social" or "community" searching, in which each attempt to find the right restaurant listing, medical advice site, vacation tip or other bit of information takes advantage of other people's successes and failures in locating the same information.

More at: A Jorney to the Center of Yahoo

Google Print : 10,000 searchable books

Google completed the first major expansion of its Google Print database of searchable books, adding the full text of more than 10,000 works that are no longer under copyright, culled from the collections of four major research libraries. The additions, from the university libraries at Michigan, Harvard and Stanford and from the New York Public Library, represent the first large group of material to be made available electronically from those libraries, which along with Oxford University contracted with Google last year to let the company scan and make searchable the contents of much or all of their collections.

Google BigTable - multi-dimensional sparse map

Google Reader blog mentions an explanation of BigTable, a Google in-house development to tackle large amounts of data in “semi-structured manner” – such as RSS readers would need. The following notes by Andrew Hitchcock from October 18 2005 are based on a talk given by Google’s Jeff Dean at the University of Washington (they are licensed under a a Creative Commons License).

First an overview. BigTable has been in development since early 2004 and has been in active use for about eight months (about February 2005). There are currently around 100 cells for services such as Print, Search History, Maps, and Orkut. Following Google’s philosophy, BigTable was an in-house development designed to run on commodity hardware. BigTable allows Google to have a very small incremental cost for new services and expanded computing power (they don’t have to buy a license for every machine, for example). BigTable is built atop their other services, specifically GFS, Scheduler, Lock Service, and MapReduce.

Each table is a multi-dimensional sparse map. The table consists of rows and columns, and each cell has a time version. There can be multiple copies of each cell with different times, so they can keep track of changes over time. In his examples, the rows were URLs and the columns had names such as “contents:” (which would store the file data) or “language:” (which would contain a string such as “EN”).

In order to make each manage the huge tables, the tables are split at row boundaries and saved as tablets. Tablets are each around 100-200 MB and each machine stores about 100 of them (they are stored in GFS). This setup allows fine grain load balancing (if one tablet is receiving lots of queries, it can shed other tablets or move the busy tablet to another machine) and fast rebuilding (when a machine goes down, other machines take one tablet from the downed machine, so 100 machines get new tablet, but the load on each machine to pick up the new tablet is fairly small).

Tablets are stored on systems as immutable SSTables and a tail of logs (one log per machine). When system memory is filled, it compacts some tablets. He went kind of fast through this, so I didn’t have time to write everything down, but here is the overview: There are minor and major compactions. Minor compactions involve only a few tablets, while major ones involve the whole system. Major compactions can reclaim hard disk space. The location of the tablets are actually stored in special BigTable cells. The lookup is a three-level system. The clients get a pointer to the META0 tablet (there is only one). This tablet is heavily used, and so one machine usually ends up shedding all its other tablets to support the load. The META0 tablet keeps track of all the META1 tablets. These tables contain the location of the actual tablet being looked up. There is no big bottleneck in the system, because they make heavy use of pre-fetching and caching.

Back to columns. Columns are in the form of “family:optional_qualifier”. In his example, the row “www.cnn.com” might have the columns “contents:” with the HTML of the page, “anchor:cnn.com/news” with the anchor text of that link (“CNN Homepage”), and “anchor:stanford.edu/” with that anchor text (“CNN”). Columns have type information. Columns families can have attributes/rules that apply to their cells, such as “keep n time entries” or “keep entries less than n days old”. When tablets are rebuilt, these rules are applied to get rid of any expired entries. Because of the design of the system, columns are easy to create (and are created implicitly), while column families are heavy to create (since you specify things like type and attributes). In order to optimize access, column families can be split into locality groups. Locality groups cause the columns to be split into different SSTables (or tablets?). This increases performance because small, frequently accessed columns can be stored in a different spot than the large, infrequent columns.

All the tablets on one machine share a log; otherwise, one million tablets in a cluster would result in way too many files opened for writing (there seems to be a discrepancy here, he said 100 tablets per machine and 1000 machines, but that doesn’t equal one million tablets). New log chunks are created every so often (like 64 MB, which would correspond with the size of GFS chunks). When a machine goes down, the master redistributes its log chunks to other machines to process (and these machines store the processed results locally). The machines that pick up the tablets then query the master for the location of the processed results (to update their recently acquired tablet) and then go directly to the machine for their data.

There is a lot of redundant data in their system (especially through time), so they make heavy use of compression. He went kind of fast and I only followed part of it, so I’m just going to give an overview. Their compression looks for similar values along the rows, columns, and times. They use variations of BMDiff and Zippy. BMDiff gives them high write speeds (~100MB/s) and even faster read speeds (~1000MB/s). Zippy is similar to LZW. It doesn’t compresses as highly as LZW or gzip, but it is much faster. He gave an example of a web crawl they compressed with the system. The crawl contained 2.1B pages and the rows were named in the following form: “com.cnn.www/index.html:http”. The size of the uncompressed web pages was 45.1 TB and the compressed size was 4.2 TB, yielding a compressed size of only 9.2%. The links data compressed to 13.9% and the anchors data compressed to 12.7% the original size.

They have their eye on the future with some features under consideration. 1. Expressive data manipulation, including having scripts sent to clients to modify data. 2. Multi-row transaction support. 3. General performance for larger cells. 4. BigTable as a service. It sounds like each service (such as Maps or Search History) have their own cluster running BigTable. They are considering running a Google-wide BigTable system, but that would require fairly splitting resources and compute time, etc.

Google Talk video plugin

Google Talk, Google’s messaging and VOIP application, is now Video enabled with a new plug-in from Festoon. Using the video plug-in, Google Talk users can now see who they are talking to, in real time. Festoon, which also has the most popular video plug-in for Skype with more than 2.75 million downloads, allows Google Talk users to talk to and see each other, play games, share pictures, or conducting business.

By installing the Festoon Google Talk Video Plug-in, Google Talk users can securely conduct video voice calls in groups from 2 to 200 and share photos, spreadsheets, presentations, or applications with others on a call. Festoon offers high-quality group voice utilizing the industry leading GIPS audio codec used also by Google Talk, Skype, and AIM Triton. Festoon’s Video plug-ins are advertiser supported.