My laptop appears to be dead. Whenever I turn it (a ThinkPad T42p) on, I get a “Fan error” message and it immediately turns itself back off. It was working fine (suspending/resuming) before, so I get the feeling it’s either lying to me or that it runs fine without a fan. In any case, my GUADEC photos and slides are trapped inside this insidious black box. Anyone have any ideas on how to get it up and running again?
MadPenguin, who always have good, in-depth reviews that don’t solely focus on the installation process have a glittering review of the upcoming SUSE Linux Enterprise Desktop 10 release. And why wouldn’t they? It’s a great release. At one point I was fixing a migration bug from the old Novell Linux Desktop 9 to SLED, and I got to play with NLD again for the first time in a long time. We have come a long, long way in the past two years on the Linux desktop.
During GUADEC, Miguel showed me a bug in which Beagle was more or less eating his machine a few times an hour. He blogged about the issue and his nifty leet Mono workaround. The problem he was seeing was that Beagle was overactively optimizing his indexes. Optimizing is the process in which multiple segment files are merged back into a single file. This is an intensive operation, but one which greatly speeds up searches.
The way the Beagle code worked previously was pretty dumb when it came to scheduling optimizations. After 10 minutes of indexing inactivity, the indexes would be optimized. In Miguel’s situation, he was receiving a couple of emails at a time. Ten minutes would pass and the index would optimize itself. Shortly later he’d receive more emails. Ten minutes later it would optimize. For most users, they would never even notice this. Optimization is expensive, but for smaller indexes you probably wouldn’t notice the 2 or 3 second spike of CPU usage. Miguel, on the other hand, had an extremely large email index, which made these optimizations very painful. The fix I just checked in ensures that we optimize an index at most once a day. Anything more often is overkill.
This is still somewhat of a band-aid over a larger issue, which is that optimizations are extremely expensive. On our walk to dinner one evening during GUADEC, Jon and I talked about this and our open-ended metadata issue which I talked about extensively in my Beagle talk and BOF and with individuals at GUADEC. The rough idea is basically to move metadata storage out of Lucene and into a separate store — yet to be determined, but SemWeb and sqlite are the early favorites — and do only text indexing with Lucene. This should greatly reduce the size of the indexes and make optimization more palpable. Also on my radar for some time is to move away from the concept of one-index-per-backend and move to a hashed pool of indexes, which will more evenly distribute indexed data, which will make certain types of searches much, much faster and generally reduce search time and memory usage.