vFAT is what provides long filenames in FAT16. As long as you limit yourself to using 8.3 filenames on the disk, you wouldn't need a license - and since it's only Windows that needs this driver, the filenames can be chosen specifically to fit within that naming scheme.

Hmm. I have to say it wouldn't surprise me, this being Windows and all, but my drive worked in Windows 7 and XP SP 3. The manual says it doesn't work in Windows 2000 - you can only have one partition per USB socket there.

A small partition at the start of the drive formatted as FAT16 or FAT32 that contains the drivers. The rest of the space is a big partition formatted as ext-whatever. I have a 256-meg USB drive with a floppy-sized partition that contains some sort of driver for Windows 95 or 98, presumably so that you can format the big partition without making the drive useless with any computer where you didn't install the driver.

Until a few years ago, you could've (ab)used the autorun feature to make that work, but since malware writers finally got around to exploiting the gaping security hole that autorun represents, Microsoft now disable it by default. So you're back where you started.

Support for long filenames in FAT appeared in Windows 95, so any patents on it ought to expire in the next few years. FAT32 came in with Windows 95 OSR 2 - I'm too lazy to look up when that was released, but patents on it probably haven't got much longer. I don't imagine it's a coincidence that Microsoft are pushing a replacement for these filesystems.

I have a novel on sale in the Kindle Store ( Death & Magic , a murder mystery set in a school for wizards). I wrote it in OpenOffice.org, before I had any thought of releasing it as an ebook. When the time came to convert it, I exported it as HTML and used a text editor to get rid of all the crap that OO.o puts in just in case you want to re-import it and have it look something like it used to. This took a couple of evenings - I could probably have done it faster if I'd been braver with my regexs. It kept the italics without any problems. I put in some basic CSS to control the paragraph indents and make the chapter headings look nice.

I tried using Amazon's KindleGen program for converting the HTML to .mobi, but couldn't figure out how to fix all the compiler warnings. Then I found Mobipocket Creator, which did everything I needed without any fuss, and produced a file that looked perfect on my Kindle. (Well - perfect apart from the known bugs in rendering, such as the way it won't add more than a certain amount of padding between words, so a line can look too short if there's a long word at the start of the next one.)

I learned my lesson - the book I'm writing now (volume 3 of the series) is starting life as HTML in a text editor, so I control exactly what formatting goes into it.

Let me know when your book's on the Kindle - it sounds like the sort of thing I might like.

A solution would be to make the first chapter free and the full book $5.

Amazon already requires this as a condition of publishing your book on the Kindle. They make the first 10% of any book available as a free download. When you get to the end of that 10%, there's a link to buy the complete book. If you don't want to buy it, just delete the sample. Smashwords does the same, but allow the author to say how much of the book he wants to offer as a free sample. I presume other bookshops have a similar arrangement, but I haven't bought anything from them.

This feature probably needs to be more heavily promoted... I saw a review of The Help by Kathryn Stockett that amounted to, "The Southern dialect made the book too hard to read. If I'd known about it, I wouldn't have bought the book." The Southern dialect is readily apparent from the first page (or screen), so this person could easily have saved their money...

One use of the data would be to create a uniform worldwide definition of "sea level". Countries have their own standards for it. We know they're not the same, but we don't always know by how much they differ. When the Channel Tunnel (between Britain and France) was being dug, and the diggers from each end met in the middle, they found they were about 50cm out - each side had been measuring their depth relative to their own definition of "sea level".

That would probably work better, yes. Though you can bet this hack wasn't done by someone looking up the record for phone number 000-0000-0000, then 000-0000-0001, then... Perhaps as well as limiting the number of searches an employee can do, searches should be limited to returning no more than X records, where X is much smaller than the number of records in the database.

Partition the call centre employees according to the least significant digit or digits of the customer's telephone number. Employees A, B and C deal with customers with phone numbers ending in 0, and can only see records of those customers. Employees D, E and F deal with phone numbers ending in 1, and so on.

This is how it was done when I worked in the civil service nearly 20 years ago (well, there it was alphabetically by customer surname, but it's the same principle). That was done for logistical convenience, because we had huge quantities of paper. The records of any customer who might call me would be within 10 feet of where I was sitting, but it had the useful side effect of making it obvious if I went looking at records I wasn't supposed to.

Granted, this approach in itself wouldn't stop someone copying everything they can access onto a DVD, but if done properly, it would limit the number of customers who want to sue you. It would also give you a head start on figuring out which employee has gone rogue or wrote their password on a Post-It...

...I did my computing A-Level on these machines. The school had about 20 of them, networked together with Econet and using a 20 megabyte hard disk for storage. Students had an allocation of 100 K (yes, kilobytes), and I don't think I ever filled mine up...

Now get off my lawn!