Looks like there is a PlanetPlanet fork on steroids, it's called Planet Plus and added saving the entries in an SQL database and a web frontend so you can search inside the entries. Looks great. p.s. sorry about the planet post with images and all, I'm still unable to find the readmore plugin to pyblosxom. If anyone has a copy of it or something similar I'd be happy if you dropped me a note.

I was at Berlinux 2005 this weekend and though the very chaotic — because understaffed — organisation it was interesting and also funny. Thursday I arrived around 20:15 in Berlin, met Klaus Knopper and others at the train station, headed to Sven Guckes’ appartment for dropping all my luggage, then going back to meet with Klaus and the others for a theremin concert with Dorit Chrysler. No wonder that it sounded sometimes like one of my favourite musicians, Jean Michel Jarre, since — according to the Wikipedia theremin article — he also plays this instrument. On Friday I held my talk about WML in front of a — for that topic — surprisingly high number of auditors (around 30, maybe 35). In comparision to my WML talk at OscomTag 2005 all people who asked questions had understood about what the talk was, so the questions were most time interesting and justified. As usual I held the talk using Lynx with LSS support (picture by Sven Guckes) on my nine year old Pentium 1 ThinkPad bijou running Debian GNU/Linux 3.0 aka Woody. Before and after the talk I helped out at Werner Heuser’s xtops booth (another picture by Sven) and the booth of the Debian Project (yet another picture by Sven :-) directly beside Frank Ronneburg’s Debian powered model railway. (picture by you-know-who ;-) In the evening I was at the social event, hanging around with alphascorpii, Tolimar and Joey and being surprised that Joey studies biology — as I did as minor to computer science. On Saturday I was on alphascorpii’s talk about why being a BOFH is not funny, hung around at the same booths as the day before, fixed the X configuration on my laptop after hints on a unknown Debian booth visitor. Before the exhibition closed I heard a very interesting talk about web accessibility held by Sebastian who is blind himself. Although or maybe because I’m interested in that subject, the talk opened my eyes regarding two things: First Captchas are evil and Blind HTML tables aren’t as evil as all the priests of web accessibility are always preaching . They are easier than frames for blinds and seem to have only little disadvantages against a CSS based layout for blinds nowadays if used the right way. Oh, and btw. — nested tables are still evil. :-) Saturday evening I had dinner together with Stefan Gerdelbracht, Frank Hofmann, Klaus Knopper and Manfred Krejcik. Later Thomas Winde joined us. It was very interesting evening, especially talking with Klaus and Manfred. On Sunday, after having brunch with Stefan and Manfred, we met with Sven (who was our host at Berlin, thanks again!) and shortly after that, Stefan left for visiting some other friends in Berlin. Sven, Manfred and I visited C-Base where Sven stumbled over a sound editing seminar while Manfred was preparing his zipFM show for Monday which mainly consisted of an interview with Klaus. After that we headed to a small but fine birthday party of a friend of Sven and were back home around 2:30. My train left Monday morning at 8:56 and I was at home around 14:30. And on Friday I’ll go to Dresden for the Linux-Info-Tag by train just to go back to Berlin afterwards, where I meet my parents for a two week baltic sea holiday in Mecklenburg-Western Pomerania near Rügen. But due to the Systems fair at Munich and autumn holidays I have to stay at work this week. And yes, I wrote this and the other postings posted today offline, so they’re dated quite close together. :-)

Rosa Parks died today at the age of 92. For those who were asleep in US History, she made waves by refusing to give up her bus seat to a white person on a segregated bus and being arrested for it.

Putting the impact of her actions into perspective, here's Wikipedia:

On August 30, 1994, aged 81, Rosa Parks was attacked and mugged in her Detroit home by Joseph Skipper. She had a total of $53 stolen from her. The incident created outrage throughout America. Parks said she had asked Skipper "Do you know who I am?" Skipper, an African American himself, was reported to have stated he did know who Rosa Parks was when he beat her, but didn't care. Skipper was arrested, and eventually pleaded guilty to charges of assault and robbery before being sentenced to prison.

Last week, I read that the bird flu drugs problem is partly caused by our governments (after pressure from big pharmaceutical developers), Xerox DocuColor printers put tracking codes on all printouts, an Australian farmer is being sued after GMOs infected his crop, there's an amazing claim that XML is patent infingement and ATM fraud nearly killed British banking. More amusingly, Granada's annoying copyright screens had the opposite effect on Rob Myers:

"I've never wanted to copy a DVD before. But if there was an easy way of copying this particular DVD to strip this amateurish mood-breaker off of the beginning I'd be sorely tempted."

On Friday and Saturday this year's Berlinux event took place in Berlin, Germany. It's a regional event with a small exhibition and a conference program. The Debian project took part with three talks and a booth, plus Skolelinux, and two companies that demonstrated their Debian-based distribution. On Friday a lot of students visited the exhibition area since it was built more or less in the middle of the usual university maze. The entire exhibition had to be dismantled during the night if the equipment shouldn't get lost in the morning. That way we had the fortune to see more of the building of the Technical University of Berlin that is quite impressive. The building was old, with huge walls and a very high ceiling, paired with wide and voluminous stairs and hallways. A very classical and very nice building. On Saturday there were more visitors and more parallel tracks. It was a bit unfortunate that the exhibition was split into two levels of the building and that the conference rooms were farer away from the exhibition. Getting there meant to walk through the usual University maze since Berlinux was embedded there and not separated from it.

SWMBO got a letter recently regarding her car insurance. It was, quite impressively, signed by the MD of the insurance company. His name? Terry Towell.

Planets are a fairly common method to aggregate blogs. They are especially pervasive in the FOSS world, with planets for Debian, Gnome, KDE, and many others. I find planets as a useful resource for a community to give a single place for the communication and to check for updates. The usual method of communication in blogs is a reply in a post, the planet makes the replies come in the same page for the reader with little context loss. For this reason I'm also fond of setting up planets myself for those communities that lack them, and so I setup planets for FOSS-IL for Israeli blogs about FOSS issues (mostly in Hebrew), Planet (former) Advogato for former Advogato bloggers and the latest one is Planet MicroISV for MicroISVs. I was asked to provide some (tutorial help something) on setting up a planet, and this post is the answer to that request.

---

The PlanetPlanet program is a very common RSS feed aggregator, it works with most feeds and is fairly tolerant to non-standard-conforming feeds. It is also relatively low maintenance, which is why I chose it for my aggregators. Prerequisites The first thing you'll need is to make sure you have Python 2.2 or better installed. If you're on a sane OS, you can just do apt-get install python2.3 otherwise you are left to fend for yourself. For the Windows folks there is ActivePython. Another would be prerequisite is GNU Arch or GNU Arch or Bazaar, two implementations for the Distributed Revision Control algorithm which was pioneered in GNU Arch. Bazaar would be more user friendly, but both IMNSHO are horrendous user-interface wise. Which is why I provide a snapshot of the latest revision for your benefit. Install Installation would be fairly simple, just unpack the tar.gz and it's installed, nothing else needs to be done, except configuring it. The snapshot I provided is just a raw dump of the arch repository, it is useful as is since you can update the installation as needed by just updating and merging with Arch/Bazaar. This will not be covered here. Too much of a trouble for now, and the PlanetPlanet development is at the pace of a snail carrying an elephant, don't expect updates in the near future. Configure I assume you have in mind the list of blogs you want to put on the planet. It need not be comprehensive, a few blogs to start would be good enough. It's trivial to add more as you go. In the planet directory you should copy the examples directory to a new one, say myplanet, copy the output directory to myplanet-output and edit the myplanet/config.ini file. At the minimum you should change the following variables:

• name – The name of your planet
• link – The URL where you planet will live, used inside the feeds the planet exports
• owner_name and owner_email – obvious isn't it?
• output_dir – that should be myplanet-output according to the instructions above
• template_files – change and replace examples with myplanet

The next stage would be to replace the existing blog listed in the config.ini file with your own list. The example is there and is trivial to follow, the entry for a blog looks like:

[http://baruch.ev-en.org/blog/index.rss2]
name = Baruch Even

Where the feed URL is in square brackets and the name of the blog is the name. There are various games that are possible with the templates but we'll ignore them for now and let you learn them from the examples provided by the authors. The next stage is just to run the planet on the new files, we will use the defaults for the rest.

python planet.py myplanet/config.ini

The planet will work for a while, churn out various uninteresting messages and generate the files we asked it for in the myplanet-output. You can now inspect the files in the output directory, load them in a browser and enjoy. Tweaks So you haven't left yet? Want some more info? One obvious question is now that we have the files, how do we serve them to the world so everyone can enjoy our creation? First, you should ask yourself if the world really cares... you do, ah?! OK. If the world cares enough it will find a way to show you how to do it. Since it depends on your OS, web server and various configurations, I can't help you on this. This is left as an exercise to the reader. The configuration in config.ini should be fairly obvious and is well commented. The look of the site depends on two factors, the HTML that is generated, which is a clean HTML version 4.01 and has all formatting controlled by the CSS file which was kindly provided in the outputs directory. The templating code is very simple, it has two operations, TMPL_LOOP and TMPL_VAR. TMPL_LOOP will loop over a variable, usually the Channels variable. And the TMPL_VAR operator will emit that variable, there are the global vars and the loop vars. The best way to figure it out is to use the existing templates as a building block, they are fairly easy to understand. Enjoy your new Planet!

Mike Sperber finally reviewed my patches; they unfortunatly were not deemed appropriate for the Scheme48 distribution, see this thread. Hopefully these issues can be sorted out in the not-to-far future. If you also need the one or other features from my hacks so far, and are adventurous, you can conact me on #scheme on freenode for help with getting and building my fork. Writing portable Scheme programs with scmxlate and spells For the conjure project, we are using scmxlate to make it portable across multiple Schemes. For that purpose, I slightly extended scmxlate and built a kind of meta-module system on top of it. Here is how that looks like: You write a description of the modules your application or library is made of; this is done in a sightly extended subset of the Scheme48 configuration language. For example (from this page, see there for more details):

 (define-structure conjure.foo.bar (export qux baz
					  ((froboz fribnitz)
					  :syntax))
  (open scheme srfi-1 srfi-13 conjure.util.files)
  (dialect (guile (open ice-9.syncase))
           (scheme48 (open extended-ports)))
  (files (foo basic-bar)
         (foo bar)))

This defines the module conjure.foo.bar, which exports the identifiers qux and baz, as well as the macros froboz and fribnitz. The open clause means: this module is written in R5RS Scheme (scheme), plus additionally using srfi-1, srfi-13 and the conjure.util.files module. The dialect clause can be used for specifiying additional modules needed for the dialect-specific code for the module. Finally, the files clause tells us that this module consists of the files foo/basic-bar.scm and foo/bar.scm. This file then gets processed by scmxlate, generating a file with the right module definitions for the selected target dialect, e.g.:

(define-module (conjure foo bar)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-13)
  #:use-module (conjure util files)
  #:use-module (ice-9 syncase)
	
   #:export (qux baz)
  #:export-syntax (froboz fribnitz))
	
 ;; code for foo/basic-bar.scm and foo/bar.scm follows

will be generated for Guile. We recently split scmxlate and the meta-module systeem out of conjure, see the scmxlate category in the conjure archive, so it is available for other projects. Now the split-out of the general purpose modules into a separate project — SPELLS, (S)pell’s a (P)ortability (E)nvironment (L)ibrary for (L)ots of (S)chemes — is in preparation. This library will further aid writing portable code, by providing a consistent interface to functionality that has different APIs in different Schemes. These modules are already there:

• spells.util.pregexp: Dorai Sitaram’s portable regular expressions
• spells.util.named-args: Conviniently create procedures with named arguments
• spells.util.table: Hash tables
• spells.util.condition: SRFI 34 and SRFI 35
• spells.system.file: Lots of file-related proedures, e.g. copy-file, directory?, …

All of those are implemented for all of mzscheme, Guile, Scheme48 and Gauche, using native functionality where available. Other modules will surely follow, a project has been requested at Gna! to facilitate contribution. The spells library will also be used by my upcoming port of G-Wrap to Scheme48.

This are some random thoughts I posted to the G-Wrap development mailing list regarding creating bindings for C libraries for Scheme. Although partly G-Wrap specific, it also might be of interest to other Scheme hackers. I’m not at all convinced my effort to make G-Wrap support Scheme 48
makes much sense at all, for these reasons:

• Most of G-Wraps complexity stems from C code generation, which is
  not necessary with a Scheme-level FFI, such as Scheme 48 and PLT
  Scheme provide. It seems a different, more simple tool, with the
  different features would be much more suitable: With a Scheme-level FFI, you can conviniently bind a given C API
  by writing Scheme code; it seems backwards to use a code
  generator, as you have one in Scheme itself in the form of
  macros. The problem is a different one: extracting certain
  information from the C API that is not (convieniently) available
  without invoking a compiler, such as the values of C macros and
  enumerations. With the code-generation approach, this knowledge is
  compiled into wrapper functions (and thus hidden away). With a
  tool I envision, that knowledge would be _extracted_ at the tools
  run time, by generating simple C programs that print those values
  in S-expression form, invoking the compiler on the C code, and
  running the resulting executable. This is quite different from
  what G-Wrap does, and retrofitting such functionality into G-Wrap
  would make it even more complex. I can really recommend reading the paper about the PLT FFI, linked
  from the CSW, to see how expressive a Scheme-Level FFI is; hiding it
  below a code generator only takes away from that.
• Now that my focus has shifted from Guile to Scheme 48, and
  portable Scheme in general, I view my rewrite using GOOPS
  ambivalently; the rewrite has certainly made G-Wrap more flexible
  and extensible, and probably given it a clearer structure,
  however, due to GOOPS’ use of keywords (while they are
  R5RS-compatible and supported by some other implementations),
  GOOPS is fundamentally non-standard, without touching the core of
  implementations that don’t provide #:foo-style keywords it isn’t
  possible to implement it on other Schemes. IMO, G-Wrap supporting
  multiple back-ends only makes sense when it also is able to run on
  these implementations, or else it probably won’t get much usage.

So in short: G-Wrap’s future looks brightest when staying a Guile
(-only) tool; a much more simple, portable C-binding tool can be
achieved by:

• Implementing a PLT-style FFI. This already goes a long way towards
  easing the work of creating bindings; I wrote a simple mysql
  binding for Scheme 48 in 135 lines of pure Scheme. Actually, the
  RTI (run time information) layer in G-Wrap can be seen as a
  half-implementation of that approach; implementing a subset of the
  PLT FFI for Guile based on that part of G-Wrap would be not very
  hard (speaking from my experience on doing the same thing for
  Scheme 48).
• Supplement that with tools that can extract the low-level C API
  information from headers, by parsing and compilation (as outlined
  above). Also G-Wrap could profit from a C header parser, as
  writing the declarations for the wrappers is quite tedious if more
  than a few functions are involved. I haven’t really looked at it,
  but scheffig is a tool that looks similiar to G-Wrap on a
  superficial level (generates C wrapper functions) and leverages
  the FCC C parser written by Mike Sperber, which probably is quite
  portable.
• The low-level API information, as extracted in the above step still
  doesn’t contain enough information for useful Scheme bindings, as
  part of the information needed for binding a C library are only
  available in its documentation, for example the semantics of memory
  allocation, for example whether a “double *” function argument in
  fact an array of a certain size, specified by another argument of
  that function, or a output argument. This information would be
  encapsulated in hand-written high-level bindings that make use of
  the automatically generated low-level bindings that result from
  header parsing.

I began to program in Scheme using the Guile interpreter. While I knew that its not blazingly fast, its the official GNU extension language, and as feeling quite close to the goals of the GNU project and the FSF, I felt confident it was the right choice, also considering the supreme quality of other GNU software, such as the GNU toolchain (GCC, binutils, gas) and the Gimp, to name just a few. So, feeling confident with my choice, I started to crank out code and eventually even took over maintainership over a Guile application, namely G-Wrap, after giving it a complete brush-up code-wise. When Tom Lord, of GNU Arch fame (and coincidently a former Guile maintainer), announced the Pika project (a from-scratch Scheme implementation, with ambitous goals), I decided to get on the mailing list and lurk, and later got opportunities to contribute a bit. Unfortunatly that project stalled due to time constraints on Tom’s side. Anyway it was a very valuable experience, as it opened my eyes to other Scheme implementations, foremost Scheme 48. Looking at its code base was a real eye-opener: as opposed to Guile, it was, except for a tiny amount of glue code, written in Scheme; its virtual machine is written in a subset of Scheme called Pre-Scheme that can be compiled to efficient C code, so you get most of the benefits of Scheme and the speed of C. Around the same time I discovered Scheme 48, I got involved in conjure, a make replacement being written in portable Scheme. I split off the library code from it to form a separate project, spells. As spells is basically a layer above the individual Scheme implementations which hides away their differences and presents their features (foremost the module system, but also hash tables, file system access, …) in a portable way, I gained some experience regarding the different module systems and how they compare, and I honstly must say that Guile’s is basically unusable with macros. Here’s why: A decent module system allows for macro code to refer to bindings in the module they are defined in, without requiring these bindings to be also exported; imagine a macro that expands to a call to some helper procedure that should itself should not be visible from outside the module. A real-life example are the reference implementations of SRFI-34 and SRFI-35, which define the helper procedures guard-aux and type-field-alist->condition, respectively. This deficiency (which is not present in Scheme 48, PLT Scheme, Gauche and probably most other Schemes) is really unfortunate, as it makes modules, when used with macros, a lot less usable. This, besides the total orientation toward interpretation and the codebase that is mostly in C are reasons why I’d recommend Scheme newbies also looking at other options before settling on Guile because it’s the “official GNU extension language”, as I did .

The DCC Alliance (not to be confused with the DCC Alliance, which is entirely unaffiliated with the former. But it's a recursive acronym, so there's NO TRADEMARK ISSUE) aim to produce a distribution which is entirely binary compatible with Sarge. A laudable aim. Sadly, there's a bit of a problem.

OpenOffice.org 2.0 was released this week. In common with previous versions, it's a horrid mixture of C++, Java and assembler. It's the Java that's the problem, of course. To compile it, you either need Sun's ridiculously non-free Java, or you can use gcj. That's gcj 4.0, of course. Which can be installed in parallel with gcc 3.3, so that's not a problem. Except. gcj 4.0 wants the libgcc from gcc 4.0 (unsurprisingly), which has the same SONAME as the libgcc from 3.3 (correct behaviour - code built against libgcc from 3.3 will run fine with libgcc from 4.0). However, libgcc from 4.0 adds some extra symbols - as a result, code built against libgcc from 4.0 will not necessarily run on systems with libgcc from 3.3.

Or, in other words, shipping libgcc from gcc 4.0 will result in a system that will build binaries that can't be installed on machines running plain Sarge.

So, there's a bit of a dilemma. Either

• Fail to support OpenOffice.org 2.0


• Only support OpenOffice.org 2.0 if non-free Java is used


• Break binary compatibility with Sarge


• Do something really quite nasty

The DCC Alliance want to build a distribution base that's binary compatible with Sarge. It's an entirely laudable aim, and (regardless of any impression I may have given in the past) I hope it's successful. But. That level of binary compatibility inherently compromises your ability to use new software. To begin with, you can work around that - backport code to older versions of libraries, include local copies, do static linking, that sort of thing. Over time, it gets harder.

Optimistically, Etch will be released in December 2006. If we assume that DCC releases occur at roughly the same rate as Debian ones, we're looking at 18 months until we get a DCC based on etch.

In 18 months time, is it really going to be possible to build a useful modern desktop system that's binary compatible with Sarge without it being an utterly unmaintainable pile of ugly hacks? Even after 5, we're seeing pain.

There's a reason that derivative distributions tend to diverge from the original project. It's because it's really quite remarkably difficult to maintain sanity, technical correctness and not change any of the underlying structure. I'd like to see DCCA succeed in doing so, and I do admire them for not just giving up in exasperation already.

This are some random thoughts I posted to the G-Wrap development mailing list regarding creating bindings for C libraries for Scheme. Although partly G-Wrap specific, it also might be of interest to other Scheme hackers. I’m not at all convinced my effort to make G-Wrap support Scheme 48
makes much sense at all, for these reasons:

• Most of G-Wraps complexity stems from C code generation, which is
  not necessary with a Scheme-level FFI, such as Scheme 48 and PLT
  Scheme provide. It seems a different, more simple tool, with the
  different features would be much more suitable: With a Scheme-level FFI, you can conviniently bind a given C API
  by writing Scheme code; it seems backwards to use a code
  generator, as you have one in Scheme itself in the form of
  macros. The problem is a different one: extracting certain
  information from the C API that is not (convieniently) available
  without invoking a compiler, such as the values of C macros and
  enumerations. With the code-generation approach, this knowledge is
  compiled into wrapper functions (and thus hidden away). With a
  tool I envision, that knowledge would be _extracted_ at the tools
  run time, by generating simple C programs that print those values
  in S-expression form, invoking the compiler on the C code, and
  running the resulting executable. This is quite different from
  what G-Wrap does, and retrofitting such functionality into G-Wrap
  would make it even more complex. I can really recommend reading the paper about the PLT FFI, linked
  from the CSW, to see how expressive a Scheme-Level FFI is; hiding it
  below a code generator only takes away from that.
• Now that my focus has shifted from Guile to Scheme 48, and
  portable Scheme in general, I view my rewrite using GOOPS
  ambivalently; the rewrite has certainly made G-Wrap more flexible
  and extensible, and probably given it a clearer structure,
  however, due to GOOPS’ use of keywords (while they are
  R5RS-compatible and supported by some other implementations),
  GOOPS is fundamentally non-standard, without touching the core of
  implementations that don’t provide #:foo-style keywords it isn’t
  possible to implement it on other Schemes. IMO, G-Wrap supporting
  multiple back-ends only makes sense when it also is able to run on
  these implementations, or else it probably won’t get much usage.

So in short: G-Wrap’s future looks brightest when staying a Guile
(-only) tool; a much more simple, portable C-binding tool can be
achieved by:

• Implementing a PLT-style FFI. This already goes a long way towards
  easing the work of creating bindings; I wrote a simple mysql
  binding for Scheme 48 in 135 lines of pure Scheme. Actually, the
  RTI (run time information) layer in G-Wrap can be seen as a
  half-implementation of that approach; implementing a subset of the
  PLT FFI for Guile based on that part of G-Wrap would be not very
  hard (speaking from my experience on doing the same thing for
  Scheme 48).
• Supplement that with tools that can extract the low-level C API
  information from headers, by parsing and compilation (as outlined
  above). Also G-Wrap could profit from a C header parser, as
  writing the declarations for the wrappers is quite tedious if more
  than a few functions are involved. I haven’t really looked at it,
  but scheffig is a tool that looks similiar to G-Wrap on a
  superficial level (generates C wrapper functions) and leverages
  the FCC C parser written by Mike Sperber, which probably is quite
  portable.
• The low-level API information, as extracted in the above step still
  doesn’t contain enough information for useful Scheme bindings, as
  part of the information needed for binding a C library are only
  available in its documentation, for example the semantics of memory
  allocation, for example whether a “double *” function argument in
  fact an array of a certain size, specified by another argument of
  that function, or a output argument. This information would be
  encapsulated in hand-written high-level bindings that make use of
  the automatically generated low-level bindings that result from
  header parsing.

There’s a subtle difference between a replacement and an upgrade, and in my mind it has something to do with the relative qualities of the old and the new. I like my current car and don’t expect that my next car will be particularly better, but different, and for a different purpose. My old and new RSS aggregators are both complete crap. Lisa and I have been living in our home for almost exactly one year now; the exact day that we moved was July 23. It’s been a good starter house, but there are a few factors lately that have convinced us that it’s getting time for an upgrade. Recently we discovered that the air conditioning didn’t work; it didn’t cool the air that came out, and it no longer blew into the downstairs area. It’s taken us two weeks to get it working, and it’s still not fixed; there’s a leak and it’s so slight that to find it will take a week, during which we won’t be able to use the system. Since it’s the middle of summer we opted to postpone fixing it and will just have it refilled periodically, until we’re willing to not have heating or cooling (like October). It’s under warranty so it’s not our expense. Also, being in a townhouse has made us keenly aware of our neighbors, and our desire to have a bit of distance from them. So last weekend we started getting an idea of places and types of homes that we’d be interested in looking at. We’ll probably end up moving in a year or so. As a housewarming gift, my dad bought us a rather nice television. We have DirecTV with TiVO, but it’s not the HD service, so recently I’ve been thinking about getting it. The satellite dish is actually currently owned by our homeowners’ association, and they’re absolutely miserable to try and get anything done through. So I think since I’m the only one in my building who has DirecTV, that I’ll just replace the dish myself, and put back the original one when I move out. Is there more than one HD DirecTiVo box? The one that Best Buy has on their website is $700 for 250GB.

Breaking radio silence to complain about something both trivial and technical, so it’s probably best if everyone skips this post. Unless you write a CD ripper or audio tagger. Then please read this post, because I’m going to explain why you’re wrong. (Someone emailed me about why Quod Libet acts this way, and I figured I’d make my answer public, with the hope it helps things.) History
Decades ago, before there was Ogg Vorbis, people used an obsolete standard called MP3, and tagged it with something called ID3 (in particular, ID3v2). One of the possible tags was TRCK, for the track number. It was stored as a string in “x/y” format, for track number x out of y total tracks. Perhaps this could be improved upon; maybe not (I’ll make a case for not later). Regardless, that’s how hundreds of thousands, if not millions, of files were tagged. Ogg Vorbis Comments
These days we have something better — Ogg Vorbis and its tagging format. Vorbis specified a tag called tracknumber, analogous to TRCK.

TRACKNUMBER: The track number of this piece if part of a specific larger collection or album

Now, this is a bit ambiguous. In particular, TRCK says how you should store the total number of tracks, and the Vorbis comment specification doesn’t. A strict reading indicates you can’t, but then the same standard is designed to be particularly loose about the data stored in the tags. So a lot of programs, including really popular ones, just kept their ID3 format and wrote tracknumber=x/y. Everyone was happy. Then someone — I wish I knew who, so I could write this to them personally — decided trying to parse the track number in this format was too hard, and so decided they would make a tracktotal tag that stored, as a single number, the number of tracks. Whoever Did This Is Wrong
Whoever decided to do this was pretty dumb. There’s a number of false assumptions here, roughly in decreasing order of annoyance:

• When you make a new standard, people won’t follow it (assuming otherwise is one of the stupidest design decisions possible). Lots of programs still wrote the x/y format. Quod Libet still does. I think it’s a better format. So now all that happens is everyone needs to implement both formats.
• When you make a new standard, people won’t follow it (as bad as it is, they made this mistake twice). Anything that does Vorbis tags probably does ID3 tags, and ID3 isn’t going away any time soon. So you still need the x/y parser no matter what.
• When you make a new standard, people get it wrong. So now we all need to support totaltracks, tracktotal, and x/y.
• Every other new tagging standard uses something much closer to x/y. Apple’s MP4 metadata, for example, uses two bytes in a single trck value. APEv2 uses Track=x/y. This is pointless differentiation.
• x/y is not hard to parse. There’s a horrible function called atoi that does it, and a lot of better ones.
• Using a simple numeric string still needs atoi and friends, because you don’t want “2″ to sort after “11″.
• You’re just trading parsing for reconstruction later. Quod Libet displays “Track [tracknumber]” which gets it right every time. Otherwise you have two strings “Track [tracknumber]” and “Track [tracknumber] of [tracktotal]” (no, you can’t just have “of [tracktotal]”, that ruins i18n).
• Users would rather enter a single “tracknumber=1/21″ than “tracknumber=1; tracktotal=21″.
• All else being equal, tracknumber=x/y is shorter. Maybe not a big deal, until we see a proliferation of discnumber (requiring disctotal, and totaldiscs), partnumber (requiring parttotal, and totalparts), and …

The result is that every program still needs to understand x/y — even if every Vorbis file used the new format — and the new format, and also needs to do the work to construct track numbers in the new format, assuming it wants to use them. That’s why Quod Libet converts everything to x/y format. I urge authors of tagging applications and CD rippers to abandon stupid standards. Instead, you should be spending time fixing your ID3v2 readers and writers, because they all suck too. P.S.
If anyone knows what program is putting ISO-8859-1 values into Vorbis tags, please let me know. I have spiked cluebat for you. A Summary of Other Things
I moved into a new apartment building next door to my old one, owned by the same student co-op, so it doesn’t actually seem like I moved at all. School started and is going well. I saw DOOM earlier this week for free, and enjoyed it. I’ve learned a lot about Python i18n over the past few months and am writing a brief howto explaining how to do it properly.

Frederico Oliveira talks about some interesting issues regarding the information overload most of us are experiencing. He unsubscribed from several RSS feeds in order to cut down the mass of information. I'm goint to do the same thing, too. My first step was to reduce the amount of daily email, though. I have just finished unsubscribing from 16 mailing lists which I don't really read very often (this automatically reduces the amount of spam I get, too). I'm left with ca. 80 mailing lists now. I'll probably remove some more and concentrate on those which I really need and/or read regularly. The next step is to unsubscribe from several RSS feeds, but that's not that much of an issue. I find tracking RSS feeds easier and more manageable than tracking mailinglists (not sure why). For the statistics freaks, I currently subscribe to ca. 320 feeds, but I read way more of them regularly than I do with mailing lists...

Just a quick post to reply to the comments I’ve had on some previous posts. On Missing entropy on my server box, I received lots of comments on how to feed random other stuff into the entropy pool or make it bigger or other hacks, but Alexander Reelsen pointed me to the real cause — a kernel bug in older 2.4 kernels which causes the entropy pool to deadlock on SMP systems, and never get refilled. There is a patch from RedHat which backports the fix from 2.6, and is included in recent 2.4 kernels. On the topic of kernels, now I’ve upgraded from 2.4.29-rc1 to 2.4.32-rc1 I get lots of errors like hw tcp v4 csum failed in my syslog. I’m using the e100 driver which as far as I can see hasn’t changed between versions, but there have been some changes to TCP checksumming code which I havn’t quite been able to grok. Google finds mailing list posts with other people asking what the cause is, but nobody answering. Anyone know what’s going on there? On Windows accessibility, many people seem to not listened to the first couple of minutes of the tasteless song I linked to, and hence taken my comment completely seriously. Thanks to everyone who told me about sticky keys etc in comments, but I did already know about the existence of Windows accessibility support (warning: mjg59 in furious anger mode). :D On the topic of blog comments, how do I cut down on the comment spam I have to moderate without requiring people to go through a completely unaccessible captcha image thing, or the annoyance of registering and acknowledging an e-mail? Would prohibiting comments and URIs containing words like ‘mortgage’, ‘casino’ and ‘ringtone’ ever cause false positives?

A small regional event covering Free Software and GNU/Linux took place here in Oldenburg on Saturday. It comprised a Debian installations party, two tracks of interesting talks and a small exhibition. There were about 500 visitors, I guess. Circa 40 people listened to the Debian talk in which I presented the goals of the Debian project, its internal structure, explained how the distribution is developed and by whom and demonstrated why well defined dependencies are so important. Several visitors came to our booth which was located in a classroom together with 9 other small booths. The exhibition room wasn't crowded ever, but it wasn't too boring either. Even during the talks there were always a couple of visitors lingering around in the exhibition.

Due to a combination of unlucky circumstances, my workstation decided to fry its own CPU the other day, so I'm without one for the time being. After trying to replace it and breaking the heatsink in the process (the screws were not very durable!), I've more or less given up the project, so I'll probably have to order something new. In any case, I might be a bit less responsive with regard to answering e-mail for a while (reading mail without your usual .procmailrc and .muttrc is... not very comfortable), but I should still be able to at least keep track of my RC bugs :-)