I’ve been working to push database accesses down further on PenguinTV to lessen the load it puts on the disk. If the system is under heavy disk load to begin with, PenguinTV slows to a crawl and becomes unusable. Following up on my previous optimization work, a database hit for an unread entry is now this:
SELECT title, creator, link, description, feed_id, date, read FROM entries WHERE id=? (93729,)
SELECT id,entry_id,url,file,download_status,viewed,length,mimetype FROM media WHERE entry_id = ? (93729,)
UPDATE entries SET read=? WHERE id=? (1, 93729)
UPDATE media SET viewed=? WHERE entry_id=? (1, 93729)
SELECT id FROM feeds WHERE feed_pointer=? (322,)
We only read from each table once, and only write to each table once. That’s about as good as it can get, I think.
I like evolution, I really do. At least that’s what I tell myself. I’ve used it for about six years and I’ve never once lost my mail, so I try to give it the respect it deserves. That said, this bug is totally lame. Basically, when using message filters, any actions after a “move” action are not performed. There is no documentation on this, no warning in the UI, and no indication that there is a problem at all. Instead messages mysteriously don’t get filtered correctly.
I know everyone has their pet bugs, and developers hate people with pet bugs, so I’m not going to press the issue. But I really think there should be some indication in the UI that “move message” is a final act and that nothing can happen afterward.
I’ve been adapting PenguinTV for use on the olpc, which is not entirely easy. For an all-python application it’s not too hard, but I have precompiled libraries that I need to distribute with PenguinTV because the olpc doesn’t provide pycurl. Since I run Ubuntu Edgy and the olpc is based on Fedora Core 6, I need to do some sort of virtualization to test my activity.
The recommended practice is to download an OLPC OS Image and run it with qemu. Unfortunately, the image is broken for Debian-based distributions like mine.
The next option is to download the OS image and chroot inside it and run sugar-emulator from there. That also doesn’t work for me.
My solution is really complicated: Run Fedora Core 6 in VMWare, and then chroot inside the OS image from there. Success!
So here’s a picture of PenguinTV, running inside olpc build 142, chrooted on FC6, running inside VMWare Workstation, on Ubuntu. It’s not a pretty way to do software development, but it seems to work.