This is basic stuff to anyone who actually maintains a build, but Slashdot hasn't been a forum mostly populated by engineers for a number of years, now.

This appears to be due to link-time optimization blowing up the resident memory size of the linker, taking it past 3GB (which is already a non-standard hack the 32 bit build has had to do). Firefox is large, yes, but this has nothing to do with the final binary - which appears to be about 100MB total including all libraries in the Aurora builds.

I used to routinely run out of 32 bit address space compiling executables for a 64MB embedded ARM platform. This was due to symbol bloat, not executable size (which was 8MB). I also ran out of space compiling for a DSP with 288KB of RAM and 1MB flash, but that was mostly piss poor tools (Tasking). In fact, doesn't Chrome and even the Android sources already require building on a 64 bit host?

I don't have to explain:

Theora really can't even compete with MPEG-1 on either video quality at a given bitrate, or performance. It was very specifically designeed for extremely low quality, extremely low resolution, extremely low bitrate streaming video, over a decade ago...

This isn't true. There's plenty of results out there which say Theora is, while not the best, a good codec. To quote Wikipedia: More recently however, Xiph developers have compared the 1.1 Theora encoder to YouTube's H.264 and H.263+ encoders, in response to concerns raised in 2009 about Theora's inferior performance by Chris DiBona, a Google employee. They found the results from Theora to be nearly the same as YouTube's H.264 output, and much better than the H.263+ output.

There are plenty of people proclaiming that because it doesn't come out top, it's useless. Theora is far from useless: the results in any scenario that H.264 (even main profile) would be used, are still usable if you select Theora instead. They just aren't as pretty, because it's just not designed to the same constraints as H.264.

Becoming the HDTV standard would be an unrealistic goal. You attribute Theora not becoming the dominant standard due to Xiph's mishandling of the codec. The more obvious reason is politics: the MPEG group exists specifically to create audio/video standards which can be licensed. Broadcasters and content providers generally only use MPEG standards, and they just love licensing.

I'm interested to know what your theory is that Xiph could drive HDTV standards and have handled this better than a small company could?

The solution is obvious: allow installation of your own root certificate. This is supposed to be for security, not vendor lock-in. Without this option, I simply don't believe their intent.

Yes: Gmail (IMAP and SMTP), Google Chat (XMPP), etc. Try it out...do the DNS lookups yourself from different places.

So, it's only Google doing it?

FTP? Smtp? Distributed file shares? SQL server mirrors? NNTP? Ntp? I could probably list a dozen more.

Yes, that's a list of common internet protocols. I do not know of any example of anyone actually using geolocated DNS to CDN them. Do you have a concrete example?

Because it works, and there is more out there than just HTTP. This same approach will work for any protocol that uses DNS to resolve domain names.

Except that this is only used for HTTP. I do not know of any non-HTTP examples.

And here we have the real reason why this is being promoted:

3. And IMO most importantly, this removes the server selection choice from being under the sole control of the CDN provider. If this stuff is logic'd through the main HTTP page of the website, the CDN must expose its server selection strategy to the client, which is likely proprietary business knowledge.

It breaks DNS. It certainly breaks my local DNS installation, for starters. It also means that *everyone* must use this DNS hack because service will be degraded unless you do.

Messing with DNS is doing it the Wrong Way. All of these CDN services are based on HTTP. When you're using them, that's an HTTP server you're talking to. It's perfectly capable of geolocating you by IP, and it can either hand you back links to a local CDN, or redirect you to another server.

Why the hell must we mess with DNS to do this? This is a solution which only works if you use Google DNS, OpenDNS, or sometimes if you use your local ISP's DNS. What if you're just running bind for you local net vs the root servers? Bzzt. Doesn't work.

The most insane thing about this is it's Google we're talking about here. They damn well know how to implement this entirely in their servers without resorting to DNS hacks. Why are they promoting this net-neutrality breaking, layering violating botch? We need less people to use this, not more.

The missing option is: "They all suck". None are my favorite. I only buy that crap out of necessity, and generally curse its cheap unreliability every day.

NaCl is not so much about executing C/C++ code as it is about executing native compiled binaries. This has issues:

• If I compile my C++ code for x86, I can run it on x86 browsers (well, specifically only Chrome on x86).
• Ok now I have a cell phone, which is ARM. Guess I have to compile for ARM.
• Now I have to compile everything for both x86 and ARM.
• Ok now some other architecture is popular, but it won't run x86 or ARM.

It's incredible Google is even pushing this. It's so anti-portable and in concept anti-web.

There is a "portable" version of this, called "Portable Native Client". This means, of course, that NaCl is actually "Non-Portable Native Client" and that should itself be a clue. The "portable" version uses LLVM bitcode and a virtual machine. So more than a decade later, we've basically reinvented Java virtual machine applets minus the gigantic runtime (and language of your choice).

The only people who could possibly benefit from NaCl are Google. There's no general case use for this, and pushing it as standard into Chrome is a nasty move. Mozilla also reject the idea of NaCl. I believe Opera rejects it too (lacking a link). So, why is this being pushed?