But first a couple of definitions:

• Libvirt is an API/toolkit for interacting with Linux virtualization systems (including KVM/QEMU, Xen, OpenVZ, Oracle VirtualBox, VMWare ESX/GSX/Workstation/Player, Microsoft Hyper-V, LXC, UML, etc). It is a very active project that is widely used by many (maybe most) higher level virtualization platforms.
• Clojure is a relative new language that brings the dynamic power of LISP to the huge Java ecosystem. At LonoCloud we are using Clojure to create an operating system for cloud applications (more on that in later posts).

It is a truism that any time you have two awesome (or not so awesome) ideas, eventually somebody will try to put them together. Fortunately in this case, Libvirt provides Java API bindings which means it also has Clojure bindings so combining them is quite easy. Let's get started...

Prerequisites

My assumption is that you have a access to Linux system on which you have administrator/sudo permission.

Familiarity with Clojure and libvirt will be helpful but not critical for following this walkthrough. If you are familiar with libvirt and the libvirt APIs but are new to Clojure then this walkthrough will give you a taste for the power and expressiveness of Clojure.

Install a Java JDK if you don't have one already. On an Ubuntu-like system you can do something like this:

sudo apt-get install openjdk-7-jdk  # 6 for older systems
sudo update-alternatives --config java  # select the one just installed

Install the libvirt library and libvirtd service. On a Ubuntu-like system you can do something like this:

sudo apt-get install libvirt-bin libvirt0

Download the leiningen script to somewhere on your PATH. Here is an example that assumes you have $HOME/bin on your PATH.

wget https://raw.github.com/technomancy/leiningen/stable/bin/lein -O $HOME/bin/lein
chmod +x $HOME/bin/lein

Launch the REPL

Use lein to create a new project skeleton.

lein new clj-libvirt
cd clj-libvirt

Add JNA and libvirt Java bindings to the leiningen project.clj file. It should look something like this:

(defproject clj-libvirt "1.0.0-SNAPSHOT"
    :description "Use Libvirt from Clojure"
    :dependencies [[org.clojure/clojure "1.2.1"]
                    [net.java.dev.jna/jna "3.3.0"]
                    [org.libvirt/libvirt "0.4.7"]])

Use lein to pull down the project dependencies.

lein deps

Start a Clojure REPL using lein. This REPL environment will have all the project dependencies available on the Java CLASSPATH.

lein repl

Libvirt from Clojure

You should now have a Clojure REPL (read eval print loop) running with the "user=>" prompt indicating that we are in the default REPL namespace called "user" and that the REPL is waiting for input. In the following examples I will show the REPL prompt followed by the text to type followed by the output and/or return value resulting from running the command.

Start by importing the Libvirt Connect object.

    user=> (import '(org.libvirt Connect))
    org.libvirt.Connect

Now create a connection to the libvirt mock/test driver which is an ephemeral memory only driver for test purposes. The "Connect." syntax is the Clojure way of calling a Java constructor.

    user=> (def mock-conn (Connect. "test:///default" false))
    #'user/mock-conn

    user=> mock-conn
    #<Connect org.libvirt.Connect@50903025>

Make sure things are working by querying the Libvirt library version. Note that getLibVirVersion is a (Java) method of the connection object we defined above.

    user=> (.getLibVirVersion mock-conn)
    7005

Domains

The test driver automatically starts with a faux virtual machine that is defined and "running". List the running domains (virtual machine instances are called domains in libvirt terminology).

    user=> (.listDomains mock-conn)
    #<int[] [I@4a504ec1>

That's less than useful. This ugly output indicates that we have a Java array of ints. Wrap this in Clojure sequence which the REPL knows how to print.

    user=> (seq (.listDomains mock-conn))
    (1)

Much better. This indicates we have one running domain that has an ID of 1. To interact with the domain you need use one of the Connect methods that returns a Domain object (domainLookupBy*). We know the running domain ID, so use domainLookupByID method to get a domain object. Then get the name of the domain and info about it.

    user=> (def mock-dom (.domainLookupByID mock-conn 1))
    #`user/mock-dom

    user=> mock-dom
    #<Domain org.libvirt.Domain@5a56b93a>

    user=> (.getName mock-dom)
    "test"

    user=> (.getInfo mock-dom)
    #<DomainInfo state:VIR_DOMAIN_RUNNING
    maxMem:8388608
    memory:2097152
    nrVirtCpu:2
    cpuTime:1322765442068879000
    >

Domain Control

Now stop the domain and verify that it is off.

    user=> (.destroy mock-dom)
    nil

    user=> (.getInfo mock-dom)
    #<DomainInfo state:VIR_DOMAIN_SHUTOFF
    maxMem:8388608
    memory:2097152
    nrVirtCpu:2
    cpuTime:1323714453027037000
    >

Now start it back up again.

    user=> (.create mock-dom)
    0

    user=> (.getInfo mock-dom)
    #<DomainInfo state:VIR_DOMAIN_RUNNING
    maxMem:8388608
    memory:2097152
    nrVirtCpu:2
    cpuTime:1323714627116985000
    >

Getting More Info

The Connection and Domain objects have a number of useful methods. List their methods names by mapping the getName method onto the list of methods.

    user=> (map #(.getName %) (.getMethods (class mock-conn)))
    ("finalize" "close" "getType" "getHostName" ...)
    user=> (map #(.getName %) (.getMethods (class mock-dom)))
    ("shutdown" "finalize" "getName" "destroy" ...)

Those are mind-numblingly long lists of methods. For a user-readable reference you will probably want to use the Libvirt javadoc page.

Conclusion

That's all for now. I hope you have seen in this post how easy it is to interact with and control Libvirt from Clojure. Of course, we haven't actually done anything useful yet since the only interaction was with Libvirt mock/test driver. In a follow-up post I will walk through creating and interacting with real virtual domains instead of just virtual virtual domains.

or The New Web Platform

or An Introduction to HTML5

A Little Perspective

The Birth of the Web

20 years ago today (Aug 6th, 1991), Tim Berners-Lee released the World Wide Web on the world while working at CERN. Actually what he released was a program called "WorldWideWeb" which was eventually renamed "Nexus" to clarify the distinction between the concept of the World Wide Web and the browser itself.

The initial browser could render documents written in HyperText Markup Language (HTML). The first HTML supported some limited formatting and hyperlinks (we just call them links now) to other documents. Here is a screenshot from 2 years later when color and inline images were added:

WorldWideWeb Browser Running on a NeXT System

The Rise of the Web

In the next 10 years "the Web" exploded in terms of innovation, standardization (Footnote 1), number of users, browsers (installs and variations), web servers (installs and variations), and economic impact. With the release of Mosaic (at NCSA) in 1993, with its seamless integration of graphics and text, the World Wide Web quickly grew to become the dominant use of the Internet and the driving force behind Internet adoption. In fact, for most computer users "the Web" and "the Internet" have become synonymous.

The Fall of the Web

At the turn of the century, Web innovation slowed due to the emergence of Microsoft's Internet Explorer as a near monopoly in the web browser market. Once Microsoft achieved a controlling share of the web browser market they lost interest in driving or cooperating on new Web standards and technologies because this might threaten their profitable Windows platform.

The Rise of the Web (Again)

In the last three years there has been a new explosion of Web innovation. The Web has been released from its cage by three main trends: the rise of Mozilla Firefox (a spiritual descendant of the Mosaic browser), the rise of Google Chrome, and the rise of mobile devices.

Web Browser Market Share (Wikimedia)

A core part of human nature is to give names to everything including to abstract concepts. The new energy and innovation surrounding the Web platform is no exception; it needs a name. Which brings us to "HTML5" ...

"HTML5"

Technically, HTML5 is a specification from the World Wide Web Consortium (W3C) (Footnote 2). Many pedants will claim this is the only correct usage. For the rest of us, HTML5 is a useful term to describe the rapid changes that are currently happening to the Web platform. This is what I will mean when I use the term "HTML5". I will refer to the formal specification as "W3C HTML5".

W3C HTML5

Although the W3C HTML5 specification is not going to be officially complete until 2014, the specification finished last call review earlier this week (Aug 3rd) so there are unlikely to be any radical changes in the next three years before finalization.

W3C HTML5 is Boring

The W3C HTML5 is very important at one level, but it is also pretty boring. It is basically a formal description of the state-of-the art in the Web platform from 3 years ago. The actual content of the specification is pretty mundane (even apart from the dry and technical nature of specification documents). The most interesting API in the W3C HTML5 is the Canvas 2D Context and that is defined in a separate document.

W3C HTML5 is Important

However, the W3C HTML5 is important because it makes official all the good ideas that have been learned over the years and it attempts to remove most of the things that are now considered mistakes. It also brings a great deal of consistency and completeness to the various DOM APIs and HTML elements. And probably most importantly, it has brought the various browser makers into agreement. This means web developers that develop against what is defined in the W3C HTML5 specification should have one application that works well on all recent browsers versions without the need for browser specific kludges.

W3C HTML5 vs HTML5

If I were to sum up the differences between the W3C HTML5 specification and the larger concept of HTML5 it would be this:

• The W3C HTML5 promotes many of the existing second class elements of the Web such as video, audio, animations, smart forms, etc into first class elements.
• HTML5 (the common usage) takes those new elements and adds power and functionality to them that was not previously possible. HTML5 also creates a whole new set of first class elements out of technologies that were not part of the Web in the first place such as hardware device access, binary data, file system access, multiprocessing, etc.

Or another way of summing up the relationship between the two:

The W3C HTML5 specification serves as the foundation and framework upon which all the interesting HTML5 developments are happening.

The Most Important Parts of HTML5

Now we come to my purpose for this article: to list and describe the HTML5 APIs, standards, and technologies that are most important (and most interesting). I have tried to imagine the Web as it will exist five years from now and from that vantage point determine what parts of HTML5 were most crucial in bringing us to that imagined future.

The following list is ordered from most to least important. Obviously this is just my opinion. I do web application development (noVNC, websockify) and participate in HTML5 working groups and discussions, but the future is always more interesting (and less) than any experts can predict.

So without further ado...

1. Faster Javascript Engines

The Web as a application platform is built on this more than anything else. The new Javascript engines are the warp drive for the Web. Without the warp drive, Star Trek is a story that takes place on earth (or at best in one solar system). Without the massive increase in Javascript performance we would still be talking about web pages and not web applications.

2. WebSockets

This moves the browser solidly into the space of highly interactive networked applications. After fast Javascript engines, low-latency networking has the largest potential for allowing the Web to conquer new application domains.

3. Binary Data Types (Typed Arrays and Blobs)

Javascript started its life as a way to do validation of textual form data. However, many of the first class elements introduced in HTML5 contain, receive and/or output binary data and so native binary data types in Javascript has become a necessity. Developers have used various hacks to encode binary data in old Javascript data types for many years. But using these hacks is a significant barrier and the full power of HTML5 will not be unleashed without native binary data support.

4. Web Audio API

This is not the <audio> tag but rather the APIs/proposals for allowing low-latency, direct audio manipulation from Javascript. The <audio> tag (which is part of W3C HTML5) allows an audio file to be embedded directly in a web page and it provides a playback and synchronization API.

The Web Audio API proposals allows for direct creation and manipulation of audio waveforms and also address issues of high-latency playback that exist in current <audio> tag implementations. These proposals are still very young and the final solutions may merge with the <audio> tag, but the issues addressed by the Web Audio API proposals will be in future browsers in one form or another.

5. Canvas 2D Context

Direct pixel manipulation. Everybody agrees it is important so there is not much I will add. I put it below the Web Audio API because much of what can be done with Canvas 2D Content can be done with other methods (SVG, WebGL, CSS3).

6. CSS3 and WOFF

Cascading Style Sheets 3 and the Web Open Font Format together bring the full power of design, typography, layout, and visual transformation to the web. Also, with CSS3 (in particular the Flexible Box Model), web applications will finally have a simple and powerful way of doing user interface layout without the element positioning mess that is necessary with CSS2.

7. Local Storage, Offline Applications and the File APIs

There are many application domains that are just not feasible without fast, local and persistent storage (at least not until everyone has cheap Gigabit Internet connections). Some form of local storage is also necessary for web applications to be usable when there is no Internet connection available. There are a number of APIs/standards being developed in this area but they are all addressing different aspects of the same fundamental limitation of pre-HTML5 browsers.

8. Web Workers

Moore's Law is dead, long live Moore's Law! The year-after-year exponential increase in CPU frequency due to Moore's Law ended several years ago. But Moore's Law was actually a statement about transistor cost/density and this has not changed, it simply has a new face: processor cores per square inch of chip. In a few years, even your mobile phone will have more processor cores than you have fingers.

New software models are required to take full advantage of the new multi-core reality of Moore's Law. Fortunately, even though Javascript has always been a single threaded language it was also designed from the beginning to an event driven language. This means that while multiple lines of Javascript in the same web application cannot be running simultaneously, the browser can be doing multiple things at once on behalf of that Javascript code that is running.

Being event driven only goes so far. The Web Workers specification was created to allow a single web application to have multiple threads of Javascript running simultaneously. To avoid the massive complexity that usually comes with multi-threaded programming (locks, special data structures, etc), Web Workers are independent Javascript contexts and they can only interact with each other and with the main Javascript thread using event driven message passing.

9. SVG 1.1/2.0

The SVG (Scalable Vector Graphics) format has been around for a long time and some browsers have been able to embed SVG images into web pages. SVG is finally starting to be adopted by all browser makers in a form that adds powerful APIs and that allows full access and manipulation to the contained elements (i.e. a truly first class element).

SVG is actually a difficult one to place in the list. Many (perhaps even most) of the uses of the Canvas 2D Context are actually more appropriate to SVG and in many ways SVG is far more powerful. However, SVG has had an uneven history and I fear that it has accumulated some unjustified mental baggage that will prevent it from being as fundamental and important as it otherwise would be. I will be happy to be proved wrong if it turns out to be more important than I have rated it.

10. WebGL

This is the Canvas 3D Context and it is basically a hardware accelerated OpenGL API for the Web. Like SVG, this is potentially a very important piece of HTML5. But I say potentially because Microsoft has been somewhat dismissive of WebGL (possibly since it is defined in terms of OpenGL rather than their own DirectX API) and so there is uncertainty about whether this will ever make it into Internet Explorer. If there were less uncertainty I would place this higher in the list because it brings the Web to the doorstep of so many new application domains (including 3D games).

11. All the Rest

The ultimate vision of many who are pushing forward the Web platform is to make the Web platform as powerful, capable and comprehensive as native applications. The first 10 items each open up the Web platform to large new application domains that have historically only been possible with native applications. But they leave many gaps that must be filled before we reach a future where the question asked by developers is no longer "Can I build this as a web application?" but rather "Do I want to build this as a web application?"

There are numerous proposals that are being worked on to address the gaps in web application functionality. Several of them would probably be higher on the list if they were further along or had less uncertainty about whether they will be universally adopted by all browser makers. Here are just a few of the proposals/APIs that are attempting to fill the gaps:

• WebRTC/Stream API: Peer-to-peer video conferencing.
• Geolocation: Where in the World am I?
• Orientation: Which way is up?
• Crypto: Encrypt/decrypt efficiently in Javascript
• WebCL: The Web version of OpenCL. Who wouldn't want to use the GPU directly for computation from Javascript?
• WebNotifications: Tell me what's happening, but gently.
• Web Intents: Associate data types with default actions and pass data back and forth between web applications. Your favorite web application for editing images will inevitably be different then the default one for that web based slideshow application. Shout with me: "OLE!"
• Page Visibility: Imagine how much energy the world would be save if those animations and movies stopped rendering when you aren't looking at them.
• requestAnimationFrame: with setTimeout you get 100 FPS or you get 2 FPS (often within the same second). Now you can get a consistent 30 FPS. And there was much rejoicing.
• Microdata: unambiguous parsing of embedded machine-readable data.
• Etc
• Etc (Footnote 3)

Mac vs PC vs Browser (from xkcd.com)

What about <video> and <audio>?

The <video> and <audio> tags are probably the HTML5 features that have caused the most excitement (and angst) on the web regarding HTML5. In fact, some of you may have scanned ahead looking for them in the list and were surprised they were not #1 and #2. These two elements are part of W3C HTML5 and while they do make first class elements out of what has traditionally been second class (e.g. done with Flash), they are still really just a better way of doing what has already been done. The <video> and <audio> tags don't significantly expand the scope of what web applications are capable of so that is one reason why they are not on the list. Another problem with these tags is that the list of supported media formats is inconsistent across browsers. Until this is resolved, their adoption will be hampered. (Footnote 4)

Footnotes

These were originally inline in the article and they seemed to interrupt the flow so I moved them here. And even without these notes the article is still too long.

Footnote 1

Here are some notable standards that developed around the Web platform in the first few years after the first web browser was released by Tim Berners-Lee:

• 1995 - HTML 2.0 is published as the first official HTML standard.
• 1995 - HTML make the first baby step toward becoming dynamic and interactive when JavaScript is created by Brendan Eich and added to Netscape Navigator 2.
• 1996 - The CSS1 (Cascading Style Sheets) specification is completed and parts of it appear in Internet Explorer 3. Part of the reason for CSS is to separate web page appearance from content and functionality. This follows as well established principle in computer science of separating concerns.
• 1998 - The DOM Level 1 (Document Object Model) specification, the API of HTML elements on a page, is published by the W3C.

Footnote 2

I should note another important group (with a long and forgettable name) that is involved in HTML standards is the Web Hypertext Application Technology Working Group (WHATWG). Many (perhaps most) of the people at WHATWG also participate in work at the W3C. The WHATWG can be thought as a more dynamic and less restricted version of the W3C.

The WHATWG maintains two overarching standards documents. The first is HTML. Many of the ideas that are in the W3C HTML5 were first documented here. This document can be thought of HTML5+. The second standard document is called Web Apps 1.0. This contains the content of the HTML document and adds many of the APIs that are considered important for the Web to become a full fledged application platform.

The WHATWG Web Apps 1.0 document is much closer to what people generally mean when they use the term "HTML5", however, even that does not encapsulate the whole meaning. There are many other APIs and proposals that are part of the new energy of the Web that are or will make their way into most browsers (either via the standards process or not).

Footnote 3

Etc. I am not aware of a web proposal/API yet with those three letters. The question is will this article will make it more or less likely that there will be one soon?

Footnote 4

By combining fast Javascript, WebSockets, Canvas, Web Audio, and binary data types you can have video and audio without the <video>/<audio> tags and without any plugins. The frame rate and resolution might be lower than desired but it is possible.

Resources

• Dive Into HTML5
• HTML5Rocks
• Excellent Presentation on HTML5 from HTML5Rocks
• When can I use... Compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers.
• HTML5 Readiness - Flower chart of HTML5 & CSS3 features in major browser versions
• The HTML5 Test - How well does your browser support HTML5?
• The Web Platform: Browser technologies ()
• HTML5 Tweets
• W3C Blog
• WHATWG Blog
• Google Chrome Blog
• Mozilla Firefox Blog
• Opera Developer Blog
• Microsoft Internet Explorer Blog
• "An Open Web" book
• "20 Things I Learned About Browsers and The Web" Google comic
• "What is HTML5"

Links

• Early History of the Web (W3C)
• Where the web was born (CERN)
• W3C
• W3C HTML5
• WHATWG
• WHATWG HTML
• WHATWG Web Apps 1.0
• 1. EcmaScript/Javascript: ECMA-262
• 2. WebSockets
  • API: W3C, WHATWG
  • Protocol: IETF/HyBi
• 3. Binary Data Types
  • Typed Arrays
  • Blob Type
• 4. Web Audio: Google, Mozilla, W3C
• 5. Canvas 2D Context: W3C, WHATWG
• 6. CSS and WOFF
  • CSS3: W3C
  • WOFF: W3C
• 7. Local Storage, Offline Application and the File APIs
  • Web Storage: W3C
  • IndexedDB: W3C
  • Offline Applications: W3C, WHATWG
  • File/Reader: W3C
  • File Writer: W3C
  • File Dir/System: W3C
• 8. Web Workers: W3C, WHATWG
• 9. SVG 1.1/2.0:
  • W3C 1.1
  • SVG 2.0 W3C Roadmap
• 10. WebGL
• 11. All the Rest
  • WebRTC/Stream API
  • Geolocation
  • Orientation
  • Crypto
  • WebCL
  • WebNotifications
  • Web Intents
  • Page Visibility
  • requestAnimationFrame
  • Microdata

    var input = [2, 4, 6, 8];
    var a = map(m3, filter(f2, map(m1, input)));

where m3, f2, and m1 are various application-specific functions.  Again, just as an example, let's say:

    function m1(x) { return x / 2; }
    function f2(x) { return x % 2 == 0; }
    function m3(x) { return x * 10; }

That is, we want to divide everything in the input array by two, keep only even numbers from that, and multiply each of those by 10. Of course map and filter aren't standard JavaScript functions, so we have to write them.  The first dilemma in writing them is: what should they return?  Each could return an array, but then each stage will run through the entire sequence before the next stage starts, which seems undesirable if we can find any better way.  Another option would be for each to return a lazy sequence.  We've done this, including the required mechanisms for creating and examining Clojure-style lazy seqs.  But this ends up creating a closure for every stage of every iteration. This causes us various problems such as memory leaks in buggy JS engines and failure to serialize lazy seqs to JSON.

So what other options exist?  I did say we're generating this JavaScript, so it's not actually a requirement that the code look as tidy as the snippet above, which puts continuation-passing style on the table.  CPS is a style of API in which we don't use the return value of function, but instead pass in a function to be called once the result it known. If this reminds you of event-handling systems, then good for you:

    var a = [];
    forEach(input, function(x1) {
      cps_map(m1, x1, function(x2) {
        cps_filter(f2, x2, function(x2) {
          cps_map(m3, x2, function(x3) {
            a.push(x3); })})})});

A few things to note here:

1. The order in which the steps appear is reversed here compared to the earlier one-liner.  The ordering here feels more imperative and is arguably more comfortable. "For each of these, map with m1, then filter with f2, then map with m3, and finally push the results into array a"
2. The cps_map and cps_filter functions are not identical in responsibility to the earlier map and filter functions. Specifically, these do not have loops of their own but expect to be called repeatedly if necessary by earlier steps. This isn't part of translating them to CPS, but rather part of trying to avoid looping across the same sequence multiple times.
3. Despite points 1 and 2, we still have abstracted out the loop, map, and filter work so that we can refer to these operations by their names instead of re-implementing them.  That is, we didn't have to write our own for loop for this case and instead are still using high-order functions.

This solution doesn't walk through the sequence more than once, since only forEach has a loop. But does it still create a closure for each iteration of each step?  Well, that might depend.  Technically the anonymous functions aren't closures since they don't access anything except their arguments and globals, but I wouldn't be surprised if some JS engine allocated a new instance each time anyway.  We could re-write it so that all the functions are named and defined at the outer scope, but that would damage the readability even more. So instead of pursuing that rought, lets try out Google Closure compiler's advanced optimizations instead:

    for(var a = [], b = [2, 4, 6, 8], c = 0;c < b.length;++c) {
      var d = b[c] / 2;
      d % 2 == 0 && a.push(d * 10)
    }

No closures, in fact no functions defined at all.  Just one tight for loop. That's nice.

If you want to try this yourself, start with the full code for my example, and paste it into GClosure's compiler.

• Storage is cheap, communications are not
• Storage is low power, communications are not
• Local storage always works, communications does not
• My use of local storage is private, in the cloud there are watchers
• Local operations have predictable performance, remote does not

Larry is correct about the current problems with "Connected-only devices" and cloud storage and he has identified some real problems/costs of cloud storage vs local storage. I'm going go further and identify some additional costs involved in the local vs cloud storage equation. These other costs are more dominant (in determining what choices people will make) and by considering them I think they reveal a interesting trend:

There is a cross-over point where cloud data becomes cheaper than local data.

The cross-over point varies for different people and different types of data and in many cases it has already been crossed.

Storage/Network costs:

First lets look at some of the costs that Larry identified. It is well known that transistor density is currently doubling every 24 months or so. This principle is known as Moore's Law. Less well known is Butter's Law which states that the amount of data able to be sent per optical fiber doubles every 9 months and Nielsen's Law which states that the maximum bandwidth available to home users will double every 21 months. On the storage side is Kryder's Law which states that storage density doubles every 12 months.

Network and storage capacities are following exponential curves just like transistor densities. Even if network capacity and user bandwidth were doubling at a much, much slower rate than storage capacity there would still be a cross-over point where cloud data becomes cheaper (in practice and for most people) than local data. This is because the most important factors to consider are not the raw resource costs, but rather the time cost and the cost of convenience lost.

A few thoughts before moving on:

1. The doubling of storage density affects the cost of cloud storage too,  so it's not a cut and dry Moore vs Kryder argument.
2. The speed/latency of disk storage is not keeping up with capacity. Cloud storage systems often have a better answer for this than is available with local storage. For example, before the advent of Gmail, we used to have to wait for email searches to complete.
3. The relevant question is not "How much am I paying per bit?" rather "How much is it costing me to keep my email/pictures/music (insert data/media type) stored locally vs stored in the cloud?"
4. When I'm talking about cloud storage, I'm not referring to a remote cloud hard drive service like Dropbox, I really mean a cloud service that is designed around a certain type of data such as Gmail for email or Github for source code, etc.

Time Cost:

Both local data and remote/cloud data have a time cost. The time cost for remote data is primarily waiting for access to my data to download/cache and be available/usable. The primary time cost for local data is time spent managing that data: backups, upgrades, organizing, permissions, etc.

The time cost of remote data is decreasing on an exponential curve (the smaller the file/media type, the sooner this becomes essentially a negligible cost). The time cost of managing local data certainly is not decreasing at anywhere near the same rate.

Cost of Convenience Lost:

Both local data and remote/cloud data also have a lost convenience cost. For remote data, this lost convenience is any time I don't have reasonable Internet connectivity (or the service is down). Finding yourself in a location without Internet access is extremely annoying, but imagine how much worse the situation was just three years ago.

The convenience cost for local data is that few people have access to this local data once they leave their homes. If they do have access, then they have probably either turned their home into a personal remote data service (time cost) or they duplicate their data to all their mobile devices (time cost).

There is also a privacy/security cost, but unfortunately, I think for most people it is very hard to quantify and therefore irrelevant for their day-to-day decisions. Also, it could be argued that the average person's mis-managed Windows PC might be more exposed than the average cloud provider.

The Cross-Over Point(s):

The cross-over point has already happened for most Internet users with email, bank records, contact lists, etc. Anyone remember POP3 email?

For most younger people this cross-over has also already happened with pictures (Facebook, Picassa, etc) and music (Pandora, last.fm, Apple Cloud, Google Music, etc). For the younger crowd (and other early adopters) the cross-over will happen soon (if it hasn't already) with documents (Google Docs, Office 365), presentations (Scribd, Google Docs, Youtube), videos/movies (Youtube, Hulu, Netflix, etc), etc, etc.

Large connected-only devices like the Google Chromebook will reach the cross-over point much later because they add a significant additional cost to the equation: weight/reduced portability. It's certainly possible that large connected-only devices may be so premature that they will die and not be ressurected for well beyond when they would have otherwise reached the cross-over point of cost-effectiveness.

The trend towards remote/cloud storage is already well underway. Nearly everyone who uses the Internet uses cloud storage in one form or another and they will be using much more of it in the near future.

"The future is already here — it's just not very evenly distributed."

---

PostScript:

I knew Larry while I worked at SiCortex. I have met few software engineers that are more brilliant than Larry. Whenever I think about Joel Spolsky's famous post about hiring poeple that are "1. Smart and 2. Get things done", Larry is one of the people that comes to mind for me. Thank you, Larry, for unknowingly spurring me on to write something I've been wanting to write for a while now.

• Ubuntu bug #539477: Video out hot key sends super + p + return on many upcoming Dell & HP systems
• Ubuntu bug #694910: Regression: patch to bug 539477 breaks Super+P keybindings

The nutshell: Recent gnome-settings-daemon unconditionally binds Super+P to rescan the video outputs and possibly reconfigure them. (If you're wondering, "Super" is the Win key, usually located between Ctrl and Alt.) The reason gnome-settings-daemon creates this binding is that newer PC BIOSes send this keystroke when they detect a monitor being plugged into, or unplugged from, the computer. And why do they do that? Because that's the keystroke in Windows 7 to bring up the display configuration dialog! So gnome-settings-daemon is simultaneously catching the BIOS announcement of changes to the attached displays, and also protecting your applications from a stray keystroke (that would most likely result in a "p" being inserted into the blog post you're writing).

I can't blame the authors of gnome-settings-daemon — this situation is really Microsoft's fault — but in any case, I'd rather handle video configuration changes without the extra help (I can launch the dialog on my own, thanks) and I can tolerate the tiny risk of a "p" turning up somewhere I didn't expect. I just want to be allowed to bind Super+P to change terminal tabs as I have in the past.

So here's a hack that gets the job done. The trick is to create a keybinding before gnome-settings-daemon starts, thereby blocking gnome-settings-daemon from grabbing it. After gnome-settings-daemon starts, release the binding so it's available to other programs, in my case the terminal emulator. To accomplish this I'm using xbindkeys, which is available in Fedora and Ubuntu.

Most of the time the distribution starts GNOME directly; i.e. gdm launches gnome-session for you. In that case you have no opportunity to run xbindkeys before gnome-settings-daemon runs. However you can customize the startup of your X applications by creating an $HOME/.xsession script and configuring your distro to use it. For Ubuntu instructions, see help.ubuntu.com; on Fedora you need to yum install xorg-x11-xinit-session then choose "User Script" at the login screen.

The minimal .xsession to rescue Super+P from gnome-settings-daemon is:

#!/bin/sh
xbindkeys -f $HOME/.xbindkeysrc-super+p
exec gnome-session

with the accompanying configuration:

# $HOME/.xbindkeysrc-super+p
"pkill xbindkeys"
 mod4 + p

So xbindkeys grabs Super+P before gnome-settings-daemon runs, then goes away the first time you press the combo, leaving the key available to your programs.

After reading the title, you may have thought: "Wait ... Javascript doesn't have binary byte arrays." Actually, not only does Javascript have access to binary byte arrays but there are two unique variants available (technically neither are part of ECMAScript yet).

Jump list:

• The Options
• Typed Arrays
• ImageData arrays
• Traditional Solutions
• The Bad News
• Testing
• The Four Tests
• Test Results
• Test Result Summary
• Browser Improvements/Regressions
• Firefox
• Chrome
• IE 9
• Final Thoughts
• Requests
• Followup Posts
• References

The Options

Typed Arrays:

Those who follow browser development and HTML standardization may already be aware of one of these array types. ArrayBuffers (technically: Typed Arrays) are a required part of the proposed WebGL and File API standards. To use an ArrayBuffer as a byte array you create a Uint8Array view of the ArrayBuffer.

The following Javascript creates an ArrayBuffer view that contains 1000 unsigned byte elements that are initialized to 0:

var arr = Uint8Array(new ArrayBuffer(1000));

ImageData arrays:

But there is an older and more widely supported form of binary byte arrays available to Javascript programs: ImageData. ImageData is a data type that is defined as part of the 2D context of the Canvas element. ImageData is created whenever the getImageData or createImageData method is invoked on a Canvas 2D context. The "data" attribute of an ImageData object is a byte array that is 4 times larger than the width * height requested (4 bytes of R,G,B,A for each pixel).

The following Javascript creates a ImageData byte array with 1000 unsigned byte elements that are initialized to 0:

var ctx = getElementById('canvas').getContext('2d'),
arr = ctx.createImageData(25, 10).data;

Traditional Solutions:

There are two traditional ways of representing binary byte data in Javascript. The first is with a normal Javascript array where every element of array is a number in the range 0 through 255. The second method is using a string in which the values 0 through 255 are stored as Unicode characters in the string and read using the charCodeAt method. For this post I'm going to ignore the string method since Javascript strings are immutable and updating a single character in a Javascript string implies reconstructing the whole string which is both unpleasant and slow.

The following creates a normal Javascript array with 1000 numbers that are initialized to 0:

var arr = [], i;
for (i = 0; i < 1000; arr[i++] = 0) {}

The Bad News

We are left with three methods for representing binary byte data: normal Javascript arrays, ImageData arrays, and ArrayBuffer arrays. One might expect that since ImageData and ArrayBuffer arrays are fixed sized, have elements with a fixed type, and are used for performance sensitive operations (2D canvas and WebGL) that the performance of these native byte arrays would be better than normal Javascript arrays for most operations. Unfortunately, as of today, most operations are slower when using these byte array types.

Testing

Originally I planned to show the performance numbers comparing browsers on Linux and Windows. However, I discovered that there is very little difference (for these array tests) between the same version of a browser running on Windows vs Linux. Since all the Linux browsers also run on Windows (but not vice versa) I have limited the performance results to Windows.

For this post I have hacked together four quick tests to compare normal Javascript arrays with ImageData and ArrayBuffer arrays. All the tests use arrays that contain 10240 (10 * 1024) elements and repeat the operation being tested many times in order to push the test times into a more easily measured and comparable range. Each test is also run 10 times (iterations) and the mean and standard deviation across all 10 iterations is calculated.

You can run tests yourself by cloning the noVNC repository and loading the tests/arrays.html page. These test results are based on revision bbee8098 of noVNC. Running the test in a browser will output JSON data in the results textarea. This JSON data can then be combined with JSON data from other browser results and run through the utils/json2graph.py python script which uses the matplotlib module to generate the graphs.

The test machine has the following specifications:

• Acer Aspire 5253-BZ893
• AMD Dual-Core C50 at 1GHz
• 3GB DDR3 Memory
• AMD Radeon HD 6250
• Windows 7

Here are the main browsers that were tested:

• Chrome 12.0.716.0 (build 79495)
• IE 9.0.8112.16421 64-bit
• Firefox 4.0
• Opera 11.01

In addition, older browser versions were also tested to see if the browsers are making progress:

• Chrome 9.0.597.98
• Chrome 10.0.648.204
• Chrome 11.0.673.0 (build 75038)
• IE 9.0 Platform Preview 7
• Firefox 3.6.13
• Firefox 3.6.16
• Firefox 4.0 beta 11

Please note that I am not a professional performance tester so I probably haven't made use of optimal testing techniques and there is certainly a possibility that I have made mistakes that invalidate some or all of the numbers. I welcome constructive criticism and dialog so that I can expand and improve on these results in the future.

The Four Tests:

1. create - For each test iteration, an array is created and then initialized to zero and this is repeated 2000 times.
2. randomRead - For each test iteration, 5 million reads are issued to pseudo-random locations in an array.
3. sequentialRead - For each test iteration, 5 million reads are issued sequentially to an array. The reads loop around to the beginning of the array when they reach the end of the array.
4. sequentialRead - For each test iteration, 5 million updates are made sequentially to an array. The writes loop around to the beginning of the array when they reach the end of the array.

Test Results:

First let's take a look at how the different array types perform at the different tests.

Create Test Results

This is the only test where ImageData and ArrayBuffer arrays have a significant performance advantage because they are automatically initialized to 0 when created. IE 9 and Opera do not currently support ArrayBuffer arrays.

Random Read Test Results

Chrome and Opera have the best overall performance although Opera does not support ArrayBuffer arrays yet. Firefox has particularly bad random read performance across the board. The results show that there is little advantage to using ImageData or ArrayBuffer arrays for random reads and their performance in Chrome and Opera is significantly slower.

Sequential Read Test Results

For the sequential read test the situation is quite different. Firefox has consistent and leading performance across all array types. Chrome has an order of magnitude worse performance for ImageData and ArrayBuffer arrays. Opera 11 show a 3X fall in performance for ImageData arrays compared to normal Javascript arrays. Normal arrays are still the best choice overall.

Sequential Write Test Results

The sequential write test relative results are very similar to sequential reads with a slow down across the board. Firefox again shows comparable performance across all three array types. Opera 11 continues to show a 3X fall in performance with ImageData arrays. Chrome continues to show an order of magnitude speed different between normal arrays and the binary arrays.

Normal Array Test Results

Chrome is the best overall performer here with Opera pulling a close second. However, the most notable result in this view is the terrible performance of Firefox random reads. Given the huge amount of jitter in the Firefox result compared to the others, my guess is this is a degenerate case and that Mozilla has some low hanging fruit here.

ImageData Test Results

Opera is now the overall performance winner with Chrome pulling a close second. The Firefox problem with random reads continues to show up with ImageData arrays (although this time without the jitter). Excluding the random read result, Firefox would be the clear winner. IE 9 has a good showing here coming in a close third overall.

ArrayBuffer Test Results

The pack thins out significantly since only Chrome and Firefox support ArrayBuffers. Once again Firefox shows pessimal random read performance. With that result excluded (or fixed), Firefox would be the clear winner against Chrome.

Test Result Summary:

• Chrome has the best overall performance for normal arrays.
• Opera has the best overall performance for ImageData arrays with Chrome a close second.
• Firefox has good performance except for random reads where performance drops off a cliff on all array types.

Browser Improvements/Regressions

Now we will compare some older browser versions to see if the browser vendors are making progress over time in improving the performance of the binary byte array types.

Firefox

Normal Array Test Results for Firefox

Firefox mostly shows steady improvement for normal arrays, but once again the terrible random read perform rears its head in the shift from 4.0 beta 11 to the 4.0 release version.

ImageData Test Results for Firefox

Again, Firefox mostly shows steady improvement for ImageData arrays. This time the terrible random read performance was introduced somewhere between the Firefox 3 and Firefox 4 code base.

ArrayBuffer Test Results for Firefox

Only Firefox 4 supports ArrayBuffer arrays. The awful random read performance still exists.

Chrome

Normal Array Test Results for Chrome

No strong trends appear in the Chrome data for normal arrays. The array create speed shows a significant dropoff in Chrome 12. For sequential writes there was a 2X regression for Chrome 10 and 11.

ImageData Test Results for Chrome

There appears to be a significant regression in Chrome 12 related to ImageData performance. The amount of the dropoff (3X to 6X) and the significant jitter indicate to me that their is a obvious propblem that should be fixed.

ArrayBuffer Test Results for Chrome

There are no strong trends in Chrome ArrayBuffer array performance although there seems to be a weak trend towards worse performance.

IE 9

Normal Array Test Results for Internet Explorer

ImageData Test Results for Internet Explorer

The final release of IE9 shows a huge performance decrease compared to the Platform Preview 7. If Microsoft is able to recover this performance in a subsequent release then this would significantly change the standing of IE 9 in relation to the other modern browsers.

Final Thoughts

ImageData and ArrayBuffer arrays have different performance characteristics within the same browsers. I'm not sure why this should be the case. In fact, I would recommend that the WHATWG/W3C and browser vendors standardize on ArrayBuffers for both purposes. This could be done by adding an additional attribute to the ImageData object perhaps named 'buffer'. The new 'buffer' attribute would be a generic ArrayBuffer containing the the image data memory. The existing 'data' attribute would become a Uint8Array view of the ArrayBuffer (this would maintain backwards compatibility). In addition to code consolidation within the browsers (and one place to focus optimization effort) this change would allow developers to create a Uint32Array view of the buffer which would allow whole pixel updates (3 colors + alpha) with one operation.

Using ImageData and ArrayBuffer (typed array view) arrays will generally not give better performance for binary byte data than just using normal Javascript arrays. This is unfortunate since these binary array types exist specifically to serve performance sensitive functionality (2D and 3D graphics). It is also surprising since they have a fixed size and a fixed element type which in theory should allow faster read and write access to the elements. I suspect (and hope) that this performance problem is due to the fact that not enough optimization effort has been applied by any of the browser vendors to these binary arrays.

Requests:

• Mozilla, Google (and Apple), Microsoft and Opera: please spend some effort to optimize your Javascript binary array types!
• Microsoft and Opera: it would be nice if you would implement WebGL. But if not, please at least implement typed array (ArrayBuffer) support since it stands on its own and will likely be used in the near future in other places where it make sense such as FileReader objects and in the WebSocket API to support binary data.

Followup Posts:

The browser wars are back and new browsers versions are being released every few weeks. My plan is to continue updating these tests to include the most recent browser versions. I would also like to expand the tests to include a random write test and also to test the random and sequential read performance of binary data stored in Javascript strings. Stay tuned.

References

• noVNC
• matplotlib python module
• Typed Array (ArrayBuffer) Specification
• MDN Typed Array Page
• ImageData spec section
• CanvasPixelArray spec section
• MDN Canvas pixel manipulation page
• FileReader spec
• MDN FileReader Page
• WebSocket API spec

The screenshot on the right was taken after clicking on the little "plus" button in Safari and adding the page to my "home screen", then launching the page from there. This gets rid of the URL bar, so that you can have more empty black space above your carefully drawn portraits.

I only tested it on my iPhone 3G, but it ought to work on any iOS device. Please comment if you notice it fails on an Apple touch device or if it works on anything else.

I count the project as a success because my three-year-old now prefers this to the little drawing app she used to use on my phone, and mine of course doesn't have any ads.

Feel free to use the 110 or so lines of code however you'd like.

Update: I received a report that it works on the Droid.

What we need is a duck-typed replacement for sys.stdout that behaves like a writeable file, but also provides the ability to capture to thread-local storage. One of the ways to use threading.local is to subclass it. An instance of this subclass will have per-thread attributes, even if the instance itself is common to multiple threads.

Since StringIO intentionally doesn't implement isatty(), we need to make sure that gets passed through to the underlying file (we do this by catching the exception in getattr). And since we like seeing HTTP transactions when we're debugging, we include a writethrough mode that provides simultaneous capture and print.

import cStringIO, threading

class LocalCapturingWriter(threading.local):
    def __init__(self, fp, writethrough=False):
        self.__dict__['_fp'] = fp
        self.__dict__['_stringio'] = None
        self.__dict__['_writethrough'] = writethrough

    def start_capture(self):
        self.__dict__['_stringio'] = cStringIO.StringIO()

    def stop_capture(self):
        v = self._stringio.getvalue()
        self._stringio.close()
        self.__dict__['_stringio'] = None
        return v

    def write(self, s):
        if self._stringio:
            result = self._stringio.write(s)
        if not self._stringio or self._writethrough:
            result = self._fp.write(s)
        return result

    def __getattr__(self, name):
        if self._stringio is not None:
            try:
                return getattr(self._stringio, name)
            except:
                pass
        return getattr(self._fp, name)

    def __setattr__(self, name, value):
        if self._stringio:
            setattr(self._stringio, name, value)
        if not self._stringio or self._writethrough:
            setattr(self._fp, name, value)

And here's how to use it. First, the global settings:

import httplib2, sys

httplib2.debuglevel = 1

sys.stdout = LocalCapturingWriter(sys.stdout)

Then the code that runs in a thread to capture the debugging output. This will work as expected even in multiple threads simultaneously.

sys.stdout.start_capture()
try:
    response, content = \
        httplib2.Http().request("http://n01se.net")
finally:
    debug_trace = sys.stdout.stop_capture()

# Note that httplib2 doesn't include the content in its
# debug output.
debug_trace += "content: %r\n" % content

We're now using this in our Django app, with a custom Exception class (to hold the captured trace) and middleware that knows to look for it. The end result is that every time an exception occurs due to a problem talking to a backend server, the exception email includes the httplib2 trace. Yeah!

P.S. I wrote this entry less than a week after my previous entry, but then went on vacation and never managed to get it posted. Sorry for the delay...

One of the pieces of data I'd like to add to the email is the conversation between our server and the internal servers. On a development server, this is easy: Set httplib2.debuglevel=1 and watch the HTTP conversations scroll past on stdout.

On a staging or production server, one quickly discovers a crippling mistake made by the httplib authors: the library uses Python's "print" for debugging!

If the application were single-threaded, we could capture the trace by temporarily redirecting sys.stdout to an instance of StringIO (maybe using a context manager). Sure, it's more load on the server to capture the debug on every transaction, but I'll gladly pay that price for the hours we'll save when something goes wrong and we have the ability to debug it.

But it doesn't matter, because we haven't this option. Our app is multi-threaded and sys.stdout is global. We would have to serialize our HTTP transactions to prevent traces from being mixed together. Or fork to isolate sys.stdout. These aren't realistic approaches.

This sort of unfortunate shortcoming is to be expected in add-on libraries. After all, part of the reason they're not included with Python is that they don't necessarily meet the quality requirements of the core distribution. But I'm taken off-guard to find such an obvious shortcoming in the Python standard library. One of the things I'd hope to assume by using the standard library is a trust in the quality of the implementation, but a discovery like this forces me to question that assumption.

I'm pretty new to Python, so maybe I'm missing something. Is httplib a particularly poor example of the Python standard library? The existence of httplib2 seems to imply that (and also seems to imply that it's hard to get problems fixed in the core distribution). Maybe I need to find an add-on networking library that ignores httplib entirely...?

The problem is that the page's css has the following rules:

h1, h2, h3, h4 {
  color: #333;
}

pre {
  background-color: #fcfcfc;
}

Both these rules assume the usual black-on-white color scheme, but I'm using a gtk theme with a dark background and light foreground, which firefox respects. (Chromium doesn't have the issue because it enforces black-on-white defaults regardless of the gtk theme. I'm not sure how I feel about that; it fixes the problem but at the expense of ignoring my theme.)

This isn't to say anything bad about febootstrap, of course. I'm thrilled that somebody has finally written for Fedora what the excellent debootstrap has been providing for Debian and Ubuntu users for years! But I've come across this mistake enough times that Rich's site drew the unlucky number.