Mozilla has no license at all. Virtually all mobiles have hardware decoding (in form of a DSP --- I'm unaware of any using the GPU) for H.264, so the license has already been paid for.

This is for *Android Firefox* as the subject says --- you'll be able to build your own Firefox (for Android) and you'll have H.264 support. This does *nothing* for Windows/OS X/Linux/other-OS-here.

Really? OS X looks more like NeXTSTEP (from which it is directly descended!) than CDE.

IE8's big change was all the brand-new layout engine (thus the fairly rapid development in IE9/10, coming from nowhere to being right up there with CSS Level 3 module support). It changed relatively little elsewhere.

Except that's not the case. Go to any Google website in Opera: it looks different. Why? UA sniffing. Go to Facebook in Opera Mobile: it looks different. Why? UA sniffing.

In both cases Opera functions fine if you change the UA string. Sadly, evangelism isn't enough to fix everything.

It is still under copyright in the UK (copyright held by the Crown has no fixed expiry date), FWIW.

Avionics software may be subject to totally different requirements, but plenty of other life-critical systems is not. Medical systems have very little in the way of certification requirements in most western countries, for example (and yes, it's a terrifying reality how insecure and buggy, esp. in obvious ways, such software is!).

I have a film scanner (cost £500 a couple of years ago â" second hand, it's been out of production for about a decade). It isn't supported by SANE, there are some very limited F/OSS drivers for Windows which don't even work for most of what I have the scanner for (and don't work on Win64), and the official drivers work on OS X/PPC and Win32 (up to Vista â" don't know what stops it running on 32-bit Win7).

I run WinXP in a VM (without networking, except for to host) for it, as it's practically the only way I can keep it running for the indefinite future. That said, I don't expect the majority of users to be happy with VMs, given a mixture of working inside and out, and the different filesystems, and the different networking.

See http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html, which is a post to llvm-dev which concerns itself with this, as well as the more general unsuitability of the IR for program distribution.

It's depends what you're doing. I've spent a while dealing with the Scottish Corpus of Texts and Speech, and there the size is around four million words. If you're doing anything based upon dialects, size does make a very real difference, because you're interested in the density of usage by area. Personally, even in a non-linguistic context, I find it useful to know whether someone in x is likely to know (by virtue of using) a word y.

Bear in mind that Opera is far from the smallest browser which funds a viable business: yes, we are probably the smallest browser that attempts to compete on the Desktop (and certainly growing in absolute terms; whether we're growing as fast as the market is less clear, however), but there are other browsers out there.

Consider browsers such as NetFront and SkyFire: both of them have radically different business models (in fact, both ones that Opera has moved away from!), the former developing custom browsers for OEMs, and the latter charging end-users.

Opera very much gets money from Google.

In the past year, Desktop has brought in c. 70 million NOK per quarter, the vast majority of which comes from Google, which is approximately equal to 50 million USD per year.

In addition to that, Google is the default browser in Opera Mobile and Mini, but the amount there is far harder to quantity. Note that Mini alone has a userbase (in absolute numbers) equal to that of Desktop, so it seems reasonable to expect a considerable amount of money there as well.

See Opera's financial reports:

Opera's monetization strategy for its desktop browser revolves predominantly around search. Google is Opera's global search partner and provides the vast majority of desktop monetization.

...and...

Today, revenue generated from Opera's mobile consumers emanates primarily from mobile search, the Opera Mobile Store and content partnerships.

Google is Opera's default search partner for Opera Mini and Opera Mobile world-wide.

Both go on to mention other, smaller, search affiliation deals.

The MiG-25 was obtained by the West after a Russian pilot defected, aircraft and all. It had nothing to do with a Soviet aircraft being in airspace without permission.

PHP is far less dynamic than JavaScript, Python, Ruby, etc., though: function and class assignments are constant (though first-class functions exist in PHP 5.3, they're rarely used and probably aren't worth spending *too* much time optimizing for). The main source of dynamism is the dynamic weak typing, everything else is far closer to most compiled languages.

NaCL binaries are not portable in the same way I can't install the FireFox's Windows binaries on Linux (or the armel ".deb" from packages.debian.org on my amd64 computer), but honestly, who cares? Mozilla and Debian guys just compile it for each supported platform. There is also the possibility of creating a "fat nexe" that supports all platforms.

And what happens when I'm browsing the web on my MIPS-based TV? I'm at the mercy of the website author to specifically support my architecture. Today, I can visit any website and it will work. There is no dependency on any architecture specific stuff. Most developers will only bother compiling for x86 and ARM in all probability, which will hurt anyone else.

Is open source code on an open source browser. I would prefer it being a plugin (I think at some point there was one) so I can run it in all my browsers. But this is no different than any other proprietary feature on other browsers. I'm currently using Mozilla's proprietary "crypto" JavaScript API for an application, and it only runs on Mozilla's browsers. Not convenient, for sure, but what should I do? Not use the feature at all? Or try to make something valuable from it, so other developers might consider incorporating it?

It is a plugin... using a non-standard, non-documented plugin API, which nobody apart from Chrome supports or has any intention of supporting (it's a huge amount of badly documented, totally web irrelevant, anti-Open-Web chunk of code --- why should anyone take it in?). If they had used the standard plugin API (NPAPI), it would work today in every browser.

And I'm sorry, but this is fundamentally different to a lot of proprietary functionality in other browsers. Most of browser vendors are putting in large amounts of effort into removing old proprietary behaviour and specifying anything they wish to keep. Even Apple when it adds new proprietary behaviour to WebKit typically specifies it. Writing a spec is a big deal: it allows anyone else to write a clean-room implementation, which is often desirable (especially for CSS/DOM extensions: it's practically impossible to share much code without all moving to a single engine). Google hasn't released any spec for NaCl (and neither for the Pepper plugin API it relies upon), the spec it has released for Dart is nowhere near complete enough to allow a new implementation (and it had a several year headstart on implementing --- something that makes their implementation very hard to compete with), the spec for WebM is mostly just a dump of the code of the implementation (it's not really a spec: it's just code and the spec just says "match this").