[24-Nov-2009] Pic of the day: Chrome's mission: Making Windows obsolete

Video of demo: http://www.youtube.com/watch?v=ANMrzw7JFzA

Reference:

http://blogs.computerworld.com/15135/chromes_mission_making_windows_obsolete

_______________________________________________________

Some people are already convinced that Google will fail with its Chrome operating system. Others think that Chrome can't possibly be a threat to Windows. Both groups are so, so wrong.

First, for those who think that Chrome is simply a failure from the word "go", their reasoning is pathetically flawed. They argue that Chrome will fail because it's based on Linux. What century are these people from?

The specific complaints, such as "From power management to display support, Linux has long been a minefield of buggy code and half-baked device driver implementations." reveal that they're coming from people who know nothing whatsoever about Linux. Linux is tried and proven.

You don't have to believe me, though. Just look at the world around you. Linux rules on devices from your TiVo DVR to your Droid smartphone to you name it. Linux kicks rump and takes names on supercomputers, where nothing else is even competitive. And Linux rules stock markets, where failure is never an option.

The only place where Linux hasn't been a strong competitor has been on the desktop. There are many reasons why desktop Linux hasn't done well: number one has been Microsoft's desktop monopoly. With Google's backing, however, Chrome avoids the Linux desktop's real problems.

The other compliant, that somehow the Web interface isn't sufficient, also flies in the face of reality. Google has been showing us for years now that almost everything you can do on a computer, you can do with a Web interface. So what if the interface itself isn't groundbreaking?

What is revolutionary is that Google isn't trying to fight with Microsoft in a mano-a-mano battle for the desktop. No one, especially not Google, is claiming that Chrome OS is a direct competitor to Windows 7. At the high end, where power users use applications like Autodesk or Photoshop, Chrome simply won't play.

Instead, Google is saying that, for most users, most of the time, Windows is obsolete. And it's not just Windows: Google is telling us that we don't need Office, Outlook, and all the other day-in, day-out Windows applications, either.

Google suggests that inexpensive Chrome OS devices, not Windows PCs, are all that most people need for most of their home and office computing. With Chrome OS devices and Web-based services, you won't need to pay theWindows tax or buy Microsoft Office.

It's a radical approach. Google is saying: sure, go ahead and use Windows where you have to — but keep in mind that, for your second computer, or if you don't need high-end PC-specific applications, Chrome OS is all you'll need.

I can see this working. Chrome OS is faster, safer and cheaper. In addition, unlike Windows PCs, Chrome laptops won't require monthly maintenance to keep them running well. In short, Google is trying to make Windows, and all the software that goes with it, obsolete for most users, most of the time.

I like this plan — I like this plan a lot. Rather than trying to take Windows head on, Google is using 21st century technology to reinvent the desktop operating system and question just how important the 1980s style desktop is today. You'll know it's working even before the first Chrome OS netbooks appear if Microsoft revamps Windows 7 Starter Edition to make it more fully functional and cheaper. Keep your eyes on Chrome OS and Microsoft's reactions against it. I'll be very interested to see how this plays out.

[13-Nov-2009] Tech Talk of the Day: Google File System A Critical Analysis

Google File System: A Critical Analysis

Who does not know Google? It will not be wrong to say that Google has become a vital need in today’s information age. But have you ever wondered on the driving force behind Google, what is it that makes Google stand out as Google? There are many answers to this question but one most prominent research by the Google engineers emerged in 2003 by the name of Google File System, the paper of which was presented in the famous SOSP Conference of 2003.

GFS is a distributed file system highly customized for Google's computing needs and clusters composed of thousands of commodity disks. GFS uses a simple master-server architecture based on replication and auto-recovery for reliability, and designed for high aggregate throughput. The file system is proprietary and has been used to serve Google’s unique application workloads and data processing needs.

Why GFS?
Traditional file systems are not suitable for the scale at which Google generates and processes data: multi gigabyte files are common. Google also utilizes inexpensive commodity storage, which makes component failures all the more common. Google's data update patterns are specific, and most of the updates append data to the end of the file. Traditional file systems do not guarantee consistency in the face of multiple concurrent updates, whereas using locks to achieve consistency hampers scalability by becoming a concurrency bottleneck.

GFS Details
The diagram below presents the fundamental architecture of Google File System:


A GFS cluster consists of a single master and multiple chunkservers and is accessed by multiple clients. Files are divided into fixed-size chunks and each chunk is identified by a chunk handle. Large chunk size is chosen for better performance. The master maintains all file system metadata. This includes the namespace, access control information, the mapping from files to chunks, and the current locations of chunks. It also controls system-wide activities such as chunk lease management, garbage collection of orphaned chunks, and chunk migration between chunkservers. The master stores three major types of metadata: the file and chunknamespaces, the mapping from files to chunks, and the locations of each chunk’s replicas. All metadata is kept in the master’s memory. The first two types (namespaces and file-to-chunkma pping) are also kept persistent by logging mutations to an operation log stored on the master’s local disk and replicated on remote machines. The master does not store chunk location information persistently. GFS client code linked into each application implements the file system API and communicates with the master and chunkservers to read or write data on behalf of the application. Clients interact with the master for metadata operations, but all data-bearing communication goes directly to the chunkserver.

Permissions for operations are handled by a system of time-limited, expiring "leases", where the Master server grants permission to a process for a finite period of time during which no other process will be granted permission by the Master server to access the chunk. The modified chunkserver, which is always the primary chunk holder, then propagates the changes to the chunkservers with the backup copies. The changes are not saved until all chunkservers acknowledge, thus guaranteeing the completion and atomicity of the operation.
Programs access the chunks by first querying the Master server for the locations of the desired chunks; if the chunks are not being operated on (if there are no outstanding leases), the Master replies with the locations, and the program then contacts and receives the data from the chunkserver directly (similar to Kazaa and its supernodes).

Critical Analysis
1) The authors and developers of Google File System make trade offs aggressively to their advantage. Unfortunately, the only other people in the world who could benefit from these decisions were other people at Google, or perhaps their direct competitors (and not for long, it appears).

2) The chunkservers run the file system as user-level server processes and are less efficient than implementing file system directly in the kernel to improve performance.

3) Most consistency checks are pushed to the application and it needs to maintain ids/checksums to ensure that the records are consistent. Google built not only the file system but also all of the applications running on top of it. While adjustments were continually made in GFS to make it more accommodating to all the new use cases, the applications themselves were also developed with the various strengths and weaknesses of GFS in mind, and this approach makes the life of the application developer quite difficult.

4) Clients that cache chunk locations could potentially read from a stale replica.

5) One flaw of the design is the decision to have a single master, which limits the availability of the system. Although the writers argue that a takeover can happen within seconds, I believe that the most important implication is that a failed master might mean that some operations are lost, if they have not been recorded in the log. Relying on a quorum among multiple masters seems a straightforward extension and can provide better performance.