Lars Wirzenius: May, 2005
- May 30: Finnish glossary for Debconf5
- May 29: Got my notification wish: zenity
- May 28: Notification from command line
- May 26: Nokia 770 and patents
- May 24: Sarge is not small, How big is sarge?, PSU poof
- May 17: Bug number error checking codes
- May 15: WYSIWYG word processing
- May 11: Encrypted laptop disk, Web log software update
- May 09: Testing woody to sarge upgrades, Automatic package testing, part 2, Sea-Hack 2005?
- May 07: Automatic testing of packages
- May 01: Winnow
Monday, May 30, 2005
If you're coming to Debconf5 in Helsinki, and don't know any Finnish, here's an essential glossary. I'll try to provide pronounciation guides as well: speak very slowly and clearly and people might understand you. Shouting won't help.
- Thank you: kiitos (pronounced approximately as "key toss").
- Greeting(s) (for all occasions): tervehdys ("ter" from terry, "ve" from verandah, and "dys" from dysentery).
- Good bye: hei hei ("hey hey").
- One, two, three, four, five, six, seven, eight, nine, ten: yksi ("ix e"), kaksi ("kax e"), kolme ("col" from colon, "may"), neljä ("nel" from Nelly, "ya" from Yankee), viisi ("we see"), kuusi ("coo" from cool, see"), seitsemän ("see it see man"), kahdeksan ("ca" from "carve", "dex", "an"), yhdeksän ("iih", "dex", "an"), kymmenen ("kim man an").
- Taxi: taksi ("taxi").
- Where am I: missä olen ("mis", "sa" from salad; "ol" from olfactory, "an").
You may also want to print out a few pieces of paper with the following phrases (I'm not going to give pronounciation guides for these):
- Olen ulkomaalainen ja eksyksissä. Auttaisitteko minut Otaniemeen? ("I am foreign and lost. Please help me to Otaniemi." Otaniemi is where Debconf is.)
- Ajaisitteko minut osoitteeseen Jämeräntaival 4. ("Please drive me to Jämeräntaival 4", to be shown to a taxi driver if really lost.)
- Missä on lähin tietokonekauppa? ("Where is the closest computer store?")
- Kadotin kannettavan tietokoneeni, auttaisitteko minua etsimään? ("I lost my laptop, would you help me look for it?")
- Voitteko lainata ruuvimeisseliä / ilmastointiteippiä / längatonta Internet-yhteyttä? ("May I borrow a screw driver / duct tape / wireless Internet?")
- En ymmärrä mitä sanot, mutta saanko tarjota juotavaa? ("I don't understand what you say, but may I buy you drink?"; this works equally well for all gender combinations).
- Anteeksi, tarkoitukseni ei ollut ärsyttää, älä läimäytä enää. ("I am sorry, I did not intend to annoy, please don't slap me anymore.")
- Epäilen, että minua seurataan. Missä on lähin poliisiasema? ("I think I'm being followed. Where is the nearest police station?")
I hope these are useful.
Sunday, May 29, 2005
About a dozen people told me about zenity, which is part of GNOME and in 2.10 seems to have a --notification option that does what I want. Even people who don't use GNOME knew about this: how could I have missed it? Thanks, everyone.
Saturday, May 28, 2005
I often run, from the command line, lenghty compilations or other processes. While I anxiously wait for them to complete, I keep switching between other windows and the shell window, hoping to notice immediately when the job is complete. This is annoying, but I can't stop myself.
It would be nice if there was a nice tool that could put up a flag in the GNOME panel notification area while the job is running, and, optionally, pop up a dialog box (or whatever) notifying me that the job is now complete. Something very simple that I could put in front of the command line:
flag --popup -- make -s all check
For someone who knows how to make a notification applet, this should probably be very simple. Or perhaps something like this exists already?
Thursday, May 26, 2005
Nokia has announced the Nokia 770 tablet pc and the free software development kit for it. That's free as in free speech and free software, not free as in beer. Open source, if you prefer. It's true: the machine runs Linux, and the SDK is free software. This is cool.
When I was hired by Nokia last year, that's the product I was to work on. The device has a coolness factor that was great enough that it made me sad to leave Nokia after only six weeks of employment. It would have been nice to have been part of the development team for something like that.
The reason I left Nokia, my unhappiness with their patent policies, hasn't changed. Apart from announcing the new gadget, Nokia also announced their patent support to the Linux Kernel (the press release). This seems like a nice move, but as far as I can tell, it is only a PR move to make Nokia look good. It doesn't help free software.
The Patent Statement applies to Nokia's patents infringed by current official releases of the Linux Kernel and all future official releases of the Linux Kernel to the extent that Nokia has not declared new functionality embodied in such releases to be outside the scope of the Patent Statement. With respect to new functionality introduced into future Linux Kernel releases, Nokia reserves the right to declare that the Patent Statement shall not apply.
This makes it clear the patent statement applies to official Linux kernel releases only, and only the stuff that is there now. Every Linux distribution I know of uses kernels they have patched themselves, not the official ones. New features in new official versions might or might not be covered. Obviously, were someone to fork the kernel, they'd be risking patent litigation as well. Any other free software also gets no help from this. Indeed, given that copying code between projects is common practice, people may have to start being extra careful when they copy things out of the Linux kernel.
On the whole, I don't think Nokia is evil for making this press release and patent statement. I suspect that their intention is good, as far as this press release is concerned. It doesn't do all that much to help free software, but I don't think it does any direct harm, either.
Nokia still lobbies hard for software patents to become legal in the EU. As far as I know, and that's not much since I don't have any relevant contacts inside Nokia, nothing in Nokia's attitude towards patents has changed. My reasons for leaving them haven't changed.
If you're an EU citizen, please write to your country's representatives in the European Parliament and explain your stance on software patents. Writing to your national parliament is also a good idea. Write today or regret forever.
Tuesday, May 24, 2005
Right after I posted my previous entry, I was told about an existing effort to count lines of source code in sarge. Here's a summary: 8638 source packages, over one million files, over 245 million lines of source.
That's pretty big.
Here's an idea for someone who doesn't want to help with fixing release critical bugs, but would like to do something else for sarge.
For some past releases of Debian, there have been attempts at counting the number of lines of source code in the release. I did something in 1997 or so, though I've lost the information since. Other people have done it for other releases, though I've lost links to them. I think it would be nice if someone did it for sarge. sloccount seems like a nice tool: adding a bit of wrapper scripts to unpackage sources (and then unpack upstream tarballs inside sources) should take a day or so for someone.
I bet that anyone with a beefy machine and a local mirror could then run the script on the entire archive in a couple of days and post results. AMD64 can build the entire archive in a few days, I'm told, so just unpacking and counting them shouldn't take very long.
The power supply unit in my server at home broke today, approximately at the same time as I woke. I don't know which way causality flowed.
Luckily, the PSU was still covered by warranty, and the store I bought it in had a spare, and, most importantly, my friend Droidy was able to come and install the new one. I would eventually have gotten it installed myself, but she does it much quicker and better.
Thus, if you can read this, pieni.net a.k.a. liw.iki.fi, lists.debconf.org, and a few other domains, is back in service.
Tuesday, May 17, 2005
The Debian bug tracking system now has bug numbers well over three hundred thousand. That is six digits. Typos are getting fairly common, resulting in the wrong being closed. This can be combatted by people adopting a never-type-always-copy attitude to bug numbers, but that is not particularly likely. I rather think that adding an error checking letter to bug numbers would be good. Perhaps something like "add all numbers together, take modulo 26, and pick the corresponding letter". I'm sure there are better ways to compute it, though, and some of the letters are too similar to digits and should not be used.
Use of the error checking letter should be optional, for backwards compatibility, but should be encouraged.
(I'm only half-joking here.)
Sunday, May 15, 2005
I had a need to produce a nice-looking shortish, simple text document (a business plan draft). I thought this would be a good time to experiment with what WYSIWYG word processing looks like with modern free tools: Abiword and OpenOffice.org. I wrote the draft (five pages, a few titles, some bullet point lists, mostly just plain text) in Abiword, and exported a PDF. Result: although paragraphs were nicely justified on-screen, in the PDF they were quite badly mangled, with a rather ragged right margin and weird inch-wide spaces in the middle of lines.
I then exported the document as RTF and opened that in OpenOffice.org. Result: fonts were wrong, with boldface for everything except bullet point lists, and the titles were the same size as the text. Margins were all too heck. Nothing really bad, and fixable with a little bit of effort, but not what I would expect from a smooth system. I don't know if the fault is Abiword, OO.o, or the RTF format, but I thought this level of simple stuff should work already, given all the hype going on.
I continue to be underwhelmed.
I'd put up the files so people could use them for debugging, but, well, they're meant to be confidential.
Wednesday, May 11, 2005
I re-installed esme, my laptop, again. This was my third
installation of Debian on it since I bought it just before
Christmas. The reason for the re-installation this time
was that I wanted an encrypted hard disk. Luckily, the
cryptsetup and kernel packages in Debian made
this really, really easy. Yay for their respective
Here's a brief summary of what I did: first, I wiped out
everything on the hard disk, and installed Debian from
scratch. I made three partitions: a half-gigabyte one for
/boot, a gigabyte one for swap space, and the
rest for root. I then installed a small Debian into the swap
partition, using the sarge RC3 netinst CD. Then I switched
sources.list to use unstable, and installed
cryptsetup and a 2.6.10 kernel (since certain
parts of my laptop hardware require that), and rebooted.
After this, I just followed the instructions in the
CryptoRoot.HowTo file in the
documentation directory to make the third partition
encrypted and move over the installation to that. Finally,
I converted the swap partition into an encrypted
swap space (following instructions in CryptoSwap.HowTo).
So far everything works fine. The system does not even feel any slower than it was: as long as there is no heavy disk I/O, everything is snappy. Any heavy disk I/O kills interactivity, but that happened beforehand as well. I don't do much heavy disk stuff on my laptop anyway.
End result: hopefully my laptop is a tad more secure in case it gets stolen (when turned off or with the screensaver running at least). I do have yet another password to remember, though, which is annoying, but worth it.
A few days ago I made some changes to my web log software. I don't think anyone noticed, which is at it should be. I admit that it is easy to make mistakes when writing software that generates RSS files, and that this is why so many people accidentally flood web log aggregators such as Planet Debian when they update. It is, however, annoying and avoidable.
One of the things I made into my software a couple of years ago is a limit to how many entries it puts into the RSS feed. Since feeds are supposed to be polled fairly often, having only at most, say, four days' worth of entries seems reasonable. Thus, if the software makes a mistake, there won't be all that many entries flooded anyway. Damage control is good.
I also used my web log software as the first guinea pig for testing Bazaar, one of the implementations of the arch version control system. I may put it up for others to access one day, after I figure out the details for that. It's still pretty specific for my needs, though. I don't have any intention of starting to compete in this area.
Monday, May 09, 2005
Now that sarge is frozen it is high time to start testing upgrades from woody to sarge. Using qemu, the CPU and PC emulator, can make this easier to do, especially repeatedly. Here is how I have been using qemu:
- Create a file to function as the hard disk for qemu:
dd if=/dev/zero of=disk.qemu bs=1073741824 seek=5 count=0(this creates a five-gigabyte file called disk.qemu; adjust of and seek according to taste).
- Download the woody installation cd image. The first one is sufficient.
- Run qemu with the following command:
qemu -user-net -boot d -cdrom woody.iso disk.qemu(adjust filenames as necessary). This will start a woody installation. Install a basic woody system, then shut it down. Ctrl-Alt-2 will get you to the qemu "serial console", where you can type "quit" to quit qemu.
- Make a copy of disk.qemu (to, say, woody.qemu) so that you can easily go back to a known state without having to install all of woody again. You might want to compress the copy; filesystem images usually compress quite well.
- Install the packages whose upgrade you want to test
into disk.qemu by running qemu again:
qemu -user-net disk.qemu.
- Finally, adjust /etc/apt/sources.list in disk.qemu and do the upgrade test. Make notes and file bugs as necessary.
When doing installations many times, it is usually comfortable to not have to re-download packages from the Internet. Using a caching HTTP proxy, an apt proxy, or a local mirror helps a lot. I use debmirror to maintain a local mirror.
In response to my idea about automatic testing of Debian packags, this Ubuntu wiki page was pointed out to me. It is much more thought out than my initial idea. I don't think I had heard of this beforehand, but it is not impossible. Anyway, it would be great to see Debian and Ubuntu work together on this.
Since pbuilder already has much of the functionality (setting up a chroot and such), I suspect it should be a fairly simple modification to it to do at least a simple test to see that installation works, upgrade works, and that uninstallation doesn't leave extra files around, or modify unrelated files. Running tests on a centralized server should preferably be done in a virtual machine (qemu, xen, whatever), because of security reasons, but when people build their own packages, they should anyway have enough trust in the code that it doesn't contain booby traps.
An idea I've been toying with lately: a three-day Debian hacking party on the ferries (read: big luxury cruisers) between Helsinki and Stockholm. Finns would take the cruise from Helsinki to Stockholm and back. Swedes would take the cruise from Stockholm to Helsinki and back. Each would do one crossing by themselves, and the other in full company. If enough people from each country joins, it would be possible to have a meeting room (even a small auditorium), without it becoming excessively expensive. Internet access can also happen then, though probably it is pretty slow (thus, a USB hard disk with a Debian mirror would be needed).
There should be some goal to the hacking, of course. Like, say, fixing bugs or such.
Maybe this would be doable in the fall. This summer we have Debconf5, so the fall sounds like a better timing.
Saturday, May 07, 2005
What a better thing to do at a wedding reception than talk about Debian. I had a talk with Richard Braakman (also known as "dark") about automatic tests for Debian packages. My current thoughts about this are as follows:
- Testing of upstream functionality (unit tests and so on) should be added to upstream source code and sent to upstream to be included in future versions.
- Testing of packaging functionality should be done as
much as possible in lintian and linda. Package specific
tests should also be supported. These might be run
during package building, and after a package has been
installed. The tests should be in the source package.
Adding optional targets
check-installationmight be a good way to go.
- Making a tool to automatically (and safely) check fresh installations, removals, and upgrades would be cool. Something that would create a filesystem image, add depended packages, and then make a copy of it. Then install the package into the copy, remove it, and see if any extra files were left behind, or any files not belonging to the package were unduly modified. This tool should be runnable both by developers for their own packages, and by lintian.debian.org or a similar machine.
These are just ideas, however. I don't have the time or energy to work on them, at least for the time being.
Sunday, May 01, 2005
I have started a company with a dear friend of mine, Anu: Winnow Utility Fans, Inc. We're gonna be so rich!