I lived and worked in Sydney for a year or so, and used iiNet while I was there. They had a mirror of free software, and also zero-rated most iTunes content. With most ISPs there having caps (mine was just 100GB), it was difficult to not see this as a benefit, but overall of course it's far from ideal.
The other problem was just terrible speeds; best I could get in a central district was ADSL2+, with about 16/0.8 mbit d/u, and that's not including the terrible latency issue you had to deal with for a whole host of US and EU based websites and services.
Then again, I'm back in London now with a 150/15 mbit d/u connection for under £30, no caps in sight.
The idea of legal tender not being recognised reminds me of a situation here in the UK.
The Bank of Scotland prints its own notes, but are rarely in circulation in the rest of the UK. Somehow it's mildly amusing passing over a Scottish fiver to an unsuspecting checkout assistant in London, and the ensuing suspicion.
When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application.
In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime.
They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.
I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand.
Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process.
Actually, there is another open source project in the world that does that. It's called fontpath, I believe, and it reads OTF files directly. I'm considering switching to it, as the HTML5 Text API isn't hardware accelerated and a huge amount of the processing time is being spent in the fillText method.
ah so your the one fumbling with a credit card and holding every one up at the bar when I want to get a round in.
Personally I like having access to cash reduces the attack surface for me when compared to handing over my card for every transaction and DONT! get me started on NFC credit cards that can be debited with NO interactinon
It's a risk, but you can fix it on the backend, away from the end-user. If they were bitcoins then sure you need interaction for NFC. But credit cards are a closed system on the merchant side, any new identity pulling only NFC traffic would be very suspicious. NFC would always be an expected proportion of overall captures. So it's simple to defend against this attack without killing the feature.
Same happened to me trying to use Safari Books Online on my Kindle browser (as the only official way yo access their content on an eInk display). They dropped SSLv3, and in doing so the old 'experimental' Kindle browser can no longer access it.