This is what we used to do to pirates in the UK

Execution dock.

It's still there, but has laid unused or quite some time.

I found it distinctly unpleasant to work in too. It is said that one can acclimatise to it though. Be warned though - the evenings are not necessarily cooler than Western room-temperature.

The Japanese have been very successful in curbing demand. I was over in Japan for a week on a business trip last year, and it was interesting to see how they did it. This included absolutely all hand-driers in toilets being switched off, less air-conditioning (room temperature was set for 28C in the office), the business week of large corporations shifted to reduce peak-week-time demand and increase that on the weekend, and a move to more relaxed corporate dress-code - which included in many cases, a small towel attached to the waistband with which to mop off the sweat form the oppressive environment. There were no doubt more measures that I wasn't aware of, but life definitely carries on as normal without power cuts.

Our suspicion is that this state of affairs will become the norm.

I think the point here is that whilst applications do indeed have access, this is often mediated through Apple's user-interface in each case - which I suspect you'll find is actually provided by another process within a different sandbox. This means that rogue applications are not hoovering up your data without user-interaction.

In iOS, applications don't have a lot of access to personal data to start with - and certainly not to read SMS (although apps can send using an Apple sanction UI only). They do have access to the contents of the address book, but this is looks likely to change soon.

Simply weight the toolbox on the way out and again on the way back in.

You think that brute-forcing voicemail PINs would be rather easy to spot - although they likely to have been plenty of weak PINs which were easily guessable with publicly available information.

The proposals for the UK go further: registration of scrap metal dealers and banning of cash payments for scrap, thereby also eliminating huge amounts of tax fraud.

A rather unsavoury fact is that a lot metal theft is perpetrated by employees taking surplus or redundant materials from the employer.

It is no surprise whatsoever. TFS is very much modelled after P4, but P4 is considerably more mature and robust - and it's not even terribly expensive either.

Having implemented just such an application (it has a large model layer shared with the iPad version of the same app), this is not a trivial bit of engineering.
JNI provides lots of ways to screw up and debugging across the interface is challenging to say the least.

By FAR the best way to do the development is to get the model and JNI portions working and thoroughly unit tested with a test-harness before going anywhere near any of Google's tools or a device. Since lots of your problems are going to be in C/C++ land, invoking a JVM from native code makes life a lot easier at this stage.

An easy port it was not.

With the possible scenario of Windows Phone 7 being the 3rd successful mobile platform, building the bottom layers of these apps in C#/.Net is looking quite attractive as you can run it on all of the platforms. I assume MonoDroid deals with the consequential .NET VM Native Java boundary crossing.

Clock recovery with firewire audio streams is already pretty damn accurate - and it's entirely possible to achieve sample-accurate presentation. Yamaha's mLAN chipsets had this capability, and I suspect TC's DICE family of devices can too.

Also, extremely low latency is achievable. I can't remember the precise numbers at this juncture, but the limiting factor is the latency hit of a short bus reset. Winding latency down to a couple of milliseconds in each direction is doable.

The limiting factor tends to be the software generating or consuming the audio stream - in practice this usually involves a couple of real-time threads getting woken up perhaps every millisecond to work on a small amount of data - which invariably involves a read, modify (e.g. DSP of some kind) and then write somewhere else - possibly with interleaving for large channels counts.. This starts looking like a pathologically cache-ineffecient workload that doesn't improve much as CPUs get faster.

This will be interesting to watch: whilst for applications such as storage and HD cameras, IEEE1394 isn't cutting it any more, it's more than adequate for music production applications, and Thunderbolt will do nothing but add cost to these devices. The acid test will be Apple dropping the FW S-800 port off their products.

Sure - there's plenty of investment in both off-shore and on-shore wind generation in the UK (this gives a pretty good idea of the scale), but it doesn't change the fact that wind power cannot at present - in lieu of radical developments in energy storage, or demand modulation - provide reliable base-load. Wind-farms - even when offshore generate plenty of objections.

It's disappointing that there have not been more offshore tidal energy schemes, since these could be an entirely reliable energy source. The usual excuse offered is that whilst there are plenty of prototype devices, none of them are considered mature enough for large-scale investment.

Rather than increasing the amount of nuclear energy the in the UK, the proposed reactors are replacements for existing nuclear generation capacity that is reaching the end its life. What is perhaps interesting is that economics are starting to look very favourable for Nuclear generation right now - renewable generation is not cheap.