Unless you are suggesting Oculus get into the display manufacturing business? That's certainly interesting, but would probably add several years to their release timeline.

At some point, normally before somebody spends $2 billion dollars, that stops being a valid excuse in the hardware business.

That said, here's a model with proper proportions of distance: http://www.solarsystemscope.com/ - Flash required, click anywhere, click on the gear icon to the left to select realistic size and model. Zoom slider is to the right. Note, the sizes and colors are wrong, most planets would be pretty much invisible in a realistic model.

Here's a neat non-interactive one from NASA: http://space.jpl.nasa.gov/

The nasa one gives me this: http://i.imgur.com/E6JW3Ks.jpg

Too bad they show all those stars in the background. So its a bit hard to say what is what. But it looks like the sun and the planets are quite visible. But are the proportions really correct? It looks like the sun is not much bigger then the plantes.

(1) Correct proportions of the distances between objects (namely the planets, planetoids, and the Sun), and (2) the correct proportions of the objects themselves.

The links (A) http://www.solarsystemscope.com/ and (B) http://space.jpl.nasa.gov/ show correct proportionality in DISTANCES BETWEEN OBJECTS but NOT the objects themselves.

For correct proportionality for both the distances and the objects themselves, see http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.h...

The problem with http://codepen.io/juliangarnier/pen/idhuG is that both the distances between objects and the objects themselves are not proportionally correct.

Google users have apparently been flooded with subscription requests from spammers, and the flooding suddenly became massive. The problem is, there are a large number of jabber servers out there which have open account registration without captchas. Most jabber server software doesn't come with a captcha module included by default, and of course, most admins don't bother changing defaults, even while running a public server with open registration.

Unlike some other comments here, I don't think Google has any malicious intent in this. This seems like a stop-gap measure, while they figure out and implement a proper solution.

As to the proper solution, the XMPP community is largely moving towards having captchas, or other forms of verification, and there are a number of proposed standards.

The thing to understand here is that the XMPP community has historically not had a spam problem. Due to the nature of the protocol, spoofing wasn't possible from the start, and there were no large lists of JIDs for spammers to abuse, so things worked out fine for a decade despite a lack of captchas. The good news is that the XSF was already preemptively working on the spam problem, and the speed with which XMPP specs (XEPs) get defined, implemented and deployed in servers and clients is far faster than any other large scale open protocol that I'm aware of.

As far as the XMPP protocol is concerned, the concept of sub-domains doesn't matter. It's useful for human users when configuring servers though.

Prosody for example allows running a multi-user chat service on example.com. And there's an undocumented feature which let's you have user@example.com be a user, and room@example.com be a chatroom.

[1] http://issues.igniterealtime.org/browse/OF-162

This combined with existing techniques of constructing 3D geometry out of videos could work really well if say you wish to construct a game level out of a real scene.

Raytracing complex scenes on a hand-held device at interactive frame rates is still quite a bit off. But techniques where a lot of the calculations can be done offline are possible to use today (radiosity, etc).

  function create()
    local a,b,c,d,e,f,g,h,i,j;
    return function() print(a,b,c,d,e,f,g,h,i,j); end
  end
  function array_get(f, index)
    local k,v = debug.getupvalue(f, index);
    return v;
  end
  function array_set(f, index, value)
    debug.setupvalue(f, index, value);
  end
  function map_get(f, key)
    for i=1,math.huge do
      local k,v = debug.getupvalue(f, i);
      if k == key then return v; end
      if k == nil then return nil; end
    end
  end
  function map_set(f, key, value)
    for i=1,math.huge do
      local k,v = debug.getupvalue(f, i);
      if k == nil then return; end
      if k == key then
        debug.setupvalue(f, i, value);
        return;
      end
    end
  end
  
  function test()
    local f = create();
    array_set(f, 1, "one")
    assert(array_get(f, 1) == "one");
    map_set(f, "b", "something");
    assert(map_get(f, "b") == "something");
    print("Success!")
  end
  test();

Oh, and coroutines probably also fall under composite data structures technically...

Actually, that's another point in Lua's favor. The mechanism Lua uses for managing closed-over variables is WAY more elegant than, for example, Ruby's mechanism...

  Because of the lexical scoping rules, local variables can
  be freely accessed by functions defined inside their scope.
  A local variable used by an inner function is called an
  upvalue, or external local variable, inside the inner
  function.

  When a C function is created, it is possible to associate
  some values with it, thus creating a C closure (see
  lua_pushcclosure); these values are called upvalues and are
  accessible to the function whenever it is called.