I'm happy to point to the announcement that Wikitravel Press now has a guide to Paris. Paris has long been a targeted city for Wikitravel Press, and I'm really happy we were able to get this book out. Bonus: the Wikitravel Guide to Paris includes maps from OpenStreetMap, the Open Content geo database and mapping system. We've got some new software to overlay Wikitravel listings onto the maps, and it's working really well. Thanks to OSM, editor Mark Jaroski, and managing editor Jani Patokallio for getting this great book out... just in time for Paris spring! tags: wikitravel wikitravelpress paris guidebook opencontent openstreetmap

Podcasts I asked a couple of days ago (Journal/30 Germinal CCXVI) about podcasts on the subject of Open Source and Open Content. I wanted to summarize a few that came in through comments on my blog:

• The iCommons Podcast, which (like many podcasts) seems to be running a little slow -- no updates in about a year. Still, an interesting project to be watching. (thanks Brianna)
• Wikipedia Weekly, the really great show by Andrew Lih and Liam Wyatt. I should have thought of WW before -- I was interviewed for the show last year! (thanks Padraic)
• Also worth noting is Not the Wikipedia Weekly, which is, uh, not the Wikipedia Weekly. I got this one from an episode of WW!
• LUG Radio, which I found from another podcast, LQ Radio.

This has turned into a pretty decent list, but I'd love to see some more diverse discussion of Open Content and Open Source in general. Please, feel free to send more tips. tags: podcast linux opensource opencontent

Vinismo For some reason Vinismo went over some tipping point with StumbleUpon this weekend, and we had a real flood of users from that bookmarking site. I can't say why that happens; I find SU to be a totally opaque Web site and service. In other news, Stevey likes our business cards. Me too! I think they look great. M-C Doyon, the Montreal graphic designer who laid out our Web site, also did our paper branding, and I think she did a great job. tags: vinismo stevey marieclaudedoyon cards

Yay Firefox 3.0 I don't know when it happened, but Firefox 3.0 beta does non-ASCII characters in the address bar correctly. So, if you're reading this entry on my site with FF3, you'll see the in "Flor al" rather than the URL-encoded "Flor%c3%a9al". I also like seeing Japanese Wikipedia pages in the address bar showing up correctly. Nice job, FF3 team. tags: firefox firefox3 utf8 url

Planet software should preserve categories So, apparently there's once again rising problems with content drift on Planet Debian. Personally, I think this is a problem with a technical solution. All three main flavours of RSS support post categorization. Many, many kinds of feed software provide categories (see, for example, this feed). If the Planet software would preserve these categories and pass them through to the output RSS feeds, then people who really only want to read about Debian could filter the output feeds for category "debian". People who wanted to know about other parts of their fellow Debianistas' lives would just leave the feeds unfiltered. I'm not sure if the Planet software doesn't support categories in output at all, or if it's just an option that's turned off on Planet Debian. If nobody else wants to take a look, I can look into making this work. It seems like a pretty simple fix. tags: planet planetdebian rss categories

The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:

• All Virtual All The Time (AVATT):

This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.

SCSI booting in coreboot:

Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.

This should make for an interesting summer with nice improvements for coreboot.

[Warning, long post ahead. If you aren’t interested in Debian or it’s internals or my work - skip it. :) ] So as you might have read here, I got the delegation of the debadmin AKA FTPMaster group lately. I’ve got some pressure to not accept this delegation, but the response to my blog post about it had been extremely positive, everyone said I should not deny it. Knowing to have such a support within Debian is something I really appreciate, making it worth to spent time on my various jobs. Now, lets take this and write a little about what happened since I gained that extra group:

• Aj resigned from anything that requires additional group privileges. (As a DD run id ajt on a debian.org machine if you want to verify this).

Work I did since then:

• One of my first action was to finally finish the release transitions support, something which was waiting for it’s final merge for a long time. The release team was waiting for this and did ping us (ftpteam) multiple times, but now it is there. You can read more about this feature in my list mail and my initial blog post. (Oh, and something I have missed about everywhere I wrote about this: This whole transitions thing is based on an idea from Marga!)
• Added a mapping in dak, requested by Luk
• Merged a patch from another ftpteam member, Thomas Viehmann, which fixes daks handling of Format 3.0 (something) uploads. Currently it rejects them, without the merged patch it just crashed.
• Changed our daily cronscript to no longer VACUUM/VACUUM analyze projectb in every run. Postgres >= 8.1 has autovacuum, and its turned on, so we should be fine without extra runs of it. (And while i write daily cronscript or cron.daily - I mean dinstall, right now run twice a day).
• Fixed a breakage in code introduced by Debian maintainers which led to process-accepted (one main part of the daily cronscript) breaking. It was triggered by some octave-$FOO package upload, where the ###censored### did add someone twice into the Uploaders: field. Not helpful, but now we ignore this case and just warn us.
• Added a script to expire old database dumps. We do dump our projectb (the main archive database) twice in every run (beginning/end), which made 4 dumps a day. While old dumps seemed to have been removed on an irregular schedule - the dumps took about 71Gb in total. Which pretty much filled up merkels /org, as they get synced there. Now, my script (reworked version of a script from Florian Reitmeir) works with an “incremental deletion” scheme:

  RULES = [ ‘days’:14, ‘interval’:0 , ‘days’:31, ‘interval’:1 , ‘days’:365, ‘interval’:31 , ‘days’:3650, ‘interval’:365 , ]

  That means we now keep all files from the last 14 days. Then keep one per week. Then one per month and finally one per year for up to ten years. All the rest gets deleted. Space usage of our dumps now: 4.8Gb. Thats 66Gb gained. Source is in dak bzr if you want it, MIT licensed. If you improvie it further I love to see patches.
• Changed the way the projectb copy on merkel gets synced. Up to now it was run from a cronjob which syncs a number of files people want to see on merkel, including the database dumps, then reloads the database using the latest dump. This was run at a “random” time, scheduled to be shortly after dinstall. Problem with such a setup is that it will miss extra dinstall runs and also might import old data, as the timing of the cronjob meant it runs while dinstall on ftp-master is still doing its work. So bad bad. It is now done using the ssh trigger feature I described a while ago. So our daily cronscript now tells merkel when it should sync its database again.
• Coordinated with the qa group we now also push them, when the sync on merkel is done, so they can kick their cronjobs to reread projectb and just run whenever they get told that something changed. Yet another bad timing eliminated. (Well, will be done today). Oh, if you have something that depends on information from projectb / ftp-master and try to schedule it to run after dinstall - talk to me, we might just push you too.
• Started talking with the release team how britney, the script which manages our testing distribution, should be handled in the future. It currently is run fully under control of us ftpmasters (and reading hint files from the release team). Ideally this gets changed so that the release team has the control of the code and whatever gets run with it and then, in some way, maybe using ssh triggers, tells us to import a new dataset for testing. That needs some thinking, as obviously it should be limited to testing and we should make sure it doesn’t break the archive, but I think that is doable.
• Prepared a patch that sanity checks the Provides: field, something we currently don’t do. Mailed our internal team address about 3 days ago, to let others look at it, no response yet.

The above should nicely sum up my work in the past few days. Most of it pretty trivial, but still things that have to be done. I plan to keep doing things, slowly going from the trivial stuff to more complicated ones, but there is lots of stuff ahead. Some ideas, and this is a very incomplete list just from my head, there are tons of things that one could do, include

• Finally allowing dpkg-sig support in .deb files. I once, years ago, made a patch for it, which never got applied. (Mostly my fault here). Need to rewrite that to fit the actual code.
• Add a few more sections to our archive. There are multiple bugs asking for them, and some others also come to mind. Like java, ruby, octave, haskell, debug to name a few, but there might be more needed. (Yes, longterm all sections should die and be replaced with debtags. I just don’t think debtags is there yet?!)
• Maybe finally drop m68k and add other architectures to the archive, like some $foo*bsd one. (Thats for after lenny of course, at the time arm also gets dropped).
• Merge a patch I got from Myon which will keep uploaders in projectb.
• Enable bzip2 support for sources, not only for the binary packages. I have a patch ready, it’s not yet merged. Needs to test if anything breaks in stable if we apply it, before we can think about it. Worst case it has to wait until we are running lenny. (The archive runs on a machine with stable, so allowed features always have to be supported in stable).
• Process the currently waiting requests for pseudo-packages and either reject or approve them. After thats done - talk to the BTS maintainers to hand the management of pseudo-packages over to them, as 99% of the usage of those is in the BTS.
• Get dak to optionally mail the sponsor of a package too, if not already in the list of those getting a dak mail. Which isn’t easy. One proposal is to just look at the gpg keyid and get the Debian uid from it, send mail there. I don’t want this, as people are, unfortunately, able to disable mail receiving for their @debian.org address. Which would give us lots of bounces. No way we like that. Similar problems with “Just take one userid that looks like a mail address from their key”.
• Improve various parts run by our daily cronjob, as that one takes ages (about an hour today). Speed improvements are always nice there.
• Think about having more dinstall runs a day. Like - every 2 or 4 or 6 hours could be nice. But that needs discussion within the ftpteam and also with the mirror people before it can be done. But 6 hours seems to be something nice to have, more might be also ok.
• Coordinate with DSA to enable the continous AKA WAL archiving for our database.
• Make merkels sync be more instant, ie. no longer rely on a push of a database dump whenever dinstall run, but something thats near realtime. Having changes done on ries immediately synced to merkel.
• More (active) ftp-team member, maybe?!

Now, do you have any time to kill? Do you want to help? Some things you could do:

• Go look at our bug page and start there. Someone, I think Don, already started using user categories. It would be nice if someone is willing to keep up with the bugs and put them in categories. And continue to do that in the future.
• Generally help with our bug page. One nice task some people do, and possibly more could also do, is retitling bugs. Especially removal bugs tend to have a wrong title. The format is pretty specific…
• Feel free to submit patches to me. I promise to look at them without too much delay and at least give you a hint what might be wrong or could be done better. And if it makes sense, doesn’t break the archive, works, and is something dak should have - I will also merge it. Of course trivial patches are way easier in that regard, non-trivial ones should go via our ftpmaster address first, to leave others a chance to comment on. Bonus points if you provide bzr trees one can merge from, and the bzr tree you should work with is http://ftp-master.debian.org/bzr/ftpmaster-dak/ - patches/bzr trees against outdated versions won’t have much luck to get looked at. :)
• Keep me happy. However you do it, just don’t hug me. :)

Tux likes this fish-like object. I finally got bluetooth file transfer working between my phone and laptop a little while ago. It wasn't particularly hard, although there were a couple of dead ends. The basic bluetooth layer is petty easy. Start dbus, start hcid, start passkey-agent if you've not paired the two. It seems to be a bit simpler to start the pairing from the phone. Then use sdptool browse to check the phone is seen clearly. After that, it got a bit complicated. obexftp worked well enough as far as it went, putting items onto the phone and getting files off the phone, but I couldn't work out how to get some items off the phone. They just didn't appear in the obexftp or obexfs listings. So I wondered if it night be easier to start the transfer from the phone. There's an obexftpd, but I didn't figure out how to send it files. I also tried to compile opd but I think it offer patching for modern gccs. (Anyone got these working?) What I did get to work was sobexsrv - just tell it a directory and it puts any files it's sent there. Works a treat. One other thing that has been really useful is anyremote. It's a command server for the GNU/Linux side and a Java client for the phone. The phone mostly picks from option menus or preprogrammed keys, but editable fields are also possible. You can run any commands that the server configuration allows, including starting file transfers. I think that's possible because remote control and object transfer are on different bluetooth channels, but I don't really understand it yet. I've improved the RSS reader to use xsltproc and added shell commands to it. Once I'm fairly sure it's reliable, I'll upload it near here. (Posted in part due to an ALUG thread which reminded me about this forgotten draft.)

My previous post has led to a new name and a lot of improvements in the codebase. estron is the new name for DWI. With help from ikiwiki and Alioth, estron has a new home, a new wiki and a fresh start. I've implemented -Werror fixes across the codebase (with the sole exception of some old Gtk2 code that is now deprecated).

As is my regular practice, make distcheck is now working (although some actual tests need to be added) and I've added versioned symbol support. estron can work with libqof1 but it will be better served with libqof2 and that's probably for the best as that means I have time to finish estron to coincide with the libqof2 transition after Lenny. As mentioned in the ITP, if anyone wants to play with the code before then, I'll make an upload to experimental if you just ask (or you can just build estron from Debian SVN).

I m a person who isn t satisfied with a lot of things. This both affects me and helps me on several circumstances in life, such it is. The latter also affects my way to deal with mail, mail serving and MUAs. For years, I was a strong Novell Evolution user, mainly because it was quite easy to use, it was pretty and it used to understand the needs that people like me, involved in a lot of things (some of the worthwhile, some of them shitty), required. But in the last couple of years, it began to bloat, to handle connections Bayesian filters and SpamAssassin in a way that was utterly broken and decomposed. I took a break years ago, and tried Mutt, as many free software folks and Debian developers use them on a daily basis to deal with even more incoming mail. I actually liked it, but I was just unable to deal with spam too. My local config was probably broken, fixing it was an obscure fart of Benedict XVI and hidden folders for mailing lists were just a way to forget that I actually was subscribed to mailing lists and focused only on the incoming mail on the inbox. I then tried KMail, since I started usign KDE. It was good enough for it was sometimes slow when trying to load or search on about 100 000 mails and it just didn t fulfill me. I also tried Thunderbird which only made me hate its very closed format to display its ugly UI. Besides, a lot of things on it were getting my angry, like the message filters, etc. So I just didn t give a damn and moved my whole personal mail accounts to Google Apps, giving an opportunity to a totally different approach on mail handling. So I started using the Web interface of GMail. At first I was shocked watching me dealing with a Webmail but after a while I started getting used to it and liking it. Its way to put all conversations threaded on a central inbox was sweet (i was able to filter, tag and take out of inbox too). So I liked it. Some things have never liked me whatsoever: It will always use your default mail address to reply to all messages, even if they are delivered to another recipient, which I consider retarded; its way to let users to top-post, etc, (you should also see how debian-private is seen on GMail and how the google sponsored links propose products based on all its threads xD). The good thing here also was that while not being a total purist, I loved that most spam has automatically handled for me, oh thank Lord I m a lazy bastard. Then I found Sup, which I think is like GMail but on mutt. It is written in Ruby and distributed as a gem (I d prefer it to be in C/C++, but I ll always give the benefit of doubt). Its main feature? A console mail client featuring GMail s features, such as, one inbox, one big archive and labels all over the place, which is exactly what I was (probably) looking for. As the time of writing,Sup can only connect to IMAPs remote servers or read a number of local file formats. So, I undusted fetchmail and set it up. Since all my mail accounts now are forwarded to the main GMail account, I only need to handle one fetchmail config to get messages with POP (and some procmail recipes salting touch). Here comes the sweetest thing from all this setup, by enabling GMail s POP support, you can also specify if you want it to delete the GMail copy or store it. Since I ve used 2% of all my storage, the best thing to do right now is to store and archive, which means that while i download all my email everyday and several times a day, all downloaded copies are also being stored on GMail, so in case I don t have access to my machine, I can still find messages on the web interface. GMail also works nicely when you are sending an email from your remote mail client and using GMail s SMTP, then also the mail you are sending gets stored on your GMail web interface, which is totally cool. So I think I m mildly content now with what I have. This also leads me to another awesome feature for me: Spam gets processed by GMail before I fetch it, so most of my downloaded POP mail is ham. In case I want to see some spam, the web interface will have it as usual for 30 days before being deleted. I like to improve my time for productivity, to get more things done in less time, I do like learning about it, and the proof of concept for GMail handling being used by Sup and the free facilities that Google offers to dudes like me is just a great of avoiding procrastination. It s a hell nice bag of features for me, and probably for you, why not try it?

J rg Jaspert wonders, if planet.debian.org should be available as a mailing list, too. That's a proposal to solve the problem, that planet has been used by more or less official announcement and discussions, but not all people have time / want to read planet. An other solution would be to make sure, that important blog posts are mention in the next issue of the Debian Project News (which have just been started and could still need some help).

I started physiotherapy this past week. The first clinic I went to on Wednesday (Mountain View Physical Therapy) turned into an interesting disaster. When we walked into the place, the first impressions were that it was noisy and dirty. There was someone sitting upright in the waiting area asleep. The place is one big room, with the massage tables in the middle of the room and exercise equipment all around the outside. None of the staff looked really happy to be there. I met my therapist who, it turns out, is the director of the clinic. She was truly excellent - good enough that I would've overlooked everything else, except for the fact that she doesn't have 3 days a week free to see me. More weeks, I would've been lucky to get her more than once per week.

So for Friday, we found a different clinic. Orthosport. It was such a difference from the previous place, there's no good comparison. The receptionist was friendly, the therapist very professional, and the place really tidy. Even the assistants were very friendly and checked in on a regular basis.

But in between those two days, I got sick again. I had some sort of stomach flu or drug reaction the previous week, and it seemed to be coming back. After two days of throwing up, I made an appointment with the after-hours clinic today to get more anti-nausea drugs. They've also taken some more blood and want to do some tests next week to make sure that everything's still doing okay.

Another bit of love and affection goes to my new bank, RBC Centura. Not only have they done lovely things for bill payments, and sending money for free between my Canadian and American accounts, they also have a "Bank by Mail" program, where I can just stick cheques in an envelope that's already postage paid, and they deposit them for me. No need to find a machine of the right persuasion to do deposits. We still have a couple tasks to do before we can close out the HSBC account, but we're almost there.

Leif is pushing out new teeth. He'll be up to 9 when he's done.

I was recently checking to see what, if any follow-up there had been from Sun’s ham-handed handling of the Open Solaris Trademark, and I ran across this very interesting comment from Jon Plocher’s Candidate Statement for the Open Solaris Governing Board:

“I also think there was a misunderstanding about what Sun desired when it launched the community (in part) to encourage developers to adopt and use Solaris. My take is that, while there *is* value in getting more kernel, driver and utility developers contributing to and porting the (open) Solaris operating system, there is significantly *more* value in having a whole undivided ecosystem based on a compatible set of distributions, where application developers, university students, custom distro builders and users are all able to take advantage of each other’s work. Put these two things together, and you can see Sun’s predicament. Sun *wanted* a community that empowered application developers, but *got* a community aimed squarely at kernel hackers. Whether you see this as the “kernel.org -vs- Ubuntu” fight, or the “fully open -vs- MySQL model” argument, in my opinion, it all is simply a reflection of the above mismatched expectations.”

So that explains why it’s take three long years to try to get basic open source development tools (such as putting Open Solaris source code in a distributed SCM located outside of the Sun firewall) for Open Solaris. It was never was Sun’s intention to try to promote a kernel engineering community, or at least, it was certainly not a high priority for them to do so. This can be shown by the fact that as of this writing they still are using the incredibly clunky requester/sponsor system for getting patches into Solaris; setting up a git or mercurial server is not rocket science. This lack explains why Linus gets more contributions while brushing his teeth than Open Solaris gets in a week. So if you run into a Sun salescritter or a Sun CEO claiming that OpenSolaris is just like Linux, it’s not. Fundamentally, Open Solaris has been released under a Open Source license, but it is not an Open Source development community. Maybe it will be someday, as some Sun executives have claimed, but it’s definitely not a priority by Sun; if it was, it would have been done before now. And why not? After all, they are getting all of the marketing benefit of claiming that Solaris is “just like Linux”, without having to deal with any of the messy costs of working with an outside community. As a tactical measure, astroturfing is certainly a valid marketing trick. But after three years, the excuse of “just you wait a little longer, we’re just trying to figure this open source community stuff out”, is starting to wear a little thin. Furthermore, if (as Jon Ploncher claims) this was about “empowering application programmers”, why was it that Sun’s first act was to trumpet how wonderful it was to release the Solaris source code under a Open Source license? This only seems to make sense if the Open Solaris initiative was really a cynical marketing tactic to try to save Solaris from being viewed as irrelevant. If that was Sun’s intention, I think it is fair to say that from a marketing point of view, the tactic has been at least partially successful — although as Jon has admitted, the goal of creating a full community with application developers, university students, and so on, hasn’t materialized for Open Solaris. Sun has the dream; the Linux community is living it. However, from business standpoint, I wonder if Sun will really be able to sustain their Solaris engineering team if they will really be doing all of the work themselves, and outside contributions continue at the rate of 0.6 patches per day. After all, the margins when you are selling low-cost AMD servers are much lower than when you are selling ber-expensive SPARC servers. With Linux, we have a major advantage in that kernel improvements are coming from multiple companies in the ecosystem, instead of being paid for by a single company. And given that 70-80% of Sun’s AMD servers are running Linux, not Solaris, it’s not clear how Sun justifies their Solaris engineering costs to their shareholders. Furthermore, if Solaris on x86_64 were to actually take off, there’s nothing to stop competitors from selling Solaris support — except the competitors won’t have to pay the engineering costs to maintain and improve Solaris, so they would be able to provide the support much more cheaply than Sun could. So while Sun’s marketing tactics have kept Solaris alive in some verticals, I have to question how successful Sun will be in the long-term.

Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

• Windows 2000
  
• Windows 2001
  
• Windows 2001 SP1
  
• Windows 2001 SP2
  
• Windows 2001.1
  
• Windows 2001.1 SP1
  
• Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

Yesterday I signed the contract for a new job in Berlin. I'll start begin of June.
It's remarkable how fast the subscription to debian-jobs mailing list resulted in a new job, although I think that this is not necessarily the same for everyone subscribed there. :-)

I spent the entire week at the SambaXP conference in G ttingen, Germany. The conference is the annual conference of the community of developers, contributors and users of Samba. I general call it "my annual german pilgrimage" as I attended all seven editions of the conference, the only FLOSS conference I attend on my work time, as my daily work involves quite a lot of uses of samba. This year featured a workshop or training session held by John Terpstra, longstanding FLOSS evangelist and member of the Samba Team for over 10 years, and Karolin Seeger, the brand new release manager of Samba. This has indeed been an incredible opportunity to have discussions with them about the packaging work for Samba. Actually, the work we did in the last 3 years to bring Samba Debian packages in a very good shape (when I don't screw up) is much appreciated. I think these days have been another opportunity to keep that link very closed. I have been impressed by the promising work of Karolin with respect to the preparation of the release and the very serious way she has to do that work....as well as her very friendly, while still discreet approach to technical discussion. Some work was done on Samba package bugs, though less than usually (the remaining ones are harder and harder to tackle!). I mostly work on Debian packages as well as .deb packages prepared by Sernet (the services company that organises the conference and employer of some Samba Team members), as these could some day become the packages provided by the Samba Team. Talks at the conference were pretty interesting, to keep connected with Samba 3.2 and 4.0 development. News from Andrew Tridgell about exchanges with Microsoft (yes, The Evil) and access to MS documentation, are very promising. The collaboration between Samba developers and Microsoft enginneers is now working well again, at the engineers level (as Tridge says: "lawyers are away, now, we can talk at the engineers level and restore the link that existed in the early 90's"). I also could measure the progress of the Openchange project whose ultimate aim is to provide a complete Microsoft Exchange replacement solution. They currently have working MAPI libraries and an Evolution plugin for Exchange is under development, while the bricks to build a server are patiently being put together. Good discussions with Julien Kerihuel, the lead (and French) developer and manager of the project. Jelmer Vernooij and I also settled the final plans to get Samba4 packages in Debian. I proposed to make a first upload to experimental, but quite soon to upload to unstable, the point being a largest as possible exposure of that code, so that upstream developers (Jelmer himself, Andrew Bartlett and a few others...) get as much feedback as possible. That upload will not be targeted for lenny (we'll block it from entering testing). For that reason and also because Samba 3 and 4 will certainly coexist for years, the source package will be named "samba4". Expect more news quite soon. And final conclusion of that week: I've also been delighted to be able to visit Alex and Meike in Hildesheim, as well as Andreas in Wernigerode. It's always a great pleasure to see longstanding Debian friends. At the beginning of the week, I planned to see *two DD and finally, at the end of the week, I can tell I've seen *three* Debian developers, finally!

Hi, Julien, I agree that Debian is not dying and it was a bad PR move for Lucas to suggest it is, but what makes you think your response is any better from the PR perspective? I too have represented Debian at trade shows, LUGs etc. and I've had to deal with this topic before. My response is not to berate the holders of misinformation (and while I believe you when you say you were only aiming at Lucas, you used the plural so it would be easy for readers to be misled into thinking you meant multiple people.) but to emphasize that Debian is unique. Noone has conducted a social experiment of this type on this scale before and it is only natural for experiments to occasionally result in explosions and bad smells. Adopting this angle does not make us look bad and steers the questioner away from negative lines of thinking without belittling him. Much better PR don't you think?

The default keyboard autorepeat setting on most systems is boringly slow. Even worse, the delay before autorepeat kicks in is so long. This is great for novice users, but we programmers deserve better. Here's a calibration procedure that I use:

• The autorepeat delay should be as short as possible, but a concentrated, damp but short keypress should not cause multiple keypress events.
• To determine the most suitable autorepeat rate, test your accuracy. Open an editor and try to enter multiple lines of about 50 characters using the autorepeat feature. Pick the highest setting with which you can consistently get the line length within 2-3 characters of the target. (The 2-3 character margin comes from the practice of releasing the autorepeated key a little early and entering the remaining 1-3 characters, if any, with separate keystrokes.)

For me an autorepeat delay of ~250ms and 80 char/s rate works well. To get your numbers, you can use the command xset q grep 'repeat rate' . This tweak make the standard direction keys (and particularly the backspace & delete keys) much more useful: you can frequently get away without using special editor commands or, say, having to select things to delete them and thus resetting the X buffer. It makes things a little faster and more responsive. Try reverting to the standard setting after a few weeks of fast repeat to feel the difference.

Cut and paste from Brack’s SATA harddisk pricelist:

Samsung SpinPoint S166,  HDD,  80GB, 7200rpm, 8.9ms,  8MB Cache, SATA II NCQ, OEM, 3.5'', SAH-HD082GJ   CHF  53.00
Samsung SpinPoint S250,  HDD, 250GB, 7200rpm, 8.9ms,  8MB Cache, SATA-II NCQ, OEM, 3.5'', SAH-HD250HJ   CHF  64.00
[...]
Samsung SpinPoint T166s, HDD, 400GB, 7200rpm, 8.9ms, 16MB Cache, SATA-II NCQ, OEM, 3.5'', SAH-HD403LJ   CHF 109.00
Samsung SpinPoint T166s, HDD, 500GB, 7200rpm, 8.9ms, 16MB Cache, SATA-II NCQ, OEM, 3.5'', SAH-HD501LJ   CHF 101.00

So from 80 GB to 250 GB the price difference is less than CHF 10 and 500 GB harddisks are cheaper than 400 GB harddisks of the same type? We live in a strange world. And no, none of this harddisks is marked as special price or promotion. Oh and for all those not having CHF as your daily currency: (Rates from x-rates.com.)

Is this traffic or congestion? This is one of those Friday Afternoon Projects - it's been put off all through a busy week because it's unpaid, I'm not completely sure how to approach it and now my arms hurt like hell from travel jabs which are making it hard to concentrate! So I'm going to float it on here... I've been asked to brief a meeting next week about that group's current web site and its problems. I'm not linking it yet to avoid insulting/embarrassing them. The site looks OK, but doesn't rank well on search engines and doesn't allow much member participation. I need to explain why that's a bad thing and how the site's technical choices have led to that. I'm not directly pitching for TTLLP to get any work (because I'm a member of that group, it might be a conflict of interest and we're pretty busy anyway - even our own site needs work on some of the points I'm going to mention), but I don't want to be unhappy if we're asked to implement my recommendations. I've got a usual outline that I follow, but my presentation's time is limited, so I'd like to ask you: what about this is important and what isn't? If you give me useful feedback, I'll put you in the Acknowledgements with a backlink and I hope the briefing will be shared pretty widely over the next few months. The current plan is to start with a basic explanation of how search engines rank pages, as far as we can tell, referring to PageRank Explained Correctly with Examples, by Ian Rogers as well as the shorter official summaries from the dominant search sites at Yahoo, Microsoft and Google. Then I go through a quick evaluation of the site against the basics of validation, accessibility and robot-friendliness, followed by a couple of SEO-style checks of its current rankings and inbound links. Next is a bit different because I have access to some of their web access stats: I summarise what we know and suggest some other stats they've probably not considered and why they're useful, along the lines of Dave Briggs's measures of blog success. Finally, I suggest ways to improve the site. The top tip will be to take control of the site hosting and stop using the cheap and cheerful donated server that makes all links except the front page point to another domain. I'll probably suggest a mix of free and open source software tools to power it. If they don't want to move it all yet, I'll suggest running a second site for member participation, using tools like Wordpress, NoseRub and so on. What do you think? Plan for success, am I missing some tricks, or am I setting myself up for a lynching? Let me know with a comment or email, please.

nion argues about the new Dilbert.com website now using flash instead of GIFs. Well, he hasn’t looked right: Dilbert.com offers now flash and static images. And the last ones are now much easier than ever to view or fetch, because Dilbert.com now has RSS feeds. Ok, at the moment, the feed seems broken respectively empty, but I have the last week of Dilbert comics in my feed reader. In colour! Additionally Dilbert.com is opening its archive. (The link to the blog post currently broken, too.) Back to 2001 is said to be available now, the reminder is in the works The new Dilbert.com site worked fine yesterday but seems to have some problems today. But I expect that they will fix that soon. :-) Noticed it btw. because the inofficial Dilbert feed from tapestry included a broken image yesterday. (Works fine now, but no new comic in that feed today…)