Terah and I are in the adult choir at church. The current choir director's aunt, Viola, is also in the choir. So she is Aunt Viola to quite a few people. Aunt Viola was the director of the choir herself for many years, back in the "old" church. That church was torn down to make room for a new building in 1965. Not long ago, I heard from someone that she was looking for a picture of the old choir. She thought it was in the church archives, but nobody could find it. But I happened to have a copy. Another person that was in the choir had given it to me to scan for a book project a few weeks before. So I uploaded it and ordered an 8x10 print for Aunt Viola. Terah and I sat behind Viola and her husband the next Sunday. As people were visiting before church started, I handed over the envelope and told her there was a little surprise in it. She opened the envelope, and knew right away what it was. And was she ever excited to have it! It made us very happy to have made her day. She was talking about it for the rest of the day -- actually, for a few weeks. So here it is, the choir of Tabor Mennonite Church in 1946. Aunt Viola is on the far right in the front row.

Yet another item on the already-too-long list of blatantly unethical behavior by Micro$oft.

This says everything, and should surprise nobody.

It seems that the horde (both version 2 and 3) is incompatible with the php session.auto_start option…
If this option is enabled in fact horde has the strange behaviour of immediately expiring the session of authenticating users, thus avoiding anybody reading their mail… This only happens with newer versions of horde btw: and old one that was installed on the same machine worked fine! Worse thing: none about this seems to be mentioned anywhere… :( And I only found out installing horde on a clean machine and starting to look for differences… which made me lose my whole afternoon (and my class)… sic!

Steinar, you use accessor rather than public data members because you may need to change the behaviour of the class to do something when you set a member variable. If you have all your data public, you can't do this. If you force people to go via a function, you can make changes to the class without affecting its users. You have a similar issue with inherited classes.

Steinar, you use accessor rather than public data members because you may need to change the behaviour of the class to do something when you set a member variable. If you have all your data public, you can't do this. If you force people to go via a function, you can make changes to the class without affecting its users. You have a similar issue with inherited classes.

Repeat with me: I HATE HARDWARE! My laptop's hard disk drive (iBook G4, purchased last year before going to Debconf4) has 369K+ load cycles completed, which means it has a very good chance of starting to fail some time soon. Great. Specially not because of loosing data or anything, but because changing a disk on one of this bastards is like finding a needle on a hayloft. Harry Potter's books are getting insane as a movie source. The Goblet of Fire is quite lengthy, but when turned into a movie it becomes a complete piece of craziness. During the whole movie you feel like someone is talking behind your ear: "run, run, cut this, run, not time for elves, no time for tournaments, forget about this, does not fit (mao, anyone?), run,... Arf arf arf, YES! We made it 2.5h !!!" It leaves me wondering how on earth they are going to turn the 5th "most boring HP book in the saga" book into a movie, and how they will manage to turn the 6th one into a 2.5h movie again, without dropping half of the superinteresting things happening there. Oh, well, I guess I have to read the books again.

So having found time to catch up satisfactorily on the implementation, time to get back into the blogging. After working out what you actually want to do, the next step in implementing stuff, in my book, is to make sure you fully understand the context of the stuff you’re trying to change. In this case, the “unapproved” queue concept comes from some thoughts from quite a while ago that come under the heading “NIv2” for “new incoming v2”. For reference, the original “new incoming” was the switch to separate queues for new, byhand, and accepted packages, which was followed by a notable update shortly after to make accepted autobuilding possible. That setup works, but has a few problems. One is that packages sit in accepted for quite a while (up to a full 24h), and occassionally in that time it can become inappropriate to actually add the package to the archive – for instance if it’s a build of a package that’s then removed from the archive. This results in an UNACCEPT, and requires manual intervention, since potentially it can result in weird inconsistencies, such as bug closures. Another is that files in the various queues aren’t tracked in the database, which can result in files (particularly upstream tarballs) being lost or left behind, and also requires some unpleasant special casing in the code. A final concern is that one of the bigger time sinks in the daily pulse is the apt-ftparchive scan, which is actually just doing work that’s already been done in order to allow packages in accepted to be autobuilt. Put all those concerns together with the ones mentioned last week, and you get the impetus for NIv2. The principle of that is to put stuff in the queue into the database properly, simplify it, extend the queuing support to deal with different queues, and move stuff from accepted directly into the pool every quarter hour, though only pushing to buildds that frequently, leaving updates of Packages files and mirror pushes to still be daily, or every few hours or whatever. This is what that bit looked like in the dak TODO:

[hard, long term] unchecked -> accepted should go into the db, not a suite, but similar. this would allow katie to get even faster, make madison more useful, decomplexify specialacceptedautobuild and generally be more sane. may even be helpful to have e.g. new in the DB, so that we avoid corner cases like the .orig.tar.gz disappearing ‘cos the package has been entirely removed but was still on stayofexecution when it entered new.

Obviously, it needed to get defined a little more clearly than that to work out how much the changes for the security queues I’m interested in depend on the other changes, and what they actually mean in detail. After some IRC discussion we came up with more or less the following summary of what NIv2 actually means:

How NIv2 should work. q/accepted goes away; once packages are accepted, they get added straight into the pool and the database. At this point they’re added to a micro-suite for the buildds, and so apt-ftparchive can cache the package contents; and a symlink tree is made up so incoming.d.o works. The micro-suite might or mightn’t be a fully fledged suite in the database. Presumably it wouldn’t be visible in dists/ though. The micro-suite probably should contain packages uploaded to unstable for X hours, where X is 48 or 2x pulse-interval or similar. This means UNACCEPT is impossible and apt-ftparchive takes less time in cron.daily. q/byhand and q/new get new friends: q/sec-embargoed, q/sec-unembargoed, q/stable-updates. Rather than checking for “byhand” entries, or a lack of overrides; uploads get diverted to those queues if they’re uploaded to security or stable, and get moved out of there when a security team member or stable RM (ie, Joey) runs an amber/lisa-esque command. This means sec-embargoed and sec-unembargoed need to be autobuilt. This also means that proposed-updates can be a full suite, and point releases can be a matter of (a) adding proposed-updates to stable; (b) removing old versions from stable; (c) removing packages that have to be dropped; and users can put “stable + proposed-updates” in their sources.list reasonably sanely. This also means that REJECTs from accepted (security) or the archive (p-u) aren’t needed. It means the queue ends up looking like:

    unchecked      [uploads go here, insecure]
    holding        [secured]
    new            [waiting NEW processing]
    byhand         [waiting byhand processing]
    stable-updates [waiting stable RM approval]
    done           [.changes files for accepted packages]
    reject         [.changes, .reason and rejected stuff]
    bts_version_track [data for BTS]

with q/accepted disappearing and q/proposed-updates and q/old-proposed-updates being replaced by the stable-updates / oldstable-updates queues.

One of the nice parts about this is that it breaks down fairly neatly into three sets of changes: supporting additional queues, removing the accepted queue, and tracking queue stuff in the database. It does make those changes more or less dependent though – the new queues need to be autobuilt in the way accepted is at present; so it makes sense to add the queues before removing accepted so as not to lose the queue autobuild support. The above actually can be simplified a little further – instead of managing a microsuite for changes since the last update, it’s possible to add accepted packages directly to the real suite; and generate the Packages files needed for autobuilding by querying packages accepted to unstable in the last 24 or 48 hours, simply by adding a field to track upload time for binaries as well as sources. In any event, this thus makes generalising the queue autobuild support the next challenge.

Several years ago (it seems like more than three) I was a student at Brown University. In addition to studying computer science and mathematics, I also took a bunch of courses in the music program, including three years of piano lessons. When I graduated, I gave a recital for friends and family, plus any members of the public who happened to wander in (not many did). And, this being the 21st century, we recorded it and I got a CD of the recording. I edited it, split it into tracks, and handed some copies out to my friends and professors as a going-away present.

Now I'm no longer a student of any sort, and Brown seems a lifetime away, but the music is still sitting on my hard drive. I've always meant to make it available for download, but I couldn't figure out how to get past technical issues of space or bandwidth. A few days ago, though, I had a rather belated bright idea: maybe the Creative Commons project would have links to places where you can host your music for free. Lo and behold, it turns out that the Internet Archive lets anyone upload audio to their server! Better yet, they're even willing to store lossless encodings -- more than willing, actually; FLAC is the preferred encoding of uploads.

So, to make a long story short, click here to hear my bad piano playing. :-)

Compare (in an utf-8 enviroment)

  % printf "'% 2s'\n" "a" 
  ' a'

with

  % printf "'% 2s'\n" " " 
  ' '

That happens with the builtin printf as found in bash and zsh, and with /usr/bin/printf. Also with perl, both with and without “use utf8”. As Clint pointed out to me, printf(3) states that “the precision determines the number of bytes written, not the number of wide characters or screen positions”, so the behavior is correct. Still, I’d like a way to get what I want (' '), does somebody have a suggestion for me? I can only think of uglyness.

Yet another thread on keyring updates in Debian has gotten me thinking about key signatures, what they really represent, and other associated topics. For those of you who might not know what I'm talking about, a brief primer. Before someone can be admitted as a Debian Developer, they have to have an OpenPGP key (practically, a GPG key) signed by a current Debian Developer. That is, someone who is currently a DD has looked at a photo ID, compared the photo to the face offering a key fingerprint, and compared the name on the ID to the name on the key. If they all match, we have a signature. The other qualification for becoming a Developer is going through a process designed to determine whether you have the required competencies. Since this testing process is conducted electronically, not face-to-face, the primary means of identifying the person behind the answers is via the OpenPGP key they used throughout the process. So, what do we have out of this process? Two things, that I can determine:

• The signature says that someone who Debian already trusts (the current Developer) affirms that the name on the key belongs to someone who has the same name.
• The holder of the relevant key has passed the necessary competence checks. Effectively, the New Maintainer process certifies that a particular key is competent, to all intents and purposes. This is important, because it's that key that gives you all of the "privileges" associated with being a DD -- voting, package upload, etc. Your identity is effectively that key.

So, the problem at issue is this -- what do you do when you lose control of that key? You lose it, or it gets compromised, or it expires (whoops!), or whatever. For all intents and purposes, when you lose control of your key, you no longer have an identity, in Debian terms. Generating a new key (and hence identity) is straightforward -- a quick invocation of gpg and you're away. Unfortunately, all that gets you is a pile of bits. There's nothing that intrinsically links you to that key. That's what other people's signatures on your key is for. Then, it comes time to get Debian to accept your new key as belonging to you. This is a lot harder than trying to convince the RTA (DMV.en_AU('New South Wales')) to give you a replacement drivers' licence. Why should it be? You're doing effectively the same thing -- "I am $FIRSTNAME $LASTNAME, give me my (licence upload privileges)". The difference is that, in the Debian case, all of our identity is effectively tied up in the key we use to go through NM. The person behind the key is somehow secondary to that whole process. So when the key completes NM, we record it in the "people who can upload" keyring. When a new key (which is prima facie completely untrusted) should be put into the keyring, we need to ensure that it is qualified. How can that key prove qualification? Well, we can send the new key through NM (dear ghods, no!) or refer to the source document (as it were) -- the human being. We're looking for consistency between the person between the two keys. That's trickier than it looks at first glance. Why? The big one is the non-uniqueness of $FIRSTNAME $LASTNAME (or even $FIRSTNAME $INITIAL $LASTNAME, for those so blessed). Google for yourself one day, and you'll see what I'm talking about. Anyone who has the same name as you could, at first instance, pretend to be "you" (for some values of, anyway). It might seem fairly unlikely, but there are two DDs with easily-mistakable names, out of a pool of 1,000 or so. The probabilities are not in our favour on this one. Then, of course, there's fake IDs, which are a whole other ballgame. How does the government get around the problem of name clashes and identity-theft-by-ID? By using other metadata about you to more uniquely identify you. Your date of birth, street address, perhaps even a general physical description -- all of these can help to disambiguate all of the identically named people out there. Debian can't use that, though, since that metadata isn't initially collected, and so it can't be rechecked later. This does suggest a bit of a solution, though. I said that Debian doesn't collect that info, but that's not entirely true. There is an optional repository of Developer contact details stored for other DDs to access, so we've got something to work from. The Developer updates their own details (whatever they feel comfortable entering). But, of course, people signing your key need to know about all that before they sign the key, so they can check (for example) your residential address and date of birth on your photo ID. You might ask "but how is the info the developer themselves entered accurate?", and that's a good question. The answer is that the legitimate developer entered that info, so if someone with the same name matches that data, then it's reasonable that it's still the same physical person. It's not a real good solution, though. Not all developers enter full metadata (and I can understand why they don't want to). People also often forget to update their details, too, which could quickly cause all sorts of problems. What is a good solution, then? We could always go with a bit of biometrics -- if there was any solution that was sufficiently cheap, reliable, and distributed enough to be used to identify 1,000 developers distributed across the globe to a reasonable standard of reliability. I'll wait for a minute while you finish laughing and wipe your eyes dry. I have to say, I'm stumped. I'd hoped, while writing this, that by the time I was finished I would have worked something out. But nope, it's a problem that's way beyond me. But I think I've got a much clearer handle on the problem space, so with a bit of luck, my subconscious (or someone else's) will eventually produce a sensible answer.

So, what’s with all the broken laptop hard disks?! I have two laptops running almost all day (one as a cheap simple server with built-in UPS) and one as workstation. But in the last, say, 2 years I had to replace the 2.5” (laptop) hard disk drives 4 times! Since laptop HDDs cost a lot more per megabyte than normal 3.5” drives, this was becoming an expensive issue for me. So, I geared up S.M.A.R.T on both machines and did some investigating. The major issue seems to be the load/unload system that is integrated into more and more of these drives nowadays. The heads will automatically be retracted (parked) after some idle time to decrease the risk of shock damage and reduce power consumption. However, this seems to be a bad combination with Linux. I have not done any research into the specific implementation of the journaled file systems that I use (ext3, XFS), but it can something to do with it. It seems the heads of almost all laptop disks I encounter are continuously unloaded and loaded instead of around 5 times per hour. It seems a hard disk drive is made to allow for 300.000 load/unload cycles, after that the mechanism wears of so that inaccurate moving can occur and the platters can be damaged because of a small miss. Now, my drives had 650.000, 1.2000.000 and 900.000 before bad sectors and completely erratic behaviour start to occur, but this was within a year. My most recent broken drive had about 3 load cycles per minute, this means 180 per hour. With things going bad at 600.000, the disk thus had a lifetime of 3333 hours (138 days). This is ridiculously short. So I’ve turned APM of all my drives off (hdparm -B254). Better a small risk of bad sectors when dropping my laptop than having to replace my disk within the year. Also note that my brand new Western Digital disk has spent 14.000 of its load cycles within the first 15 hours that I was busy with installing Debian and recovering backups! If someone has more information about this, please let me know.

If you have a firm opinion about the latest general resolution vote, please publish your ballot, and an explanation of your reasoning, in your blog (and hence in Planet Debian). Note that the ballots will all be published after the vote, so there is no voter confidentiality protecting your ballot in any case, and hearing your arguments will help people like me, who are undecided, to decide. I'm not looking to imitate anyone in my voting behaviour, but after the previous vote, I don't trust my personal reading of the proposals to be accurate or at least to reflect the reading that matters. Julien Danjou already explained his position:

Since I think we have to release Sarge as soon as possible in order to satisfay our users, I have just voted for postponing changes until Sarge is released.

Julien, I would like to ask you to publish and explain your full ballot. There are a lot of options in there, and it is not at all clear, at least to me, how one would order them to bring about a release of Sarge as soon as possible (note that I am as of yet undecided on even whether I want that or not:).

I am taking part for the second time in the (Inter)National Novel-Writing Month. The goal is to write 50000 words in one month of novel-like prose, regardless of quality. Essentially, it is a group effort of producing novel first drafts in a fairly good pace. Seems to work for some people, but I'm lagging behind with no realistic hope of catching up. I am writing each day, but my output is on the order of 500 words a day, not the 1700 words a day that the official goal requires on average. So, I'd properly belong in the International Write Something Month (IWriSloMo), affectionally known as I Write in Slow Motion. The goal there is to produce 200-250 words of bad short fiction (bad, short and fiction being all optional) each day in one month. But I think I'll stick with NaNoWriMo - there's gotta be the losers, too, you know :) And I get a noticeable boost from being able to compete in my own weight class (I can order participants by word count, and I can try to up my position on that list:). My current minimum goal for each day is to restore myself to the first page of Finnish contestants. So far, I have been successful. So what am I writing? It is a Horatio Hornblower pastiche set in the 25th Century and the setting is space. I can hear you yawn, but hey, nobody said it was any good! :)

I seem to be getting more reports on pbuilder failing weirdly.I also noticed cowdancer no longer seems to be working.cowdancer debugging time, again.First, I noticed that cp has changed behavior and cowdancer testsuite was failing to set up a test lab.cp -al 1/ 2/used to create directory 2/ from 1/,but it now fails complaining that 2/ no longer exists.cp -al 1/ 2will do what I wanted to do.The main problem was that with 5.3.0 (which was uploaded on 12 Nov),stat --format changed behavior, and that broke cow-shell. According to the NEWS, in new feature(!) section.

Weblog Software

I’ve been keeping an online journal over at LiveJournal since 23rd February 2002. To support them I actually bought a “Permanent Account” a while back, an example of putting money behind companies and/or services which are useful - even when it isn’t required. After getting into the swing of things there I started the blog which is used upon Planet Debian and have also been enjoying that. Livejournal is a nice service, and they have great software powering the site. The Livejournal code is available and it is reasonably simple to install. (I’ve setup a few installations of the codebase, and played with them. I admit I’ve never run it in anger). Obviously it is completely overkill to run your own installation of Livejournal - unless, perhaps, you’re a school or a large company. So for my personal blog I use Wordpress. I don’t particularly enjoy using wordpress. To be honest I need only four features/abilities of weblog software:

• The ability to create posts.
• The ability for users to be able to leave comments upon entries.
• The ability to search previous entries.
• The ability to export the blog entries as a feed.

Everything else is utterly overkill. The downside of using Wordpress is threefold:

• Because it is popular there are multiple bots crawling the web and leaving spammy comments.
• Because it uses some funky addressing system any replacement would leave lots of broken links.
• It has historically had a couple of security issues.

I’ve been telling mysefl for the past few months:

• This software has got to go.
• I’ll wait until there is another security hole discovered.

So .. HTML::Template & CGI::Application will at some point come to the rescue. I’m just not sure when. I guess this means I’ve not yet written a bloggin system…. I want to only cover the basics:

• Multiple users.
• Multiple catagories/tags.
• Comments with a sane anti-spam system.

PS - The Sisters of Mercy rock.

Since interviewing the creator of Ruby on Rails, David Heinemeier Hansson, I've been thinking a little more about what he calls "opinionated software." That handy little phrase seems to sum up what attracts me to a lot of technology, at all levels. What I like Free software--it's not really economics that drew me to free software, but the principles and aims. When you release or use free software, you're exercising your right to free speech and adding your voice to an argument. Desktop environments--GNOME 2.0: The move from GNOME 1.0 to version 2.0 was highly opinionated (Mac users, think OS 9 to OS X). Complexity of user interface was thrown out in favour of sensible defaults. Web standards--CSS, RDF, XHTML: not only is there a right way to do things, but it turns out to be better too! I don't automatically fall in love with everything that emerges from the W3C, but some things are so obviously the right way it's impossible not to love them--warts and all. Muine music player--this player throws out the paraphernalia of iTunes clones and gets you close to the music. Queue, play. What I want to do. Epiphany web browser--a simple text bar does for bookmark lookup, search and URLs. The bookmarks work like del.icio.us tags. Despite the lure of Firefox extensions, simplicity and efficiency keeps me with Epiphany. Make friends and enemies The thing about opinions is that people are inclined to disagree with them. Opinions won't please everybody and, being opinionated, you will never carry everybody with you. But opinions give you something with which to scythe through indifference. In both my writing and software development work taking a particular stance enables me to create interest, and gives direction to my projects. I tend to get bored easily, and if I'm bored, then my readers and users will never make it. Being opinionated in software development is easier when there's a strong leader, or it's a one-person project. It's more of a dilemma if you're running a free software project with multiple contributors. Such projects need such contributions, but run a risk of losing focus and style. I think that there we need to be brave again. If being opinionated means losing potential users, it also means losing potential contributors. Opinions help in dealing with users, too. It's obvious that the mere act of listening to users isn't good enough. They often won't say what they mean, or their requests mask a deeper issue. How often have you given your boss exactly what he asked for, to find it wasn't what he wanted? A combination of reading-between-the-lines and having opinions helps cut a way through the noise of user feedback. Stirring the pot Here are a few wishes for some free software projects that I want to see succeed further, but which really need to get opinionated to be effective. These projects aren't failing, but they're not reaching the potential I know is there. Each of them are infrastructural in some way, and that's probably where the temptation to avoid being opinionated is strongest. But here's the genius: the rewards of being opinionated here are high. Ruby on Rails is the existence proof.

• Beagle, live search technology for GNOME. Needs to decide where its primary use will be, and get on and hit the 1.0 point for that use only. Choose one or two neat applications for integration, and be so utterly cool that every other app author flocks to integrate too.
• Synchronization. First MultiSync, then OpenSync, have rumbled on for ages, without ever being truly effective for any particular device. My take: choose a few "must-have" target devices--say, iPods and Nokia phones--and make them work completely. Nearly-but-not-quite pleases nobody.
• Mono. Mono's great, but where's the story? There's loads of potential in the people and the ideas behind the project, but playing catchup with Microsoft isn't very inspiring. Early projects like Muine helped Mono's cachet here, but we need more. My personal favourite option would have been a completely free alternative to ASP.NET for web applications. (I've seen a project called MonoRail, but don't know if it's the one...)

What's better? A handful of users with the "right" idea about how fundamentally important you are to everything, or loads of users who only see a portion of the capabilities of a project? Copy the experts It may seem like cheating to copy Apple's lead, but a lot of what they've done in OS X is to take a stand on what's useful and not. On many occasions this has inconvenienced people, but it's not eroded that special lure that Apple products hold. There's not harm in asking "What have Apple done?" with some of our projects. Another poster-child for being opinionated is Ubuntu Linux. Technically, it's only marginally better than other Linux distributions. Strategically, it's miles ahead. Its founder, Mark Shuttleworth, had very solid opinions about where Ubuntu should go, and pursued them. Over time, these have pervaded the product itself, but at the start it was the message and the style that made the difference. Opinions not expressed are rarely effective.

This posting is part of my Finnish criminal court series. See the introductory essay for more information and an overview of the Finnish criminal court system. The following is a fictional account of a criminal case, one of the most frequent ones, written in the form of a play script. A PDF is also available. There is also an OpenOffice-generated XHTML renderition, which may be more pleasant to read than the version below (but lacks most of its logical markup). DRIVING WHILE INTOXICATED
A glimpse of Finnish criminal justice
Part One Dramatis personae
Presiding judge
Prosecutor
Defendant Extras
Three lay judges
Court reporter Sets
Courtroom
Courthouse lobby DISCLAIMER This is a work of fiction. Although this play is based in general terms on real life, all the specific characters and events portrayed or described in this play are fictitious, and any resemblance to real people or events is purely coincidental. The verdict presented is fictitious, and while it is based on the author's understanding of the law, it may be erroneus. No legal advice should be inferred from this work of fiction. Scene One: And so it begins The courtroom is about the size of a large school classroom, and shaped as a rectangle in terms of floor layout. The judges' bench, a long wooden table, lays near one of the short walls; the space between the bench and the wall is enough to give the judges and the court clerks comfortable room to sit and to move behind the sitting judges. At the center of the bench is the seat of the presiding judge, who has easy access to a telephone, a public address system and a panel for controlling the LED display visible in the lobby above the courtroom door. To his or her right is the court reporter's seat in front of a PC and in control of recording equipment. To the reporter's right there is room for one additional individual. To the presiding judge's left, there are three chairs for the lay judges. If one were to stand directly opposite the presiding judge, on the other side of the bench, one would find an open Bible. In front of the bench, disregarding the Bible, there is some room, approximately two meters or so. Along each long wall there is a small table, and those two tables face each other, and are therefore turned sideways from the bench's point of view. By the desk on the bench's right is the seat of the prosecutor, and the other, facing desk is reserved for the witness being examined. Facing the bench, separated from it by that empty space, are two rows of tables with chairs. Beyond them there are two rows of seats for the audience without tables; the farther row is right at the other short wall. The long wall to the judges' right contains one double door leading to the court building lobby, and the other long wall contains two sets of double doors at each end of the wall, leading to a part of the building not accessible to the public. We'll call the door closer to the bench the judges' door. The PRESIDING JUDGE is a 50-something man dressed formally in black and blue. The three LAY JUDGES are more casually but still essentially formally clothed. LAY JUDGE ONE is a sixty-something male, LAY JUDGE TWO is a female in her fourties and LAY JUDGE THREE is a female just under thirty. The COURT REPORTER is a female in her fifties, also dressed formally. It is 9:00. The four JUDGES and the COURT REPORTER are sitting on the bench. Each JUDGE has papers in front of him or her, the PRESIDING JUDGE's stack being by far the thickest. The PROSECUTOR, fourty-something man, enters through the judges' door, carrying law books and a large stack of paper. He sits down at his desk. PRESIDING JUDGE (Nodding to the prosecutor.) Okay. Let's start. (Enters codes on the LED machine. Then picks up the public address microphone.) The criminal case 'prosecutor against Matti Meik l inen' begins in room three. Parties to room three. Scene Two: Main hearing The DEFENDANT enters through the double door from the lobby. He feels a little lost. PRESIDING JUDGE (To the defendant:) Matti Vihtori Meik l inen? (DEFENDANT nods.) Please, take a seat in the front row. (He waits for the defendant to comply.) This case will be tried as follows. First, the prosecutor will read the charge. You will then respond by telling us if the charge is correct or not, that is, if you in fact did commit the acts specified in the charges, and if you did not, or the charge is only partially correct, you should state briefly why the charge is in error. The prosecutor will then present the case, he will describe us his understanding of the events in question. When he is finished, you will again have opportunity to state if the prosecutor is correct or not, and if not, in what way is he wrong. If there is disagreement between you and the prosecutor, we will hear the evidence. After that, the prosecutor will state his or her concluding opinion of the case as presented here. Again, you will have the opportunity to respond. We will conclude with discussion of what punishment, if any, would be appropriate. The court will then discuss the case alone, and will finally announce the verdict. Is this understood? (DEFENDANT nods.) Okay. Prosecutor? PROSECUTOR (Reads the charge from a paper everyone has in front of his or her.) I demand punishment to Matti Vihtori Meik l inen for driving while intoxicated. Matti Vihtori Meik l inen had on the first of May this year operated his car while his exhaled air contained 0,597 milligrams of alcohol per liter. Matti Vihtori Meik l inen's driving license must be suspended. PRESIDING JUDGE (To the defendant.) Is the charge correct? DEFENDANT Yes, it is. PRESIDING JUDGE Okay. The prosecutor will now tell us the circumstances and events in detail. PROSECUTOR Thank you. It was to my understanding late evening on May day, and the defendant had come from a bar and was apparently trying to move his car to a cost-free parking space. A police patrol happened to observe this and the defendant had apparently been a little shaky in his walking, so the officers gave him a breathalyzer test, which showed significant alcohol content. The defendant was brought in the station where a precision test was performed. The first reading was 0,597 and the second reading was 0,617; the mean of these two is 0,607, and after performing the confidence subtraction, the reading 0,597 milligrams per liter was obtained. PRESIDING JUDGE (To DEFENDANT) Well then, is what the prosecutor just said true? DEFENDANT (Speaking in a colloquial manner and very somberly. He is ashamed and wishes this would be over soon.) Yeah, it is. PRESIDING JUDGE All right. It seems to me that there are no points of disagreement, so we don't need to hear witnesses. (The PROSECUTOR nods.) Okay, it's time for the concluding statements. I think we will hear consequence opinions at the same time. Prosecutor? PROSECUTOR Thank you. I don't think there is much to say. The case has been shown beyond reasonable doubt, in my opinion. We have the precision test readings and the defendant's admission. As to the penalty... the amount of alcohol we are talking about is just below the limit for serious intoxication, so this is no small deal. On the other hand, the circumstances were not very dangerous. I think suspended imprisonment could well be considered, though a stiff fine would probably be more appropriate. The driving ban must be fairly long, obviously. PRESIDING JUDGE All right. (To the defendant.) Do you have anything to say before we adjourn to consider the case? DEFENDANT Well, I suppose it's clear that something is going to be given to me. I prefer a fine, naturally. PRESIDING JUDGE Naturally. The court will consider all options. Do you have any special requests concerning a driving ban? DEFENDANT As short as possible, of course. PRESIDING JUDGE Do you have a particular need for a car, do you need it for work, for example? DEFENDANT No. PRESIDING JUDGE Okay. Now, your income. We have here the last completed tax report for you, it says you earned 500 euros a month and had no children. Has this changed? DEFENDANT No change. PRESIDING JUDGE Okay, thank you. If you will then go outside to wait while we consider this case, thank you. The DEFENDANT exits to the lobby, the PROSECUTOR exits through the judges' door. Scene Three: Deliberation We are now in the lobby outside the courtroom. There are many doors that lead to many courtrooms. Above each door, attached to the wall, is a display showing the current case number; there is also a light saying do not enter, which is lit for most of the rooms, including Three. Also there is a numeric display which is out at the moment for most of the rooms. For some rooms, they indicate when the session will resume. Each courtroom door also has a paper pasted to the door frame listing the cases for the day. The door leading outside is separated from the lobby by a routine security check area, and one of the courthouse police guards stands there waiting for people to enter. Some other guards and janitors sit in their glass booth. There are many people sitting on the chairs, waiting for their turn to enter one of the courtrooms. DEFENDANT enters from the Courtroom Three door and sits down, waiting. It takes about fifteen minutes. During this time, announcements from other courtrooms could be occasionally heard, and people would enter or exit other courtrooms. Then... PRESIDING JUDGE (Over the PA) Verdict in the case 'prosecutor against Matti Meik l inen' in Courtroom 3. DEFENDANT exits through the Courtroom Three door. Scene Four: The Verdict The DEFENDANT enters from the lobby and sits down. After a minute, the PROSECUTOR rushes through the judges' door. PRESIDING JUDGE (Announcing to all people present.) The District Court has examined this case and has decided that Matti Vihtori Meik l inen did in fact commit the crime he was accused of in the way specified in the charge. The justification is the combination of the measured alcohol content in Meik l inen's breath and his own admission of guilt. Matti Vihtori Meik l inen is therefore sentenced to pay sixty-five day-fines, that is three hundred and ninety euros. Penal code, Chapter 23, Section 3. His driving license is suspended until the first of November this year. Road Traffic Act Section 75 Paragraph 1. One who is dissatisfied with this verdict can appeal it to the Vaasa Apellate Court within thirty days. Dissatisfaction must be declared, however, either right now to me or within a week to the Office of this District Court. (To DEFENDANT) Come and take the fine ticket and written appeal instructions (DEFENDANT takes those from the COURT REPORTER.) This hearing is concluded. The DEFENDANT leaves, as the court and the prosecutor prepare for the next case. TO BE CONTINUED
(with the next case)