Anatomy of a Murder. David Denby put it best:

Otto Preminger s Anatomy of a Murder, from 1959, is still the best courtroom drama ever made in this country, and, in its occasional forays out of the court, among the finest evocations of place an Upper Peninsula Michigan resort area in the off-season, leafless, underpopulated, alcoholic, and forlorn. James Stewart, in one of his wonderful melancholy late performances, plays a former county prosecutor named Biegler, a lifelong bachelor who now spends his time with a non-practicing lawyer (Arthur O Connell) and an unpaid secretary (Eve Arden), who sticks around for the wisecracks. The movie is leisurely, detailed, realistic, intensely companionable; you get a sense of how people exist at the margins of a profession without losing their dignity.

Although there are some distinctions between a murder defense in the 1950’s in the Upper Peninsula of Michigan and modern-day patent litigation, the essence of trial technique is really not all that different. Highly recommended.

Prosecutor: Lieutenant Manion, wasn’t your action against Barney Quill much the same thing as your action against Miller or the Lieutenant you slapped at the cocktail party — all done in the heat of anger, with a willful, conscious desire to hurt or kill?

Defendant: I don’t remember my action against Quill.

Prosecutor: How long had you known your wife was stepping out with Quill?

Defendant: I never knew anything like that. I trust my wife.

Prosecutor: You just occasionally beat her up for the fun of it, I suppose?

Defense Counsel: There has been nothing established to permit a question like that. He keeps trying to insinuate without ever coming to the point. Let him ask the Lieutenant, did he ever beat his wife.

Judge: I will sustain the objection. Do you want to re-phrase your question, Mr. Dancer?

Prosecutor: No thank you, Your Honor. I’ve finished.

Technorati Tags: Otto Preminger, Anatomy of a Murder, David Denby

Share This

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

I finally got tired of Achievo not remembering what projects I last used, so I whipped up a small greasemonkey script to do that. It just makes the selection sticky, nothing very fancy.

Noting comments by bubulle and Debian-uk preparations, I've started looking at flights for Debconf8 with an eye to actually making a booking.
There appears that there will be a variety of Debian-ites hanging around Madrid airport and catching an apparently very limited number of flights to Buenos Aires as I seem to only be able to find 2 flights a day between Madrid and Buenos Aires.
Bubulle notes a connection from Paris to Madrid, I (and most of the UK team) would need a connection from London to Madrid. For some bizarre reason, leaving from Gatwick is more expensive than leaving from Heathrow. That's a PITA for me because my return flight home leaves from Gatwick.
More annoying is that the evening flight is much more expensive than the (very) early morning flight. So much so that it comes out at almost double the cost of even a relatively expensive hotel for the night.
My current ruminations revolve around:

flight  780.62   	- Expedia Special Fare

07:25 Depart London (LHR) 

Arrive Buenos Aires (EZE) 19:25 	Fri 1-Aug



13:25 Depart Buenos Aires (EZE)

Arrive London (LHR) 10:05  tip+1 day 	Sun 17-Aug

The arrival back in London is good for me because it provides plenty of time to get between Heathrow and Gatwick, even on a Sunday.
I guess London is a little further from Madrid than Paris - my trip comes out at over 1,000 compared to 900 from Paris. Can't really justify a return Eurostar for that difference.
(Yes, I'm travelling out for DebCamp too.)

In 1996 Peter Gutmann wrote a paper titled “Secure Deletion of Data from Magnetic and Solid-State Memory” [1]. In that paper he mentions the fact that the contents of RAM last longer at lower temperatures and suggests that data could be retained for weeks at a temperature of -60C or lower (while 140C causes rapid data loss). The paper also addresses issues of data recovery from hard drives, but given that adequate CPU power for encryption is available recovering data from a disk shouldn’t be an issue unless thee attacker can get the key to decrypt it or crack the algorithm - so disk recovery is not a hot issue at the moment. Recently some researchers at Princeton University have published a paper describing in detail how to chill RAM to make it keep its data after a power cycle and even after being installed in a different computer [2]. This attracted a lot of attention, while Peter’s paper described the theoretical concept (in great detail) the Princeton group showed how to implement the attack using materials that are commonly available. Most of the analysis of this misses some fundamental points. Any suggestion that you can wipe the RAM on power failure or on boot misses the point entirely. If an attacker can chill a DIMM and then remove it from the system then there is no chance for it to be wiped. Maybe if you had security on the PC case to detect case opening (some servers have a basic version of this) such things would do a little good, but it shouldn’t be difficult to bypass in most cases. Another common flawed analysis is to suggest that this is no big deal because sniffing the memory bus has been possible for years. While it has always been possible for government agencies and companies who design motherboards to sniff the bus, for most potential attackers it has been overly difficult. When considering the effectiveness of a security system you should first consider what your threat model is. Who is going to attack you and what resources will they be willing and able to devote to the attack? An organisation that is prepared to use expensive equipment and highly trained people to break your encryption probably has other methods of gaining access to your secret data that are easier and cheaper. The research from Princeton suggests that I could perform such attacks with my spare time and with equipment that is very cheap. I’ve been idly considering doing this to an old PC just for fun! Therefore I have to assume that everyone who has the same amount of skill and money as me can potentially compromise my data if they capture one of my machines. It is still most likely that if anyone steals my laptop they will want to sell it and use the money to buy drugs. I don’t think that I have any data that is anywhere near valuable enough to justify a targeted mugging. But my procedures (in terms of changing passwords etc) in the case of my laptop being stolen now need to be scaled up due to the ease in which data might be compromised. The best way of dealing with this would be to have the decryption keys locked inside the CPU (stored in registers or memory that’s locked in the CPU cache). The possibility of getting a modern CPU to operate at any temperature approaching -60C is laughable, and the CPU is a well contained package that can operate on its own and is difficult to attack. This would make things significantly more difficult for an attacker while requiring little effort (in fact it might be possible to lock data in the CPU cache already in which case a software change is all that is required). Update: A comment by Mike made a good point about CPU cooling. Toms Hardware performed an overclocking experiment (from 3.2GHz to 5.25GHz) and used liquid nitrogen cooling [3]. It might be possible to cool a CPU core to -60C in a reasonably small amount of time. But I still believe that it would raise the bar enough to make it worth doing. Update2: Thanks Jaime for the spelling advice.

• [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html


• [2] http://citp.princeton.edu/memory/


• [3] http://www.tomshardware.com/2003/12/30/5_ghz_project/index.html

Share This

Today I've noticed that my last post was on August and I've decided that I'm going to try to keep this blog alive. Since this summer I've left the University and now I only have two jobs... my daily work and my son; I believe that things are going better at a personal level, but the truth is that lately I have near zero time to devote to Debian and Free Software in general. As I don't want to leave the FLOSS world and I'm still able to do some sysadmin related tasks at work and at home I've decided that I'll try to reserve some time for blogging about them. I'm also thinking about starting a blog and a wiki in Spanish, mainly to be able to publish some of the documents I write at work about our installations, the advantage for me is that I can publish them with a little revision and that is much faster than translating them into English. Anyway, before creating new blogs my first task is to finish my home server migration; I'm moving all the services that were running on my old PowerBook (PowerPC @ 400Mhz, 378MB of RAM, 10 GB HD) to my other PowerBook (PowerPC @ 1Ghz, 768MB of RAM, 60GB HD), as I haven't used it for ages and I still use a lot the old machine. On the move I plan to change a lot of things, the machine is going to run multiple vservers and I plan to change a lot of the software I was using, always trying to simplify the maintenance and/or get more performance from the new machine:

• The internal network will use dnsmasq for DNS and DHCP (replacing bind9 and the dhcp3-server).
• My authoritative nameservers are going to be served by powerdns using the named backend for the primary servers and sqlite3 for the secondary domains.
• I'm going to move all my webservers from apache2 to nginx and fast-cgi (the speed and memory gains are huge at work).
• I plan to move all my repositories from Subversion to git, including this ikiwiki installation.

I'll try to blog about this new installation once it is done.

So, MadCoder had doubts about the crazy idea, so I took a little time to do a test with a package I maintain, namely, xulrunner. First, take all the deb files in the history of the package (at least, everything that is available on snapshot.debian.net today).

wget -O - -q http://snapshot.debian.net/archive/pool/x/xulrunner/binary-amd64/Packages.gz gzip -cd > list
awk '/^Filename:/ print $2 ' list xargs -I wget http://snapshot.debian.net/archive/

Next, commit all these in a different repo per package name :

perl -e 'use Dpkg::Version qw(vercmp); sub v my $f = $_[0]; $f =~ s/.*_(.*)_.*/$1/; $f print sort vercmp(v($a), v($b)); map s/^Filename: .*\///; $_ grep /^Filename:/ ;’ list while read f; do
    pkg=$ f%_*_*
    [ ! -d $pkg ] && mkdir $pkg && ( cd $pkg ; git init )
    cd $pkg
    ar -x ../$f
    mkdir data control
    tar -C data -zxf data.tar.gz
    tar -C control -zxf control.tar.gz
    git add data control
    git commit -q -m $f
    rm -rf data control data.tar.gz control.tar.gz debian-binary
    cd ..
done

Finally, evaluate sizes for each package, respectively, of all .deb files, their content imported in git (only the .git directory, including the index ; some space could be gained removing it), and the “optimized” git repository (after git gc, without modifying delta depth or window size, which may even improve the result)

awk '/^Package:/ print $2 ' list sort -u while read p; do
    du -c --si $ p _*.deb tail -1
    du -s --si $p
    cd $p; git gc ; cd ..
    echo
done 17M total
16M libmozjs0d
4.7M libmozjs0d 34M total
31M libmozjs0d-dbg
14M libmozjs0d-dbg 4.7M total
7.1M libnspr4-0d
1.3M libnspr4-0d 9.2M total
12M libnspr4-0d-dbg
2.8M libnspr4-0d-dbg 25M total
28M libnss3-0d
4.6M libnss3-0d 81M total
61M libnss3-0d-dbg
21M libnss3-0d-dbg 15M total
16M libnss3-tools
3.1M libnss3-tools 288M total
265M libxul0d
146M libxul0d 2.0G total
1.8G libxul0d-dbg
1.1G libxul0d-dbg 5.1M total
6.8M python-xpcom
1.1M python-xpcom 2.5M total
5.6M spidermonkey-bin
861k spidermonkey-bin 13M total
14M xulrunner
2.0M xulrunner 3.3M total
5.9M xulrunner-gnome-support
979k xulrunner-gnome-support


So these packages, stored in git, take between 15 and roughly 50 percent of the .deb size, which may be a nice improvement. Il would be interesting to know how these numbers evolve with time. Some files, such as the changelog.Debian.gz files, would also benefit from being stored in plain text instead of gzipped form. Note git gc took a while and a lot of memory for libxul0d-dbg. Also note these don’t include delta files that would be necessary to recreate the original .deb file, but this shouldn’t make a huge difference.

I often have a bunch of somewhat crazy ideas, and I don’t have any time available to test or implement them, which is sad. So just in case these crazy ideas would scratch someone’s itch, I’m going to throw them in the wild. I’ve been using git for a few months, now, and used it not only for source code management, but for efficient storage, too. *VERY* efficient. I’ll have to write about that some day. Anyways, while installing pristine-tar, today, I just thought it would be neat to have an equivalent pristine-deb, to store deb files efficiently. I’m pretty sure someone else thought about this possibility, but it’s still better that such ideas come to the ears (eyes, actually) of someone that could implement them. Such a pristine-deb tool could be used to… store packages from snapshot.debian.net. That would reduce the amount of space required for the archive dramatically, IMHO. I’m pretty sure old packages are not requested that much, so they could be generated on-the-fly from a CGI script placed as a GET action, so that urls wouldn’t change. The same could probably be applied to archive.debian.org. It could even save enough space that archive.debian.org could host snapshot.debian.net. But that depends on the average package content and its average evolution, which I have absolutely no idea about. Update: It would also be interesting to have the .diff.gz files in there, too ; it would obviously allow to have an easy view of the contents, such as copyright files, changelogs, and other bits of information available on packages.debian.org. Update 2: Actually, pristine-deb would as easy as storing 2 pristine-tars (one for control.tar.gz and one for data.tar.gz), and a debian-binary file. The .deb can be aggregated with

ar -rc file.deb debian-binary control.tar.gz data.tar.gz

Exactly one year ago today, I wrote about Git, Mercurial, and Bzr. I have long been interested in VCS, and looked at the three main DVCS systems back then.

A Quick Review

Mercurial was, and for the moment, remains, my main VCS. Bzr remains really uninteresting; I don't see it offering anything compelling that Mercurial or Git can't do. My Git gripes mainly revolved around its interface and documentation. Also, I do have Windows people using my software, and need a plausible solution for them, even though I personally do no development on that platform.

Ted Tso wrote his own article in reply to mine, noting that the Git community had identified many of the same things I had ans was working on them.

I followed up to Ted with:

... So if Ted's right, and a year from now git is easier to use, better documented, more featureful, and runs well on Windows, it won't be that hard to switch over and preserve history. Ted's the sort of person that usually is right, so maybe I should starting looking at hg2git right now.

So I guess that means it's time to start looking at Git again.

This is rather rambly, I know. It's late and I want to get these thoughts down before going to sleep...

Looking at Git

I started at the Git wikipedia page for an overview of the software. It linked to two Google Tech Talks about Git: one by Linus Torvalds and another by Randal Schwartz. Of the two, I found Linus' more entertaining and Randal's more informative. Linus' point that CVS is fundamentally broken, and that SVN trying to be "a better CVS" (an early goal of svn, at least) means it too is fundamentally broken, strikes me as quite sound.

One other interesting tidbit I picked up is that git can show you where functions have moved from one file to another, thanks to its rename-detection heuristic. That sounds really sweet, and is the best reason I've yet heard for Git's stubborn refusal to track renames.

The Landscape

I've been following Mercurial and Darcs somewhat, and not paying much attention to Git. Mercurial has been adding small features, and is nearing version 1.0. Darcs has completed a major overhaul both of its repository format and internal algorithms and is nearing version 2.0, and appears to have finally killed the doppleganger (aka conflict spinlock) bug for good.

Git, meanwhile, seems to have made strides in usability and documentation in its 1.5.x versions.

One thing particularly interesting to me is: what projects are using the different VCSs. High-profile projects now using Mercurial include OpenSolaris, OpenJDK (Java 7), and Mozilla's projects. Git has, of course, the Linux kernel. It also has just about everything associated with freedesktop.org, including X. Also a ton of Unixy stuff.

Both Mercurial and Git communities are working on TortoiseHg/TortoiseGit types of GUIs for Windows users. Git appears to have a sane Windows port now as well, putting it on pretty much even footing with Mercurial and Darcs there. However, I didn't spot anything with obvious Windows ties in the Git "what projects use git" pages.

The greater speed of Mercurial and Git -- even for pushing and pulling small patches -- likely will keep me away from Darcs for the moment.

Onwards...

As time allows (I do have other things keeping me busy), I plan to install git and work through some tutorials and try to use it in practice as much as possible, to get a good feel for it.

Future

It is beneficial to be using a VCS that is popular, though that is certainly not a major criterion for me. I refuse to use SVN because its lack of distributed functionality makes it too unproductive to be useful. But it looks like Git is gaining a lot of traction these days, especially in Debian circles, which also makes it more interesting.

I notice that Ted did convert e2fsprogs over to git as he said he might, incidentally.

• Peace! Huh! Yeah! What Is It Good For?
• Library of Lost Dreams
• The madness of a growing crowd
• join us now and eat the software
• Wired science features Chris Anderson's DIY UAVs

After about two weeks I'm finally able to come back to Debian, which feels good. After my last package upload was botched (and gracefully recovered by my teammates) I realized that I needed to step away for a little bit.

I'm currently in my fifth year of my PhD program. For those who don't know how such things work in the US, I have a small committee of people (my thesis committee) who act as advisors and gatekeepers on my work. They're the ones who gauge my progress, and ultimately give me permission to write my thesis and receive my doctorate. I'm supposed to meet with them every 6 months, and it had been over a year since my last meeting. Because I'd like to actually graduate one day, I was rather nervous about having the meeting. I was more nervous than I realized, and the botched upload reflected that.

Anyway, to make a long story short, the meeting went as well as I could have hoped for and my committee seems to be happy with my progress. I'm looking to get a paper out in the spring, and they'd like to meet with me again in three months time (which will absolutely fly by) to assess where that paper is at, and how things are going. At that point, I wouldn't be surprised if they tell me to write my thesis and graduate.

What I do after my dissertation work has been weighing on my mind for years and years, and it's obviously coming to a head. My boss will let me stay on as a post-doc in the lab for a while, which I may do depending on other job opportunities and progress on my projects. Ultimately though I need to make a decision that's familiar to a few others in my position. Do I stay in science or go try and work on free software for a living? I honestly don't have an answer yet, because I love them both.

I see tons of incredible opportunities in my field right now, and while I'm not the only coder interested in synthetic biology, I'm one who's positioned to get in on the ground floor of the science in a very real way and have a significant hand in shaping its future. On the other hand I spend my free time devouring computing literature, not biology literature, as well as producing software and things related to it. I do this because I enjoy it, and I know I enjoy it on a deeper level than the biology. Would I enjoy it this way if I did it for a living? I've got no idea, since I've never coded professionally.

I'm coming up to the fork quite fast now, and I'll have to choose soon. I know I'm lucky because I do have the chance to choose for myself, but that doesn't make it any easier.

As Josep asks for it every now and then, and we really enjoyed this trip, it's time to write about the four days we spent cycling from Ripoll to Girona, through the Ruta del Carrilet, a Catalan via verda similar to the one we completed a year ago. I spent this year's 9 d'Octubre cycling trip with totally different trip mates, not related to my triathlon team. The extensive group was formed by Sabri, Mar, B rbara, Carles, Desi, Adela, N ria, Amador and myself. We started our journey by car from Val ncia to Mollet de Mar, where we parked the cars and take a regional train to Ripoll with our bikes, where the real journey would start.

Arrival at Ripoll When we got to Ripoll, it was quite late and dark, but we managed to find the start of the Ruta del Ferro rail trail which would take us to Sant Joan de les Abadesses. It was quite cold, but especially really humid, so we had to think twice before settling on a place to camp and setup our tents. We had to take special care of covering the bicycles as the air was really wet, and anything we left uncovered would appear soaking next morning. In part, my shoes suffered from this.

Early next morning we had breakfast on the wet grass and then started our way to Sant Joan through a deliciously well equipped and maintained cycling track, which unfortunately only lasts for 12 kilometres through a splendind landscape. After having breakfast in the old railway station in Sant Joan, we abandoned the Ruta del Ferro to take a road to Olot via Sant Pau de Seguries, where we had to climb a small mountain and then descend through the Vall de Bianya until we got to Olot.

Sant Joan de les Abadesses' railway station Asking the locals for the start of the Ruta del Carrilet was fun due to the strong oriental accent in the area and we sometimes wouldn't get a word of what we were told. An old man recommended us finding a big park in the outskirts of the town, where we prepared our entrepans for lunch, and after a little rest, we started cycling up the Carrilet, which would take us to Girona in two stages. This Catalan area is of volcanic origin, and there are several natural parks dedicated to the phenomenon. There are many mountains covered with forests and impossible peak shapes, which due to the time of the year were starting to go from green to brown and yellow, making fantastic colour schemes in the landscape.

Under a green ceiling in Olot Just after the few first kilometres, the railroad track starts to descend most of the way, which makes it easy for people who aren't too trained, and easier to enjoy your way chatting with people while you cycle. As we consumed the daylight, we came across a parish church party with lots of old and young people from the nearby town of Sant Miquel de Pineda. Amador and I were lagging behind a bit at that point, and when we got there, we found the rest of the group were already off their bikes and either having a curious look over the party, or directly following suit and dancing like the others. We had a peek into the small church and also into a small graveyard in the back, where I was surprised to find the enemies of my Catalan grandmother: Fam lia Matabosch , as one of the headstones revealed.

Partying at Sant Miquel de Pineda As it was getting late, we eventually started off again, but luckily B rbara spotted what seemed a good sleeping place for that night. To the right of the trail there was a hermitage (devoted to Santa Cec lia) up on the hill which, for bonus points, had a porch with a recently renewed roof which would help cover ourselves from humidity and rain, as we found soon after starting cooking dinner. While the cooks prepared our soup, some others went down to the Carrilet in order to find out if the next town was close so we could get some driking water for the dinner. Luckily, Sant Feliu was close enough, and we found a bar where we got some water... and two bottles of wine, which made some people back at the hermitage very happy. We were quite tired though, so we eventually went to sleep after reading some stories from a great tale book, with the sound of rain hitting the grass outside the porch. The rain was still with us when we started waking up, so we had breakfast and packed our stuff very slowly, in an attempt to avoid getting wet. But rain didn't stop, so we made a few hacks on our bicycle bagpacks to minimise the amount of rain wetting them. When we were finally ready to set off and had cycled around 3 kilometres under the light rain, it finally stopped raining, making the rest of the journey very pleasant.

Sleeping under the porch of Santa Cec lia's hermitage This part of the route is again quite beautiful, with impressive amounts of green vegetation at both sides of the track. There's a lot of water presence in the land, which makes the type of trees and bushes quite different to the ones we are used to find in the Valencian Country. After going by a few small towns, we arrived in the old railway station of Amer, hometown of the Puigdemonts. Even if it was a bit early, we decided to have lunch there, so a few of us went down to the centre of the town to buy bread and some other details to eat. Being in my friend Josep's town for the first time, I wanted to visit his family's bakery, but unfortunately it is closed on Mondays. We had lunch back at the cute station, and eventually kept going on our way to Girona. Outside Amer, the Carrilet was temporarily cut by the road, and there were two possible alternatives: using the road, with heavy lorry traffic, or diverting through a very steep track with very hard slopes. Most of the group preferred the road, but Mar, Amador and I went up that track, which was hard to climb and really fun to descend. Apparently, Amer locals call those 1.5 kilometres the Tourmalet . It's probably not so bad, though. :)

Amer's railway station Unfortunately, the Ruta del Carrilet starts getting uglier after Amer, and as you approach the more industrialised towns near the capital Girona. The area around Angl s wasn't that fun, with the track continuously being invaded by cars and other vehicles. Soon after we were in the farmland area surrounding Girona and its Devesa. Jonathan was waiting for us in the city, after his two month stay in Scotland, and we were all happy to meet him. We discarded continuing our way to the coast, which was the initial plan, and instead dropped our stuff in the house of one of Adela's friends, and went out to have dinner to a Wok restaurant, where the poor people running it suffered our childish behaviour involving the rotating central dish on our table and custard sucking contests. Jonathan guided us through the Cathedal and city wall areas of the town centre, which are impressive, and we climbed all of the wall towers to have great looks over the dark and quiet city. Eventually, we went to sleep, as Adela had to leave early, and we had to pack to get our train back to Barcelona. Back in Mollet, we cooked our last camping-gaz lunch in the park right next to the station, before noticing the place stinked of dog poo. After the careful operation of filling the three cars with 9 bicycles, we were finally on our way back to Val ncia, completing another great cycling journey. If you like bicycle tourism and can travel to this area in Catalonia, I highly recommend it, as there's many great places to visit, all of them accessible with bikes.

Having lunch in Mollet

First of all: no, I'm not a huge fan of the genre. In fact, when I don't feel too good, I tend to avoid them, since they can depress me at times. But once in a while, a romantic comedy doesn't hurt, and I do kindof like them at times. Early last week, I picked up a DVD of the first movie at a low-price DVD shop nearby, and watched it. The prince and me isn't my favourite movie in the genre; the plot surely is interesting, but I can't shake the feeling that things work out too easily in the end. Compare with Notting Hill, for example, where the two protagonists need to go through (I believe) three cycles of relationship/no relationship before the end of the movie; this, in my opinion, makes for far more interesting cinema. But, all in all, it certainly was an interesting watch. I might think the plot could've used some improvement; but that doesn't mean it's bad. The entire visual aura of the movie is great; they went through quite some effort to make it look well. For instance, in a number of scenes it's obvious that they made the clothing of the characters blend in with the background; and yet they still managed to create diversity in those colors during scenes, by making the clothing differ just that tiny bit, and different parts of the background as well; the entire scene would be built up of one painting-like shot after another, yet all of them slightly different. Impressive. And then I haven't even mentioned the casting, which was magnificent. Anyway. Since I kindof liked the movie, and since the sequel DVD wasn't expensive, either, I got that DVD as well. Boy. I've never quite seen a movie's sequel be so completely and utterly out of touch with its original. What horror. Except for the male protagonist, not a single actor of the original cast returned for the sequel. They had good reason, so it seems. The plot is utterly stupid. It revolves around an ancient law that made it somehow illegal for the couple to get married. Hello? Do you really think a king wouldn't have the influence to convince parliament to get rid of that law? Of course not, but then you wouldn't have a plot anymore. Now if the rest of the movie would make up for this silliness, then it wouldn't be so bad. Except it doesn't. This movie is bad in... let me count the ways.

1. The plot error, as explained above. Also, the plot was quite incoherent, for the most part.
2. The casting is terrible. The original King Haraald, father of the male protagonist, managed to create a believable king, with that somewhat eccentric and strange flair that most European royals seem to have these days. The queen had a bit of an iciness over her, warming up to an interesting character once she started to like Paige. Even the minor roles were so well played. In the sequel, none of this returned. The queen was just tight; an empty shell. The new Paige had a problem with overacting in some of the scenes. In fact, that was a common issue; I don't think I've ever quite seen this much overacting in one movie. Also, King Haraald didn't even remotely look like the original; not physically, and not in his acting.
3. Speaking of the King, and given the plot of the original movie, he shouldn't even have returned for the sequel; he abdicated because he was terribly ill; he should've been dead, for crying out loud!
4. The CGI was horrible. In the original movie, there were a few scenes where I'll bet CGI was used; not because it showed, but because I don't think it were possible to create that scene otherwise. In the sequel, you could tell when CGI was used due to the utter lack of natural feeling. Ever heard of a randomizer? It's what you use to avoid having a full room of butterflies all shake their wings at the exact same speed. Shudder.
5. The "painting" feeling and attention to detail of the original movie was nowhere to be found. In fact, at some point they show a castle which supposedly is in Denmark somewhere, but it shows the Czech flag, instead. Ugh.
6. Some of the gags were funny, but not as intended; because they were so silly. I've seen 3-year-olds make better jokes.

... I guess I could go on forever, but then there isn't much point in boring my audience. The short version: the original "The prince and me" is an interesting watch, but please forget about the horrible sequel... ... I guess there's a reason why they put it directly on DVD and skipped the theatres.

I'm a bit tired after driving up to Munich for the Android developer meeting, hosted by Google, and being "on" all day, but it was worth it. I was a bit apprehensive that it might be too 'introductory' in the sense of the Google guys telling you in person things that you could have easily looked up on the web, without spending a bunch of time driving around Austria and Bavaria. Fortunately, that wasn't the case. There was some of that, but also plenty of unstructured time to chat with Dan Morrill and Jason Chen, the two Google "Developer Advocates", who are both very friendly, informative and informed, approachable and put a lot of energy into what they do, despite being a bit tired from flying over from the US. It was nice to get a chance to talk with them, and considering that the platform is still changing, useful as well, because they were definitely listening to what people had to say to them. My thanks to them for a job well done. Here are some "impressions" I took away - note that they're not what anyone said, just ideas I got about what they said:

• Source code is being released when handsets ship because they want to work very closely with the hardware partners to make sure the phone experience is good (they said this). They want to "set the bar high", and they probably run the risk of someone snatching the code and slapping together a phone if they let out the source code to early. (They definitely didn't say this, it's just me connecting the dots).
• Despite interest for 'other languages', it really looks like they want everything to go through Dalvik in some way or another. Clearly, at some point in the future, there will be specs for writing Dalvik byte code.
• They won't talk about the upgrade strategy, something I asked about. I want to know that as a developer, I won't be stuck with N combinations of things that I have to support over the years. I want to know how they'll minimize that pain, but they're not currently able to discuss it.
• Talking with other people attending, there seemed to be some doubts about security and permissions for user data, since Android is moving away from the j2me "everything is private" model, to a model where data can be shared between apps, which opens up lots of good things, but also some potentially bad ones as well.

There's still really a sense of Android continuing to evolve, in a true spirit of openness. I liked that, as it means there is space for people to tell Google what they want, rather than simply being given a finished product and told that that's that... but then again, I would, being the open source guy that I am. I didn't get to show off Hecl quite as much as I would have liked to, but I did get to mention it a few times, so I guess I did ok.

Seems not so kosher, in a legal sense.

Robert A. Heinlein: Starship Troopers (Putnam, 1959)
Paul Verhoeven (director): Starship Troopers (TriStar, 1997) The trouble with movies is that they fit only a short story. You can make a terrific movie out of a short story, but I have never seen a movie made of a novel that was at the same time good and faithful – most movies made of books fail in both. The novel Starship Troopers chronicles the evolution of a high-school kid into a mobile infantry officer in a world which had seen modern democracies fail and be replaced by a veterans’ rule (veterans of also noncombat and civilian service, not just military) – Juan Rico gets in just to impress a girl, and maybe to get to vote some day, goes through boot camp, makes combat drops from orbit as a private and then as a NCO, gets opted for officer training and by the end of the book is a competent officer, helping his old drill sergeant who had found the prize. Along the way we get political sermons (now I know where John Ringo got his tendency to have characters lecture on politics!), some interesting characters and just a hint of romance. The movie paints in broad strokes and primary colors. The first half of it is in fact a fairly decent redesign of the book as a movie, though I did not like at all how much in the face the romance (and two interconnected love triangles!) was played. Johnnie Rico gets in to impress a girl, goes through boot camp, makes some combat drops – And then it transforms into a horror movie (and loses any resemblance with the book). They make a combat drop, Lieutenant Rico drops his mission and goes rescue his girlfriend (the two triangles having been – eliminated by now) and totally misses his old drill sergeant finding the prize. Allegedly, the director never finished reading the book. Well, it shows. In the book, Rico would have been hanged by the neck until dead, dead, dead well before the end of the movie just for striking a superior officer; in the movie, everybody just shrugs it off. The book is an enjoyable military story, the founding father of a subgenre consisting of lots of newer books; the movie is just silly. If you have seen the movie, read the book. Don’t bother the other way around.

We have a problem with our tools in Debian, and it's this: Above the core tools in dpkg-dev, and the nearly core tools in debhelper and devscripts, and the many different -- but all slowly converging -- revision control systems, there is the potential for infinite cruft to pollute the source package. Note that one developer's cruft is another developer's use of an excellent tool. If you don't believe that, you haven't read a lot of crufy upstream build systems, because Debian isn't the only project with this problem. The source of this cruft is a near-constant stream of new tools that are each developed in good faith by someone who needs that tool, and then adopted and used in packages of a generally small percentage of developers, who think that tool might be a good fit for their problems. The tool isn't yet suitable for everyone to use, and most of these tools never become suitable for everyone, because

1. making the leap from a special-purpose, poorly-designed hack to a general-purpose tool is hard
2. getting the project to standardise on a tool is hard
3. a tool often doesn't become general purpose until enough people use it, no matter how well designed it is to start out with

So after a while, a better, or at least different, solution to some of the same problems will come along, and some generally small percentage of developers will choose to use it in their source packages. Meanwhile, the developers who chose the old thing will be set in their ways and not want to use the new thing, and generally cannot be budged to stop using the old thing by any amount of argument. Which in a sense is normal, and fine, until you have to collaborate with them. I don't care if someone I'm collaborating with uses emacs to my vim, but I do care if they use cdbs to my debhelper. I care because their tool-choice encrufts the source that I'm supposed to be working on. Once a significant percentage of all the source packages in Debian are encrufted for a wide array of different tools, it will become harder and harder to work with Debian's source packages. We're already seeing this happen. Another way of looking at it is that we've invented dozens of source package formats that all work differently, aside from a small shared core, and we expect our developers to be able to use all of them. At this point I see this as a huge, potentially killer problem, that is making Debian development become worse with every passing year. But I have no real solution. Obviously pointing out that tools are obsoleted or bad doesn't work; we still have dozens of packages using yada, which everyone agrees is horrible. That doesn't bode well, does it? One partial solution is to design a category killer, and get it embedded in acknowledged core tools. That's what I have tried, and so far, failed, to do with an evolutionary change to the Debian source package format, which I'd hope would give people a reason to stop using dpatch, dbs, and their ilk. As noted, this approach is Hard.

---

For now, I have no interest in being on a team that requires I use any of the following things:

• dpatch
• dbs
• quilt
• Any similar system that is used to move all patches to under the debian/ directory.
• Any system that nests the actual original upstream .tar.gz inside an .orig.tar.gz.
• yada
• cdbs
• Any similar system that obfuscates debian/rules.
• Any special script that is required to be used to build a package as a wrapper around dpkg-buildpackage.

This means that I can't be on the security or release teams, and even teams like the perl team are getting sticky to be on.

---

PS, this doesn't mean I dislike quilt. I dislike quilt encrufting Debian source packages, which is entirely different. PPS, In case you're wondering why debhelper gets a pass, it's because it's gone through the three numbered steps above to become a standard, general purpose tool, and has no serious competators. (Though it does have parasites, like cdbs.)

It’s quite convenient to have your GPG private key on your desktop, laptop and USB stick.. but if one of these is stolen or lost, you are pretty much obliged to issue a revocation. Now, RAID-5 has this wonderful property whereby it is impossible to recover data from an array of size n if you have (at most) n-2 elements. So, one idea would be to create a small loopback device -based array that you can spread around your nice stealable items - you then use your key by combining >= n-1 of them. ..Or Eve must steal n-1 items before she can reconstruct your secret key. You can recover the “missing data” from single lost device, obviously. There are almost certainly cooler algorithms for this, but none that are in the Linux kernel. Some scriptage that seems to work for me:

#!/bin/sh
set -eu
NUMITEMS=3
SIZE=30
create()  
	for NUM in $(seq $NUMITEMS);
	do
		dd if=/dev/zero of=$NUM.img bs=1M count=$(echo "$SIZE/($NUMITEMS-1)"   bc)
		losetup /dev/loop$NUM $NUM.img
	done
	sudo mdadm --create -l5 -n$NUMITEMS /dev/md0 $(seq -f "/dev/loop%g" $NUMITEMS)
	sudo mkfs.ext3 /dev/md0
 
stop()  
	sudo mdadm --stop /dev/md0
	for NUM in $(seq 1 $NUMITEMS);
	do
		sudo losetup -d /dev/loop$NUM   true
	done
 
start()  
	# Collect array elements from argv
	NUM=0
	for ELEM in $ELEMENTS;
	do
		NUM=$(( $NUM + 1 ))
		sudo losetup /dev/loop$NUM "$ELEM"
	done
	sudo mdadm --assemble --run /dev/md0 $(seq -f "/dev/loop%g" $NUM)
 
recreate()  
	# Assume already running
	dd if=/dev/zero of=$NUMITEMS.img bs=1M count=$(echo "$SIZE/($NUMITEMS-1)"   bc)
	losetup /dev/loop$NUMITEMS $NUMITEMS.img
	sudo mdadm --add /dev/md0 $NEW
	sudo mdadm --misc --wait /dev/md0
 

(This proof-of-concept script is deliberately broken: you’ll have to write the argument handling yourself and convince yourself you don’t have anything important at /dev/loop* or /dev/md0 or /. It might also make sense to only use the array in read-only mode, or you will have syncing issues.)
Ingenious learners may wish to construct other scenarios with other RAID levels; 5-device RAID-6 would only require 3 elements present to function (or to be stolen by Eve, naturally). Not that I’m actually doing this: it’s almost certainly as stupid as it sounds, I just haven’t thought of a convicing reason yet.

Things have been rather hectic lately, so I haven't found much time to blog. Here's why: DBE62 The Gigabit Ethernet version of our thin client took more time to produce than I expected, for a number of reasons mostly related to a few improvements we decided to squeeze into the design at the last minute. However, today, we finally reached a point where LinuxBIOS runs as well as it did on our previous DBE61 model and where we no longer need any DOS tool to flash the MAC address into the VIA velocity Gigabit chip we selected. Hurray! Production will only commence in one month, but I'm already excited by the new model's potential, both as a thin client and as an embedded platform. Another good thing is that, thanks to Ubuntu developer Scott Balneaves, we managed to get all the necessary tools to support thin clients based on LinuxBIOS into LTSP, so our Etherboot model works out of the box on Ubuntu, since Gutsy. Hurray! There is one remaining issue related to recent changes in X.org core functionalities that make the AMD driver we need unstable but, again, various AMD, Debian and Ubuntu developers are looking into fixing this, so we should soon have spotless Geode support into Debian and Ubuntu again. T rkiye I visited Turkey twice over the last few months, because I'm putting together a pilot project to better promote the Estonian high-tech sector abroad, in collaboration with the Estonian government. I have to say that the more I visit Turkey, the more I like the place and the more understand why these people see themselves as Europeans because, you know what? They are: practically every significant civilization and religion that is at the core of European culture had major events taking place in in Anatolia or Thrace and, also, a devastatingly huge percentage of the consumer goods sold in Europe are designed and manufactured in Turkey. Learning the rudiments of Turkish has also proven to be a lot of fun. While I'm nowhere near as fluent in Turkish as in Finnish or even in Estonian, the learning curve isn't as steep as I initially expected: Altaic and Ugric languages share a surprising amount of grammatical concepts, while Turkish itself borrowed a lot of vocabulary from French, because the founder of modern Turkey, Atat rk, was very fond of the language. I'll venture that proximity with nearby Middle-Eastern countries that were formerly under French influence has something to do with it too. Identity crisis To me, the most challenging part of these business missions abroad is to represent a whole economic sector from a country of which I'm not a citizen or even a resident. Case in point: Being invited to dinner by a Turkish investor, I noticed the waiter asking my host where his foreign guest might be from. A few minutes later, as the waiter put down a gigantic pita bread with the word "Estonia" spelled in roasted sesame seeds, my host asked, reading my business card:

• Actually, your name doesn't sound Estonian. France?
• Qu bec.
• And your mobile number ... 358 ... is that Finland?
• Yup. I've been living there for the past 10 years.
• Ah! So you don't live in Tallinn?
• Nope. Helsinki.

Looking at the waiter and pointing at the gigantic pita, he continues:

• Actually, make that Canada ... no, Finland ... Ah, sorry, never mind. Just keep it as Estonia.

Honestly, trying to keep a straight face while saying "We" about a country of which I'm not a citizen and where I don't even reside becomes unbearable. At some point, some European bureaucrats will have to admit that I need a new citizenship, to reduce the confusion and to let me find myself a proper national identity again; the sooner, the better. Besides, the absurdity of the situation keeps on jumping at everyone's face: during the second mission to Turkey, I kept on bumping into Finnish diplomats who took personal offense at me for living in their country and yet representing the interests of a competing, neighboring country. If you ask me, I cannot entirely blame them for it. However, as far as I'm concerned, I've done my homeworks: I've been here 10 years, I speak the language and I don't have a criminal record. Given this, you'd think that acquiring citizenship would be a mere formality, but the Ulkomaalaisvirasto doesn't see it that way. If you ask me, this country's very first Minister of Immigration, Mrs.Astrid Thors, ought to unilaterally grant citizenship to anyone who's lived here for at least 5 years, just for the asking, regardless of what circumstances brought them here or of what absurd decisions the Ulkomaalaisvirasto might have previously made on their residence permit status. Doing this would go a long way towards undoing the mess of her predecessors at the Ministry of Interior and it would speak volumes about how much Finnish society has evolved from the days when any foreigner was a commie they had to push over the Eastern border.