Computed·Blg - Hardware

Researchers develop disposable paper-based touch pads

nospam@example.com (Christian Babski) — Mon, 14 May 2012 11:14:00 +0000

-----

A paper-based touch pad on an alarmed cardboard box detects the change in capacitance associated with the touch of a finger to one of its buttons.

The keypad requires the appropriate sequence of touches to disarm the system. Image credit: Mazzeo, et al.

The touch pads are made of metallized paper, which is paper coated in aluminum and transparent polymer. The paper can function as a capacitor, and a laser can be used to cut several individual capacitors in the paper, each corresponding to a key on the touch pad. When a person touches a key, the key’s capacitance is increased. Once the keys are linked to external circuitry and a power source, the system can detect when a key is touched by detecting the increased capacitance.

According to lead researcher Aaron Mazzeo of Harvard University, the next steps will be finding a power source and electronics that are cheap, flexible, and disposable.

Among the applications, inexpensive touch pads could be used for security purposes. The researchers have already developed a box with an alarm and keypad that requires a code to allow authorized access. Disposable touch pads could also be useful in sterile or contaminated medical environments.

Artifical leaves could charge your phone

nospam@example.com (Christian Babski) — Thu, 10 May 2012 17:45:18 +0000

Via Slash Gear

-----

Green plants use photosynthesis to convert water and sunlight into energy used to help the plant grow. Scientists have created the first practical artificial leaf that mimics the natural process and holds promise for sustainable green energy. The key to this practical artificial leaf is that unlike earlier devices it doesn’t use expensive components in its construction.

The new artificial leaf is made from inexpensive materials and uses low-cost engineering and manufacturing processes making it much more practical. The artificial leaf has an component to collect sunlight sandwich between two films that generate oxygen and hydrogen gas. When the artificial leaf is placed into a jar of water and placed in sunlight, it bubbles, releasing hydrogen that can be used by fuel cells to make electricity. Previous designs needed expensive materials like platinum along with expensive manufacturing processes.

The new artificial leaf replaces the costly platinum with a less expensive nickel-molybdenum-zinc compound. The opposite side of the leaf has a cobalt film that generates oxygen gas. The hope is that this sort of device can be used to generate electricity for remote places that are off the electrical grid. The tech could also be used to power all sorts of devices including phones and more.

“Considering that it is the 6 billion nonlegacy users that are driving the enormous increase in energy demand by midcentury, a research target of delivering solar energy to the poor with discoveries such as the artificial leaf provides global society its most direct path to a sustainable energy future,” he says.

China plans national, unified CPU architecture

nospam@example.com (Christian Babski) — Fri, 04 May 2012 10:40:00 +0000

Via Extreme Tech

-----

According to reports from various industry sources, the Chinese government has begun the process of picking a national computer chip instruction set architecture (ISA). This ISA would have to be used for any projects backed with government money — which, in a communist country such as China, is a fairly long list of public and private enterprises and institutions, including China Mobile, the largest wireless carrier in the world. The primary reason for this move is to lessen China’s reliance on western intellectual property.

There are at least five existing ISAs on the table for consideration — MIPS, Alpha, ARM, Power, and the homegrown UPU — but the Chinese leadership has also mooted the idea of defining an entirely new architecture. The first meeting to decide on a nationwide ISA, attended by government officials and representatives from academic groups and companies such as Huawei and ZTE, was held in March. According to MIPS vice president Robert Bismuth, a final decision will be made in “a matter of months.”

China has a long history with MIPS and Alpha. Loongson processors, which power millions of Chinese school computers, use MIPS — and the ShenWei processors (pictured right) found in China’s first homegrown supercomputer, the Sunway Bluelight MPP, are based on the Alpha ISA. MIPS Technologies (the company) hasn’t been doing very well recently, and it’s rumored that the Sunnyvale-based company could be up for sale — a purchase I’m sure the Chinese government could afford.

According to EE Times, there are some 34 ARM licensees in China, but at $5 million for a single Cortex-A9 core license, it’s unlikely that ARM will be China’s choice. The Power ISA is cheaper, but lacks the software ecosystems that ARM and MIPS enjoy. ShenWei/Alpha is also a possibility, but again it cannot compete with MIPS’ installed base.

The other option, of course, is developing a brand new ISA — a daunting task, considering you have to create an entire software (compiler, developer, apps) and hardware (CPU, chipset, motherboard) ecosystem from scratch. But, there are benefits to building your own CPU architecture. China, for example, could design an ISA (or microarchicture) with silicon-level monitoring and censorship — and, of course, a ubiquitous, always-open backdoor that can be used by Chinese intelligence agencies. The Great Firewall of China is fairly easy to circumvent — but what if China built a DNS and IP address blacklist into the hardware itself?

Taking a leaf out of South Korea’s hardcore gaming scene, what if the Chinese government decided to implement a hardware-level 10pm curfew for video games? Or some code that automatically turns negative mentions of Hu Jintao (the Chinese president) into positives, and inserts a few honorifics at the same time. Or a latent botnet of hundreds of millions of computers that can be activated upon the commencement of World War III. Or, or, or…

The Descriptive Camera turns your photos into someone else's words

nospam@example.com (Christian Babski) — Thu, 26 Apr 2012 09:35:37 +0000

Via The Verge

-----

While most camera innovations are aimed at higher megapixel counts or new image capturing techniques, Matt Richardson is taking an entirely different route with the Descriptive Camera: creating a device that turns your captured imagery into words. Designed as part of a class for New York University's Interactive Telecommunications Program, the camera consists of a USB webcam, a shutter button, a small thermal printer, and an ethernet connection. When a picture is "snapped," it's sent off to humans for analysis via Amazon's Mechanical Turk API. The human on the other end then creates a written description of the image, which is sent back to the camera. The resulting text is printed with the thermal printer, framed by a Polaroid-style photo outline (an example Richardson provides reads "It's a dark room with a window. The image is quite pixelated."

According to Richardson's post about the project, the Amazon Human Intelligence Task — or HIT — cost is about $1.25 for each image, with results usually taking between three to six minutes to return. An "accomplice mode" actually lets the camera send out links to the image via instant messenger, providing a cheaper option for human interpretation. While the device currently requires external power from a 5-volt source, Richardson does hope to make a version at some point that runs off self-contained batteries and can use wireless data. It's certainly an interesting project, and we won't deny that we're smitten with the idea of taking images out and about in the world, and seeing them perceived through someone else's eyes.

Barobo launches the Mobot – a low cost modular robot

nospam@example.com (Christian Babski) — Fri, 20 Apr 2012 10:37:05 +0000

Via Flexibility Envelope

-----

Mobot by Barobo.com

Soon you can get your hands on the Mobot modular robot for a very reasonable $270 a module (pre-orders available now). A number of connection plates and attachments will also be available, and I guess you can 3D print your own stuff.

Mobot by Barobo.com

I like the gripper that is powered and controlled by the rotating faceplate. I am sure the same concept can be used to 3D print some cool things in the future. A connector would be an awesome thing and definitely worth a price of some sort.

In general, it seems to be a very competent modular robotics system. It uses a snap together connector, making it simple and fast to use, but maybe not as strong as a system that screws together.

There is a Graphical User Interface RobotController, and you can program it with the C/C++ interpreter Ch so everyone from beginner to hard core hacker should be able to do some really cool stuff.

More info on Barobo.com

LG flexible epaper devices promised for April launch

nospam@example.com (Christian Babski) — Thu, 29 Mar 2012 17:23:02 +0000

Via Slash Gear

-----

LG Display has launched a new, 6-inch flexible epaper display that the company expects to show up in bendable products by the beginning of next month. The panel, a 1024 x 768 monochrome sheet, can be bent up to 40-degrees without breaking; in addition, because LG Display has used a flexible plastic substrate rather than the more traditional glass, it’s less than half the weight of a traditional epaper panel.

That means lighter gadgets that are actually more durable since the panels should be more resilient to drops or bumps. They can also be thinner, too: the plastic panel is a third slimmer than glass equivalents, at just 0.7mm thick.

LG Display says it can drop its new screen from 1.5m – the average height a device is held when it’s being used for reading, apparently – without any resulting damage. The company also hit the screen with a plastic hammer, leaving no scratches or breaks, ETNews reports.

LG isn’t the only company to be working on flexible screens this year. Samsung has already confirmed that it is looking at launching devices using flexible AMOLED panels in 2012, though it’s unclear whether the screens will actually fold or bend, or simply be used to wrap around smartphones for new types of UI.

The first products using the LG Display flexible panel are on track for a release in the European market in early April, the company claims. No word on what vendors will be offering them, nor how pricing will compare to traditional glass-substrate epaper.

Microsoft patent takes the Transformer Prime one step further

nospam@example.com (Christian Babski) — Wed, 14 Mar 2012 11:37:00 +0000

Via Slash Gear

-----

Asus’ Transformer (and Transformer Prime) seems to have resonated well with consumers, and now Microsoft may be looking to create a similar concept in the future. A new patent reveals Microsoft nurturing an idea that could see a tablet turning into a full fledged laptop or desktop PC, complete with not one but two separate processors.

How is that any different from the Transformer Prime, you ask? Unwired View reports that Microsoft would be including a processor not only in the tablet itself, but also the keyboard base unit. The processor in the tablet would be optimized for low-power, pointing towards an ARM chip of some kind, while the processor in the keyboard base unit would be focused more on performance. That could mean either a speedier ARM chip, or even an ULV Intel chip.

Right now with the Transformer Prime, you hold the same amount of processing power whether or not you’re docked with the keyboard, which only provides additional power. Microsoft’s vision would see different performance scenarios depending on your mobility requirements, which seems much more appealing.

Not only that, the operating system would adapt to the change. Microsoft lay out in their patent that the device would switch between a “resource-conserving computing environment” when in tablet mode, and a “resource-intensive computing environment” when in laptop mode. This is idle speculation, but that sounds ideal for Windows 8, switching to the Metro interface when in tablet mode, and back to the traditional desktop when in laptop mode.

Tobii's IS-2 eye tracker is cheaper, 75 percent smaller than its predecessor

nospam@example.com (Christian Babski) — Tue, 06 Mar 2012 17:57:40 +0000

Via Endgadget

-----

Of all the things we saw at CES, Tobii's eye-tracking Gaze interface was one of the most memorable, even if the execution was a bit flawed. Now the company's back with a next-gen sensor that fits on a single board and is 75 percent smaller than the iteration we saw at CES -- a milestone that will presumably allow it to accommodate a wider range of devices. Tobii also says the IS-2S eye tracker consumes 40 percent less power than its predecessor and will be cheaper to implement, though the company doesn't specify how much it'll cost. It's also unclear which Windows PC and tablet makers will take a chance on the technology, though that won't necessarily stop us from getting an early demo at CeBIT this week.

MOTHER artificial intelligence forces nerds to do the chores… or else

nospam@example.com (Christian Babski) — Thu, 23 Feb 2012 10:39:00 +0000

Via Slash Gear

-----

If you’ve ever been inside a dormitory full of computer science undergraduates, you know what horrors come of young men free of responsibility. To help combat the lack of homemaking skills in nerds everywhere, a group of them banded together to create MOTHER, a combination of home automation, basic artificial intelligence and gentle nagging designed to keep a domicile running at peak efficiency. And also possibly kill an entire crew of space truckers if they should come in contact with a xenomorphic alien – but that code module hasn’t been installed yet.

The project comes from the LVL1 Hackerspace, a group of like-minded programmers and engineers. The aim is to create an AI suited for a home environment that detect issues and gets its users (i.e. the people living in the home) to fix it. Through an array of digital sensors, MOTHER knows when the trash needs to be taken out, when the door is left unlocked, et cetera. If something isn’t done soon enough, ~~she~~ it can even disable the Internet connection for individual computers. MOTHER can notify users of tasks that need to be completed through a standard computer, phones or email, or stock ticker-like displays. In addition, MOTHER can use video and audio tools to recognize individual users, adjust the lighting, video or audio to their tastes, and generally keep users informed and creeped out at the same time.

MOTHER’s abilities are technically limitless – since it’s all based on open source software, those with the skill, inclination and hardware components can add functions at any time. Some of the more humorous additions already in the project include an instant dubstep command. You can build your own MOTHER (boy, there’s a sentence I never thought I’d be writing) by reading through the official Wiki and assembling the right software, sensors, servers and the like. Or you could just invite your mom over and take your lumps. Your choice.

The Pirate Bay declares 3D printed “physibles” as the next frontier of piracy

nospam@example.com (Christian Babski) — Fri, 17 Feb 2012 19:49:56 +0000

Via Extreme Tech

-----

While the subject of online piracy is certainly nothing new, the recent protests against SOPA and the federal raid on Megaupload have thrust the issue into mainstream media. More than ever, people are discussing the controversial topic while content creators scramble to find a way to try to either shut down or punish sites and individuals that take part in the practice. Despite these efforts, online piracy continues to be a thorn in Big Media’s side. With the digital media arena all but conquered by piracy, the infamous site The Pirate Bay (TPB) has begun looking to the next frontier to be explored and exploited. According to a post on its blog, TPB has declared that physical objects named “physibles” are the next area to be traded and shared across global digital smuggling routes.

TPB defines a physible as “data objects that are able (and feasible) to become physical.” Namely, items that can be created using 3D scanning and printing technologies, both of which have become much cheaper for you to actually own in your home. At CES this year, MakerBot Industries introduced its latest model which is capable of printing objects in two colors and costs under $2,000. With the price of such devices continuing to drop, 3D printing is going to be part of everyday life in the near future. Where piracy is going to come in is the exchange of the files (3D models) necessary to create these objects.

A 3D printer is essentially a “CAD-CAM” process. You use a computer-aided design (CAD) program to design a physical object that you want made, and then feed it into a computer-aided machining (CAM) device for creation. The biggest difference is that traditional CAM setups, the process is about milling an existing piece of metal, drilling holes and using water jets to carve the piece into the desired configuration. In 3D printing you use extrusion to actually create what is illustrated in the CAD file. Those CAD files are the physibles that TPB is talking about, since they are digital they are going to be as easily transferred as an MP3 or movie is right now.

It isn’t too far outside the realm of possibility that once 3D printing becomes a part of everyday life, companies will begin to sell the CAD files and the rights to be able to print proprietary items. If the technology continues to advance at the same rate, in 10 or 20 years you might be printing a new pair of Nikes for your child’s basketball game right in your home (kind of like the 3D printed sneakers pictured above). Instead of going to the mall and paying $120 for a physical pair of shoes in a retail outlet, you will pay Nike directly on the internet and receive the file necessary to direct your printer to create the sneakers. Of course, companies will do their level best to create DRM on these objects so that you can’t freely just print pair after pair of shoes, but like all digital media it will be broken be enterprising individuals.

TPB has already created a physibles category on its site, allowing you to download plans to be able to print out such things as the famous Pirate Bay Ship and a 1970 Chevy hot rod. For now it’s going to be filled with user-created content, but in the future you can count on it being stocked with plans for DRM-protected objects.

Brendan Dawes: Man + MakerBot = Useful Household Items

nospam@example.com (Christian Babski) — Tue, 14 Feb 2012 11:32:00 +0000

Via Core77

-----

One of the key reasons I haven't ponied up for a MakerBot yet is because I'm still not sure it will be able to produce the types of things I specifically would like to make. It would be neat if they had some sort of "try before you buy" scheme where you could e-mail them plans and get the part back in the mail for a fee, to see if it met your expectations.

Until something like that develops, one blog I've found that makes for interesting reading is Brendan Dawes' Everything I Make with my MakerBot, whereby he documents his projects dating back to December of 2010, when he first bought the machine.

Although technically an artist and DJ, Dawes has enough ID in his bones to hint at what things you, as an industrial designer, would probably come up with if you had a MakerBot lying around the house. Thus we see things like cable wraps, a bicycle mount for a camera, a notebook writing utensil holder perfectly modified to store his preferred type of pencil, a modular desktop organizer system, and more.

Also informative is that he shows us his failures as well as his successes, revealing miscalculated parts and botched jobs resulting from a particular bolt on the machine not being tight enough. As I know I'd produce my fair share of errors, it's illuminating to see what can go wrong and how you can take steps to avoid it.

As IDers we're constantly looking at things and thinking "Jeez, if I only had something shaped like [this] then I could use it for [that.]" Dawes' blog really drives home that he continually has thoughts like these, and is able to quickly turn those into a reality.

It's Kinect day! The Kinect For Windows SDK v1 is out!

nospam@example.com (Christian Babski) — Tue, 07 Feb 2012 11:34:00 +0000

Via Channel 9

-----

As everyone reading this blog, and those in the Kinect for Windows space, knows today is a big day. From what was a cool peripheral for the XBox 360 last year, the Kinect for Windows SDK and now dedicated Kinect for Windows hardware device, has taken the world by storm. In the last year we've seen some simply amazing ideas and projects, many highlighted here in the Kinect for Windows Gallery, from health to education, to music expression to simply just fun.

And that was all with beta software and a device meant for a gaming console.

With a fully supported, allowed for use in commercial products, dedicated device and updated SDK, today the world changes again.

Welcome to the Kinect for Windows SDK v1!

Kinect for Windows is now Available!

On January 9th, Steve Ballmer announced at CES that we would be shipping Kinect for Windows on February 1st. I am very pleased to report that today version 1.0 of our SDK and runtime were made available for download, and distribution partners in our twelve launch countries are starting to ship Kinect for Windows hardware, enabling companies to start to deploy their solutions. The suggested retail price is $249, and later this year, we will offer special academic pricing of $149 for Qualified Educational Users.

In the three months since we released Beta 2, we have made many improvements to our SDK and runtime, including:

Support for up to four Kinect sensors plugged into the same computer

Significantly improved skeletal tracking, including the ability for developers to control which user is being tracked by the sensor

Near Mode for the new Kinect for Windows hardware, which enables the depth camera to see objects as close as 40 centimeters in front of the device

Many API updates and enhancements in the managed and unmanaged runtimes

The latest Microsoft Speech components (V11) are now included as part of the SDK and runtime installer

Improved “far-talk” acoustic model that increases speech recognition accuracy

New and updated samples, such as Kinect Explorer, which enables developers to explore the full capabilities of the sensor and SDK, including audio beam and sound source angles, color modes, depth modes, skeletal tracking, and motor controls

A commercial-ready installer which can be included in an application’s set-up program, making it easy to install the Kinect for Windows runtime and driver components for end-user deployments.

Robustness improvements including driver stability, runtime fixes, and audio fixes

More details can be found here.

If you're like me, you want to know more about what's new... So here's a snip from the Kinect for Windows SDK v1 Release Notes;

5. Changes since the Kinect for Windows SDK Beta 2 release

Support for up to 4 Kinect sensors plugged into the same computer, assuming the computer is powerful enough and they are plugged in to different USB controllers so that there is enough bandwidth available. (As before, skeletal tracking can only be used on one Kinect per process. The developer can choose which Kinect sensor.)

· Skeletal Tracking

The Kinect for Windows Skeletal Tracking system is now tracking subjects with results equivalent to the Skeletal Tracking library available in the November 2011 Xbox 360 Development Kit.

The Near Mode feature is now available. It is only functional on Kinect for Windows Hardware; see the Kinect for Windows Blog post for more information.

Robustness improvement including driver stability, runtime and audio fixes.

API Updates and Enhancements

See a blog post detailing migration information from Beta 2 to v1.0 here: Migrating from Beta 2

Many renaming changes to both the managed and native APIs for consistency and ease of development. Changes include:

Consolidation of managed and native runtime components into a minimal set of DLLs

Renaming of managed and native APIs to align with product team design guidelines

Renaming of headers, libs, and references assemblies

Significant managed API improvements:

Consolidation of namespaces into Microsoft.Kinect

Improvements to DepthData object

Skeleton data is now serializable

Audio API improvements, including the ability to connect to a specific Kinect on a computer with multiple Kinects

Improved error handling

Improved initialization APIs, including addition the Initializing state into the Status property and StatusChanged events

Set Tracked Skeleton API support is now available in native and managed code. Developers can use this API to lock on to 1 or 2 skeletons, among the possible 6 proposed.

Mapping APIs: The mapping APIs on KinectSensor that allow you to map depth pixels to color pixels have been updated for simplicity of usage, and are no longer restricted to 320x240 depth format.

The high-res RGB color mode of 1280x1024 has been replaced by the similar 1280x960 mode, because that is the mode supported by the official Kinect for Windows hardware.

Frame event improvements. Developers now receive frame events in the same order as Xbox 360, i.e. color then depth then skeleton, followed by an AllFramesReady event when all data frames are available.

Managed API Updates

Correct FPS for High Res Mode

ColorImageFormat.RgbResolution1280x960Fps15 to ColorImageFormat.RgbResolution1280x960Fps12

Enum Polish

Added Undefined enum value to a few Enums: ColorImageFormat, DepthImageFormat, and KinectStatus

Depth Values

DepthImageStream now defaults IsTooFarRangeEnabled to true (and removed the property).

Beyond the depth values that are returnable (800-4000 for DepthRange.Default and 400-3000 for DepthRange.Near), we also will return the following values:

DepthImageStream.TooNearDepth (for things that we know are less than the DepthImageStream.MinDepth)

DepthImageStream.TooFarDepth (for things that we know are more than the DepthImageStream.MaxDepth)

DepthImageStream.UnknownDepth (for things that we don’t know.)

Serializable Fixes for Skeleton Data

We’ve added the SerializableAttribute on Skeleton, JointCollection, Joint and SkeletonPoint

Mapping APIs

Performance improvements to the existing per pixel API.

Added a new API for doing full-frame conversions:

public void MapDepthFrameToColorFrame(DepthImageFormat depthImageFormat, short[] depthPixelData, ColorImageFormat colorImageFormat, ColorImagePoint[] colorCoordinates);

Added KinectSensor.MapSkeletonPointToColor()

public ColorImagePoint MapSkeletonPointToColor(SkeletonPoint skeletonPoint, ColorImageFormat colorImageFormat);

Misc

Renamed Skeleton.Quality to Skeleton.ClippedEdges

Changed return type of SkeletonFrame.FloorClipPlane to Tuple<int, int, int, int>.

Removed SkeletonFrame.NormalToGravity property.

· Audio & Speech

The Kinect SDK now includes the latest Microsoft Speech components (V11 QFE). Our runtime installer chain-installs the appropriate runtime components (32-bit speech runtime for 32-bit Windows, and both 32-bit and 64-bit speech runtimes for 64-bit Windows), plus an updated English Language pack (en-us locale) with improved recognition accuracy.

Updated acoustic model that improves the accuracy in the confidence numbers returned by the speech APIs

Kinect Speech Acoustic Model has now the same icon and similar description as the rest of the Kinect components

Echo cancellation will now recognize the system default speaker and attempt to cancel the noise coming from it automatically, if enabled.

Kinect Audio with AEC enabled now works even when no sound is coming from the speakers. Previously, this case caused problems.

Audio initialization has changed:

C++ code must call NuiInitialize before using the audio stream

Managed code must call KinectSensor.Start() before KinectAudioSource.Start()

It takes about 4 seconds after initialize is called before audio data begins to be delivered

Audio/Speech samples now wait for 4 seconds for Kinect device to be ready before recording audio or recognizing speech.

· Samples

A sample browser has been added, making it easier to find and view samples. A link to it is installed in the Start menu.

ShapeGame and KinectAudioDemo (via a new KinectSensorChooser component) demonstrate how to handle Kinect Status as well as inform users about erroneously trying to use a Kinect for Xbox 360 sensor.

The Managed Skeletal Viewer sample has been replaced by Kinect Explorer, which adds displays for audio beam angle and sound source angle/confidence, and provides additional control options for the color modes, depth modes, skeletal tracking options, and motor control. Click on “(click for settings)” at the bottom of the screen for all the bells and whistles.

Kinect Explorer (via an improved SkeletonViewer component) displays bones and joints differently, to better illustrate which joints are tracked with high confidence and which are not.

KinectAudioDemo no longer saves unrecognized utterances files in temp folder.

An example of AEC and Beam Forming usage has been added to the KinectAudioDemo application.

Redistributable Kinect for Windows Runtime package

There is a redist package, located in the redist subdirectory of the SDK install location. This redist is an installer exe that an application can include in its setup program, which installs the Kinect for Windows runtime and driver components.

The Great Disk Drive in the Sky: How Web giants store big—and we mean big—data

nospam@example.com (Christian Babski) — Mon, 06 Feb 2012 11:16:00 +0000

Via Ars Technica

-----

Google technicians test hard drives at their data center in Moncks Corner, South Carolina -- Image courtesy of Google Datacenter Video

Consider the tech it takes to back the search box on Google's home page: behind the algorithms, the cached search terms, and the other features that spring to life as you type in a query sits a data store that essentially contains a full-text snapshot of most of the Web. While you and thousands of other people are simultaneously submitting searches, that snapshot is constantly being updated with a firehose of changes. At the same time, the data is being processed by thousands of individual server processes, each doing everything from figuring out which contextual ads you will be served to determining in what order to cough up search results.

The storage system backing Google's search engine has to be able to serve millions of data reads and writes daily from thousands of individual processes running on thousands of servers, can almost never be down for a backup or maintenance, and has to perpetually grow to accommodate the ever-expanding number of pages added by Google's Web-crawling robots. In total, Google processes over 20 petabytes of data per day.

That's not something that Google could pull off with an off-the-shelf storage architecture. And the same goes for other Web and cloud computing giants running hyper-scale data centers, such as Amazon and Facebook. While most data centers have addressed scaling up storage by adding more disk capacity on a storage area network, more storage servers, and often more database servers, these approaches fail to scale because of performance constraints in a cloud environment. In the cloud, there can be potentially thousands of active users of data at any moment, and the data being read and written at any given moment reaches into the thousands of terabytes.

The problem isn't simply an issue of disk read and write speeds. With data flows at these volumes, the main problem is storage network throughput; even with the best of switches and storage servers, traditional SAN architectures can become a performance bottleneck for data processing.

Then there's the cost of scaling up storage conventionally. Given the rate that hyper-scale web companies add capacity (Amazon, for example, adds as much capacity to its data centers each day as the whole company ran on in 2001, according to Amazon Vice President James Hamilton), the cost required to properly roll out needed storage in the same way most data centers do would be huge in terms of required management, hardware, and software costs. That cost goes up even higher when relational databases are added to the mix, depending on how an organization approaches segmenting and replicating them.

The need for this kind of perpetually scalable, durable storage has driven the giants of the Web—Google, Amazon, Facebook, Microsoft, and others—to adopt a different sort of storage solution: distributed file systems based on object-based storage. These systems were at least in part inspired by other distributed and clustered filesystems such as Red Hat's Global File System and IBM's General Parallel Filesystem.

The architecture of the cloud giants' distributed file systems separates the metadata (the data about the content) from the stored data itself. That allows for high volumes of parallel reading and writing of data across multiple replicas, and the tossing of concepts like "file locking" out the window.

The impact of these distributed file systems extends far beyond the walls of the hyper-scale data centers they were built for— they have a direct impact on how those who use public cloud services such as Amazon's EC2, Google's AppEngine, and Microsoft's Azure develop and deploy applications. And companies, universities, and government agencies looking for a way to rapidly store and provide access to huge volumes of data are increasingly turning to a whole new class of data storage systems inspired by the systems built by cloud giants. So it's worth understanding the history of their development, and the engineering compromises that were made in the process.

Google File System

Google was among the first of the major Web players to face the storage scalability problem head-on. And the answer arrived at by Google's engineers in 2003 was to build a distributed file system custom-fit to Google's data center strategy—Google File System (GFS).

GFS is the basis for nearly all of the company's cloud services. It handles data storage, including the company's BigTable database and the data store for Google's AppEngine platform-as-a-service, and it provides the data feed for Google's search engine and other applications. The design decisions Google made in creating GFS have driven much of the software engineering behind its cloud architecture, and vice-versa. Google tends to store data for applications in enormous files, and it uses files as "producer-consumer queues," where hundreds of machines collecting data may all be writing to the same file. That file might be processed by another application that merges or analyzes the data—perhaps even while the data is still being written.

Google keeps most technical details of GFS to itself, for obvious reasons. But as described by Google research fellow Sanjay Ghemawat, principal engineer Howard Gobioff, and senior staff engineer Shun-Tak Leung in a paper first published in 2003, GFS was designed with some very specific priorities in mind: Google wanted to turn large numbers of cheap servers and hard drives into a reliable data store for hundreds of terabytes of data that could manage itself around failures and errors. And it needed to be designed for Google's way of gathering and reading data, allowing multiple applications to append data to the system simultaneously in large volumes and to access it at high speeds.

Much in the way that a RAID 5 storage array "stripes" data across multiple disks to gain protection from failures, GFS distributes files in fixed-size chunks which are replicated across a cluster of servers. Because they're cheap computers using cheap hard drives, some of those servers are bound to fail at one point or another—so GFS is designed to be tolerant of that without losing (too much) data.

But the similarities between RAID and GFS end there, because those servers can be distributed across the network—either within a single physical data center or spread over different data centers, depending on the purpose of the data. GFS is designed primarily for bulk processing of lots of data. Reading data at high speed is what's important, not the speed of access to a particular section of a file, or the speed at which data is written to the file system. GFS provides that high output at the expense of more fine-grained reads and writes to files and more rapid writing of data to disk. As Ghemawat and company put it in their paper, "small writes at arbitrary positions in a file are supported, but do not have to be efficient."

This distributed nature, along with the sheer volume of data GFS handles—millions of files, most of them larger than 100 megabytes and generally ranging into gigabytes—requires some trade-offs that make GFS very much unlike the sort of file system you'd normally mount on a single server. Because hundreds of individual processes might be writing to or reading from a file simultaneously, GFS needs to supports "atomicity" of data—rolling back writes that fail without impacting other applications. And it needs to maintain data integrity with a very low synchronization overhead to avoid dragging down performance.

GFS consists of three layers: a GFS client, which handles requests for data from applications; a master, which uses an in-memory index to track the names of data files and the location of their chunks; and the "chunk servers" themselves. Originally, for the sake of simplicity, GFS used a single master for each cluster, so the system was designed to get the master out of the way of data access as much as possible. Google has since developed a distributed master system that can handle hundreds of masters, each of which can handle about 100 million files.

When the GFS client gets a request for a specific data file, it requests the location of the data from the master server. The master server provides the location of one of the replicas, and the client then communicates directly with that chunk server for reads and writes during the rest of that particular session. The master doesn't get involved again unless there's a failure.

To ensure that the data firehose is highly available, GFS trades off some other things—like consistency across replicas. GFS does enforce data's atomicity—it will return an error if a write fails, then rolls the write back in metadata and promotes a replica of the old data, for example. But the master's lack of involvement in data writes means that as data gets written to the system, it doesn't immediately get replicated across the whole GFS cluster. The system follows what Google calls a "relaxed consistency model" out of the necessities of dealing with simultaneous access to data and the limits of the network.

This means that GFS is entirely okay with serving up stale data from an old replica if that's what's the most available at the moment—so long as the data eventually gets updated. The master tracks changes, or "mutations," of data within chunks using version numbers to indicate when the changes happened. As some of the replicas get left behind (or grow "stale"), the GFS master makes sure those chunks aren't served up to clients until they're first brought up-to-date.

But that doesn't necessarily happen with sessions already connected to those chunks. The metadata about changes doesn't become visible until the master has processed changes and reflected them in its metadata. That metadata also needs to be replicated in multiple locations in case the master fails—because otherwise the whole file system is lost. And if there's a failure at the master in the middle of a write, the changes are effectively lost as well. This isn't a big problem because of the way that Google deals with data: the vast majority of data used by its applications rarely changes, and when it does data is usually appended rather than modified in place.

While GFS was designed for the apps Google ran in 2003, it wasn't long before Google started running into scalability issues. Even before the company bought YouTube, GFS was starting to hit the wall—largely because the new applications Google was adding didn't work well with the ideal 64-megabyte file size. To get around that, Google turned to Bigtable, a table-based data store that vaguely resembles a database and sits atop GFS. Like GFS below it, Bigtable is mostly write-once, so changes are stored as appends to the table—which Google uses in applications like Google Docs to handle versioning, for example.

The foregoing is mostly academic if you don't work at Google (though it may help users of AppEngine, Google Cloud Storage and other Google services to understand what's going on under the hood a bit better). While Google Cloud Storage provides a public way to store and access objects stored in GFS through a Web interface, the exact interfaces and tools used to drive GFS within Google haven't been made public. But the paper describing GFS led to the development of a more widely used distributed file system that behaves a lot like it: the Hadoop Distributed File System.

Hadoop DFS

Developed in Java and open-sourced as a project of the Apache Foundation, Hadoop has developed such a following among Web companies and others coping with "big data" problems that it has been described as the "Swiss army knife of the 21st Century." All the hype means that sooner or later, you're more likely to find yourself dealing with Hadoop in some form than with other distributed file systems—especially when Microsoft starts shipping it as an Windows Server add-on.

Named by developer Doug Cutting after his son's stuffed elephant, Hadoop was "inspired" by GFS and Google's MapReduce distributed computing environment. In 2004, as Cutting and others working on the Apache Nutch search engine project sought a way to bring the crawler and indexer up to "Web scale," Cutting read Google's papers on GFS and MapReduce and started to work on his own implementation. While most of the enthusiasm for Hadoop comes from Hadoop's distributed data processing capability, derived from its MapReduce-inspired distributed processing management, the Hadoop Distributed File System is what handles the massive data sets it works with.

Hadoop is developed under the Apache license, and there are a number of commercial and free distributions available. The distribution I worked with was from Cloudera (Doug Cutting's current employer)—the Cloudera Distribution Including Apache Hadoop (CDH), the open-source version of Cloudera's enterprise platform, and Cloudera Service and Configuration Express Edition, which is free for up to 50 nodes.

HortonWorks, the company with which Microsoft has aligned to help move Hadoop to Azure and Windows Server (and home to much of the original Yahoo team that worked on Hadoop), has its own Hadoop-based HortonWorks Data Platform in a limited "technology preview" release. There's also a Debian package of the Apache Core, and a number of other open-source and commercial products that are based on Hadoop in some form.

HDFS can be used to support a wide range of applications where high volumes of cheap hardware and big data collide. But because of its architecture, it's not exactly well-suited to general purpose data storage, and it gives up a certain amount of flexibility. HDFS has to do away with certain things usually associated with file systems in order to make sure it can perform well with massive amounts of data spread out over hundreds, or even thousands, of physical machines—things like interactive access to data.

While Hadoop runs in Java, there are a number of ways to interact with HDFS besides its Java API. There's a C-wrapped version of the API, a command line interface through Hadoop, and files can be browsed through HTTP requests. There's also MountableHDFS, an add-on based on FUSE that allows HDFS to be mounted as a file system by most operating systems. Developers are working on a WebDAV interface as well to allow Web-based writing of data to the system.

HDFS follows the architectural path laid out by Google's GFS fairly closely, following its three-tiered, single master model. Each Hadoop cluster has a master server called the "NameNode" which tracks the metadata about the location and replication state of each 64-megabyte "block" of storage. Data is replicated across the "DataNodes" in the cluster—the slave systems that handle data reads and writes. Each block is replicated three times by default, though the number of replicas can be increased by changing the configuration of the cluster.

As in GFS, HDFS gets the master server out of the read-write loop as quickly as possible to avoid creating a performance bottleneck. When a request is made to access data from HDFS, the NameNode sends back the location information for the block on the DataNode that is closest to where the request originated. The NameNode also tracks the health of each DataNode through a "heartbeat" protocol and stops sending requests to DataNodes that don't respond, marking them "dead."

After the handoff, the NameNode doesn't handle any further interactions. Edits to data on the DataNodes are reported back to the NameNode and recorded in a log, which then guides replication across the other DataNodes with replicas of the changed data. As with GFS, this results in a relatively lazy form of consistency, and while the NameNode will steer new requests to the most recently modified block of data, jobs in progress will still hit stale data on the DataNodes they've been assigned to.

That's not supposed to happen much, however, as HDFS data is supposed to be "write once"—changes are usually appended to the data, rather than overwriting existing data, making for simpler consistency. And because of the nature of Hadoop applications, data tends to get written to HDFS in big batches.

When a client sends data to be written to HDFS, it first gets staged in a temporary local file by the client application until the data written reaches the size of a data block—64 megabytes, by default. Then the client contacts the NameNode and gets back a datanode and block location to write the data to. The process is repeated for each block of data committed, one block at a time. This reduces the amount of network traffic created, and it slows down the write process as well. But HDFS is all about the reads, not the writes.

Another way HDFS can minimize the amount of write traffic over the network is in how it handles replication. By activating an HDFS feature called "rack awareness" to manage distribution of replicas, an administrator can specify a rack ID for each node, designating where it is physically located through a variable in the network configuration script. By default, all nodes are in the same "rack." But when rack awareness is configured, HDFS places one replica of each block on another node within the same data center rack, and another in a different rack to minimize the amount of data-writing traffic across the network—based on the reasoning that the chance of a whole rack failure is less likely than the failure of a single node. In theory, this improves overall write performance to HDFS without sacrificing reliability.

As with the early version of GFS, HDFS's NameNode potentially creates a single point of failure for what's supposed to be a highly available and distributed system. If the metadata in the NameNode is lost, the whole HDFS environment becomes essentially unreadable—like a hard disk that has lost its file allocation table. HDFS supports using a "backup node," which keeps a synchronized version of the NameNode's metadata in-memory, and stores snap-shots of previous states of the system so that it can be rolled back if necessary. Snapshots can also be stored separately on what's called a "checkpoint node." However, according to the HDFS documentation, there's currently no support within HDFS for automatically restarting a crashed NameNode, and the backup node doesn't automatically kick in and replace the master.

HDFS and GFS were both engineered with search-engine style tasks in mind. But for cloud services targeted at more general types of computing, the "write once" approach and other compromises made to ensure big data query performance are less than ideal—which is why Amazon developed its own distributed storage platform, called Dynamo.

Amazon's S3 and Dynamo

As Amazon began to build its Web services platform, the company had much different application issues than Google.

Until recently, like GFS, Dynamo hasn't been directly exposed to customers. As Amazon CTO Werner Vogels explained in his blog in 2007, it is the underpinning of storage services and other parts of Amazon Web Services that are highly exposed to Amazon customers, including Amazon's Simple Storage Service (S3) and SimpleDB. But on January 18 of this year, Amazon launched a database service called DynamoDB, based on the latest improvements to Dynamo. It gave customers a direct interface as a "NoSQL" database.

Dynamo has a few things in common with GFS and HDFS: it's also designed with less concern for consistency of data across the system in exchange for high availability, and to run on Amazon's massive collection of commodity hardware. But that's where the similarities start to fade away, because Amazon's requirements for Dynamo were totally different.

Amazon needed a file system that could deal with much more general purpose data access—things like Amazon's own e-commerce capabilities, including customer shopping carts, and other very transactional systems. And the company needed much more granular and dynamic access to data. Rather than being optimized for big streams of data, the need was for more random access to smaller components, like the sort of access used to serve up webpages.

According to the paper presented by Vogels and his team at the Symposium on Operating Systems Principles conference in October 2007, "Dynamo targets applications that need to store objects that are relatively small (usually less than 1 MB)." And rather than being optimized for reads, Dynamo is designed to be "always writeable," being highly available for data input—precisely the opposite of Google's model.

"For a number of Amazon services," the Amazon Dynamo team wrote in their paper, "rejecting customer updates could result in a poor customer experience. For instance, the shopping cart service must allow customers to add and remove items from their shopping cart even amidst network and server failures." At the same time, the services based on Dynamo can be applied to much larger data sets—in fact, Amazon offers the Hadoop-based Elastic MapReduce service based on S3 atop of Dynamo.

In order to meet those requirements, Dynamo's architecture is almost the polar opposite of GFS—it more closely resembles a peer-to-peer system than the master-slave approach. Dynamo also flips how consistency is handled, moving away from having the system resolve replication after data is written, and instead doing conflict resolution on data when executing reads. That way, Dynamo never rejects a data write, regardless of whether it's new data or a change to existing data, and the replication catches up later.

Because of concerns about the pitfalls of a central master server failure (based on previous experiences with service outages), and the pace at which Amazon adds new infrastructure to its cloud, Vogel's team chose a decentralized approach to replication. It was based on a self-governing data partitioning scheme that used the concept of consistent hashing. The resources within each Dynamo cluster are mapped as a continuous circle of address spaces, and each storage node in the system is given a random value as it is added to the cluster—a value that represents its "position" on the Dynamo ring. Based on the number of storage nodes in the cluster, each node takes responsibility for a chunk of address spaces based on its position. As storage nodes are added to the ring, they take over chunks of address space and the nodes on either side of them in the ring adjust their responsibility. Since Amazon was concerned about unbalanced loads on storage systems as newer, better hardware was added to clusters, Dynamo allows multiple virtual nodes to be assigned to each physical node, giving bigger systems a bigger share of the address space in the cluster.

When data gets written to Dynamo—through a "put" request—the systems assigns a key to the data object being written. That key gets run through a 128-bit MD5 hash; the value of the hash is used as an address within the ring for the data. The data node responsible for that address becomes the "coordinator node" for that data and is responsible for handling requests for it and prompting replication of the data to other nodes in the ring, as shown in the Amazon diagram below:

This spreads requests out across all the nodes in the system. In the event of a failure of one of the nodes, its virtual neighbors on the ring start picking up requests and fill in the vacant space with their replicas.

Then there's Dynamo's consistency-checking scheme. When a "get" request comes in from a client application, Dynamo polls its nodes to see who has a copy of the requested data. Each node with a replica responds, providing information about when its last change was made, based on a vector clock—a versioning system that tracks the dependencies of changes to data. Depending on how the polling is configured, the request handler can wait to get just the first response back and return it (if the application is in a hurry for any data and there's low risk of a conflict—like in a Hadoop application) or it can wait for two, three, or more responses. For multiple responses from the storage nodes, the handler checks to see which is most up-to-date and alerts the nodes that are stale to copy the data from the most current, or it merges versions that have non-conflicting edits. This scheme works well for resiliency under most circumstances—if nodes die, and new ones are brought online, the latest data gets replicated to the new node.

The most recent improvements in Dynamo, and the creation of DynamoDB, were the result of looking at why Amazon's internal developers had not adopted Dynamo itself as the base for their applications, and instead relied on the services built atop it—S3, SimpleDB, and Elastic Block Storage. The problems that Amazon faced in its April 2011 outage were the result of replication set up between clusters higher in the application stack—in Amazon's Elastic Block Storage, where replication overloaded the available additional capacity, rather than because of problems with Dynamo itself.

The overall stability of Dynamo has made it the inspiration for open-source copycats just as GFS did. Facebook relies on Cassandra, now an Apache project, which is based on Dynamo. Basho's Riak "NoSQL" database also is derived from the Dynamo architecture.

Microsoft's Azure DFS

When Microsoft launched the Azure platform-as-a-service, it faced a similar set of requirements to those of Amazon—including massive amounts of general-purpose storage. But because it's a PaaS, Azure doesn't expose as much of the infrastructure to its customers as Amazon does with EC2. And the service has the benefit of being purpose-built as a platform to serve cloud customers instead of being built to serve a specific internal mission first.

So in some respects, Azure's storage architecture resembles Amazon's—it's designed to handle a variety of sizes of "blobs," tables, and other types of data, and to provide quick access at a granular level. But instead of handling the logical and physical mapping of data at the storage nodes themselves, Azure's storage architecture separates the logical and physical partitioning of data into separate layers of the system. While incoming data requests are routed based on a logical address, or "partition," the distributed file system itself is broken into gigabyte-sized chunks, or "extents." The result is a sort of hybrid of Amazon's and Google's approaches, illustrated in this diagram from Microsoft:

As Microsoft's Brad Calder describes in his overview of Azure's storage architecture, Azure uses a key system similar to that used in Dynamo to identify the location of data. But rather than having the application or service contact storage nodes directly, the request is routed through a front-end layer that keeps a map of data partitions in a role similar to that of HDFS's NameNode. Unlike HDFS, Azure uses multiple front-end servers, load balancing requests across them. The front-end server handles all of the requests from the client application authenticating the request, and handles communicating with the next layer down—the partition layer.

Each logical chunk of Azure's storage space is managed by a partition server, which tracks which extents within the underlying DFS hold the data. The partition server handles the reads and writes for its particular set of storage objects. The physical storage of those objects is spread across the DFS' extents, so all partition servers each have access to all of the extents in the DFS. In addition to buffering the DFS from the front-end servers's read and write requests, the partition servers also cache requested data in memory, so repeated requests can be responded to without having to hit the underlying file system. That boosts performance for small, frequent requests like those used to render a webpage.

All of the metadata for each partition is replicated back to a set of "partition master" servers, providing a backup of the information if a partition server fails—if one goes down, its partitions are passed off to other partition servers dynamically. The partition masters also monitor the workload on each partition server in the Azure storage cluster; if a particular partition server is becoming overloaded, the partition master can dynamically re-assign partitions.

Azure is unlike the other big DFS systems in that it more tightly enforces consistency of data writes. Replication of data happens when writes are sent to the DFS, but it's not the lazy sort of replication that is characteristic of GFS and HDFS. Each extent of storage is managed by a primary DFS server and replicated to multiple secondaries; one DFS server may be a primary for a subset of extents and a secondary server for others. When a partition server passes a write request to DFS, it contacts the primary server for the extent the data is being written to, and the primary passes the write to its secondaries. The write is only reported as successful when the data has been replicated successfully to three secondary servers.

As with the partition layer, Azure DFS uses load balancing on the physical layer in an attempt to prevent systems from getting jammed with too much I/O. Each partition server monitors the workload on the primary extent servers it accesses; when a primary DFS server starts to red-line, the partition server starts redirecting read requests to secondary servers, and redirecting writes to extents on other servers.

The next level of "distributed"

Distributed file systems are hardly a guarantee of perpetual uptime. In most cases, DFS's only replicate within the same data center because of the amount of bandwidth required to keep replicas in sync. But replication within the data center, for example doesn't help when the whole data center gets taken offline or a backup network switch fails to kick in when the primary fails. In August, Microsoft and Amazon both had data centers in Dublin taken offline by a transformer explosion—which created a spike that kept backup generators from starting.

Systems that are lazier about replication, such as GFS and Hadoop, can asynchronously handle replication between two data centers; for example, using "rack awareness," Hadoop clusters can be configured to point to a DataNode offsite, and metadata can be passed to a remote checkpoint or backup node (at least in theory). But for more dynamic data, that sort of replication can be difficult to manage.

That's one of the reasons Microsoft released a feature called "geo-replication" in September. Geo-replication is a feature that will sync customers' data between two data center locations hundred of miles apart. Rather than using the tightly coupled replication Microsoft uses within the data center, geo-replication happens asynchronously. Both of the Azure data centers have to be in the same region; for example, data for an application set up through the Azure Portal at the North Central US data center can be replicated to the South Central US.

In Amazon's case, the company does replication across availability zones at a service level rather than down in the Dynamo architecture. While Amazon hasn't published how it handles its own geo-replication, it provides customers with the ability to "snap shot" their EBS storage to a remote S3 data "bucket."

And that's the approach Amazon and Google have generally taken in evolving their distributed file systems: making the fixes in the services based on them, rather than in the underlying architecture. While Google has added a distributed master system to GFS and made other tweaks to accommodate its ever-growing data flows, the fundamental architecture of Google's system is still very much like it was in 2003.

But in the long term, the file systems themselves may become more focused on being an archive of data than something applications touch directly. In an interview with Ars, database pioneer (and founder of VoltDB) Michael Stonebraker said that as data volumes continue to go up for "big data" applications, server memory is becoming "the new disk" and file systems are becoming where the log for application activity gets stored—"the new tape." As the cloud giants push for more power efficiency and performance from their data centers, they have already moved increasingly toward solid-state drives and larger amounts of system memory.

The rise and fall of personal computing

nospam@example.com (Christian Babski) — Wed, 18 Jan 2012 11:26:00 +0000

Via asymco

-----

Thanks to Jeremy Reimer I was able to create the following view into the history of computer platforms.

I added data from the smartphone industry, Apple and updated the PC industry figures with those from Gartner. Note the log scale.

The same information is available as an animation in the following video (Music by Nora Tagle):

This data combines several “categories” of products and is not complete in that not all mobile phone platforms are represented. However, the zooming out offers several possible observations into the state of the “personal computing” world as of today.

We cannot consider the iPad as a “niche”. The absolute volume of units sold after less than two years is enough to place it within an order of magnitude of all PCs sold. We can also observe that it has a higher trajectory than the iPhone which became a disruptive force in itself. Compare these challengers to NeXT in 1991.
The “entrants” into personal computing, the iPad, iPhone and Android, have a combined volume that is higher than the PCs sold in the same period (358 million estimated iOS+Android vs. 336 million PCs excluding Macs in 2011.) The growth rate and the scale itself combine to make the entrants impossible to ignore.
There is a distinct grouping of platform options into three phases or eras. The first lasting from 1975 to 1991 was an era of rapid growth but also of multiple standards and experiments. It was typical of an industry in emergence. The personalization of computing brought about a new set of entrants. The second phase lasted between 1991 and 2007 and was characterized by a near monopoly of Microsoft, but, crucially one alternative platform did survive. The third phase can be seen as starting five years ago with the emergence of the iPhone and its derivatives. It has similarities to the first phase.

We can also look at the data through a slightly different view: market share. Share is a bit more subjective because we need to combine products in ways that are considered comparable (or competing).

First, this is a “traditionalist” view of the PC market as defined by Gartner and IDC, and excluding tablets and smartphones.

This view would imply that the PC market is not changing in any substantial way. Although the Mac platform is gaining share, there is no significant erosion in the power of the incumbent.

Second, is a view where the iPad is added to the traditionalist view.

This view is more alarming. Given the first chart, in order for the iPad to be significant, it would need to be “visible” for a market that already ships over 350 million units. And there it is. If counted, the iPad begins to show the first disruption in the status quo since 1991.

The third view is with the addition of iPhone and Android.

This last view corresponds to the data in the first graph (line chart). If iOS and Android are added as potential substitutions for personal computing, the share of PCs suddenly collapses to less than 50%. It also suggests much more collapse to come.

I will concede that this last view is extremist. It does not reflect a competition that exists in real life. However, I put this data together to show a historic pattern. Sometimes extremism is a better point of view than conservatism. Ignoring this view is very harmful as these not-good-enough computers will surely get better. A competitor that has no strategy to deal with this shift is likely to suffer the fate of those companies in the left side of the chart. Treating the first share chart as reality is surely much more dangerous than contemplating the third.

I’ve used anecdotes in the past to tell the story of the disruptive shift in the fortunes of computing incumbents and entrants. I’ve also shown how the entry of smart devices has disrupted the telecom world and caused a transfer of wealth away from the old guard.

The data shown here frames these anecdotes. The data is not the whole story but it solidifies what should be an intuition.

Cube: The Apple Macintosh of 3D printers has finally arrived

nospam@example.com (Christian Babski) — Thu, 12 Jan 2012 19:12:05 +0000

Via DVICE

-----

Many of us have been waiting for the moment when 3D printers would not only be offered ready-to-use without the need of DIY assembly, but at a price comparable to a common computer. Well get excited, because that day has arrived.

Created by 3D Systems, the Cube will retail for just $1,299 and is connected to a community of 3D designers where you can find inspiration, or upload your own designs and sell them in the Cubify marketplace. Admittedly, the MakerBot Replicator is only a tad more expensive at $1,749, but just like the early versions of the home Windows PC versus the Mac, the Cube wins on style points for those who prefer a less industrial look and feel to their 3D printer.

You can order the Cube 3D printer here and check out the design to fabrication process in the video below.

Personal comment:

Refer also to previous posts on this topic.

This is why you'll want a 3D printer for Christmas

Modular’ 3D Printed Shoes

The First Industrial Evolution

World's first 'printed' plane snaps together and flies