So? The GPL is an agreement between two parties - the person who gives the code and the person who receives the code. If A gives GPL'd code to B and B gives it to C, then there A has no obligations towards C. If A ceases to exist as a legal entity, then B is still liable to fulfil the GPL obligations to C.

Note that this is the GPLv3, which is not relevant to android. GPLv2 only allows the first three ways of distributing the source (it was written back when Internet access was rare and software was commonly distributed on tapes - the FSF used to sell tapes of the GNU source tree).

No it isn't - read the GPL (section 3). If they did not receive the source, but just received an offer in writing to provide the source on request, then they may provide that offer instead of the source to other people. Alternatively, they must provide an offer in writing (good for three years) to provide the source, or must provide the source along with the binaries, on a medium commonly used for software interchange (for example, print-outs of the source would not satisfy this condition). Pointing at the upstream location for downloading the source is never okay for GPLv2 (it is for GPLv3, but I don't think that Android contains any GPLv3 stuff).

Until you've thrown them at some DNS, how do you know that they're unresolvable?

It's been a while since I set up a DNS cache, but I seem to recall the steps were:

• Install.
• Start.
• Point /etc/resolv.conf at localhost.

Of these, the first two steps are hidden behind a point-and-click UI in a modern *NIX system and the third is often possible via some network settings UI, so you can do the whole thing without going to the command line. You don't need to know anything about DNS, because a DNS cache is not an authoritative server, doesn't control any zones, isn't a slave, and is usually configured to work out of the box in this state.

Setting up an authoritative DNS server is harder, but that's not the issue here.

Not really. An HTTP redirect means that you make an initial connection to one server, and are then told that what you really want is on another. This adds a small amount of latency, but typically well under half a second. The original server is then not used for the remainder of the download. Akamai is typically used to serve large files - at least a few megabytes - so this extra hop doesn't add much overhead, and does make the geographic distribution much more efficient.

Using the DNS server's IP to determine the address of the client is fundamentally broken. There are other cases where it can fail spectacularly, such as when you have a computer sitting on two networks - it always sends DNS requests on one and then picks the less-loaded network for other connections, so the DNS tells it to go to the right server for the DNS cache's network and the client uses the other network. You can also have serious problems with resolvers caching addresses in a laptop - if you move between two networks (e.g. 3G and WiFi) and the server's address is cached, you'll find that you're going to the wrong server.

Iron has the lowest energy state with respect to the strong nuclear interaction of any element. Elements lighter than iron produce energy in fusion reactions, elements heavier than iron produce energy in fission reactions or nuclear decay. Once you have iron, you need to put energy in to transmute it into any other element. If you start with hydrogen, you get energy out forming heavier elements until you get to iron, if you start with something like uranium then you get energy out making lighter ones until you get to iron.

Did you not cover this stuff in school? It's really basic physics...

Or, if you must feed a troll, feed a creative one, not a rambling lunatic who keeps posting the same dull observation.

Michael Kristopelt = stagnated.

It's worth noting that Google video chat uses Jingle, which is supported by a few clients and can be used between any XMPP servers. If Google's servers go down, you can use it with some other server, just like with email. If Skype goes down, you've got a problem.

I remember reading about a bus system a couple of years ago, in Switzerland as I recall, that used induction charging at the stops. This is cheaper (and less ugly) than laying overhead wires everywhere, and it means that the battery only has to last the distance between two stops. When the bus stops, it automatically starts charging and the charging times are factored into the time table.

Smaller size also means less cooling, which may be a factor in performance of flash.

Even on a single OS, there are multiple calling conventions. For example, when returning a structure, it is common for the caller to allocate space and then pass a hidden first argument as a pointer to that. When calling a leaf function, lots of systems will use a different calling convention, and some will use a different one for tail calls. Some operating system functions (e.g. on classic MacOS and Win32) use a different calling convention where parameters are passed left to right.

If you look in a modern C compiler, you'll see a huge amount of logic for determining exactly which calling convention to use for any given function. Things get even more fun when you include unions.

A pure OO language, like Self or Smalltalk, is very simple. You have objects, you send them messages. The only flow control that you need is the combination of closures and messages. Neither language has an equivalent of an if statement in the language. If you want a conditional, you send an #ifTrue: message to an object with a block (closure) as the argument. The receiver is typically either the True or False singleton, which implements its #ifTrue: method by either sending a #value message to the argument or ignoring it. You can build additional loop constructs on top of it.

The notion of an object is trivial to understand. An object is a simple (special purpose) computer. It receives messages, does some computation, and sends messages to other objects. If you understand what a computer is, you understand object orientation. It's just about decomposing your problem into smaller components, each of which is implemented as a (model of a) special-purpose computer.

Trying to teach OO as a special case of procedural programming is a recipe for disaster.

The VPRI guys already have a version of Smalltalk that runs in a browser. Some guys at Sun already ported the Squeak Morphic UI (originally from Self) to JavaScript.

If you want to teach children, give them Smalltalk. Everything is an object and everything is directly manipulatable. You can create an inspector for any object (windows, pixels, controllers, whatever), browse the properties of that instance or the code of the class. You can create new classes by inspecting an existing class and sending it a subclass: message. You can try methods by creating an instance in the transcript and sending it messages, and you can have those objects stick around and create new ones. You can inspect the code editor itself and see how it works, and you can inspect every single object in the system in the same way. The only problem is that you then see that 'modern' IDEs are laughably primitive in comparison with where Smalltalk was in 1980.