Debian used to be the cool kid among Linux distributions. Because our stuff worked much better, was easy to install and especially to upgrade. Dependencies would be automatically resolved while others were fighting dependency chaos, and our menus would have all the apps in it, where others had to fill their menus on their own. And at the same time, Debian was very flexible and could be customized to become e.g. Knoppix. Our bugtracking was great and we were openly discussing bugs and all this stuff. Many of these Debian achievements are now common among distributions. Especially among Debian-derived distributions. Debian however has become a reliable 'stable' distribution often even called 'stale', while others stand in the spotlight of innovation. Other distributions have come up with maybe more advanced bugtrackers (I'm not talking bugzilla, which IMHO is overengineered) and other tools. Technically, this isn't completely true. There are still many fields where Debian is technically leading. But our focus has recently been a lot about individual packages or components (e.g. the installer). Maybe we should try focusing more on infrastructure again. In fact, Debian still has some very good infrastructure components others might be lacking. Our QA tools (including bug counters, tracking which versions are affected by which bugs, all kinds of graphs, wotomae) are great. All our update-* commands are missing in many other distributions, also things like invoke-rc.d. We have a solid Python policy to support multiple Python versions and precompilation (judging from the SELinux policy, none of the other distributions has that yet). We're able to use dash as a minimal shell instead of bash in most places (which does make a speed and memory difference). We have Debtags. But these projects don't play a key role in Debian anymore AFAICT. Trying to start a major infrastructure thing requires a LOT of engagement, maybe too much. I'd love to see better SELinux support in Debian, but I can't do it on my own, it's just too much. And I find it very hard to find people to help me with that effort. If Enrico hadn't been pushing Debtags again and again (and with a lot of code), it would also have gone stale. Despite being IMHO something that can take Debian on top again (making it a lot easier to find appropriate software). One of the reasons why Debian is still living pretty much outside is that it would be a huge effort to get maintainers to add the corresponding Tag information to their packages and so on. I've always balked at even trying that, fortunately Enrico got some tag information added via overrides to the Packages file already. Another thing that should have been happening within Debian (but happened at Ubuntu) is 'upstart'. There have been a couple of packages dealing with new init systems, but none ever managed to get support into other packages (nor is there any package in Debian with upstart support that I'm aware of). Getting SELinux strict support into init ramdisks is another big thing I'm too scared of to even attempt... i.e. I doubt that I'll be able to do that on my own, yet even to get it into the actual packages... DPL candidates: any ideas on how to be come more agile in such points (e.g. adding support to sysvinit+upstart+initng+runit to all packages with init scripts)? It took us already ages to get LSB headers added to many init scripts. Or on any of the other transitions we should do (SELinux support, Debtags, ...), or even why we've lost this flexibility? The one idea I have for that is to try to do some hackfests. Like an init transition day, where a group of people tries to NMU most of the packages that have init scripts. Or adds "Homepage:" to most packages, which some important package metadata we only have on some packages. Or adding 'watch' files. Some of these would be easier if we had a common way of packaging and a central SVN repository. That would make it both easier to prepare the transition (e.g. committing init scripts beforehand) or especially for adding Homepage metadata and watch files without actually interfering with the maintainers work by not doing an upload immedeately, but just adding them to SVN so the maintainer includes them on his next upload. (Sorry, no comments enabled in my blog.) P.S. another thing I'd really love to see is a (semantic) PackageWiki for Debian, that has a Wiki-like structure with a page for each (Source-) package. Including things like e.g. Screenshots, Homepage link, Link to the Freshmeat page of the package, support lists/groups ... Kind of like the QA pages, but for the actual users, and editable by visitors.

I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports). With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general. For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically. (Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.) Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes. Anyway, just my € 0.02 [Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.] [And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]

Just got finished with my "power presentation" at South by Southwest. I think it went really well, but I went over in my time and didn't have enough time for questions in the end. I've been fussing over this presentation since we landed in Houston. I had an outline and a lot of notes but I hadn't really put the two together. I've been trying to carve time out to work on the presentation, but between the logistics of travel and various requirements of child care, I've been really scratching. It came together yesterday and last night, which was great. I went through the presentation a few times this morning and after lunch, so I felt very secure in it by the time I gave the delivery. I got good feedback afterwards; people seemed to have liked it. I've put my slides up at Talks/SXSW07. Hopefully people will enjoy reading them. tags: talk sxsw07 wiki speaker

SxQC Yesterday afternoon we got together all the Montrealers and Quebeckers who are here at SxSW for a little hangout session in the registrants' lounge in Brush Square Park right outside of the Austin Convention Centre. I was pretty amazed at how many people were here -- I think there must have been 15 people speaking French around the table. It's great to see Montreal taking its place at the table at events like this. As the technology scene in Montreal becomes more confident and more mature, I expect that we'll be more of a presence -- alongside San Francisco, Los Angeles, New York City and Boston as technology centres in North America. tags: montreal sxsw07 quebec

Twitter at work I'm so psyched that I finally got my personal twitter account set up today. I set up a Twitter account for Wikitravel a little while ago for keeping people up-to-date on technical issues on the site. But now I've got http://twitter.com/evanprodromou , too. Why am I so excited? Because I was able to know almost immediately about the birth of my friends' second daughter, Anoushka. Congratulations to Mark and Allegra on such a beautiful little girl, and congrats to Anoushka on picking such great parents. You're gonna be just fine, kid. tags: allegra mark twitter anoushka

Ok, a little bit delayed due to busy days… - anyway. Last weekend Chemnitzer Linuxdays 2007 took place and as already written in the grml-develblog I’ve been there. As every year Chemnitzer Linuxdays were great. I really enjoyed meeting people, hacking and giving support at the grml-booth, though it was quite stressful for me overall. On saturday I visited only one talk, it was Meike’s one - a very nice talk. On sunday I had my own talk, about “Erfolgreiche OpenSource Projekt-Maintenance” (successfull opensource project maintenance). My slides (PDF) are available online (german only, sorry).

Yesterday I received a Fulong Miniature Computer from China. This device is produced by Lemote and is based on the Loongson chip, a MIPS-like CPU developed in China and previously known as the Godson. The Fulong mini-PC has a Loongson 2E CPU running at 666 Mhz, 256 MB RAM and a 2.5" 40 GB hard drive. There are the usual I/O ports, such as USB, PS/2, Ethernet, audio, VGA and TV out. The Fulong mini-PC ships with a customized version of Debian. I'm really excited about the Loongson because it promises to make MIPS available on the desktop. In fact, the folks at Lemote already have a laptop based on the same motherboard used in the Fulong mini-PC. Lemote is also trying to establish a community around the Loongson. They have given 400 devices to partners and 600 to Loongson fans and developers in China. It seems that the community is quite active, but it's hard to tell because I don't read Chinese. Fortunately, there is a blog where regular updates about Loongson are posted. For now, I have taken some pictures of the Fulong, but in the coming months I look forward to integrating Loongson support into Debian.

Reduced the work queue after the nice weekend on CLT, I have some time to write a summary. After 2 years I was able to be there again, cause I blocked the weekend early in my timetable.
The event was organized quite well like it was all the time before. We stayed over night in a gym with round about 100 men and 5 women, really interesting, no more details! :)
The CLT was visited really good and there was many folks at debian booth. The range of questions did vary from rookie to advanced. Anyways … the question when etch will be released did hit us quite often.
The talks I visited was really good and very interesting. I did count 6 talks and one workshop held by debian folks.
The social event was a lot of fun and the buffet was nice. Debian scrounged, supported by team(ix) folks, at the game … the task was, to find linux commands in a text. We got place one, tree and the consolation prize. We found more commands than the organization committee, but we missed “ssh” .. what a blame … ;)
In summary I meet really interesting people, the event was quite well and I got too less spleep. Hopefully see you again there next year. Debian, opensource, planet

Christian is talking about problems with suspend-to-RAM and suspend-to-disk and the major cause of issue being the non-free Conexant HSF modem driver.

Since I got my new laptop I had my share of issues with suspend-to-*.

At the beginning everything worked fine, out of the box. Then (I think) I realized that my video card (damned ATI) was not working in accelerated mode, so I decided to fix that and since the card is too new to be even listed as existing on radeon driver's support page, I had to use fglrx.

Then I made the DRI work but suspend-to-ram ceased to work (after a few testing->experimental; experimental--> upstream updates, both ways); I started using the experimental driver (8.31.5-1) which proved to be stable enough (this time) just for suspend-to-disk, if it had dri enabled, or suspend-to-ram, if not having DRI enabled.

I even made a patch to help the maintainer update faster the package (I added a get-orig-source rule in debian/rules).

Now I have ported the patches in the debian package and updated it to 8.33.6 and I am running that. Problems include: consoles are not accessible, but suspend-to-ram and dri work. I will submit a bug with the patch to updated fglrx package.

I expect that I'll try soon to update to 8.34.8 in the hope that I will get all the things working: suspend-to-*, consoles, dri.

In a recent article I explained some of the mechanics behind putting together the schedule for XTech 2007. We've just added new visualization features to Expectnation that make proposal choice easier, and I thought I'd show some examples from the XTech 2007 review voting. Sparklines, devised by Edward Tufte, are thumbnail sketches of data that succinctly convey patterns. When Nat Torkington used sparklines to show reviewer voting patterns for OSCON program committee, it seemed a helpful addition to make to Expectnation. The profile of each reviewer is interesting — are they a harsh marker, or liberal with the top grades? — but sparklines really come into their own when drawn per proposal. Here are some small screenshots from this year's XTech voting, anonymized of course.
High flyers Reviewers are pretty unanimous about this proposal, as 4.0 is the top grade in our scoring system. The lack of variance suggests that I ought to ensure that all the assigned reviewers put in their scores — this could be just one person voting.  These next two are the pretty typical distribution for highly graded proposals: mostly top marks and a few average ones.  Middle rankingSome of the more interesting trends show up when the scoring isn't biased to either the top or bottom ends of the scale.  The reviewers are unanimous about this paper's soundness. It's not made anyone go "wow", but there's nothing to grumble about either.  This proposal clearly polarises opinion, and is such stands a better chance than the unanimous 3.0 above. Perhaps the subject matter or approach is controversial or timely.
Another proposal that divides the reviewers' opinions. It's also worth me checking here that I don't either have a pathologically strict reviewer, or at the other end, a reviewer with a wild passion for the cause this paper advocates.  Low scoring The quality of submissions is usually so good that I don't give low graded proposals much attention, but the sparklines could alert me to potential oversights. This proposal seems to polarise opinion between "rubbish" and "ok", so it's interesting to me to check out the subject matter and see if I'm missing something with potential.  These proposals were not received at all well.In summary, I'm delighted to find a solid practical application for sparklines. My thanks to Nat Torkington for the inspiration. 

I got some feedback for the script which tries to find conflicting packages I hacked together after the Chemnitzer Linux-Tage. Seems to be a useful tool, so it might be nice to add it to devscripts? Some criticized, that it won't work perfectly, since I only check against files mentioned in Contents-.gz where files / folder created in a maintainer scripts are not listed. I know that, but I don't know a useful way to solve the problem. It's better than nothing, and maybe I'll find later a way to add support for installation time created files. Thanks to Kevin Mark and Marc Bockschmidt who pointed me to some improvements for the script, which reduced the time the script takes dramatically! While my first hack needed for a simple package nearly 15 minutes, the new one is down to one or two minutes. Thanks! So please test it a bit; feedback is alway welcome. You can find the latest version at http://www.schmehl.info/tmp/conflicts". Special thanks to Alexander Wirt and Thomas Viehmann who did proof of concept rewrites in perl and python. Alexanders perl version is quite fast... but needs a huge amount of memory. Thomas' python version is very elegant! You don't need to understand python to understand his script. Nice done, but could need some further improvements; since it takes as much time nearly as my bash script. And since I hope it might be interesting for devscripts maintainer, and I'm not sure if they would like to add a dependency on python, I think my bash script has - for now - the lead :)) The script could still need some improvements. For example tweaking the code a bit; I'm sure many of the things I do with pipes from awk to another awk to sort (or something like that) can be cone my awk itself. I Just don't kno how. And instead of fetching the Contents-.gz from the main server, the script could tread it from the users prefered mirror... and maybe even support for other downloaders than wget.

Stratus seeks for comments from Alioth admins. Yes I’d like to see OpenID integration with Gforge. The upstream situation is a bit difficult, so I don’t think that you’ll have official opinion from them. In my case, I want OpenID integration because it would be cool to offer a standard wiki and be able to define ACL on some pages which refer to the Alioth accounts that people are used to use. In the longer term, we have other web services which are going to need authentication (DWTT, new version of the PTS, …) in order to provide customized content and it would be great to rely on OpenID for that part. I’m waiting your patches! And next time you want an opinion from the Alioth admins, please mail us instead of hoping that we won’t miss your blog entry in planet.debian.org.

The Chemnitzer Linuxtage event is over and like every year the event was very nice.
From my point of view it's one of the best organized and community driven events in Germany.

Sadly I just saw one talk (libfind) because most time I was busy with meeting all the people I can just see one time a year on this event and finding a way to allow dpkg to merge old and new configuration files.

This year I attended two booths, the one of my favorite live cd grml and the one of debian.
It was the first time for grml having a booth at the CLT and I think the feedback was quite good.

The debian booth was also very cool and well organized (thanks Noel) and I had alot of interesting discussions with different users.
One question which came up was why debian permits root logins in a default ssh installation. I had no answer for this question since I also think it's definitly a security issue. Elmar Hoffmann thought it could have to do with an easy way of scping files for root without using a user temporary.
If someone has an answer, let me know.

This is the sound of Galician po-debconf translations being given a big push with the last upload of dbconfig-common and its 101 strings for po-debconf. I'm amazed by the current effort of Magic Jacobo who is doing alone all this effort. Simultaneously, the Portuguese team has definitely beaten up the Brazilian team and the Catalan team is still running after world domination. Czech and German are progressing rapidly and all this should be soon available as nice graphs thanks to the work of Nicolas Fran ois.

While I’m not a Harvard student, I’m vaguely affiliated through some friends of mine with Harvard Free Culture, a local Free Culture chapter. They are, after all, just up the street. One of our newest projects is the Free Music Project. The goal, is, well, to gather together music under free licenses, both for just making a centralized collection of free music and for other specialized purposes, like providing music to go on OLPC laptops and school servers. So, go find free music, or if you’re an artist, re-release your music under a free license or record some new stuff. (If you’re in the Boston area, Antenna Alliance can help you get your music recorded for free. Who knows, maybe your music will end up on millions of laptops.

Not that this city would be a very attractive one (in my humble opinion), but they have one of the most interesting and well organized Linux events in germany. If you have nothing to do during the weekend (or need an excuse for not having squashed any rc-bugs ;) get to Chemnitz; it's really worth it. There'll be a Debian booth organized by Noel (Sorry, too lazy to dig out how to get your accents in HTML), as well as other interesting booths. I'll give a small workshop about debian package building. See you there!

Thanks to Rommel, I got infected with the FizzBuzz. I won’t bother to repost my own Perl solutions here, but let me say for the record what intrigued me most:

it’s amusing to me that any reference to a programming problem– in this case, FizzBuzz– immediately prompts developers to feverishly begin posting solutions.
1) The whole point of the article is about WHY we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz is irrelevant.

I should also say it took me a while (more than the 2 minutes for CodingHorror, and more than 10 for Rommel) to write up a couple of solutions; I had to set up a Test::More test script first. Yes, I cannot read.

Since I’m on a Google kick these last few days, let me ask a question I’ve been kicking around in my head for a long time: When are we going to get an API for our Gmail contacts? Like scads of other people, I use Gmail as my primary mail “client” these days, and that means I want things like email autocomplete to work, which means Gmail has to know about my contacts (or at least their email addresses). Gmail actually has a really slick interface to contact management that I’d happily use as my main address book. Trouble is, it’s not synchronized with anything, most importantly my cell phone, where I also want that address book to be available. So, for now, I have to maintain two address books—one in Gmail (with just the email addresses), and one in my phone (with everything else). Invariably, it takes effort to keep them “synchronized”, and I’m not always successful at doing so. I was hopeful that the new “APIs to integrate with existing infrastructure” introduced in Google Apps Premier would finally address this shortcoming—after all, integration with corporate directories would seem to be a feature high on the “must have” list for any enterprise looking at Google. Alas, the APIs appear to only deal with single sign on and account provisioning, and do not appear to do any sort of deeper directory integration. With an API, Plaxo could presumably synchronize contacts between Gmail and phones (and Outlook etc.), or even better, someone could do over the air synchronization. There have certainly been a wave of interesting products doing similar things using the Google Calendar API. I’ve thought about doing a synchronizer with libgmail, by I’m not sure what would happen (e.g., would I somehow trip the “lockdown in sector 4” alarm, which given my reliance on Gmail, would be pretty darned disruptive). Thoughts? Anyone else in a similar situation?

FOSDEM was great! And too short. (But this is maybe a feature.) And too crowded, which is also a feature. Too tired for more, I am only blogging anyway, cause I cannot sleep and because I realized I should probably comment on the videos here, instead of answering many times indiviudally.

The recording of the videos went fine. I have all 13 talks of the debian devroom on (unchecked) tapes. Thanks to Herman for the camera, I'll send your powersupply to you tomorrow.

A hour of DV needs about 13 GB. So I need to buy a new hard drive. Then I need to give it to a friend, who'll copy the tapes to disc. Then encoding and uploading. If all goes well, the videos should be online in a week or two. Definitly, when they're ready :-)

The debian-community talk went well, although I was too much in a hurry, because I had to start late due to the previous talk and having to end 5min early, so pixie could get her (then belated) plan back (with the camera and awesome tripod). I got quite some good feedback, which already resulted in a bit further developing of some ideas, which I "documented"on #debian-community before writing this. More to come.

I recently came across two old and unrelated writings about law, both of which are worth reading, especially for people with strong opinions but no formal training. The first is this piece, entitled Seven Ways in Which Code Equals Law (And One in Which It Does Not), by recently-appointed New York Law School professor James Grimmelmann and EFF Legal Director Cindy Cohn. Several observations are particularly appropriate for the slashdot crowd (and, to a lesser extent, certain members of the Debian community and others who grew up on a diet of BASIC, Pascal, and then C and later perl). I especially like this bit about “hacking the law”:

Some people, seeing this connection, and remembering the values of good code, try to improve the legal system by treating it as a computer. People come to me with ideas for hacking the law. The government says that cryptography is a weapon, they say, but the Bill of Rights says we have the right to bear arms. So that means we have a Constitutional right to use cryptography. But the legal system isn t a computer. If you can t convince a judge that what you re proposing is consistent with the values underlying a law, your argument will go nowhere. People go to jail every year because they think they ve found a way to hack the Sixteenth Amendment. The income tax is illegal, they say, or, The income tax is voluntary, see, it says so right here, and then they get convicted of tax evasion and sent to jail. We did convince several judges about the Constitutional dimension of cryptography, but the claim started from the values of the First Amendment, not a mechanical reading of its words. It s a category mistake to treat the legal system as just another architecture with its own specialized language. Code and law are different ways of regulating; they have different textures. All of those people who are required to make the legal system work leave their mark on its outcomes: they make a certain amount of drift and discretion almost inevitable. Code doesn t have such a limit: it can make perfectly hard-nosed bright-line rules and hold everyone in the world to them. Code is capable of a kind of regulatory clarity and intensity that law can only state, never really achieve.

I don’t entirely agree with the other article, entitled What I Ate For Breakfast and Other Mysteries of Judicial Decision Making by outspoken Ninth Circuit Judge Alex Kozinski (unofficial site maintained by Aaron Swartz, wikipedia entry). For example, I think critical legal studies has resulted in some interesting insights, some of which actually have practical applciation. Still, Judge Kozinski makes an important point about the numerous factors that act as a check on discretion in judicial decisionmaking:

It is popular in some circles to suppose that judicial decision making can be explained largely by frivolous factors, perhaps for example the relationship between what judges eat and what they decide. Answering questions about such relationships is quite simple - it is like being asked to write a scholarly essay on the snakes of Ireland: There are none. But as far back as I can remember in law school, the notion was advanced with some vigor that judicial decision making is a farce. Under this theory, what judges do is glance at a case and decide who should win - and they do this on the basis of their digestion (or how they slept the night before or some other variety of personal factors). If the judge has a good breakfast and a good night’s sleep, he might feel lenient and jolly, and sympathize with the downtrodden. If he had indigestion or a bad night’s sleep, he might be a grouch and take it out on the litigants. Of course, even judges can’t make both sides lose; I know, I’ve tried. So a grouchy mood, the theory went, is likely to cause the judge to take it out on the litigant he least identifies with, usually the guy who got run over by the railroad or is being foreclosed on by the bank. This theory immodestly called itself Legal Realism. Just to prove that even the silliest idea can be pursued to its illogical conclusion, Legal Realism spawned Critical Legal Studies. As I understand this so-called theory, the notion is that because legal rules don’t mean much anyway, and judges can reach any result they wish by invoking the right incantation, they should engraft their own political philosophy onto the decision-making process and use their power to change the way our society works. So, if you accept that what a judge has for breakfast affects his decisions that day, judges should be encouraged to have a consistent diet so their decisions will consistently favor one set of litigants over the other. I am here to tell you that this is all horse manure. And, like all horse manure, it contains little seeds of truth from which tiny birds can take intellectual nourishment. The little truths are these: Under our law judges do in fact have considerable discretion in certain of their decisions: making findings of fact, interpreting language in the Constitution, statutes and regulations; determining whether officials of the executive branch have abused their discretion; and, fashioning remedies for violations of the law, including fairly sweeping powers to grant injunctive relief. The larger reality, however, is that judges exercise their powers subject to very significant constraints. They simply can’t do anything they well please.

Finally, I will link, but not embed, this video of the Anna Nicole Smith court order, for an entirely different perspective on the legal process. You almost don’t really want to have to see this stuff.

ImageJ is probably the coolest piece of Free Software that the Free Software community isn't broadly aware of yet. It's a stable, mature piece of cross-platform code that supports both plugins and macros, and a large number of these have already been written by the scientific community. When contrasted to the photoshop/gimp debates, there simply is no competitor to ImageJ in the world of biological imaging: it's the standard for such work (except for specialized tasks like driving microscopes). If it wasn't in java (which I don't really know the tools for right now) I'd have uploaded it to Debian long ago.

A word of note though: if you want to use it seriously, I recommend building it yourself. I just spent two hours reading through the interpreter trying to speed up an extremely slow macro only to find that with a simple rebuild with the jdk in unstable's non-free I got an immediate and more than acceptable speedup, which should speed up my PhD work significantly. Still, the code is relatively nice and it was fun digging in to the interpreter, which was quite easy to understand. I may have to add a few more macro functions that I've been itching to have.

With the recent freeing of java, it'll be great to see software like imagej and jedit (which I'm also really enjoying) enter Debian finally.

Wow! Great and unexpected network at FOSDEM! Yay! At least in the Debian developer room. The camera is also set up and we recorded the first talk already :-)

FOSDEM is organized pretty well this year again and again it's great to meet so many different people here!

More "later", but rather after the weekend, I prefer to talk to people here instead of writing long blog entries... :-)