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.

I'll second this. The Open University is not a degree mill and has an excellent academic reputation.

You can (or at least certainly could when I did it) go straight to a Masters Degree in engineering at UK universities by doing a 4-year programme, missing out the Bachelors degree on the way. It's marginally faster than doing a BEng/Bsc + MSc combination, and academically equivalent.

This is currently getting coverage on the front page of the BBC News website - both the domestic and international front pages - ( http://www.bbc.co.uk/news/ and http://www.bbc.co.uk/news/world/ respectively). Coverage doesn't get much more mainstream than this.

The hurdle of creating an application and getting it accepted is a much bigger factor than the cost of a developer subscription.

Whilst you can of course submit variations of some generic application, Apple is taking an increasingly hard-line on apps with little apparent customer benefit, so they may well get rejected, the whole process taking about a week for each iteration.

I would also not be surprised if Apple rejected developer account applications paid with pre-paid payment cards - they certainly check the bone-fides of corporate applications quite thoroughly. It's not hard to use a credit reference agency to validate a customer's identity once armed with a name and address.

The termination clauses of the contract will probably be considered unfair and thus unenforceable in situations like this.

Service providers and utilities rely on customers not being sufficiently aware or motivated to exercise their rights.

I wonder whether ACS:Law's behaviour approaches the legal definition of Extortion?

There are really only two explanations: that they were incompetent or, alternative, entirely competent, and trying it on.

The judge in fact refused all 8 requests for default. Of the eight, 3 had in fact filed defences, and there was no evidence of service in 3 more. The remaining two were technically in default, but the judge found the case lacked any legal merit due to the plaintiff not actually being the rights-holder or exclusive licensee, and therefore incapable of bringing a copyright infringement action. It looks as if ACS:Law's business model of speculative invoicing is holed below the waterline and sinking rapidly. The question I have is whether launching actions with such fundamental errors in law and procedure amounts to mal-practice? It certainly wouldn't be the first allegation of this type for ACS:Law.