The only reason I have a current Motorola phone is because it's GSM 4-band (which one needs to use it in North America and the rest of the world), and because it has a clamshell design, which means the buttons don't get pressed by accident when it's in my pocket or a briefcase. Losing the latter, is crazy, as it was the only really good feature, and one which you can't get from otherwise decent phone manufacturers like Nokia. I won't buy a smartphone until they come out with one having a design which protects the display and the buttons when it's in my pocket along with keys, loose change, pocket knife, and whatever.

Susan Greenfield has a history of making these claims, without a scrap of evidence to back them up. For a more sceptical treatment of the subject, see Ben Goldacre's Bad Science column of a couple of weeks ago: http://www.guardian.co.uk/commentisfree/2011/oct/21/bad-science-publishing-claims

That is really annoying for those who don' t live in the USA so have no zip code. It means two extra trips to the booth to get your credit card read and approved, and then debited with the actual amount of gas used. Almost all other countries use a PIN number (typically 4 digits) to approve credit card purchases done by machine but machines in the USA don't seem to be able to read them. I can't wait for the USA to catch up with the rest of the world.

But I suppose one can't expect any more of the only part of the world not to use International Standard road signs, A4 paper, 00 as the international dialling prefix, 230/240 volt mains, and metric units.

Because of the toolbar at the top, page down scrolls too far (using latest Mozilla) so I keep on having to press page down then the arrow to go up a line or two that has been missed.

The serious side-effect is that it makes it extremely difficult, if not impossible, for visitors buy a local SIM card for their mobile phone in order to avoid the rip-off charges that nearly all mobile phone companies charge for roaming. I guess governments are in league with the mobile phone companies in this respect.

When I visited Australia and bought a local SIM card it took me ages on the phone to register, since I didn't have whatever the Australian equivalent was of an SSN number, and the whole process cost me a lot of time and money, making the SIM-card purchase only marginally worth-while.

Fortunately the UK doesn't (at present) require SIM card registration, so visitors to here shouldn't have that particular problem.

The obvious answer is to use a database but only for the metadata, that is the items that describe the main dataset, such as filename, date of collection, dates of processing etc, shape, size, important parameters. Leave the data in the files so you can use your usual software packages, but use the database to organise the data collection. On the whole that gets you the best of both worlds.

But one thing you will find is that you have to use SQL to get the best out of any relational database, and this involves thinking in a new way - it's basically set-oriented - rather than sequentially row by row. This takes a bit of effort, but can be rewarding, as you will discover new ways of achieving some of the things you want to do.

As it happens I'm also in space research. My feeling is that what approach you take depends a lot on what sort of operations you need to carry out. Databases are good at sorting, searching, grouping, and selecting data, and joining one table with another. Getting your data into a database and extracting it is always a pain, and for practical purposes we found nothing to beat converting to CSV format (comma-separated-value). We ended up using Postgres as it had the best spatial (2-d) indexing, beating MySQL at the time. The expensive commercial DBMS like Oracle didn't have anything that the open-source ones did for modest-sized scientific datasets. I found Postgres was fine for our tables, which were no bigger than around 10 million rows long and 300 columns wide. You might well get better performance using something like HDF but you'll probably spend a lot more time programming to do that, and it won't be as flexible. The only thing you can be sure of in scientific data handling is that the requirements will change often, so flexibility is important. If your scientific data are smallish in volume and pretty consistent in format from one run to the next, you might consider storing the data in the database, in a BLOB (binary large object) if no other data type seems to suit. But a fairly good alternative is just to store the metadata in the database, e.g. filename, date of observation, size, shape, parameters, etc and leave the scienficic data in the files. You can then use the database to select the files you need according to the parameters of the observation or experiment.

That is undoubtedly a voiolation of European Union laws because it is discrimination against other EU citizens. But who is going to take it to the EU Court of Justice just to buy a SIM in Italy? Or even raise it with your MEP? It is such a pity that such petty restrictions still exist all over Europe.