FAQ

How do I get free public domain titles from Google Books?

Free titles are indicated by a "Get Free" button in place of the "Buy Now" button. Barnes & Noble.com has partnered with Google Books to bring you half a million public domain titles for free. Look for these titles throughout the website, as indicated by the icon shown below.

Frequently unanswered questions:

What quality are these books? How are Google verifying the results of OCR'ing old books? Why don't Barnes and Noble make it easy to find and download the thousands of ebooks which _have_ been carefully checked over years by volunteers from Project Gutenberg?

Sounds like a deliberate decision to associate free ebooks with low quality (and an overwhelmingly high quantity of it).

DRM Irony

Hmm, perhaps I'd use this blog thing [more] if the editor had cooler graduated enhancement.

I consider asking why Fictionwise's free ebooks are all "secure" (encrypted) formats.

I search for Cory Doctorows "Little Brother"

head asplode

Well, I'm still using Gmail as my primary account. Heh.

Tuffmail is more geared towards business than personal accounts. I can't switch back to it noew, because my email archive is bigger than my Tuffmail quota. Tuffmail don't provide an automatic way to buy more quota. So I'm waiting for the next tuffmail invoice (I still use the tuffmail _address_, but forwarded to Gmail). At that point I'll ask for more quota, or close my account.

GMail still sucks.

They still require periodic captcha unlocks for IMAP access, and they still don't include an explanation in the error message. Switching my Dad over to GMail IMAP (from the ISP's unreliable account) wasn't an unmitigated success. And he only uses Gmail from a single computer! Normal users should not have to bookmark a such page - which has the stupidly meaningless title "Google Accounts"... /rant.

GMail still works rather well.

If you use the web interface, I'm sure it's more reliable than most ISP accounts.

Plus, it's a cheap way to keep personal mailing list archives. I have a separate GMail account to cope with the fire-hose that is the linux kernel mailing list. For this, I actually use the web interface - I don't actually want to download the text of every message. GMane (no relation to GMail :-p) is great, but it's had some downtime recently, so I prefer to have a personal archive.

Reasons to wean myself off Gmail

I became addicted to Gmail soon after it was opened to the public. Web access, labels, conversation view, gigabytes of free storage and (more recently) IMAP access, yay! But I've come to the point where it's a bit too much magic and I need to look at moving elsewhere.

1. To import my email archive with accurate dates, I had to set up a box poll. Uploading over IMAP causes broken dates.
   
2. To use Thunderbird on multiple computers I have to repeatedly unlock a CAPTCHA. Google said they were working on it... at the end of March.
3. Spam and general filtering. I'd like to have as much control over spam filtering as possible. I'd like to be able to keep spam if I really want to. I definitely want to keep the spams I flag for training. And for general filtering, I'd like to at least be able to export my filters.
4. Google like to think they use standards so people can control their data at will. But they don't provide Sieve or any other way to manage filters. They're not leading in the IMAP standardization effort, in particular on the mobile side. And while they provide contact import and export, they didn't quite go as far as providing LDAP.
5. They don't support my favorite browser - KDE's Konqueror. Fortunately the "basic HTML" view is very usable, but it lacks support for e.g. changing settings and easily deleting lots of junk mail. This is not really graceful degradation, let alone progressive enhancement.

Call me impatient, but my general impression is that Google aren't quite set up for application support. In any case, they don't value my use cases.

Email is very important to me. I appreciate Google for showing the world and I how powerful webmail can be, but I just can't rely on them to get it right. I have a couple of family members I'd like to convert to email-stored-on-the-server (IMAP and/or webmail), but I can't in conscience recommend Google. Both of them are used to desktop email clients, and Problem #1 above negates the advantage of being able to access email from multiple different computers.

I've been paying for what looks like a loss leader test account at Tuffmail.com for a few years now. It's time for me to review it again and see if I can make the switch. It's a smallish technical-oriented service. My only concern is it looks like a one-man company - I don't know what would happen if the guy left the business.

Phew. Links are tiring - but I don't like to moan without any citations. I need to start using Markdown.

Git (Guilt) followup

Aha! The Guilt docs say

"The patch directory can also be placed under revision control, so you can have a separate history of changes made to your patches."

I assumed this meant "git-add .git/patches/master". That's not possible though as Git doesn't believe you should be able to shoot yourself in the foot by tracking files under .git/. But it does let you do "cd .git/patches/master; git-init", and create a second repo under .git/. I guess this is what the doc means by a "separate history".

The advantage of this format is I can easily publish all my changes before I'm 100% happy with them. So I've now published the complete code for module-init-tools indexes, which shaves a whole second off my EeePC boot-time. It passes the testsuite, as well as my own "does it break my computer" test:

time grep MODALIAS /var/log/udev | cut -d = -f 2- | xargs -n1 /sbin/modprobe 2>&1|sort -o a
time grep MODALIAS /var/log/udev | cut -d = -f 2- | xargs -n1 ./modprobe 2>&1|sort -o b
diff a b

I just need to clean it up a little now and wait for the maintainer to get back in touch with me.

WARNING. It is not suitable as a drop-in replacement for module-init-tools. At least on Ubuntu/Debian, their module-init-tools package has been heavily customized with extra options, in particular -Q (--silent). Your Ubuntu will likely fail to boot if you build modprobe from scratch and install a binary which doesn't support the -Q option.

Git: is not so great for managing patch queues actually

I found myself doing a bit more work on module-init-tools than planned. The good news was that it had a testsuite. The bad news is I had to fix the testsuite first to work on my computer, then to get it to use valgrind as documented.

I also ended up fixing a number of memory leaks. These are unlikely to important in module-init-tools where all the programs are short running commands. However, they make it much more difficult to use valgrind to check for leaks in my new code.

Plus, while I was grokking all this existing code it seemed a pity not to profile it and shave some time off the hotspots (again, using valgrind, also with wonderful profile graphics from kcachegrind).

As a result, I currently have 12 patches with just under 6000 lines. My first approach was to import all the changes into separate commits in Git - hence the GitHub account. This is, it turns out, the Wrong Thing To Do. It's very cumbersome to go back and correct a commit if you miss something, or as a response to feedback.

So I'm now using "guilt". This is much like Andrew Mortons "quilt" patch management system, except it lets you feel superior for using Git underneath and not having to type "quilt add" every time you edit a different file. I've already used it to reorder my patches and regroup them more logically, and it works great.

What I'm trying to say here is that all the history I published on GitHub is now obsolete, and I'm going to blow it away :-). Before I do that, hopefully I can work out what the murmerings about tracking your patches directory in Git mean - then I can publish my patch queue on GitHub.

But now I have to go collect my SDM open assessment feedback. I was hoping to meet with Niall at the same time but he's not replied. Oh, and maybe I should get some food in the house.

Boot times revisited

I've been fiddling with boot time optimisations for a while now, but it's now born fruit.

If you look at GitHub sidebar on the left right you'll see "my-module-init-tools". I've just published all my baseline fixes.

Coming soon: the module index (already implemented and tested) that speeds up stock Ubuntu boot times by 3 whole seconds! This is on my EEE, remember - a 630Mhz Celeron. But even my Core 2 Duo desktop takes a whole second faffing around reading these module configuration files!

The current maintainer Jon Masters is very interested, but apparently quite busy at the moment.

Next up: UDEV. I had one simple fix to speed rule execution (compute jump targets at load time, instead of scanning at run-time), but the main problem appears to be that it just forks too many processes. I spent ages squeezing the last drops out of string manipulation code etc, because the fork overhead isn't really clear on oprofile. I still don't have a good way to profile it. My planned fix is to move away from directly access to environment variables, use pthreads instead of multiple processes, and then only fork & set environment variables when udev needs to run a different program like modprobe or vol_id.

Altogether, we can expect a modest boot-time improvement for everyone. (Ignoring the few freaks who manage to run a functional system without udev).

Sorry, no convenient links - I've run out of time and need to sleep. You know where the search engine is. (No, it is so not extra effort. Use a proper GUI & browser with support for middle mouse button "paste URL", and default search, aka search from the address bar. Select a word or phrase on the page, middle click, and magic happens. I'm on Konqueror on X11).