OpenSSH can be compiled against OpenSC. Since the latter has support for the Belgian electronic ID card, that means you can use your eID card to log on to a remote server using OpenSSH. To do this is fairly simple, once you know how it works. First, obviously, you need to have ssh compiled against opensc. Unfortunately, the Debian package comes with that option disabled, but it's easy to enable that:

sudo apt-get build-dep openssh
sudo apt-get source openssh
cd openssh-*
$EDITOR debian/rules

Find the "Common build options", and add another line:

confflags += --with-opensc=/usr

Now add another changelog entry, so that your next apt-get upgrade won't overwrite your locally-modified SSH package:

dch -i

Next, build and install the package:

dpkg-buildpackage -rfakeroot -b -uc -us
cd ..
sudo dpkg -i openssh-client*

You now have an OpenSSH that can access smartcards. So, how do you use it to log on to a remote system? Simple:

pkcs15-tool -c
ssh-keygen -D 0

The first command will tell you the order of the certificates on the card. In my case, the Authentication certificate is first, while the Signature certificate is second. You do not want the Signature certificate; you only want the Authentication certificate. The second command will output the RSA public keys that are on the smartcard in both SSH1 and SSH2 format, in the same order as in the pkcs15-tool output. You only want the SSH2 version, and you only want to get the Authentication key. That key needs to be added to your ~/.ssh/authorized_keys on the remote host. Note that the '0' assumes that your smartcard is in slot 0; if that doesn't work, 'pkcs11-tool -L' should tell you which slot you need. After we've done this, we're ready to start using the smartcard to log in. While ssh-add has an option to load keys from a smartcard, this only works with smartcards that allow one to download the private key from the smartcard into the computer's RAM. This is not possible with the eID (and for good reason), so you can't use ssh-agent with your eID card. However, you don't really need it.

beid-pkcs11-tool -l -t

This will log in to the Authentication key on the smartcard (note that while it is possible to log in to the Authentication key, it is not possible to do the same with the Signature key). You will get the familiar belpic login window now, and the smartcard will now allow use of the private key. In order to actually use this key, you need to specify one extra option to ssh:

ssh -I 0

The -I option instructs SSH to use a smartcard key as a private key. Since we're already logged in to the smartcard, we do not need to enter a PIN code (and regardless, SSH does not know how to do that). You will now be logged on to the server. Note that there is no way to 'log out' of a smartcard; the proper way to do that is to remove your card from the cardreader...

Emacs CVS has an interesting new feature: it now accepts a --daemon command line option which makes it start up as a Unix daemon; it detaches from the controlling terminal, starts up a new process session, goes to the background, starts an Emacs server and just waits for connections. The user can then use emacsclient to create new frames (console or graphical) for the background Emacs, using the new multi-tty abilities of Emacs 23. Since frame creation is virtually instantaneous, this makes the editor start up much faster than in the usual case (and a lot more so if you have an extensive configuration). Also, if your X session goes down, the editor is still running in the background with your buffers and applications, safe from harm. Very neat! (Get it from the usual place if you run Debian.)

(Note: this new --daemon mode is a cleaner replacement for the old screen-based preload-emacs script that was distributed with the multi-tty branch.)

I bought an EEE 901. More on that later.

For the past few weeks I've been trying to work out which "mobile broadband" provider to go with for my daily commute. It's a train journey from the north coast of Northern Ireland to Belfast and goes through some sparsely populated areas, so I wasn't expecting to get anything that would provide 3G all the way. However I do want a provider that can do their best to keep a session up for the journey, handing over between 2G + 3G as necessary. Coverage maps/checkers aren't too bad if you just want to check a static point, but really even then it's better to actually try the provider in the location yourself. So, armed with a bluetooth GPS (Bl eNEXT BN-909GR), an Option GT 3G Quad PCMCIA card and my laptop I set about measuring signal strength along my train journey for each of the 5 providers available. I also made sure to actually try a session with them for at least one journey, because signal strength is not everything.

I wrote some Perl using Net::GPSD and Device::Gsm to query my current location, signal strength, 2G/3G status and network every 10 seconds. I did this for 3 train journeys (except for O2) and then also produced an "optimistic" file of all the data points combined for that provider.

A second piece of Perl took this data and drew the maps you see below. The graph on the right for each provider is all data points. Red means 2G, blue means 3G, green means "Limited Service" (ie it could see a signal, but not one it was allowed to connect to). White means that we had a GPS location and no signal at all. Click on the maps for bigger versions. You can see the route on OpenStreetMap - my graphs are a little squished horizontally, but the journey is from Castlerock (top left on the coast near Coleraine) to Belfast (bottom right).







At first glance 3 look to be the best bet. Lots of blue, a reasonably priced data plan. Except they can't hold up a session to save themselves. Not only does a 2G/3G handover almost always seem to result in a drop, but I had periods of failing to get a 2G session up at all and had some random drops while in 3G coverage as well. So strike them off.

O2 and T-Mobile don't manage any 3G outside Belfast (that's the bottom right corner btw). I found that a few periods of 3G along the journey helped a lot; it meant I could do a quick mail sync rather than the long drawn out affair it was on a 2G connection. They can both handle handover between 2G/3G and keep a session up for most of the journey, but the lack of speed counts them out.

Vodafone managed the worst reception, which is disappointing. I found them quite good when I lived in England (my datacard is from a Vodafone Pay as You Use data contract). I did find sessions being dropped during the no signal regions, so they just don't seem to be a good bet.

Which leaves Orange. I've had issues with Orange and data in the past (pre 2004 IIRC) but in testing they were able to keep a session up between Belfast and Castlerock, handling 2G/3G handover fine. Coverage was reasonably good and they manage 3G at several points along the journey (the blue points roughly correspond to Coleraine, Ballymena, Antrim and Belfast). I understand Orange have some EDGE capability, but my card doesn't do EDGE so I've no idea if that'll be an extra gain or not. I had a few issues with getting dud DNS servers but this happened with the other providers too so I was beginning to suspect the datacard of playing up. Manually setting known good servers in resolv.conf worked fine.

So, before I go and sign up to an 18 month Orange contract, what have I forgotten?

I recently bought a 4GB Sansa Clip to solve the problem where once-a-week or so I want portable music or podcasts and don’t have any: namely, at the gym, occasionally when walking somewhere, and on trains and buses. I’ve been looking for something exactly like this for ages—small, attachable for use during exercise, enough space for a few hours of music/audio, OGG support, and not necessarily much more than that. Basically, an iPod Shuffle that plays OGG and doesn’t involve dealing with Apple. For the longest of time, this was pie-in-the-sky nonexistant. After a few weeks of using the Clip, I’m extremely pleased so far. The battery life is much longer than I’d ever want to listen to music for continuously (they claim 15 hours, and I haven’t gotten it down to less than half charge yet). It’s light in the hand but not too flimsy in feel, the clip makes it easy to attach to e.g. shorts, the interface is easy to use, and the sound quality is good. After upgrading to the latest firmware, it plays OGG as well as MP3. Both Rhymthbox and Banshee work for transferring files to it. I think my biggest complaint so far would be that the audio jack doesn’t fit in as securely as it could, which sometimes manifests as sound skipping and can be fixed by making sure the headphones are completely plugged in. Seriously, it was funny when my Walkman skipped during runs in 2003, but I hope I’m past that phase of life at this point. At any rate, it doesn’t happen all that often, so it’s more of a minor annoyance than anything. And well, the firmware isn’t free—but hey, can’t have everything.

I am a big fan of zotero as it has helped me manage my research, especially collect, tag, time stamp, and keep web pages that are likely to vanish. I can’t recommend it enough. I have yet to use its bibliographic functionality and apparently it is this functionality which has made it the subject of what what looks like a pretty questionable law suit. It has been a while since a IP lawsuit has really caught my attention (only in so far as it was the same old thing, not because it was not important) but this one definitely has caught my attention (and caught me off guard as well as I never really associated End Notes with Zotero, in so far as they seem to work pretty distinctly). I am eager to see how an academic institution, George Mason in this case, will react. I just hope they stand firm and also get some great legal team to help out.

Importing bugs from the Debian Bug Tracking System into UDD (the Ultimate Debian Database) in a reasonable time is challenging. The BTS uses flat files to store bug information, and importing a bug typically requires reading a ’summary’ file, and a file containing the verisoning information, both of a few hundred bytes. That looks easy, but when you multiply it by ~70000 unarchived bugs, it takes a lot of time (about 40 minutes) to read those ~100k files, because the import process will block on every I/O. The problem is not the amount of data to read (19.8 MB for summary files, 7.4 MB for versioning files), but the number of files (69612 summary files, 17507 versioning files). The obvious solution is to preload all the files into the page cache, so they are there when you need them. But you can’t simply do that with find /org/bugs.debian.org/versions/pkg -type f -exec cat \+ &>/dev/null, because that wouldn’t fix anything: you would still block on each file, and prevent the I/O scheduler to reorder the reads and optimize them (it’s called elevator for a reason). So, how do I tell the kernel “I’m going to read that in the future, please preload it?” readahead(2) is blocking, so it’s not helpful. The right solution is to use posix_fadvise(2), that allows to declare an access pattern. Using fadvise to preload all the files takes less than 5 minutes, and importing the bugs after that takes less than 8 minutes, so it’s really a big win. Does someone know if there’s already an fadvise-based tool that allows to preload a list of files? That’s something that I could need in other contexts as well.

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

Some people troll free software lists with remarks like:

Linux will never be able to displace MacOS/Windows since the latter are much more pretty/user-friendly. You will lose.

Such people assume that hackers write free software because they "hate Microsoft" or "hate capitalism" or have some other pet hates. However, it should be obvious that such a large creative effort cannot be sustained if it is based on such negative emotions.¹ There are a number of positive reasons why one works on free software. The software that I like to work on is software² that I use or want to use. This has some consequences which are worth underlining:

• Contrary to the views expressed in some articles about free software, the theme of usability (by me!) is uppermost in my mind whenever I approach any task pertaining to software.
• Since the software I work on should be usable long after I have forgotten the ideas behind its implementation, the user interface should be one that confirms to "standard" expections. This means that it should be possible to use the software without reading the code.
• When I look at the code after a long time (for example to extend it in some way) I should be able to read and understand it, which requires clean code with adequate documentation.

Giving others the "four freedoms" results in wider critical examination of these aspects. Bugs must be acknowledged and fixed --- or elevated to features! Moreover, there are parts of the task that are "obvious" to me but I would have to ask others for advice on other parts. So I gain a lot by being part of a larger community. There are other reasons to write free software. For example, someone may pay you to do it. However, this is just deferring the same question to your employer. In most cases, your employer already has a use in mind for the software. The employer has the same concerns as I outlined above except that the job of writing the code is being out-sourced. The usability, portability and long-term maintainability are probably even bigger concerns for your employer. "Last but not the least" (as we always wrote in our school-day essays) free software is fun! You share ideas with people from across the globe and to show them your own clever little tricks. Good code and good themes resonate with people who may not even speak the same language as you do. What could be nicer than that!

Lennart Pottering’s post about the sound APIs available for Linux appears to have caused some consternation from people working with the modern out of tree OSS drivers who feel that the current, out of tree, OSS drivers are being unfairly maligned. This rather misses the point of his post. The fact that there are improved versions of the OSS code doesn’t really help developers who are trying to target current Linux distributions which only ship the old OSS drivers. From this point of view the new OSS drivers are probably best looked at as a completely different product. Joss is right, though - most applications should be working with a higher level user space API than either ALSA or OSS. One of the most obvious examples of this is in the embedded space where there are often vast numbers of controls that need to be exported in order to support the complex audio routing that devices like phones can have. Most of these should only be touched very occasionally when changing use case and should therefore be hidden from normal applications where they’re at best irrelevant and at worst confuse end users. They do, however, need to be exposed by the kernel in order to allow user space the flexibility to manage the audio configuration of the system at run time.

Dear Adrian, I can only but complain about the "Guide Through The Linux Sound API Jungle" that you mention in your last post. All that is said there about OSS is pure FUD and only reflects a deep ignorance of the current project. It is a pitty to spread misinformations that deprecate the work of others without even trying to understand it. Here is what is said about OSS in this document:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

And here is what one of the devs from OSS answered to this [1]:

It's pretty inaccurate FUD (From the URL address - it's Pulseaudio's author, right? I'd have expected him to know better). He's basically judging OSS per the old OSS/Free drivers, which is like 5 years ago, and even that he does wrong. First, *all* current implementations/emulations of OSSv3 do sample conversion. It's not even a property defined by the API but by the underlying drivers. Second, even OSSv3 supported surround, USB cards, etc. Third, arguing that "it cannot be virtualized" is disproven by the amount of emulations and alternative implementations existing out there and working in practice. (The main difficulty is mmap() API, which is very rarely used anyway, and even that can be done with, say, oss2pulse). Fourth, complaining about OSS API being awkward, is... well, awkward when you compare it to ALSA API, if you could compare it, since most ALSA API isn't documented. It's kinda funny he advocates using ALSA API (not in the quoted part above, but last time I read his blog he suggested it). Actual ALSA devs advocate against it, but using a sound library with multiple backends [2].

If you read some documentation, you can understand that OSS has been the target of some kernel developpers that didn't like it to be reused in a commercial product, back in the 90s. Hence, ALSA was launched, and OSS was progressively discarded, while constantly being the target of FUD like this. OSS has then lived for almost 10 years in the dark side of the force, but eventually did the way back in July 2007. Ironically, now most of the developpement in the linux kernel is driven by commercial interests. Most of the original complains about OSS are now fixed, including all the FUD written in this guide. In particular, software mixing is now supported. Being also part of a project that writes code to handle sound input and output, I can only but complain about the mess in the area of sound APIs in linux. However, OSS should really be reconsidered. In particular, its API is designed in order to abstract as much as possible access to the sound card, so that application writers have as less as possible to do with sound conversion and the like Those who have tried to use ALSA may for instance compare that to the "set rate near" call in its API: this call will set the rate to what the hardware support and let you handle the conversion... For each application... Also, OSS API is available across all unices, except OSX, and there is even a BeOS port going on. Finally, OSS API is POSIX oriented, reading and writing on the sound card, being a matter of calling few ioctls and then reading from the device file. In the future, OSS developpement will most probably be done as a community project, and I believe it is now time to stop spreading false ideas about the project, and give it as much attention as the other projects. For the debian users who want to try OSS4, a package is available in the packaging team's svn repository. It has been sitting in NEW for some time, I hope it gets accepted at some point.

For those who use emacs with Ruby on Rails, and perhaps even use rhtml-minor-mode, I have published an update: http://www.welton.it/freesoftware/files/rhtml-minor-mode.el It now handles .html.erb extensions for layouts/ files and layouts/application.html.erb files (or .rhtml). Something that would still be nice to see is some hacking to better integrate partials, which currently don't really know exactly where they fit in their parent document. That would take some work though, as you'd have to scan for use of the partial in question and perhaps do some other parsing of ruby code. If you're clever though, you could probably get the most common cases by looking for something like :partial => ......

Russell writes about the iphone. I think he's missing a few things.

The open nature of the PC wasn't inherently what brought it greater success. The open nature of the PC meant that it could spawn an ecosystem of third party hardware vendors, sure. It also meant that it could be cheaply cloned by other manufacturers, ensuring competition that drove down the price of hardware. The net result? x86 is ubiquitous, sufficiently so that even Apple use a basically standard[1] x86 platform these days. Low prices and the wide availability of software that people wanted to run bought the PC the marketplace, with Microsoft being the real winners. Apple hardware remained more expensive for years, and the compelling MacOS software was mostly limited to areas like DTP. Nobody else had any incentive to buy a Mac.

Now, let's look at the phone market. Third party hardware vendors? No real distinction between the iphone and anything else. Sure, anything remotely clever has to plug into the dock port, but developing something to work with that also gets you into the ludicrously huge ipod market. Other phone accessories are either batteries, chargers or headphones. That's really not going to be what determines market success.

Competitive cheapness? When you have a multivendor OS like Android or Windows Mobile, you might expect there to be more opportunity to compete to undercut each other, offering equivalent platforms for less cost. But that's missing something. In the same way that the home computer market has basically consolidated towards PCs, the phone market has already consolidated. Your smartphone has an ARM in, probably along with an off the shelf GSM chip and some 3D core (generally something from Imagination, though in Android's case Qualcomm seem to have come up with their own core - I haven't been able to find out if it's derived from something else). There's no realistic way to make a phone with equivalent hardware functionality and quality to the iphone and sell it for significantly less money. And if you figure out how to, Apple get to take advantage of the same price reductions in their next generation hardware. And, being Apple, they'll probably find some compelling wonderful design feature that costs them nothing extra but makes you want it more anyway. So hardware competition probably isn't going to be what determines market success.

Which leaves two things - advertising and applications. Apple are good at marketing. This is unfortunate, because I'd really rather live in a world where everyone running MacOS was running Linux instead, but we seem to suck in comparison. The good news is that Microsoft also seem to, so maybe we'll have our act together some time between now and Apple crushing us to death. So, assuming current trends continue, Apple's marketing probably isn't going to kill the iphone. Which leaves one thing: applications.

The obvious argument against the iphone's success is that, as a closed software distribution platform, it's less attractive to developers. I don't think that's true. If we look at the console market, the gp2x was hardly a PSP killer. Or a DS killer. You could possibly argue it was a Gizmondo killer, but only if you ignore the Finnish mafia. Being an open platform doesn't immediately result in you killing closed platforms. You need developers, and you need applications. Otherwise nobody's going to buy your hardware, even if it costs $10 less than an iphone and has a few extra bits of plastic. What attracts developers? An attractive development environment and a revenue stream. Android has one real thing going for it here - it's not tied to Objective C, and so there's probably a larger number of potential developers. But let's be realistic. If you're a competent developer, you can move from C++ or Java to Objective C without too much effort. And if you're an incompetent developer, you're not going to be deciding the future of a platform.

Apple have made it easy for people to write applications that share the iphone's delightful[2] UI. There's almost active encouragement to write beautiful programs that integrate well. Sure, the platform limitations bite you in weird ways (like the no background running thing), but Apple have come up with hacks to smooth most of those over. The iphone is a wonderful device to develop for. Sufficiently delightful that there was a huge developer base even before Apple had released the SDK. What does that tell you? Developers actively want to write for the iphone. In fact, they wanted to even before there was a real revenue model. Mindshare means a lot.

What are we going to see in response from Android? To begin with, uglier applications. I'm sure that'll get better over time, but right now the Android UI just isn't as well put together[3]. It's functional, even attractive. But it's not beautiful. And lowering the bar to developer involvement means the potential for more My First Phone Application. Windows Mobile and Symbian have huge numbers of applications. They're mostly dreadful lashups of functionality you'd never want and a UI that's ugly enough to make you want to stab out your eyes, coupled with a nag screen asking for a $10 donation to carry on using it assuming it hasn't crashed before it got that far. To be fair, a lot of iphone stuff isn't much better. But proportionately? Right now the Apple stuff has it. I never want to see another listing of Symbian freeware.

At the moment, Apple wins at providing compelling applications. They may be a gatekeeper between the developer and the user, but right now that's not causing too many problems. Well. It wasn't. The recent fuss about Apple dropping applications because of perceived competition with their own software is an issue. If a developer is going to spend a significant amount of time and money on an application, they want a reasonable reassurance that they're going to be able to ship it. And, right now, Apple's not giving that. It remains to be seen whether this has long term consequences, but there's some danger of Apple alienating their developer base. If those developers move to another platform, and if they create compelling software, Apple might stand some real competition. At the moment? Apple has the hardware, the OS and the applications. They have the potential to take over broad swathes of the market. But they also have the opportunity to throw it away. And that's what's going to decide the success of the iphone - a closed platform is not inherently a problem, but it gives the vendor the option of removing one of their key advantages. If Apple get through this with their developer popularity intact, I don't see the open/closed distinction as having any real-world importance at all.

The relevance to Linux? We're not going to succeed by being philosophically better. We have to be better in the real world as well. Ignoring that in favour of our social benefits doesn't result in us winning.

[1] It's slightly more legacy free than a "genuine" PC - there's no i8042, and things like the gate A20 hack aren't implemented. But it'll boot DOS (given enough effort), so hell, it's a PC

[2] And yes, I genuinely do think that the iphone's UI is better than anything else on the market. There's no reason someone else, including us, couldn't have got there first. But we didn't, and now everyone gets to play catch up. Shit happens

[3] I have no idea where Apple gets its UI engineers from, but someone needs to find the source and start waving huge piles of money to pick them up first.

Now that bug #500000 has been reported, let’s have a look at all our other bugs, using UDD. Number of archived bugs:

select count(*) from archived_bugs;
 count
--------
 402826

Number of unarchived bugs marked done:

select count(*) from bugs where status = 'done';
 count
-------
  8267

Status of unarchived bugs (”pending” doesn’t mean “tagged pending” here):

select status, count(*) from bugs group by status;
    status       count
---------------+-------
 pending         53587
 pending-fixed    1195
 forwarded        6778
 done             8267
 fixed             167

The sum isn’t even close to 500000. That’s because quite a lot of bugs disappeared:

select id from bugs union select id from archived_bugs order by id limit 10;
 id
-----
 563
 660
 710
 725
 740
 773
 775
 783
 817
 819

Now, let’s look at our open bugs.
Oldest open bugs:

select id, package, title, arrival from bugs where status != 'done' order by id limit 10;
  id       package                                         title                                            arrival
------+----------------+----------------------------------------------------------------------------+---------------------
  825   trn              trn warning messages corrupt thread selector display                         1995-04-22 18:33:01
 1555   dselect          dselect per-screen-half focus request                                        1995-10-06 15:48:04
 2297   xterm            xterm: xterm sometimes gets mouse-paste and RETURN keypress in wrong order   1996-02-07 21:33:01
 2298   trn              trn bug with shell escaping                                                  1996-02-07 21:48:01
 3175   xonix            xonix colors bad for colorblind                                              1996-05-31 23:18:04
 3180   linuxdoc-tools   linuxdoc-sgml semantics and formatting problems                              1996-06-02 05:18:03
 3251   acct             accounting file corruption                                                   1996-06-12 17:44:10
 3773   xless            xless default window too thin and won't go away when asked nicely            1996-07-14 00:03:09
 4073   make             make pattern rules delete intermediate files                                 1996-08-08 20:18:01
 4448   dselect          [PERF] dselect performance gripe (disk method doing dpkg -iGROEB)            1996-09-09 03:33:05

Breakdown by severity:

select severity, count(*) from bugs where status != 'done' group by severity;
 severity    count
-----------+-------
 normal      27680
 important    7606
 minor        6921
 wishlist    18898
 critical       29
 grave         209
 serious       384

Top 10 submitters for open bugs:

select submitter, count(*) from bugs where status != 'done' group by submitter order by count desc limit 10;
submitter                        count
----------------------------------------------------+-------
 Dan Jacobson                     1455
 martin f krafft                    667
 Raphael Geissert                    422
 Joey Hess                            392
 Marc Haber                368
 Julien Danjou                         342
 Josh Triplett                    331
 Vincent Lefevre                    296
 jidanni@jidanni.org                                    260
 Justin Pryzby      245

Top bugs reporters ever:

select submitter, count(*) from (select * from bugs union select * from archived_bugs) as all_bugs
group by submitter order by count desc limit 10;
                  submitter                     count
----------------------------------------------+-------
 Martin Michlmayr                4279
 Dan Jacobson               3652
 Daniel Schepler     3045
 Joey Hess                     2836
 Lucas Nussbaum        2701
 Andreas Jochens                   2605
 Matthias Klose            2442
 Christian Perrier           2302
 James Troup                   2198
 Matt Zimmerman                  2027

You want more data? Connect to UDD (from master.d.o or alioth.d.o, more info here), run your own queries, and post them with the results in the comments!

I don't really know why I found myself looking at the gitweb for automake just now, but I noticed that they've finally committed something I've wanted for a bit (but was, of course, too lazy to code myself)[0]

AM_MAINTAINER_MODE was the subject of huge debate when it first came out. It's the bit that can set itself so that the autotools scripts won't get regenerated even if the source files for those have been touched.

The problem is that by default, that's the wrong thing to do. A developer with the source (which I assume anyone with the source is. Otherwise their distro is probably handling all their compilation needs) *wants* those updates to happen automagically. In a distro, however, it's occasionally necessary to patch the autoconf bits, which means that you're trusting the installed autoconf on either the builder or your machine to consistently do the right thing in an automated fashion. And hopefully leave you with a readable debdiff in the end.

I'm hoping that AM_MAINTAINER_MODE([disabled]) becomes a standard thing to do with autoconf-based packages.

[0] http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=861c19856121d8e875e30268dee6033ded6fc7ae

(semi-joke only fully understandable by French folks. Julien Blache used the same joke in the past) My dear Genneff, "Valid-Until" is certainly a good idea and I have no doubt it's well implemented in our archive tools. I'm less sure about this being implemented in apt, because of the loose resources of the APT maintenance "team" as of now. And I'm damn sure that implementing that feature will add yet more work coordinating l10n. APT is currently fully translated to 18 languages and, of course, the warning message issued by APT when a user is directed to a faked security repository *has* to be translated for the user to really understand what's happening. It even has to be translated very carefully. Contrary to popular belief, not all systems admins understand English easily. And we really want the important message that will be issued by APT in such case, to be understood and understood well. So, good luck to /me dealing with a last minute l10n update that will quite certainly happen, now. I can't even use this in an attempt to get bug #500000, as #499897 is already reported against apt. Crap. I'm out of ideas for getting that bug report... As a revenge, I propose that next time we all see Ganneff in a group, we all hug him to death for implementing that very good feature in our archive tools.

As I wrote in blog item 29 there are many ways to break your debian/rules file. As I grew of seeing those and many more, I decided to write a lintian test for this. Getting that finished will still need several days, as the general Makefile syntax is quite intresting in detail, and lintian is written in perl thus so have to be tests. It's quite intresting that the different cases when variables are resolved and when not seem to quite firmly force an specific way to parse it. (And relearning perl when I so successfully unlearned all parts of that language in the past make it not much faster). Anyway, the reason I'm blogging is to give you already the results of one particular test a preliminary version gave when running over the lintian lab: It's checking for targets with -stamp in them that are phony, as that makes no sense. It will either cause configure or make run multiple times via build, wasting buildd cycles or even make the build more unstable, or just indicates needlessly complex Makefiles (having an install target that invokes an install-stamp target that does not actually produce a stamp file just makes the Makefile longer without doing anything at all but confusing readers). You can find the preliminary results for that test at http://people.debian.org/~brlink/debian-rules-phony-stamp-file.log. I looked at some randomly choosen results and did not find a false positive. As that list was produced by the last runable version which did not yet look at variables, I guess the list will only increase.

I don’t have the expertise to intelligently explain the entire global financial meltdown myself, but here are a few resources that merit wide dissemination, especially if you are a podcast-listener:

• The Planet Money Podcast. NPR’s Adam Davidson hosted one of the most memorable episodes of This American Life on the Giant Pool of Money (complete PDF transcript). He has springboarded that show into a frequent short podcast in these times of peril. He finds a near-perfect balance between accessibility and complexity for a non-specialist but educated audience. It’s also entertaining. Of all major media outfits, NPR is miles ahead on the podcast front.
• Paul Krugman’s blog. Admittedly on the partisan side (”Conscience of a Liberal”), Krugman’s analysis is deep both on politics and economics. Steve drew my attention to this excellent illustration of the flaws with the current approach to bailout:

Just stumbled over this meme at Adrian (the meme seems to be started by madduck involuntarily), and since I’m fascinated by how people choose hostnames since my early years at university, I can’t resist to add my two cents to this meme. To be exact, I have two schemes, one for servers out there somewhere (Hetzner, xencon, etc.) and they’re all wordplays on their domain name noone.org, e.g. symlink.to.noone.org (short name “sym” :-), gateway.to.noone.org (usually an alias for one of the machines below), virtually.noone.org (always a virtual machine, initially UML, soon a Xen DomU), etc. So nothing for a quiz here. My other scheme is for all my machines at home and my mobile machines. I’ll start this list with the not so obvious hostnames, so the earlier you guess the scheme, the better you are (or the better you know me ;-). One more hint in advance: “(*)” means this attribute or fact made me choose the name for the machine and therefore can be used as hint for the scheme. :-)

azam

My first PC at all, a 386 with 25 MHz and MS-DOS. (Got named retroactively(*). Hadn’t hostnames at that time.)

ak (pronounced as letters)

Got it from my brother after he didn’t need it anymore. It initially was identical to azam, but once was upgraded to a 486. Still have the 386 board, though.

azka

My first self-bought computer, a pure SCSI system with a AMD K5-PR133 and 32 MB RAM. Initially had SuSE 4.4 and Windows 95 on. Still my last machine which had a Windows installed! :-)

m35

Same case and same speed as azka. Used it for experimenting(*) with Sid years ago.

azu

Initially also an AMD K5-PR133, later replaced by a Pentium 90 and used as DSL router.

azl

An HP Vectra 386/25N book size mini desktop I saved from the scrapyard at Y_Plentyn before his (first) move to Munich. The cutest(*) 386 I ever saw.

ayce

A 386 with 387 co-processor(*) and solded 8 MB of RAM.

ayca

A 1992 Toshiba T6400C 486 laptop bought at VCFe 5.0.

bijou

My 1996 ThinkPad 760ED, which is still working and running Debian GNU/Linux 5.0 Lenny (I started with Debian 3.0 Woody on it and always dist-upgraded it! :-)

gsa (pronounced as letters)

My long-time desktop after azka. A Pentium II with 400 MHz and 578 MB of RAM at the end. Bought used at LinuxTag 2003, it worked until end of last year when it started to suddenly switch off more and more often and now refuses to boot at all. Hasn’t been replaced yet though. I mostly use my laptops at home since then.

gsx (pronounced as letters)

An AMD K6 with 500 MHz I got from maol and which was used as Symlink test server more than once. (It was the machine initially named symlink.to.noone.org because of that.)

hy

My 32 bit Sparc, a Hamilton Hamstation.

hz (pronounced as letters)

My 64 bit Sparc, an UltraSparc 5.

tub

An HP Apollo 9000 Series 400, model 400t from 1990.

tpv (pronounced as letters, too ;-)

My Zaurus SL-5500G.

tryane

A Unisys Acquanta CP mini desktop with a passively cooled(*) 200 MHz Pemtium MMX. Used as DSL router for while, but the power supply fan was too noisy.

lna (pronounced as letters)

A 233 MHz Alpha

loadrunner

An IBM ThinkPad A31 running Sid. I use it as beside terminal.

pony

A Compaq LTE5100 laptop with a Pentium 90 running Sid.

dagonet

A Sony Vaio laptop which ran Debian GNU/kFreeBSD until it broke.

Those who know me quite good should already have guessed the scheme, even if they can’t assign all the names. For all others, here’s one name which doesn’t exactly fit into the scheme, but still is related in someway, but you need to knowledge of the theme’s subject to know the relation:

colani

A big tower from the early 90s designed by Colani.

Ok, and now the more obvious hostnames:

rosalie

A very compact Toshiba T1000LE 8086 laptop running ELKS and FreeDOS.

amisuper

Also an old Symlink test server from maol. He named it “dual”. 2x(*) Pentium I with 166 MHz. Unfortunately doesn’t boot anymore.

visa

An IBM NetVista workstation running Debian GNU/kFreeBSD. My current IRC host.

nemo

My ASUS EeePC running Debian 5.0 Lenny.

pluriel

My current WLAN router running FreeWRT.

c1

My MicroClient JrSX, an embedded 486SX compatible machine with 300 Mhz for VESA mountings.

c2

My MicroClient Jr, an embedded Pentium MMX compatible machine with 200 Mhz for VESA mountings.

c-crosser

My Lenovo ThinkPad T61 running Debian 5.0 Lenny.

c-cactus and c-metisse

The KVM based virtual(*) machines on c-crosser running Sid and Debian GNU/kFreeBSD.

jumper

My NAS(*) at home, currently a TheCus N4100. Soon to be replaced by some Mini-ITX box.

Any one who hasn’t guessed the scheme yet? For those understanding German it’s explained at the end of my old hardware page. For all others I suggest either to look at the domain name in my e-mail address (no, it’s usually not noone.org). Still not clear? Well, feel free to ask me for all the gory details or mark the following white box to see the scheme as well as the explanations for nearly all hostnames hidden in there:

All the machines are named after Citroëns. Old machines after old Citroëns, current hardware after current Citroën models or prototypes. Those names starting with “A” are 2CV derivatives since the 2CV was Citroëns “A” model. “AZ” was the 2CV, AZU and AK were 2CV vans and everything starting with AY (e.g. AYA, AYA2, AYB – but those don’t sound that nice ;-) is Dyane based, but I currently only use Méhara names (AYCA is the normal Méhari, AYCE the 4x4 version). Interestingly not everything starting with AYC is a Méhari: AYCD was the Acadiane, the Dyane van. HY and HZ are variants of Citroëns “H van” (HX, HW and H1600 as well, but they don’t sound that nice), TUB was the pre-WWII “H van” prototype and later the nickname of the “H van” in France. TPV was the name of the pre-WWII 2CV prototype and an abbreviation for Toute Petite Voiture (French for “Very Small Car”), hence the Zaurus, my smallest Linux box, got that name. Rosalie was the nickname of a rear-wheel drive pre-WWII Citroën. M35 was a Wankel engine prototype of the Ami 8 and the Ami Super was the 4 cylinder version of the Ami 8. Bijou was a 2CV based coupé build by Citroën UK in the late 50s and early 60s. Visa and LNA were 2CV predecessors which were available with 2CV engines, but were stopped before the 2CV. GSA and GSX are GS late derivatives. C1, C2, (C3) Pluriel, C-Crosser, Jumper and Nemo are current Citroën models and C-Cactus and C-Métisse are recent Citroën prototypes and show cars. The 2CV Dagonet was an aerodynamically optimised 2CVs by Jean Dagonet in the 50s. The Tryane is an aerodynamic and fuel efficient, three wheeled car by Friend Wood based on the 2CV and with a body of wood. And Colani once dressed a 2CV so that it broke several efficiency world records. The Namco Pony was a 2CV based light utility truck (similar to the Méhari, but with steel body) built in Greece under license in many variants. And Loadrunner is the name of some CX six-wheeler conversions.

Some links about the naming items:

• Tryane II
• An original Loadrunner and a just recently built Loadrunner. I even saw the base of exactly that one in RL shortly before it was converted into a Loadrunner.
• Luigi Colani
• Dagonet
• Namco Pony
• C1, C2, C-Crosser, C-Cactus, C-Métisse, Pluriel, Nemo, Visa, LNA, GSA, Ami Super, Rosalie
• AZAM, AZL, AZKA, AZU, AK, AYCD, Bijou, TPV
• HY, HZ, TUB.

Hope you had fun. I had. ;-)

Now playing: Willi Astor — Gwand Anham Ära