When thinking about the scale of computing problems, consider the rendering times of Ratatouille:

During Ratatouille, the renderfarm consisted of about 850 machines with nearly 3200 processors between them. When rendering the final Ratatouille film frames on a 2.66 GHz processor, each frame took an average of six hours. It took about 1532 CPU-years to render Ratatouille, including the lower-resolution renders done at various points in the pipeline and working iterations. That means that if we only had one CPU in the renderfarm, Ratatouille wouldn’t have been released until the year 3539. To store the images generated while making the movie, we used 12 terabytes of disk space.

Scaling Twitter, covering the path the Twitter developers took to scale their growing Rails application.

Hey folks, it’s the Chumby, a hackable Freescale wifi device.

A Distributed Storage System for Structured Data PDF (local cache) describes Google’s gargantuan distributed storage system. One of the most amazing aspects of the system’s develompent was the scale that they tested it at:

The tablet servers were configured to use 1 GB of memory and to write to a GFS cell consisting of 1786 machines with two 400 GB IDE hard drives each.

I regularly hear developers complain about how difficult it is to set up realistic tests. I think those developers are just lazy, unskilled, or working for the wrong company.

Weird, Bloglines uses flat files for most of its backend datastore (instead of a database). I’ve always liked flat files at smaller scales, interesting to see it used for larger problems.

The adventures of scaling, a story about a successful, large scale Ruby site.

99.999% uptime is for Wal-Mart.

IBM poop heads say LAMP users need to “grow up”
Nope. We call bullshit. After wasting years of our lives trying to implement physical three tier architectures that “scale” and failing miserably time after time, we’re going with something that actually works.

I made my first panorama today, stitching together a few pictures I took hiking last weekend. I used the hugin panorama tools, which are freely available for Linux, Microsoft Windows, and OSX.

The panorama

This is a wider view of one of our favorite hikes in the area. The raw image measures 4,800 pixels wide (after cropping), which combines the two 2,400 pixel source images. I only used 7 control points in this test, so a few of the seams are slightly visible. Had I doubled the number of control points (or used a tripod), the image would have been seamless.

The wider view was created by stitching two hand-held digicam shots together. The process allows any number of images to be merged, but I only had two useful shots that overlapped. Here are the source images (scaled down a bit):

panorama_part_1.jpeg	panorama_part_2.jpeg

The process

First off, I suggest you read the tutorials on the hugin panorama tools home page. It’s a complicated tool, and it took me a few passes before I understood what it was doing.

1. Take some pictures that overlap (by hand, or on a tripod). Copy the images to a temporary directory.

2. In the tool, add each image and tag with the overlap information. Use as many points as you can find between each image, as the tool works better with more control points.

3. Process and wait. 2 images, on my 2Ghz laptop takes about 3 minutes to process.

The software does a great job, and can stitch hundreds of images together. I’m going to try a few more complicated panoramas on the next hike, and maybe a few with my tripod at home.