Via reddit (which kicks the crap out of slashdot and digg): What I've Learned From Failure.

The link above is a long, but fascinating piece. I've had to become a lot more interested in how to manage software projects since taking on Xorg maintainance, and the same lessons seem to scale up well to how Debian as a whole manages itself. This article talks about some of the major problems that I've seen myself deal with, and the experiences of this guy echo my own over the past year very strongly. Here's a few examples:

"Getting away from weak teams, another source of failure is the omnipresent threat of "chickens." A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team."

I like this and I've noticed it in the XSF and in Debian as a whole. People are free to work on what they want how they want, and this tends to work out well for us. But we also have no structure in which people must actually commit to what they do. As such, there's no accountability. This frees Debian developers from the preassure of having to work on something they don't enjoy, but it also creates abandoned packages, ignored bugs, and frustrated release schedules. In the past I've described a need for a stick in addition to a carrot for Debian developers, and the sentiment here echoes that idea. I've spoken with Manoj about his conception of personal responsibility in Debian, and I think it may truly be the bedrock on which Debian needs to rest. I still don't have a good mechanism for this yet though.

"Another sign of a weak team is poor development hygiene. There are dozens of development practices that seem trivial to the inexperienced outsider or to the manager focusing on "big wins." Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews)."

This is a something I myself have had a problem with over the past year. Branden was extremely good about keeping the XSF svn repo and the BTS up to date and well managed. I've done just about the opposite over the past year, and it's bitten me a few times. This however, was a conscious decision on my part, knowing that I was so far behind upstream that it was going to be hard to effectively manage the BTS without a recent codebase deployed to our users. So I focused on packaging instead, and luckily that road is nearly finished. Also fortunately, everyone else in the XSF managed the BTS for me, most notably (in alphabetical order by last name) Julien Cristau, Michel D nzer, Eugene Konev, and David Martinez Moreno, and they've managed to keep it relatively tidy. I'm going to spend some serious effort over the coming months to clean out the BTS so it's more manageable both for users and developers again. Luckly our SVN repo is in good shape still, so for the most part we're doing pretty well here. Debian as a whole also seems to be doing better at this, with lots of public svn repos springing up on alioth.

"It's mandatory to fail early. You need to know you're in trouble right away. That's essential when taking over an existing project or starting something new. You have to find out how you're doing within weeks. Not quarters, not months. The longer you wait, the more inertia the failure will have."

We're getting better at this, and I've sort of made it my mantra for this release cycle. Get things in to experimental as fast as possible, and then when I've fixed the majority of the bugs that show up there, put it in unstable as fast as possible. It worked out well for all the releases I've done so far and I'm going to keep doing it. Michel is really pushing me to keep CVS (or git as of Real Soon Now) snapshots from upstream in experimental, and I really like this idea and plan to follow through with it for this reason. This also echoes some of aj's ideas about speeding up development pace. Hopefully he'll implement them whether or not he becomes DPL, because I think they're going to be important for Debian as a whole.

"Dates are sacred."

We learned this during the sarge release cycle.

"The net result is that I've tried to find the happy medium where I generate weekly management reports on projects. A management report is something that is used to actually make a decision. Everything else is garbage. I've learned that when I haven't had management reports for a project, failure has resulted."

This is an interesting idea. It sort of echoes how I try and provide status updates on my blog, as well as the "Bits from" emails, but perhaps something more like this would be useful. I may try and play with this idea in the near future.

There's a lot more in there, but this entry already got way too long. Hopefully there's some food for thought in there for everyone who's interested in how Debian is run. The Debian development model has carried us very far, but I can't shake the feeling that we need to make some critical changes for it to continue. This will require a certain degree of boldness, but in order to fix the problems with the project I think we just need to clench our teeth and go for it. With that, I'll leave you with one last line from the above: "And if you decide to make changes, have the courage to go 100% with your gut. I've failed more than once when I watered down my convictions in order to appease dissenters. The only thing worse than evangelizing change and failing is looking back and realized you might have succeeded if you'd held firm on your convictions."

Yesterday I did some work for the XMMS2 Debian packages. Thereby I noticed that libxmmsclient0, the xmms2 client library, that allows you to write your own xmms2 clients, is bound to quite a lot of languages, but perl bindings were still missing. I took a look at the library interface and it seemed that creating bindings shouldn't be a big deal. Therefor I gave a try and wrote Audio::XMMSClient. There are still some rough edges, but it works pretty well already. The interface is quite close to the C API, so it's possible to work with it even if documentation, examples and a test suite are still missing. Comments on the API, the namespace and whether this module should go into the xmms2 distribution, like other language bindings, or directly to CPAN are most welcome.

Thursday 23^rd March: Friday 30^th March: In the space of seven short days, they've managed to go from hard-line right-wing, give us tax cuts, don't "throw it away" on the state; to full-on fund the NHS more "Daily Express Crusade" your childen are All Going To Die. If these headlines were in The Onion they'd be a fine example of tabloid spin and use of language. But they are serious, and I hate this paper. NP: g tis Byrjun, Sigur R s

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean time, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

The coldfire development kit of which I made mention in a somewhat recent -devel-announce post has arrived about a week ago. Mine was the last one to arrive; the other four have already arrived. It took a while, because mine apparently got lost in shipping, so they had to ship me a second one. That, and the fact that I said I'd ask around in my neighbourhood whether it'd been delivered at the wrong address (but then eventually forgot to tell the Freescale folks that I had done so and that, no, it wasn't) meant it took a bit over two months to arrive here. But it finally has. Whee! The box contains a number of things I do not and will not likely ever need (the CodeWarrior Development Studio, for example, or power cables for other places of the world, like the US, the UK, and Japan), but, well—that's not important. It also contains some things that are interesting, such as a serial cable—even if I already have a few of those. The box contents also smells funny. Oh well. In the mean, however, I've come across a bit of a problem: I can't seem to boot the thing. Well—I can, except it seems to be mangling the serial output it's sending for some reason. I can see that some output is being sent to the serial console, but it's not readable. And I can also see that it doesn't find it's root file system—I'm doing NFS root currently, and there's no network activity. Not sure what the problem is, though. Update: someone suggested that it is the baud rate. Yes, obviously it's something like that; however, I did try every baud rate between 9600 and 115200, but none of them worked. Besides, I have my command line say "console=ttyS0,19200n8", and it's still not working. I suspect a driver problem at this point...

By now, you would think that I would have learned that Breakfast + Freshmeat = mess. Today, we have an unimaginatively named program called "font manager". Some day, in the future, we may have a font manager -- but we don't yet. Here's the description, direct from the horse's mouth:

font manager is a font manager for GNOME. It cannot do any font management tasks yet, but is already useful for picking fonts.

It's quite adamant that font manager is a font manager. Yet it can't manage fonts. Interesting. I suppose this is an example of the curious issue of true identity -- are you who you are because of what you are called, or because of what you are? The author(s) of "font manager" obviously believe that your true identity stems from your name, regardless of what you may actually do. I disagree somewhat -- in a lot of ways, I identify more closely with the term "computer geek" than with my name -- I think it's essentially social conditioning and a need to be uniquely identified from all the other computer geeks out there that makes me remember to respond to a call of "oi, Matt!". An interesting book on this subject is Jennifer Government, by Max Barry (ISBN 0349117624), in which people's surnames are determined by who they work for (so take a guess as to who Jennifer works for). There's something very wrong with me when a quick scoff at a freshmeat article turns into pseudophilosophy and a book review...

I wrote a wiki engine last week, maybe I should write a weblog engine next week? Here's my own take on converging the two, which has been done before, but which some differences in ikiwiki perhaps allow to be approached slightly differently.

• ikiwiki supports pages that are subpages of others, for example, "Page/Discussion".
• Various parts of ikiwiki allow users to select a set of pages using globs. For example, "SomePage OtherPage OtherPage/* !OtherPage/Bar"
• ikiwiki renders pages statically, and can render rss statically too. This makes rss rather less expensive to serve..

First, I plan for all pages in the wiki generate a rss feed for that single page, which can be subscribed to if you want to track changes to the page alone. Then, pages can have a blog embedded in them by adding a special tag to the page, which includes a list of globs for the pages on the wiki that comprise the blog. Something like "Blog/* !*/Discussion", to exclude discussion subpages from the blog. This makes the most recently created of those pages be inlined into the html version of the page (with a form at the bottom to make a new post, if you don't want to commit to svn by hand) ... and enables creation of a regular rss feed too. Some nice features that just fall out of this:

• It's easy to set up subfeeds for categories. Just make blog pages for the categories, and an overall blog page that includes everything.
• All blog pages get discussion pages, without having to worry about people spamming your blog (unless they're already spamming your wiki of course).
• You can subscribe to an rss feed for any of the discussion pages if you like. Discussion pages can even be turned into little blogs of their own. Or they could even all be aggregated into a discussion blog (Containing anything matching "*/Discussion").
• Permalinks are just links to the wiki pages that are combined to form the blog.
• You can refer to any other blog posts using wikilinks; the wiki will automatically add backlinks to pages that link to a post, too.
• Since I keep my blog in plain text .mdwn files alredy, I can migrate from pybloxm to ikiwiki using pretty much just an svn mv ...

ikwiki's TODO has the details (about half way down; that page needs to be implemented as a collection of pages/blog itself).

Over the past week or so, I've decided to get around to listening to some of the "amateur" (in the same way that Open Source software is "amateur") podcasts that I've collected in the past couple of months (primarily so I can either archive them, or delete them and free up a bit of HDD space). As a great fan of radio, I've been pretty disappointed at the quality of the podcasts I've listened to. While I hadn't expected the BBC world service, there are a number of quite common mistakes I've noticed across several of the podcasts I've listened to. In the spirit of kaizen, I've noted down the really bad things that I've noticed, in the hope that someone who does a podcast, or is considering doing a podcast, might keep these simple mistakes in the back of their mind and avoid them. No podcast I've listened to so far has exhibited all of these symptoms (there's no way I would have gotten to the end of that hypothetical nightmare audio file) but most have exhibited at least one of these flaws. For a better general idea of how a good podcast might sound, listen to professional radio for a bit -- a lot of good shows are podcast themselves these days -- and get an idea of what a good show looks like. I'm also prepared to go further than just bitching about podcasts. If you do a podcast, and would like my (unprofessional but oh-so-opinionated) assessment of your podcast, please e-mail me at mpalmer@hezmatt.org with a link to your podcast, and I'll try to give it a listen and honest critique.

• Ad-libbing is a sometimes thing. I think I'm quite good at it (I gave my wedding thankyou speech unscripted and unrehearsed, and survived, so I can't be that bad) but I'd never consider doing a podcast without a script. In a podcast, all you have are your words, so if you're searching for words, or mangling them, it all falls apart. The downside to scripting is that you can end up reading your script in a monotone, without any life at all. I think practice with your script can probably improve that, but see the last point below.
• Waffle sucks. I'd say that scripting can help here, but if your script is full of waffle too, then you're SOL. Brutal editing is the only cure. The worst part here is that, since most people silently read faster than they speak, what looks fine on paper turns into something amazingly long and boring when read.
• Avoid meta-podcasts -- that is, don't talk about your podcast in your podcast. Something like "we're always looking for new content, see for more info" is bearable, but when 8 minutes of a 30 minute podcast is taken up with talking about the podcast wiki, mailing list, forum, ouija board, and so on, know that you're killing your audience.
• You do actually need content. Things that somebody out there is going to care about. A regular podcast is a brutal thing to commit to, and sticking to it must be hard at the best of times, but if you've got nothing interesting to say, don't record it, just have a short or missing show. We all know what filler sounds like -- you're not fooling anyone.
• Uhm is your mortal enemy. Not so much the occasional quick 'uhh' in the middle of a sentence, but I've heard "Uhmmmmmmm"s that went for at least 5 seconds. If you're that stumped for something to say, you need more scripting or editing.
• "Funny" voicing can be really distracting. Having a bit of life in your voice is great, but going completely off the charts only works for Robin Williams (and even then it's not a surefire hit).
• Whilst talking faster than a chipmunk on speed isn't a great way to run a podcast, you can easily fall into the trap of going too far the other way, and... talking... like... your... jaw... is... stuck... in... chilled... molasses...
• Why in the name of $DEITY are you reading out a long command line in a podcast? Sure, without the help of something like Annodex it's tricky to do commands and links the way you're supposed to (as text, dammit), but please do try. If your podcast is example-heavy, either consider dropping the podcast angle, or at the very least, provide an annotated transcript or "companion guide".
• You are allowed to do multiple takes of your podcast. Really. Read in small sections, and then stitch it together. Listen and retake a bunch of times until it sounds reasonable. (Aside: my one appearance in a podcast to date was about 15 minutes of recorded audio, before final editing. It took me about 7 hours to do -- admittedly, that included learning how to drive Audacity and do my editing, but I'd say I had at least 2 hours of mic time in there.)
• Some people just weren't cut out for "radio". You may be unable to stop your voice sounding like Lurch, or you get the giggles, or just can't think of interesting things to say "on air" -- whatever the problem is, you may just have to accept that you're better behind a keyboard than a mic. There's nothing wrong with that, but please be self-aware enough to realise it. No podcast I've yet listened to has been "kill it, now!" bad, but since I've only been listening to personal recommendations, I figure I'm mostly listening to the better class of podcast out there, and there's plenty of "give it up, please" podcasts out there.

I gave a talk to the Finnish Unix User's Group about PyGTK programming (see also examples). It seemed to go fairly well, although one hour is certainly not enough to do more than scratch the surface a teeny bit. This happened at FUUG's annual cruise, which this time went to Tallinn, Estonia. The service on the ship was not the bestest ever, but otherwise it was pretty nice. I had a cabin on my own, which was much nicer than the usual style of putting four people into a sardine jar. One of the things that came up was the fact that while there is fairly much interest in arranging a big happening in Finland next fall in honor of Linux's 15th birthday, there seems to be a severe lack a head organizer. This is sad.

Via Guilded Lilies (Grown Women Playing Games):

One of the things I find interesting in the development of computer games is the selective application of the increased realism that has been made possible by improvements in game engine technology. [...] What I find to be ironic is that there has been an industry-wide movement toward more realism through the function of, for example, physics AI in computer game design, without there necessarily being a concurrent application of that ideal to the creation of certain female body parts. This point has generated the response that games are not about realism, but rather fantasy, and thus do not have an obligation to represent women realistically

Many Linux distributions suffer the curse of the Galician-Portuguese words. This means that many of such distributions have names which look or sound like (or are) Galician and/or Portuguese words. For example, “Ubuntu” sounds, in Portuguese, like “O Ponto”, which means “The Point”. “Debian” means, in Galician, “They Should” or “They Owed”. “Centos” means “Hundreds” (and reminds Galician speakers of “Centolos”, “Spider Crabs”). “Fedora” looks like “Fedor”, which means “Stench”. “Nexenta” looks like the Galician word “Noxenta”, which means “Disgusting”. AFAIK, “Red Hat”, “Slackware”, “Caldera OpenLinux”, “SuSE”, “Mandrake” (sorry, “Mandriva”) and “Yggdrasil” mean nothing in Galician or Portuguese, but I’m sure that, given enough beer, somebody will be able to think of something. (As a speaker of Galician, I can offer my services as a naming consultant. My fees may look expensive, but think of the advantages of not having millions of Brazilians laugh at your distribution’s name!)

It’s been a while since I announced a release of randomplay, my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period. This new version features the much sought ‘back a song’ keybinding. It also announces the “random weight” preference of the current song as it plays.

As I've had to use Windows on a daily basis, I've found that I am no longer able to maintain my air of detached tolerance for the foibles of the system. In fact, I'm starting to get really infuriated with the utter boneheadedness of so many facets of it. Not so much things that are broken, as things that are done badly, and done so in the face of widespread examples of how to do it right.

Here are two simple examples that are emblematic of what Windows users have to suffer through.

(a) Mandatory file locks.

On Windows, every access to a file, by default, acquires a mandatory lock on it. Want to recompile the program you're working on? Sorry, you have to track down and kill all its running instances. Want to read that file on the network server? Sorry, you'll have to run around the office and ask all the people using it to close it.

Last week I got an email asking me to unlock a directory on our local fileserver so it could be renamed. It turned out that I was running an acroread process to view a PDF file...and that locked the directory from being renamed. Because, of course, the universe would implode if someone were to rename a file I had already loaded into memory. This is, however, better than how shared libraries are treated; trying to register a new version of a shared library with the system (the Windows version of ldconfig) will silently fail if programs have the old version mapped into memory. WTF? No, really, WTF?

Windows users get around this by having tools to find out which processes have a file open so they can terminate them with extreme prejudice. This is considered normal and acceptable behavior for a computer in the Windows universe. After all, in the real world two people can't use the same document at once, so why should they be able to do so on a computer?

(b) C# events.

They've been invented many times. Signals, events, hooks, whatever you want to call them, they're collections of function objects that are invoked when some particular condition occurs. It's a great way to make it easy to connect together objects that don't know about each other, they're simple enough that your average CS sophomore could implement them in a half hour, and the concept is so obvious (besides having dozens of examples of working and deployed implementations) that there's no way to screw it up, right?

Wrong.

Now, C# is generally a somewhat clunky language, but this is nothing to do with that (I am not, for instance, surprised that it's cumbersome to bind extra parameters to an event in a language that has little support for higher-order programming anyway). No, this is one of those utter idiocies that just make you scratch your head and go what the *@&# were they on when they did that? You see, when you call an event with no attached listeners, C# throws an exception. Just, you know, as a friendly way of letting you know that you didn't connect to that event.

But wait! It gets better! In order to test whether the event has any connected delegates (the Microsoft term for a function object), you ... compare it to the null pointer. Yes, that's right. Every time you call an event, you have to do this:

if(Event != null)
    Event();

...because, of course, an empty collection of events is clearly the same thing as a nonexistant object.

I really wish I could be a fly on the wall at the meeting where this was decided. My imagination supplies a scene along these lines:

Scene: A smoke-free office somewhere deep in the sterile labyrinth of the Microsoft campus

Programmer 1: "...and we call this bold new innovation 'events'! It's a way for you to perform method calls without knowing which method you're calling. We've found that it's amazingly useful when doing UI programming. I'm sure that introducing this new idea to the world will be yet another chapter in the Microsoft story of advancing technology!"

Programmer 2: "Have you checked the corner cases? What happens if there is no method available to call?"

Programmer 1: "Oh, of course! In that case, the list of methods is null, so we throw a NullPointerException. We thought about adding an IsEmpty property, but who would want to look up properties on the null pointer? Besides, hardly anyone will ever want to create an event that might not get connected to."

Programmer 2: "Uhhh, sure, that makes sense to me."

...!!!?!?!?!

This post is going to be a little handwavey, but here goes. I really want to know what other Debian developers (and users, too, they’re in the same boat) think about this. So here’s the situation. You’re at a party — a college party, if you’d like to be precise, where all the things you saw in ‘Old School‘ happen — and by chance you are wearing a Debian t-shirt. There is consideration that doing this was a bad idea in the first place, but nevertheless, you’re there, and then the people you’re talking with start going on… First question from the peanut gallery: What’s Debian?
Second question, for those are looking closely at the words on the t-shirt (indicating that they have not quite had enough to drink yet): What’s Linux? For me, at least, it feels a little odd talking about heady stuff like Linux at parties like this. Not only is it awkward, it makes me feel like I’m getting a large ‘NERD’ stamp on my head no matter how I try to dilute it and explain it. It’s true — I am a geek. But I think it’s a bit of a faux-pas to flaunt it at a party where you’re more likely to see lots of “Mass Communications” and Political Science majors who, seriously, don’t give a damn. I’ve often tried to tell it off with “it’s a long story, not worth telling,” but all drunks love a good story. Just that this story isn’t particularly interesting! “So uh, to make a long story short, a lot of computer nerds got together and put together a lot of free software together, and it got called a ‘distribution’! Debian’s one of those distributions.” At this point, the hippies will have totally bought into it, because free is good, and free is love, etc. But they’re usually downstairs smoking pot and singing songs of liberation or whatever the hell it is that hippies do these days, so you’re still talking to the Mass Comm majors. So the question I’m really asking is: Is there a graceful way to explain Debian to people who don’t really care about it, but want a plausible answer? Should I just lie through my teeth and say it’s something they can identify with, like a band or a fraternity or something? That just sounds wrong, but if I try to sort of explain what it is, it’s hard to figure out how deep to go with it. This doesn’t just happen at parties, but it’s a notable example. Are there others in my situation? Am I the only DD in college in the USA who also has social interaction on a regular basis and inevitably stumbles on this dilemma? Help me out, guys…

This is probably one of the worst flames I've seen in a long time. The funny part is that he complains about "AA zealots", while he clearly is a "non-AA-zealot" just as bad as any "AA zealot" can possibly be. I know a few (definitely a minority) of people who dislike AA fonts. But as far as I can tell, it's really easy to disable them. And from all I the average user will like them better, so it makes for a sane default to enable them. So, yes, you zealot, I want my fonts blurry, because I find them easier to read. Sorry for having a different personal taste. Oh, and then there is an explanation why AA fonts can actually be easier to read then black-and-white fonts. Because they grey levels are more consistent (which btw, is one of the tings LaTeX does very well, keeping the grey level) than if you have to make each pixel either black or white. Let's say we want to make a line 2 pixels to the right and 1 pixel down. In fonts these things happen... Here are your options: (Sorry, I forgot one: the hole in the middle...) the right one is obviously using AA and is "blurred". The left one is "too dark in the middle" and the other two are deformed. Now let's blur them a bit, like the average non-eagle would see them: The last one clearly is the best representation of the intended shape (a diagonal line of even thinkness). This is of course different if the intended shape was that it becomes slightly "fatter" here, or deformed. The only sane default for vector fonts is to assume that lines should well, not become deformed or thicker. I agree that a excellently made black-and-white pixel font might be done in a way that these deformations don't hurt. It doesn't apply to your favourite Helvetica font IMHO, because that font was designed for printing quality. Now go, and play configuring your "window manager", while I get some work done with openbox as my WM of choice. Because it just sits there in the background and allows me to have all my windows maximized on their own desktops except for my terminals which tile nicely without any zealot WM.

In the aftermath of the SELinux Symposium, tons of stuff has been released. (It's only a pity it wasn't released earlier. ;-)) For example MITRE has released polgen 1.3. The web page doesn't tell much yet (as usual documentation is what SELinux is missing most...), but the Slides from the symposium explain what it's about. I think polgen can probably do at least as much as AppArmors genprof (which I havn't seen a screenshot of in action yet). There are more SELinux power tools coming up, easier policy languages and so on. Do also visit the Symposium website and check out the other slides and presentations to see what's going on. The polgen tool might also (like much of the other ways to write a secure policy, instead of learning the policy 100% automatically) be a good way to check applications for intended behaviour. Such things can turn up lots of weird stuff, for example the sshd trying to write to /etc/krb5.conf on a system with kerberos uninstalled, but this config file present.

There’s a big push in Massachusetts to eliminate the 15 year statute of limitations on child sexual abuse (that runs from the child’s sixteenth birthday)—for example, this Boston Globe article and editorial. Eliminating a criminal statute of limitations is generally a popular cause—after all, the only people negatively impacted would be criminals, and they don’t form much of a lobbying constituency, right? These articles rarely provide the full reasoning behind statutes of limitations, however. If they address the issue at all, they cite the difficulty of getting a fair trial many years after the events at issue occurred, as in the Globe editorial. There is a more compelling reason, I think, to preserve the statute of limitations: scarce resources. As with my position on the death penalty, I believe this issue should ultimately be decided pragmatically based on real experience. Prosecutors are terribly overworked. When I represented some indigent criminal defendants, the prosecutors were uniformly younger than me and had no idea what their cases were about until about 30 seconds before they were called to argue (especially in bail hearings). It was all they could do to not drop their two-foot-high stack of files (each representing a criminal case) on their way in and out of the courtroom. Every case requires resources. Police resources to investigate; prosecutorial and judicial resources to try; and ultimately prison resources if the defendant is convicted. While I understand the need to address past injustices, it seems to me far more important to address current injustices. For every trial relating to sex abuse that may have occurred 25 years ago, there are certainly as many abusers commiting crimes today. If the sex abuser from 25 years ago is still dangerous, he has likely committed more recent crimes for which he could be convicted. With current funding levels, it is absolutely impossible to pursue every crime committed. Even if we quadrupled funding for the criminal justice system, we are still going to be unable to do a good job catching and convicted all the bad guys. There are at least 250 recent unsolved murders in Boston currently. Necessarily, a choice to pursue sex crimes from 20 years ago is a choice not to pursue something else. All policy decisions involve trade-offs. Just about everyone is in favor of reducing or eliminating crime and child sex crimes in particular. We can agree on that, but it doesn’t answer the key question of how you do it. Despite the injustice in letting people get away with crimes committed many years ago, it’s a worse injustice to have inadequate resources to deal with crimes committed today.

<p>Came back from a nice walk on the seafront, including a 30 minute professional firework display from a boat 20 meters offshore and about 50 people watching, to find that someone had attempted to attack my blog comment to send spam. Fortunately according to my mail logs, nothing went out, but it did make me go through and read the comment plugin code. I did wonder if every suitable field had been cleaned and have now made sure that it is. Looks like it came from several IP addresses over a 5 minute period and got past my (admittedly very) simple turing test, so I don't think it was an automated script. For an example of the attacks, check out this <a href="http://www.davidpashley.com/cgi/pyblosxom.cgi/general/fists-of-fury.html">old posting</a>.</p>