I'm in hospital, taking an enforced rest from work and normal life.with much too much time to think. Luckily I have relatively slow 'Net access.

I've just spent about three weeks in a specialist orthopaedic hospital which is also a centre of excellence, a research and teaching hospital. Some lessons for FLOSS:

Research methods matter: open communication matters more

The hospital was apparently doing various research projects, some minor, some major: whether cooling a knee joint in surgery improved recovery and aftercare, whether complete pain relief and comprehensive analgesia stimulated recovery, trying to standardise on a pain score to measure subjective pain - " On a scale of 1-10 how does it feel?"

The knee joint research was being written up and would be shared worldwide - if it proved worthwhile, hundreds of patients could benefit. If it wasn't worthwhile, it would still be written up just as comprehensively with testing methodology, evidence from double-blind trials or whatever as appropriate to save someone else from having to re-invent the wheel.

The analgesia study sounded just like the application of a doctor or nurse's intuitive commn sense and experience - but it was being carried out scientifically and measured. also answering supplementary questions like "If pain is sometimes a helpful indicator of problems, how should you guage reactions when all pain is dulled?" Additionally, the ward had dispensations to use different and more flexible drug regimes to include the use of oral morphine derivatives. Again, everything was being noted, measured and shared.

Many people know Ultimate Debian Database already, and do use of it to create useful QA tools, or other Debian related activities. There is another database which is widely used by all of us, every day, and runs behind the scenes without being noticed. It is called projectb, the huge database of the Debian archive. projectb is the place where dak stores all the information it needs to run the archive (including but not limited to source packages, related binaries, suite definitions and associations, overrides, and so on), and it tells dak to hit you with a REJECT if you try to upload a package twice, or if you do something The Wrong Way. OK OK, it eventually allows your packages to be accepted too, sometimes it also behaves good projectb is hosted on ftp-master.debian.org. Most fellow Debian Developers cannot login over there because access is restricted to FTP and Release people only, but can enjoy its clone on merkel.debian.org ^[1]. Please note that clone is synced on a regular basis, but it could be a little bit not up-to-date with the very latest changes. Just run the following: psql -d projectb -p 5433 Now that you have access to it, you could want look at its structure to start looking at it. I just provide a couple of trivial examples of what you can do with it, your imagination is the limit ^[2] This query displays which dpkg version known suites ship:
SELECT s.source, max(s.version) AS version, su.suite_name AS suite
FROM source s
JOIN src_associations sa ON sa.source = s.id
JOIN suite su ON su.id = sa.suite
WHERE s.source = 'dpkg'
GROUP BY s.source, su.suite_name
ORDER BY version; This query displays changelog entries for debhelper which versions are greater than 8:
SELECT changelog
FROM changelogs
WHERE source = 'debhelper'
AND version > '8'; Working with projectb means working with real Debian archive data, so you are sure to always get solid information. You can also experience a limited (but functional) dak session on merkel. You cannot do much, data is read-only, but this is not a limit for a couple of commands. The most interesting is dak rm, where you can simulate a package removal, and discover reverse dependencies in advance, to save some work to your lovely FTP Team Just run the following:
dak rm -n -R -m "Don't worry, it's a Dry Run" your_behated_package Wait a little bit, and you will be prompted with removal report. Just remember to always use -n and -R flags, though. Want even more? Join FTP Team, and you will given the chance to learn a lot more about Debian! DISCLAIMER: if you plan to write a tool, or perform an activity which relies on current projectb implementation, PLEASE TALK TO FTP TEAM FIRST. Internal structure can change a lot over times, and it is way better let FTP Team to handle exporting/parsing its data for day-by-day tasks. ^[1] This is probably supposed to change, as merkel is going to be decommissioned soon. ^[2] If you need a new feature, just talk to FTP Team.

Here are the Debian users who have submitted a request to appear in our website so far in this year. Please welcome them into our Project!

1dental.com: Commercial company from US.

A.S.D. Irishmassa American Football Team: Non-profit organization from Italy

Centro de Comunicaci n Cient fica, Universidad de Buenos Aires: University from Argentina.

Creppolo, crepes e piadine: Commercial company from Italy.

Eye Of The Beholder BBS: Non-profit organization from Spain.

IT Services, Medhurst Communications Ltd.: Commercial company from UK.

JSC VS: Commercial company from Russia.

King Abdulaziz City for Science and Technology (KACST): Academic section from Saudi Arabia

Lumut MARA Vocational Institute: Educational institution from Malaysia.

Madkom Ltd.: Commercial company from Poland.

Media-X Systems Inc.: Commercial company from Canada.

Microbiology laboratory. Science Faculty. UNAM: University from Mexico.

Nimbus Hookah Lounge: Commercial company from US.

Nomura Technical Management Office Ltd.: Commercial company from Japan.

oriented.net Web Hosting: Commercial company from Switzerland.

Parkyeri: Software development company from Turkey.

Pastoral da Crian a: Non-profit organization from Brazil.

XSoft Ltd.: Software development company from Bulgaria.

Ziehm Computer Repair: Commercial company from US.

And here are some of their reasons to choose Debian:

We have chosen Debian over other alternatives; because of its reliability and easiness of maintenance.

The decision was based on the selection of additional expandable components, availability of distribution, a regular cycle for issuing amendments, stability and support solutions for a wide range of equipment for a dedicated server solutions.

Stability is important for us.

The main reason for choosing Debian over other distributions is the package management, security, number of available packages, ease-of-use, stability, amount of quality documentation, and cost.

We choose Debian to easen the burden of system administration. Also because Debian has very well maintaned packages and for high security.

Debian is powerful and keeping originality of Linux.

We find the software that comes with Debian very useful and easy to use since we are not specialists in computer matters.

Debian is the most powerful Linux distribution! The best choice for our jobs, our servers and our lifestyle.

We chose Debian because it is stable, simple and fast to install and to use, and because it is Free Software.

We are proud to say that we use Debian/GNU Linux on more than 90% of our servers and this simply because of it s stability, security and great packaging system.

Debian offered the perfect balance between security, stability and ease of administration.

We chose Debian for its rock-solid stability, ease of installation and configuration, and awesome ability to not only run on old, second-hand hardware, but to turn that hardware into powerful production machines perfect for our needs. We also like Debian s Social Contract. None of the other options were as successful in this implementation.

It is refreshing and enjoyable to have an operating system which gives users easy access.

Thanks very much for the hard work, Webmaster Team.

I recently invested some time to work on several cool features in Deb-o-Matic.
I plan to release 0.9 version soon, so I wanted something new for its users I merged some patches by Alessio Treglia, who implemented a couple of nice things:

• Mailer support, to send build status notifications to the uploader
• Blacklist support, to temporarily limit builds for a given distribution

Then, I worked on some changes I really wanted to have:

• Rebuild support, to redo build of a package already in distribution archive
• Improved lock system, to avoid random build hangs which affect older code
• Fix pyinotify loop, which prevented Deb-o-Matic to quit in interactive mode

Now that the big part of the planned features is committed, I am going to test them to spot major issues, and add some minor improvements to have a shiny release Last but not least, your help is appreciated to complete translations! There are really a few strings to process, and several languages are already half-completed, so if you can spend five minutes (or even less!), I will be grateful

You have a computer. You're afraid of it being stolen by baddies or raided by the police, so you've encrypted its hard disk with LUKS. You also want to carry around some of your crypto keys (SSH and/or GPG), or any kind of sensitive data, on an USB key, so you can restore a normal activity in case the computer gets stolen or becomes untrustworthy. You like things that Just Work, including automounting with autofs (no GUI popups, no need to manually unmount and so on). But of course, you can't very well just mount the drive and store your keys on it in the clear. Well, actually you can (I did it for way too long), but let's assume you want to do without. Because USB keys get stolen or lost, too. autofs just handles the mounting of the drives, not their unlocking, and there's no hook in there specifically for LUKS. There is, however, a more generic way of running arbitrary commands on mounting: the program maps. It's all described in the documentation, so I'll just paste the relevant parts of my /etc/auto.removable, with a few comments. Remember to make it executable and reference it in /etc/auto.master.

 #! /bin/sh
 volume=$1
 autoluks ()  
   dev=/dev/$1
   cryptname=$ 1 _crypt
   cryptdev=/dev/mapper/$cryptname
   keyfile=/etc/private/$cryptname.key
   options=$2
   [ ! -e $dev ] && exit 0
   if [ -b $cryptdev ] && ! cryptsetup status $cryptname   grep -q device:.*$dev ; then
       cryptsetup remove $cryptname   logger
   fi
   cryptsetup --key-file $keyfile luksOpen $dev $cryptname   logger
   [ -b $cryptdev ] && echo $options :$cryptdev   true
  
 case "$volume" in
   # LUKS-encrypted volumes
   lacie-keys)
       autoluks lacie-keys -fstype=ext4,ro,noatime,nodev,noexec,nosuid
       ;;
   lacie-keys-rw)
       autoluks lacie-keys -fstype=ext4
       ;;
   lacie-backups)
       autoluks lacie-backups -fstype=ext4
       ;;
   # Non-encrypted volumes
   cd)
       echo -fstype=iso9660,ro,nodev,nosuid            :/dev/cdrom
       ;;
   floppy)
       echo -fstype=auto,sync,nodev,nosuid             :/dev/fd0
       ;;
 esac

The astute reader will have noticed that the keys volume is mounted either read-only or read-write with the same mechanism. This volume contains SSH keys that I use quite regularly, that filesystem is going to be mounted and unmounted very often. USB keys, and flash memory in general, don't really like repeated writes. Fortunately, the SSH keys are mostly read, and very rarely written to, so I can afford to mount the partition read-only and save the write cycles for when I generate new keys (the mere action of mounting a partition read-write changes it, even if the files in it are never modified). The backups volume is mostly accessed in write mode, and much less frequently anyway, so there's no need for a distinction there. This supposes that the partitions on the USB key appear as /dev/lacie-keys and /dev/lacie-backups. Due to the dynamic naming of devices, you may like to use rules similar to the following in /etc/udev/rules.d/local.

 KERNEL=="sd[a-z]1", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-keys"
 KERNEL=="sd[a-z]2", ATTRS idProduct =="1027", ATTRS idVendor =="059f", ATTRS manufacturer =="LaCie", ATTRS product =="LaCie iamaKey", SYMLINK+="lacie-backups"

You'll also need to initialize LUKS on the partitions, save the key, make the filesystems, and so on. If you're still with me, you probably know what I'm talking about, then I don't need to explain about that. This setup works for me, but there's no guarantee and so on. Based on a tutorial found on the Debian Administration website (great resource, by the way). Update: I'm told a large part of the script could be replaced with pmount. If you like short scripts, you may want to investigate that too. Update 2: Josselin points out a different solution using Gnome, udisks, gnome-disk-utility and Nautilus. It's worth checking out, for those who like to run all that and click around. I can't test it right now (Gnome/Nautilus currently refuses to mount any USB key, for some presumably transitional reason), but I have no reason to believe it's inherently broken. I just don't like having to do anything when I plug my key or before I unplug it, and I'm not always running a graphical session with a desktop.

A while ago, I found the nice arcade game Zaz. The goal is to sort rolling marbles by color to make them vanish before they fall down a hole. I enjoyed playing it in turn with my girlfriend, but it was not nice that one of us always had to wait and watch. Also, Zaz is quite hard and my girlfriend (who is better at the game) did not manage to finish all levels. So I thought, that it would be great if we could play the game together! I recently read that the version of the X server on my laptop supports XInput2 and thus multi-pointer-input, so I thought I give it a shot. The main problem with making the change was SDL, a very common library used by Zaz to interact with the system. The SDL code fetches the events from the X server, handles them (e.g. mapping button presses to unicode characters, remembering mouse positions to calculate relative movement). SDL itself does not know anything about multi-pointers, or the events generated by XInput2. So once I started to listen to XInput2 events, no regular events would come through any more and the game stops reacting. The SDL supports passing unknown X events in a SDL_SysWMEvent. This would have helped, but XInput2 passes its data in X s new GenericEvents where additional data needs to be fetched with XGetEventData before the next X event is handled. SDL does not know that and thus, when more than one event is waiting, the event data is lost before SDL passed them to the application. Therefore I completely bypass the SDL event handling and only use XNextEvent myself. This meant re-implementing some logic, especially relative mouse movements and keeping the mouse within the window, guided by the SDL code. I did not worry about text input, so you need to enter the name for the highscore with an unpatched Zaz :-). The game logic site was surprisingly easy to adjust to more than one player. Just replaced the Player object by an array of Player objects, and the game machinery still works. This is a sign of very good design, kudos to Remigiusz Dybka. At first, when the laser pointer bonus was picked up, only the first player would get it. I changed that so both players benefit from the bonus. It would make more sense if only the player who actually killed the bonus ball would get it, but that would be hard to track. In the end, the result is very satisfying. And together, we managed to finish the game at once. Enough words. Here is a demonstration of us two playing the first level, as a HTLM5 video (alternatively watch it on YouTube): If you want to try it yourself, you can either grab the Debian packages (v0.2.9, source package and binary built for amd64), the patch against version 0.2.9 or the patch against version 1.0.0. Then you need to plug in two mouses and use the xinput command line program to create a new master and reattach one of the mouses to the second master, before starting the game. And of course, you need a partner (unless you want to play the game bimanually good luck). PS: Why is my Ogg/Theroa video, created with recordmydesktop, all green when uploaded to YouTube? I hat to locally convert it to MPEG4 first...

Debian s testing distribution is where Debian developers prepare the next stable distribution. While this is still its main purpose, many users have adopted this version of Debian because it offers them a good trade-off between stability and freshness. But there are downsides to using this distribution and the Constantly Usable Testing (CUT) project aims to resolve those. This article will present the project and the challenges involved to make it happen. About Debian unstable & testing Debian unstable is the distribution where developers upload new versions of their packages. It happens frequently that some packages are not installable due to changes in other packages or due to transitions not yet completed. Debian testing, on the contrary, is managed by a tool that ensures the consistency of the whole distribution: it picks updates from unstable only if the package has been enough tested (10 days usually), if it s free of new release-critical bugs, if it s available on all supported architectures, and if it doesn t break any other package already present in testing. The Release Team (RT) controls this tool and provide hints to help it find a set of packages that can flow from unstable to testing. Those rules also ensure that the packages that flow into testing are reasonably free of show-stopper bugs (like a system that doesn t boot, or X that doesn t work at all). This makes it very attractive to users who like to regularly get new upstream versions of their software without dealing with the biggest problems associated to them. This is all very attractive, yet several Debian developers advise people to not use testing. Why is that? Known problems with testing Disappearing software The release team use this distribution to prepare the next stable release and from time to time they remove packages from it. Either because it s needed to ensure that other packages can migrate from unstable to testing, or because they have long-standing release-critical bugs without progress towards a resolution. It also happens that they remove packages on request of the maintainers because they believe that the current version of the software cannot be supported (security-wise) for 2 years or more. The security team also regularly issues such requests. Long delays for security and important fixes Despite the 10-day delay in unstable, there are always some annoying bugs (and security bugs are no exceptions) that are only discovered when the package already has migrated to testing. The maintainer might be quick to upload a fixed package in unstable, and might even raise the urgency to allow the package to migrate sooner, but if the packages gets entangled in a large ongoing transition, it will not migrate before the transition is completed. Sometimes it can take weeks for that to happen. This delay can be avoided by doing direct uploads to testing (through testing-proposed-updates) but this is almost never used, except during a freeze, where targeted bugfixes are the norm. Not always installable With testing evolving daily, updates sometimes break the last installation images available (in particular netboot images that get everything from the network). The debian-installer (d-i) packages are usually quickly fixed but they don t move to testing automatically because the new combination of d-i packages has not necessarily been validated yet. Colin Watson sums up the problem:

Getting new installer code into testing takes too long, and problems remain unfixed in testing for too long. [...] The problem with d-i development at the moment is more that we re very slow at producing new d-i *releases*. [...] Your choices right now are to work with stable (too old), testing (would be nice except for the way sometimes it breaks and then it tends to take a week to fix anything), unstable (breaks all the time).

CUT s history CUT finds its root in an old proposal by Joey Hess: it introduces the idea that the stable release is not Debian s sole product and that testing could become with some work a suitable choice for end-users. Nobody took on that work and there was no visible progress in the last 3 years. But recently Joey brought up CUT again on the debian-devel mailing list and Stefano Zacchiroli (the Debian project leader) challenged him to setup a BoF on CUT for Debconf10. It turned out to be one of the most heavily attended BoF (video recording is here), there is clearly a lot of interest in the topic. There s now a dedicated wiki and an Alioth project with a mailing list. The rest of this article tries to summarize the various options discussed and how they re supposed to address the problems identified. The ideas behind CUT Among all the ideas, there are two main approaches that have been discussed. The first is to regularly snapshot testing at points where it is known to work reasonably well (those snapshots would be named cut ). The second is to build an improved testing distribution tailored to the needs of users who want a working distribution with daily updates, its name would be rolling . Regular snapshots of testing There s general agreement that regular snapshots of testing are required: it s the only way to ensure that the generated installation media will continue to work until the next snapshot. If tests of the snapshot do not reveal any major problem, then it becomes the latest cut . For clarity, the official codename would be date based: e.g. cut-2010-09 would be the cut taken during September 2010. While the frequency has not been fixed yet, the goal is clearly to be on the aggressive side: at the very least every 6 months, but every month has been suggested as well. In order to reach a decision, many aspects have to be balanced. One of them (and possibly the most important) is the security support. Given that the security team is already overworked, it s difficult to put more work on their shoulders by declaring that cuts will be supported like any stable release. No official security support sounds bad but it s not necessarily so problematic as one might imagine. Testing s security record is generally better than stable s one (see the security tracker) because fixes flow in naturally with new upstream versions. Stable still get fixes for very important security issues sooner than testing, but on the whole there are less known security-related problems in testing than in stable. Since it s only a question of time until the fixed version comes naturally from upstream, more frequent cut releases means that users get security fixes sooner. But Stefan Fritsch, who used to be involved in the Debian testing security team, has also experienced the downside for anyone who tries to contribute security updates:

The updates to testing-security usually stay useful only for a few weeks, until a fixed version migrates from unstable. In stable, the updates stay around for a few years, which gives a higher motivation to spend time on preparing them.

So if it s difficult to form a dedicated security team, the work of providing security updates comes back to the package maintainer. They are usually quite quick to upload fixed packages in unstable but tend to not monitor whether the packages migrate to testing. They can t be blamed because testing was created to prepare the next stable release and there is thus no urgency to get the fix in as long as it makes it before the release. CUT can help in this regard precisely because it changes this assumption: there will be users of the testing packages and they deserve to get security fixes much like the stable users. Another aspect to consider when picking a release frequency is the amount of associated work that comes with any official release: testing upgrades from the previous version, writing release notes and preparing installation images. It seems difficult to do this every month. With this frequency it s also impossible to have a new major kernel release for each cut (since they tend to come out only every 2 to 3 months) and the new hardware support that it brings is something worthwhile to many users. In summary, regular snapshots address the not always installable problem and changes the perception of maintainers towards testing, so that hopefully they care more of security updates in that distribution (and in cuts). But they do not solve the problem of disappearing packages. Something else is needed to fix that problem. A new rolling distribution? Lucas Nussbaum pointed out that regular snapshots of Debian is not really a new concept:

How would this differentiate from other distributions doing 6-month release cycles, and in particular Ubuntu, which can already be seen as Debian snapshots (+ added value)?

In Lucas s eyes, CUT becomes interesting if it can provide a rolling distribution (like testing) with a constant flux of new upstream releases . For him, that would be something quite unique in the Free Software world . The snapshots would be used as starting point for the initial installation, but the installed system would point to the rolling distribution and users would then upgrade as often as they want. In this scenario, security support for the snapshots is not so important, what matters is the state of the rolling distribution. If testing were used as the rolling distribution, the problem of disappearing packages would not be fixed. That s why there have been discussions of introducing a new distribution named rolling that would work like testing but with adapted rules, and the cuts would then be snapshots of rolling instead of testing. The basic proposal is to make a copy of testing and to re-add the packages which have been removed because they are not suited for a long term release while they are perfectly acceptable for a constantly updated release (the most recent example being Chromium). Then it s possible to go one step further: during freeze, testing is no longer automatically updated which makes it inappropriate to feed the rolling distribution. That s why rolling would be reconfigured to grab updates from unstable (but using the same rules than testing). Given the frequent releases, it s likely that only a subset of architectures would be officially supported. This is not a real problem because the users who want bleeding edge software tends to be desktop users on mainly i386/amd64 (and maybe armel for tablets and similar mobile products). This choice if made opens up the door to even more possibilities: if rolling is configured exactly like testing but with only a subset of the architectures, it s likely that some packages migrate to rolling before testing when non-mainstream architectures are lagging in terms of auto-building (or have toolchain problems). While being ahead of testing can be positive for the users, it s also problematic on several levels. First, managing rolling becomes much more complicated because the transition management work done by the release team can t be reused as-is. Then it introduces competition between both distributions which can make it more difficult to get a stable release out, for example if maintainers stop caring of the migration to testing once the migration to rolling has been completed. The rolling distribution is certainly a good idea but the rules governing it must be designed to avoid any conflict with the process of releasing a stable distribution. Lastly, the mere existence of rolling would finally fix the marketing problem plaguing testing: the name rolling does not suggest that the software is not yet ready for prime time. Conclusion Whether CUT will be implemented remains to be seen, but it s off for a good start: ftpmaster Joerg Jaspert said that the new archive server can cope with a new distribution, and there s now a proposal shaping up. The project might start quickly: there is already an implementation plan for the snapshot side of the project. The rolling distribution can always be introduced later, once it is ready. Both approaches can complement each other and provide something useful to different kind of users. The global proposal is certainly appealing: it would address the concerns of obsolescence of Debian s stable release by making intermediary releases. Anyone needing something more recent for hardware support can start by installing a cut and follow the subsequent releases until the next stable version. And users who always want the latest version of every software could use rolling after having installed a cut. From a user point of view, there are similarities with the mix of usual and long term releases of Ubuntu. But from the development side, the process followed would be quite different, and the constraints imposed by having a constantly usable distribution are stronger: any wide-scale change must be designed in a way that it can happen progressively in a transparent manner for the user.

This article was first published in Linux Weekly News. If you want to see more articles like this, join Flattr and click on the flattr button below every article that you like.

21 comments Support my work

Since I ran Bois d'Arcy hal-marathon back on Sept 12th, breaking my record down to 1h37, I continued working on resistance, in preparation for the Sein-Eure marathon on Oct 17th, two weeks from now. I'm still working empirically. No program, no fractioned sessions, work on speed, constant cardio training, etc. Just running...a lot...most often at marathon speed, and alternating trail and road running. Usually, I'm out 4 days per week: both Saturdays (short 10km run, or so), Sundays (long run, up to 20) and two week days, during lunch (skipping lunch and going out running). I'm now working one day per week in another facility of Onera, in Palaiseau. This is 20km away from center Paris and has woods close to it. So, I can train in trails rather than stupid roads...:-) I ran a small local race on Sept 26th: "la vir e des Deux Bois", in Villebon sur Yvette, a 18km trail with 330meters positive slope. I finished 27th out of 69 in 1h31, despite the high level of runners....most being trained trail runners who didn't want to run in the crowd of Paris-Versailles. Finally, this week-end (Oct 3rd), I (alone) ran a long trail to the Colline d' lancourt, one of my favourite spots in the neighbourhoods, marvelous when the sun is shining, with a 360 paronamic view up to 30 km in distance (yes, one can see the Eiffel Tower). This artificial "moutain" is the highest point in Paris region. That trail involves many funny...and muddy...single tracks in the forest. A great piece of cake. It also involves 300 meters positive slope, so that's hard training..:-) I now feel ready for the third marathon of this year! Let's rest for two weeks, now.

diocles' blog post reminds me that it's time again for some more RCBW propaganda. so here are the RC bugs I've worked on in the last two weeks:

• #574624 dibbler-client: "dibbler-client: after removing package with dselect impossible to purge it."
  apply patch to init script, upload to DELAYED/2
• #578403 mysql-proxy: "DAEMON=".." in initscripts points to"
  fix init script (patch from BTS), upload to DELAYED/2
• #589582 eucalyptus: "eucalyptus: FTBFS with upcoming Hibernate 3.5"
  add a comment to the bug report
• #595839 verilog-mode: "verilog-mode: FTBFS in squeeze: Nonexistent build-dependency: 'emacs22'"
  add emacs23 as first alternative in B-D-I, upload to DELAYED/2. later cancelled
• #595876 multiboot: "multiboot: FTBFS in squeeze: rm: cannot remove debian/multiboot/usr/share/info/dir': No such file or directory"
  remove potentially created file unconditionally, upload to DELAYED/2
• #597409 tk707: "tk707: install-info installed leads to /usr/share/info/dir.gz in built package"
  rm /usr/share/info/dir.gz in debian/rules, upload to DELAYED/2
• #597411 ssed: "ssed: install-info installed leads to /usr/share/info/sdir.gz in built package"
  rm /usr/share/info/sdir.gz in debian/rules, upload to DELAYED/2

which RC bug are you going to tackle today?

I travel pretty regularly, about 35% so far in 2010. When it goes wrong, travel can be exhausting, frustrating, complicated, stressful and even debilitating. I m always looking for ways to make my trips run more smoothly. On a recent flight to Taipei, I wrote down a few of the techniques which I ve successfully put into practice and found helpful. This is not an exhaustive list; I ve omitted a lot of the common and obvious tips I ve seen elsewhere.

1. Make a packing list. This one may be obvious, but a lot of people neglect it. Perhaps they think making lists is boring and fussy, but really, it isn t. Without a packing list, it s easy to forget to do the things which will make your trip better. Use it every time, and bring a copy with you (or store it online) so you can add the things you wish you had brought or done. A simple, ever-improving packing list is the most effective technique I have found for making travel less stressful and more enjoyable.
2. Carry a water bottle with a tight-fitting lid. I use a 32oz Nalgene bottle, which fits nicely into the seat next to me or under an armrest, and gives me enough water for even the longest flights. I fill it up after passing through security, at a cafe, bar or lounge, and generally decline the beverages offered by the cabin crew. Staying hydrated helps me feel better during the flight, and leaves me with less malaise when I arrive. I don t need to manage a tray table or armrest full of cups and other debris, so I can sit more comfortably, with the tray table folded away.
3. Consolidate essential items using multipurpose equipment. For example, invest in a power adapter which has USB sockets onboard, and carry USB cables instead of wall chargers. Versatile items like this save on space and weight. I can charge two devices this way, but the equipment is smaller and lighter than even a single wall charger.
4. Learn how to sleep on an airplane. Getting some sleep on a long flight really helps to offset the effects of traveling. There are several resources out there with practical advice on how to do it. One thing which really helped me was to buy a high quality eye mask which blocks out all of the light in the cabin. The one I use looks a little funny and is not cheap, but is very comfortable and effective. It s made of memory foam with a soft, washable cover and works much better than the ones the airlines give away for free. I no longer bother with a neck pillow, and use the flaps built into the seat to lean my head against. I m surprised at how many people don t know about this common aricraft feature: virtually every long-haul seat has something like this, even in economy, though it may not be obvious how to use it.
5. Buy duplicates of things like toiletries, and keep them in your travel kit so you don t need to pack your everyday items (and risk forgetting them) each time. The less packing you need to do, the less time it will take, and the less opportunity there is for mistakes. This also saves time unpacking when you get home, and lets you buy a smaller size of the item where available.
6. Optimize border crossings Carry the forms you ll need for customs, immigration, etc. in your carry-on. They don t always provide them at the counter or on board the plane, and it s a hassle to rush to fill in the form at the last minute. If you have a few of them with you, you can fill them out early (perhaps even before you fly) and then hustle to the front of the queue. For countries you enter frequently (especially your home country), programs like Global Entry (US) and IRIS (UK) will save you a lot of time by allowing you to use an automated kiosk to cross the border.

For some time, I've had this idea brewing for how the 'net would work without DNS. Initially I was mostly thinking of how to get rid of the dark side of the registrar business, but it appears that maybe it could help with security in general too. It may not be feasible at all, or I may have forgotten extremely crucial points. I'm not a DNS guru, so bear with me and consider this as a thought experiment. This is, however, a proposal for how the Internet could be made truly decentralized, or acentric. Made so, because it currently is very centralized on at least two counts: the DNS is an inherently hierarchical structure of authority; and so is the situation with the SSL certificates used for securing websites. Let's start with DNS, if you will. Basically, the idea is to replace the current Domain Name System, which is centralised in nature (even if subdomains can be delegated) with a fully decentralised system with no central authority. The point of current DNS is to map names to IP addresses in a unique way. It currently works by registering a this name is managed by such-and-such server, ask for details at such-and-such IP address message. Of course, since there's only one namespace (or a limited number thereof, if you consider that TLDs are different namespaces), there needs to be a central authority to resolve conflicts, because some names will be more popular than others. I propose to start with a cryptographic key pair (think GPG key). Anyone can create their key pair; we assume that it's extremely unlikely for two people to generate the same keys, and that it's also very hard for two people to generate keys with the same fingerprint. By (being the only one) knowing the secret part of a key, I am the authority on what can be signed with it. I could for instance sign records that say that www points to this set of IP addresses, and smtp points to that other address. Within my area of authority, which is to say within my domain. Which is identified by the fingerprint of my key pair. What do we have so far? A mechanism that allows in a decentralised way to verify who's authoritative on the F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more probably F55...3F5.some-tld. Now let's publish the signed records on a decentralised peer-to-peer network. I'm not up to date with the latest trends in that domain, but I think something like Gnutella or Freenet would qualify, since it doesn't need central hubs but only an initial list of nodes, and it does automatic discovery of new nodes. Projects such as the FreedomBox (name likely to be changed) will probably help with that. Anyway, when looking up www.F55...3F5.some-tld, the resolver gets the signed record (and the public part of the key) from the P2P network, checks the signature, and uses the contents of the record to determine the IP address. No central or delegated registry involved at any point. Lesser risk of a single point of failure, which means better resilience against outages. Also, a better resilience against DNS-based censorship, be it promoted by non-democratic states or by greedy corporations. Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly easy name to remember or transmit. But the string of hex could be presented to the user in some other form easier to recognize for people without geek super-powers. My favourite would be the bibi-binary representation, but I'm told that the bubble-babble method works equally well. It would still be unreasonable to expect people to remember such names, and especially to type them into their web browsers or e-mail agents. A possible solution to that would be to use a short form, such as 144843F5 (or its bibi-binary equivalent), complemented by a visual representation of the full fingerprint such as the one SSH does. That pair could be displayed on business cards, email signatures, glossy brochures, advertisements and so on, and allow users to just type the strange word or flash the 2D barcode, check that the funny picture matches (in case the strange word returns several results), and get the website they want. Which they can of course bookmark under a name they can remember, probably even the same name that everyone else uses to bookmark that website. And nothing precludes convenient directories mapping names to full URLs (like search engines currently do) as long as users check that the visual representation of the site they go to matches what they've seen elsewhere. That elsewhere could, of course, take advantage of the natural web of trust that emerges in of GPG-using communities. If I'm directed at a website whose key I don't immediately recognize, then I can see who trusts that key to be legitimate (by checking the signatures), and who trusts them, and so on. Ultimately, the decision is mine to make, and mine only. In any case, once I know what URL I want to visit, I can be sure this DNS replacement will give me the right IP address (or addresses). DNS servers replying with advertisement sites instead of correct ones, and DNS-based filtering, will be things of the past. Of course, having the right IP address only solves the attacks on the DNS part. Eavesdropping can also happen by diverting traffic at the IP level. But we have a trustable way to know information related to a domain, so let's use it: the signed record can also contain the fingerprint of cryptographic keys (SSL or SSH or whatever). So we can be sure we're actually talking to the correct server, rather than to some man-in-the-middle spy. With the same guarantees of correctness as the ones for the DNS, backed by the web of trust and out-of-band validation. Again, we get rid of the hierarchy of certification authorities , some of which have been known for helping organizations get at the (supposedly secret) data people exchange over the net. To summarize: with this scheme, if I know the site I want to access is F55...3F5, then I can be certain that a) I get the right IP address for it and b) I'm actually talking to it. And nobody in-between can intercept the traffic, if the site is properly administrated and its private key is kept secure. And from the site admin's point of view, there's no need to trust DNS registrars and SSL certification authorities not to fool around with the data, or blackmail me into paying increasing fees for keeping my URL working or my SSL key certified. There's still the problem of the allocation for the IP addresses themselves, but two major parts of the centralized and hierarchical net can be gotten rid of. There are proposals attempting to fix part of the problems already, but they're incomplete. DNSSEC only solves the authentication of DNS records, not the centralisation problem. Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details). This is of course only a rough draft, full of technical considerations yet certainly not exhaustive. I've thought about it though, and I believe there are no theoretical problems with the implementation of such a scheme (apart for the handling of expiration and revocations, probably). The main obstacle to mass-adoption I can envision is the UI part, and the entrenched habit of just typing a keyword into a search engine and implicitly trusting its results, then blindly trusting the website itself; but even if mass-adoption isn't reached, I can't see anything wrong with giving those who want to be careful a more secure Internet.

Being a buildd admin means one gets to sign successful build logs so that the built packages get uploaded from buildds to the archive, but that also includes filing bugs for packages which fail to build from source (Build-Attempted). Once that done, they can be marked as Failed, usually with a reason. A few words plus a bug number is usually convenient, so that people (maintainers, possible NMUers, other buildd admins) browsing https://buildd.debian.org/status/ can just click the bug number to reach the BTS. There were a few packages in Build-Attempted for alpha, for which I reported some bugs yesterday, which explains the crossing lines on the following graph: (That s an edited version of the buildd stats for alpha.) One has to be careful while filing bugs, since the severity depends on the target architecture(s) for which the package is failing, but also on its already being built there. Mostly, that boils down to serious for regressions (no longer builds) on release architectures, important otherwise. The only exception I m applying is packages failing on all architectures due to obviously missing build dependencies, since they can t be built again, even on the single architecture they re available for (and we want to guarantee that doesn t happen, we want to be able to binNMU them). There are currently no packages in Build-Attempted for alpha, kfreebsd-amd64, kfreebsd-i386, and sparc (architectures I take care of), but I m going to have a look at other architectures as well, since having portable software and reported (FTBFS) bugs sounds like a worthwhile goal.

xserver-xorg-video-intel There s a previous episode regarding this driver, but let s try and get a short summary regarding UMS (User Mode Setting, old-fashioned) vs. KMS (Kernel Mode Setting, new but also Linux-specific): upstream moved from UMS+KMS to KMS only (that means a single code base and allegedly fewer bugs). UMS vs. KMS timeline:

2.9	2.10	2.11	2.12	2.12+legacy	2.12+shadow	2.13
UMS+KMS	KMS	KMS	KMS	KMS+UMS	KMS	KMS

In order for UMS introduced back into 2.12+legacy to be useful for the ever-buggy i8xx chips, those were blacklisted for KMS in the i915 module as of linux-2.6 2.6.32-21. The plan didn t quite work out, so we moved to the shadow version, relying on KMS again. At that point, we asked for the removal of the kfreebsd-* binaries, since they were unusable. Kernel timeline:

k 2.6.32-20	2.6.32-21 k 2.6.32-23	2.6.32-24 k
KMS	KMS + blacklist for i8xx	KMS

Quick summary:

• You want to use the latest kernel from sid, with the latest -intel driver from sid as well. (That holds for other drivers as well.)
• You may want to check whether kernel bugs are fixed in experimental s kernel.
• You may want to check whether driver bugs are fixed in experimental s driver package (2.13). Feel free to open a bug upstream if there s none for your issue already, optionally telling us about it (through a bug in the BTS which can be marked as forwarded there).

libdrm Due to nouveau s ABI changes, libdrm s compatibility (for nouveau users) is a funny subject. Nouveau users are expected to have the following in mind (README.Debian is there already in the xserver-xorg-video-nouveau package).

2.4.21-1~squeeze3 (sid)	2.4.22-1 (experimental)
nouveau 0.15	nouveau 0.16 aka 1.x
2.6.32 k 2.6.33	2.6.34 k

We carry a big ABI-revert patch in our 2.4.21 package so that we get the bugfixes of that version while still using the 0.15 interface, which is what we have in the sid kernel for now. If we need more stuff from 2.4.22 for squeeze, we should be able to cherry-pick them, or even adjust the ABI-revert patch quite easily. For now (and in experimental anyway), the 2.13 version of -intel is going to depend on libdrm 2.4.22, but cherry-picking fixes should be easy; making it build against sid s 2.4.21 shouldn t be hard either. xserver-xorg-video-openchrome It s now possible to start X with the openchrome driver again, thanks to Nethanel s feedback on #597379, but that doesn t mean it s usable for real unfortunately, since users still report frequent crashes.

There was a lot of news coverage like Credit card fees being imposed by councils, says Which? earlier this week. People seemed outraged that councils were making a small surplus over the year in total. Interviewees suggested that councils should just include the cost of taking payments in the amount charged. Of course, councils are sort-of not-for-profit, so they ll just set prices to include the credit card fees and make a small surplus on other cheaper forms of payment over the year in total. So everyone who uses bank transfers will pay more because credit card fees are high! Will that be next year s scandal? Presumably that s what happens in France, Germany and other countries where sellers can t charge more for credit card payment. That, or you just don t accept credit cards, like many German retailers never used to. What else can they do? It s a bit odd of Visa to claim it costs more to accept other forms of payment. Cheques are horrendously expensive if you only get a few, but seem to get cheaper if handled in bulk. Domestic bank transfers and cash also seem cheaper than Visa to me. Sellers seem to be asked explicitly to assume much more fraud risk in order to accept credit cards, too. Mind you, with the amazingly slack approach of most US retailers to cards (no chip-and-PIN and they usually don t bother to even check the signature I cut up the card I used in the USA when I arrived home), I m surprised there s not more card fraud. I m also a bit surprised Bath and North East Somerset (which neighbours my home district) is paying 2% on credit card transactions. Our co-op has been offered deals about as good as that and we don t do anything like as many transactions. We ve not yet taken one up because the setup paperwork is a pain and the setup and maintenance fees usually suck. It feels like it doesn t matter what you do with money, bankers still get rich. Even though I keep looking (like in 2007), it ll probably happen: we need to act again, because some overseas customers seem unwilling or unable to register with a site to pay (and some payment sites have ethical questions too), while international bank transfers are even more expensive and an even bigger pain. Besides card payments, we re considering opening a currency trading account and a Euro bank account. Anyone done these and do you think they re worth it or not? And do any Eurozone banks allow a UK company to open an account without a member visiting in person? I ve found few possibilities, after looking at banks in seven countries so far.

For once, not using that journal entry title to talk about my own. Someone posted a pointer to an opinion piece looking at productivity differences between the US and Germany to a private hierarchy I read. I know productivity numbers like this are somewhat disputed, but I don't want to get into that. What I'm more interested in is the analysis. Whether or not the US does significantly better or worse than other countries in this regard is hotly debated, but what isn't is that the length of typical work weeks for employees, particularly in IT, is not going down. Fifty or a hundred years ago, it was common to expect that the growth of automation would mean more leisure for humanity. There was, at the time, some argument over whether that would be a good thing, but it seemed to be a trend. This didn't happen here. The above article argues that the amount of vacation that US employees take is going down over time. And in IT it's common to hear about 50 hour weeks (or 80 hour weeks in startups). Little of that promise of increased leisure from modern technology seems to have happened in the US, although it seems to have happened somewhat in Europe; about all we managed was to get down to a 40-hour work week, which is now honored in the breech for a lot of exempt employees. And that was seventy years ago. Most of the scientific research that we have available is quite clear that working longer hours causes diminished productivity. Standard time management advice is to focus more and work in shorter intervals. Hours of unfocused work are considerably less effective than much shorter periods of focused work, recovery time is vital, and forcing oneself to work long hours leads to bad decision-making. Even in less cerebral and more repetitive work, such as some assembly line work, we've known for many decades that working longer hours leads to more accidents and more bad decisions, and there the costs of an accident are often much higher. So, why are we so dead-set on doing the exact opposite of what available evidence says is the best way to work? I think this is to some extent a Rorschach blot question: you're going to see the answer in this that fits your pre-conceived notions about what's dysfunctional about US workplaces. I rambled elsewhere about my own pet peeve: the overwhelming focus on money and short-term profit and cutting cost, which I think leads to a lot of the nasty employment abuses in the US. But here I want to raise a different point: as the article says, we work long hours because that's what we're measured on and rewarded for. We work unproductively for many of those hours partly because it's impossible to be productive for that many hours. We get used to feeling intermittantly unproductive at work; it becomes normal. And in many jobs, particularly in IT, we don't measure ourselves by results because we have no idea what a reasonable level of results actually is. Management gets a lot of blame for failure to manage by results rather than by artificial measures like attendance and time worked (or tickets closed, or hours logged against customer requests, or similar trivially manipulatable and artifical measures). But I think this goes deeper than management. I think even we ourselves, with as good of knowledge as anyone could possibly have of what our jobs are and what good results look like, don't have a clear idea of how much to expect from ourselves on a daily basis. I know from time management exercises that I wildly mis-estimate tasks and don't have a good feedback loop to get better at estimates. I also tend to plan towards maximums rather than the average. If I have a very good day, I try to work at that level and hold myself to that level of work, rather than trying to find a long-term average. And my perceptions about what results constitute good results vary wildly based on the most recent events and surrounding context (such as whether a project is late), even though I know that my basic work capacity is not going to change significantly because a project is late. If we want to change how we measure work, I think this may be the place to start. We can't ask managers to measure us by results if we don't even know what that measurement would look like. I'm going to start asking myself some new questions: What is the average amount of work I can get done in a day? What's the standard deviation? Is there some way that I can measure this over time so that I'm not fooling myself based on circumstances or temporary surges of productivity, since my day-to-day productivity seems to have a lot of "noise"? What realistically constitutes finishing a week's worth of work? When am I "working" but not accomplishing something, and more importantly, why am I doing that? What broke when that happens? I'm firmly convinced that one of my personal breakthroughs in time management will happen when I can stop "working" when I'm not being productive. Whenever I manage this (rarely, right now), I both find I needed the break and find that I can return far more productive than I was before I took the break. But usually I continue to "work" unproductively, clocking hours without creating results, and feel both guilty about the lack of results and even less productive. That's the trap that I think this article is pointing at.

The month is coming to an end, and I d like to recommend you some things on flattr.com :)OpenRheinRuhr Ein Pott voll Software Die OpenRheinRuhr ist eine Messe mit Kongress rund um das Thema Freie Software . Die OpenRheinRuhr 2010 findet am 13. und 14. November im Rheinischen Industriemuseum in Oberhausen statt. Freie Software ist aus Firmen, Verwaltungen, Bildungseinrichtungen und Privathaushalten nicht mehr wegzudenken. In der bev lkerungsreichsten Region Europas bietet der OpenRheinRuhr e.V. durch Ausstellungen, Vortr ge und Workshops Informationen ber Freie Software. Auch Themen jenseits der Technik, wie B rgerrechte im Netz oder die Handhabung von Lizenzen werden behandelt. Vortr ge in mehreren Tracks sprechen Menschen mit unterschiedlichem Kenntnisstand an vom Anf nger bis zum Profi. Entwickler & Projekte bekommen die Gelegenheit zum Erfahrungsaustausch. Weitere Informationen und Anmeldem glichkeiten unter: http://openrheinruhr.deBitlBee The IRC geek s solution to instant messaging. Tunnels instant messaging traffic (supporting all popular IM protocols and Twitter) to a virtual IRC channel and virtual IRC queries. Can be installed locally, but also available as a public service for people who can t/don t want to install it.
KiBi s blog This blog mainly features Debian-related posts on various topics: X.Org package maintenance (including calls for help, and status updates towards users), Debian GNU/kFreeBSD (GNU userland running on a FreeBSD kernel), and Debian s Graphical Installer (now based on X.Org). Also some upstream stuff, like the bugzilla replica type for SD (Simple Defects).
phpMyAdmin phpMyAdmin is a tool intended to handle the administration of MySQL over the Web. It can create, rename, and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, create dumps of tables and databases, export/import CSV data, and administrate one single database and multiple MySQL servers.
Debian Backports Over the last years I did numerous backports for Debian and also run backports.org. Since September 2010 we moved backports.org to backports.debian.org so its an officialDescriptions shamelessly stolen from flattr.Some words on these things:

• OpenRheinRuhr is a nice small FOSS event in my area
• I m using BitlBee every day as my main jabber client
• KiBi just rocks ;)
• phpMyAdmin is a tool I couldn t live/work without
• formi runs backports very good :) (yes, I know, he is not the only one)

Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian The first one, on September 12 and the second one, on September 29. I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that's solved with one of Gems' main features being the simultaneous installability of different versions. The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in They should only care that it works. We, as packagers, should take care of all the infrastructural stuff. And yes, that's where we find the conflicting spot: We don't want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors' only response to a bug in an older release will be "upgrade and rewrite whatever breaks in your application". As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years. That's the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work. And yes, the Perl community is a joy to work with in this regard. And that's the same I understand from the Python one. Because of their origins and where their main strength was grown and remains. PS - And yes, I will join the flock of people saying that... The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a "sigh" of lack of understanding, and not with the flames you got targetted with :-/

In my Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ, I wrote The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). Zed A. Shaw just provided a very good example of that. Quoting the most juicy parts:

It s simply a tactic to make sure that you are stuck on Debian.

If we look at this problem from an open source perspective, Debian is at a minimum being a horrible citizen.

What is happening is control is not aligned with responsibility. Debian has taken control of the software package and recrafted it for their very narrow set of system administrator users. However, they refuse to take responsibility for the defect and quality problems they create. Instead I end up being responsible for their mistakes, which is wrong.

If Debian is in control, then Debian should be made responsible. That s the only way to get them to change it. If they don t want to be responsible, then they should let me be in control.

I m imagining a mass petition, maybe some funny ad campaigns, in-person confrontations meant to embarrass package maintainers, SEO tricks to get people off Debian, promotion of any alternative to Debian, anything to make them pay, apologize, and listen.

If you write software and you re sick of Debian screwing up your gear, then shoot me ideas for how we can make this happen. I think that if enough of us band together to make Debian responsible for its actions we can actually get them to start asking us before they package our software to find out how we think it should be packaged.

On the technical part of the post: The problem that Zed is experiencing is unknown to me, and also to the Debian and Ubuntu bug trackers. To my knowledge, rubygems doesn t not require openssl or net/scp to work, and a simple grep through the sources kind-of confirms that. But of course, that blog post was written as a rant, not as a proper bug report. My best guess is that the gem that Zed is installing requires openssl and net/scp. But of course, rubygems can t just depend on all the libraries that applications or libraries installed via rubygems could possibly require. Regarding openssl, we had a problem in Ruby because of the licensing situation of Ruby (dual licensed GPLv2+ and Ruby license, linked with openssl, which might raise some eyebrows), so it was split off the main standard library package until recently (and, apparently, in the version Zed is using). For net/scp, it is not part of the standard library, and not a dependency of rubygems, so I don t see why Zed expects it to be installed. On the rest of the post: Following my last post, several people volunteered to help with Ruby on Debian (and Ubuntu). In particular, Laurent Arnoud has been doing some fantastic work fixing the pkg-ruby-extras team s RC bugs. Also, all the messages of support both in the comments of my last post were very much appreciated. But I m really wondering why the Ruby community generates so many poisonous people. All my work on Debian is done on a volunteer basis, and it s really hard to get so much shit from it.

If you do not play PokerTH yet, you might want give it a try :)If you already do, read on :)PokerTH 0.8PokerTH 0.8 was released a couple of days ago. The most exciting feature of this new release is the online ranking feature: you can register at poker-heroes.com and login with these credentials in PokerTH, now your games will be logged and you might reach place 1 at the ranking site.However, you won t see 0.8 if you do not have experimental (for Debian) or the pkg-games PPA (for Ubuntu) in your sources.list. As the release is only a few days old, it won t be included in Squeeze or Maverick. Sorry for that. But I plan to provide needed backports as soon they are needed (currently experimental and PPA should be sufficient, tell me if they are not).PokerTH 0.7.1As written above, 0.8 won t be shipped in Squeeze and Maverick, but 0.7.1 will be. With the release of 0.8, upstream has moved their server to 0.8. This means that Debian and Ubuntu users won t be able to play internet games on the official server (as long they did not install 0.8). I ve set up pokerth.debian.net running 0.7.1 and have just uploaded 0.7.1-2 which uses this server as default one to unstable (sync to Maverick will follow in a couple of hours). However, default means default on new installs. If you have already played PokerTH, you have a ~/.pokerth/config.xml with the upstream server in it and you have to change this if you want to play on my server. Please read /usr/share/doc/pokerth/NEWS.Debian.gz for this:

 pokerth (0.7.1-2) unstable; urgency=low
  The server at PokerTH.net now runs the 0.8 version of the software,
  which is incompatible with 0.7.x we ship in Squeeze.
  Because of that a 0.7.x server is running on pokerth.debian.net.
  On new installations this will be the default server used.
  On old ones you have to reconfigure your client yourself.
  Either set "Serverlist Address" under Settings   Internet Game to
  "pokerth.debian.net/serverlist.xml.z" or use the "Manual Server
  Configuration" using "pokerth.debian.net" as the server address.
 -- Evgeni Golov  <evgeni@debian.org> Mon, 27 Sep 2010 14:09:17 +0200

Sorry for that and enjoy nice flops and raises :)

Kevin Stone gave an interesting TED talk about the biological future of joint replacement [1]. Using stem cells and animal tissue which has been prepared to destroy the chemicals that trigger immune responses the tissues can regrow. Replacing joints with titanium and ceramic lets people walk again, regrowing them with Kevin s methods allows them to compete at the highest levels of sporting contests! Derek Sivers gave a brief and interesting TED talk advising people to keep their goals secret if they want to achieve them [2]. The Parrot AR.Drone is an interesting device [3], it s a four-propeller helicopter that is controlled by WiFi. Apparently there is little security (it binds to the first WiFi client it sees) which is a significant down-side. It returns a video feed to the controlling iPhone as it flys and can hover when it loses it s connection. It will be interesting to see when people write software for other devices (Android etc). Also I wonder whether there will be open source weapons kits for it. If you could have those devices use either a nerf gun or a lance to attack each other s turbines then you could have drone jousting. Don Marti had an interesting new idea for a crime game [4]. The main concept is to use the element of mistrust that is present in real criminal gangs. The new guy you invite to join a job might inform the police and you won t know for sure. Sometimes a heist will be discovered by the police through bad luck (or good police work) and you will wonder whether there was an informant. The aim is for a simple game design and with the complexity in email discussions between the players. The C64 isn t dead, it s even on the Internet [5], an original C64 is running a web site! Tan Li gave an interesting TED talk about a new headset to read brain-waves [6]. The device in question can be applied in minutes, requires no gel or abrasion of the scalp, connects to the computer wirelessly and is relatively cheap at $300US. The developer s kit (which I think includes a headset) is $500US. I wonder if the community can develop a cheaper version of this which is more open. Lisa Margonelli gave an interesting TED talk about the politics of oil [7]. One of her insightful points is that the subsidies for oil should be shifted from the oil industry to middle-class consumers. But she goes off track a bit by suggesting gradual oil tax increases until 2020, according to the best estimates of groups such as the CSIRO they won t need to have taxes to give a high oil price in 2020! She is aiming for a 20% reduction in petrol use by 2020, but I m not aware of any serious group of scientists who have evidence to suggest that the production capacity in 2020 will be close to 80% what it is now. Slate has a good article about The Innocence Project which uses DNA tests to overturn false convictions [8], it s scarey how badly the justice system works. Rachel Sussman gave an interesting talk about the World s Oldest Living Things [9], nothing less than 2000 years old is included. Nicholas Negroponte gave an interesting EG 2007 talk about the OLPC project [10]. While some of the content about OLPC production is a little dated the OLPC history is relevant and his personal opinions regarding the benefits that children receive from computers are insightful. Jayne Poynter gave an interesting TED talk about life in Biosphere 2 [11]. Her work on mini-biospheres is also interesting. Let s hope we get a permanent Biosphere running outside the Earth sometime soon. Sheryl WuDunn gave an informative TED talk titled Our Century s Greatest Injustice about the plight of women in most of the world [12]. Daniel Kahn Gillmor wrote a good article about the use of ssh-agent [13]. You really should use it to secure your ssh keys. Mark Shuttleworth has described the development process for the Ubuntu font [14]. This is a very interesting project and IMHO one of the most significant things that Ubuntu has done. Prior to this an entirely closed development process has been used for font development. Now we are getting a major new font family developed with a free and open process and with some new legal developments for a font license! One thing to note that this project appears to have involved a lot of work from professional font designers, it sounds like Canonical spent a significant amount of money on this project.

• [1] http://www.ted.com/talks/kevin_stone_the_bio_future_of_joint_replacement.html
• [2] http://www.ted.com/talks/derek_sivers_keep_your_goals_to_yourself.html
• [3] http://toucharcade.com/2010/09/06/parrot-ar-drone-review-the-coolest-rc-toy-ive-played-with/
• [4] http://zgp.org/~dmarti/wiki/software/better-crime-game/
• [5] http://www.c64web.com/
• [6] http://www.ted.com/talks/tan_le_a_headset_that_reads_your_brainwaves.html
• [7] http://www.ted.com/talks/lisa_margonelli_the_political_chemistry_of_oil.html
• [8] http://www.slate.com/blogs/blogs/thewrongstuff/archive/2010/08/17/reasonable-doubt-innocence-project-co-founder-peter-neufeld-on-being-wrong.aspx
• [9] http://www.ted.com/talks/rachel_sussman_the_world_s_oldest_living_things.html
• [10] http://www.ted.com/talks/lang/eng/nicholas_negroponte_on_one_laptop_per_child_two_years_on.html
• [11] http://www.ted.com/talks/lang/eng/jane_poynter_life_in_biosphere_2.html
• [12] http://www.ted.com/talks/lang/eng/sheryl_wudunn_our_century_s_greatest_injustice.html
• [13] http://debian-administration.org/users/dkg/weblog/64
• [14] http://www.markshuttleworth.com/archives/537