Lars Wirzenius: March, 2007

Contents

Friday, March 23, 2007

Random hacks: Finnish .ics files

I abandoned paper calendars in 1997. For a few years I used various Palm devices, then Evolution. For the most part, this has worked fine. One of the drawbacks is that I have not had any info in my calendar about official holidays in Finland. That would be useful so that I would know when other people are going to be responding to e-mail slowly, and get annoyed if I call them on business.

Evolution can deal with several calendars at the same time, and can import calendar files in various formats. A couple of years ago I found an iCal file with Finnish holidays, and imported that to Evolution, but it's out of date by now. This week I decided to look for a new one, but before I did, Droidy, the fastest interface to search engines, found one for me. Unfortunately, it was severly lacking, and did not even include Midsummer Eve, the biggest summer festivity in Finland.

I then decided to make my own. I skimmed the web pages of The Almanac Office at University of Helsinki. They used to have the monopoly on making calendars in Finland (and what a silly anachronism that was), and they still have the copyright on name days, but that stuff doesn't interest me. The list of holidays is uncopyrightable, and that's the info I extracted from their pages.

I also looked at the list of times when food stores are allowed to be open. That's actually more important to me than holidays.

I ended up making two .ics files: aukiolot2007.ics for opening hours, and suomi2007.ics for the holidays. They're probably riddled with errors: if you find any, e-mail me and I'll fix and update. I hope they're of some use for someone.

(I realize that someone is going to tell me about a complete and officially supported .ics file with all the above data as a response to this log entry. Good.)

Permanent link to this entry

Saturday, March 17, 2007

Random thought: Energy meter

A few weeks ago I bought a device for measuring how much power other devices use. An energy meter, that is. You plug it in a power socket, and the device you want to measure into the socket in the meter, and it tells you how much power gets used at the moment, or over a period of time.

So far, I've used it on two devices: my laptop, and the so called desktop machine I have, which acts as my music player, movie player, disk server, local Debian mirror, and so on.

The results: the laptop used 2.25 kWh (kilowatthours) over 164.5 hours, for an average energy use of 13.7 Watts. That's measured over 24/7; since I put the laptop to sleep while I sleep, the laptop probably uses about 20 Watts while I'm actually using it.

The desktop used 22.07 kWh over 232.0 hours, or about 95.1 Watts. Again, I shut it down while I sleep, so it's probably around 140 watts actual use while running. Quite a difference. That's for the case and contents only, the display is separate (but used only when I watch a video).

Yearly energy use would be around 120 kWh for the laptop, or under 10 euros (at 8 c/kWh), and 830 kWh or 67 euros for the desktop.

Both machines use cpufreq to slow down the CPU when load is low (which it is, almost all the time). I'll have to figure out other ways to optimize energy use in other ways.

Permanent link to this entry

Thursday, March 01, 2007

Debian: Automatic testing wishlist

Joey Hess writes about automated system testing in his anti-platform. That's one of the things that I'd like to work on, some day, when I have some free time again.

There's two things I would like to do next in this area. First are improvements to piuparts so divide the tests it does into smaller bits, and to add a plugin framework so that it becomes easy to write new tests. The current piuparts code isn't really well suited for this, but the whole program is only a few hundred lines of code, so even if it had to be rewritten completely from scratch, it shouldn't take more than a couple of weeks of full time work (piuparts development is often slow because you need to run tests on large parts of the archive).

The other thing would be to test upgrades not of individual packages, which piuparts does now, but of entire systems, preferably in emulated machines instead of chroots. This would probably need a new tool.

The third of these two things would be to start adding automatic tests to packages so that we can test whether they work when they're installed. Ian Jackson did some work on a tool for this, but we need to use the tool.

Ideally, we would have a setup where packages get tested automatically, continuously (daily, if possible) and results are reported instantly. At the moment, piuparts results need to be filtered manually, and that's a pain. Adding a "package health indicator" the PTS based on these automatic tests would be cool.

We could even have a "Debian big board" web page, with a small square for each package, colored green if it's bug free and passes automatic tests; colored cyan if there's only bugs of severity normal or below, or a problem with some of the automatic tests; colored pink if there's a bug of severity important, or all automatic tests fail; and colored red if there's bugs of severity higher than important. This would give an overview to the health of Debian with a glance.

Permanent link to this entry