A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems. The wish I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time. The patch Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that. The rebuff The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors. The fork(let) So I m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don t want to maintain this fork of nagstamon I don t plan to diverge any more from Henri s code, so if you have other feature requests, please talk to him first.

A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems. The wish I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time. The patch Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that. The rebuff The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors. The fork(let) So I m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don t want to maintain this fork of nagstamon I don t plan to diverge any more from Henri s code, so if you have other feature requests, please talk to him first.

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux grep fgplayer grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team

Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

racket (previously known as plt-scheme) is an interpreter/JIT-compiler/development environment with about 6 years of subversion history in a converted git repo. Debian packaging has been done in subversion, with only the contents of ./debian in version control. I wanted to merge these into a single git repository. The first step is to create a repo and fetch the relevant history.

TMPDIR=/var/tmp
export TMPDIR
ME= readlink -f $0 
AUTHORS= dirname $ME /authors
mkdir racket && cd racket && git init
git remote add racket git://git.racket-lang.org/plt
git fetch --tags racket
git config  merge.renameLimit 10000
git svn init  --stdlayout svn://svn.debian.org/svn/pkg-plt-scheme/plt-scheme/
git svn fetch -A$AUTHORS
git branch debian

A couple points to note:

• At some point there were huge numbers of renames when then the project renamed itself, hense the setting for merge.renameLimit
• Note the use of an authors file to make sure the author names and emails are reasonable in the imported history.
• git svn creates a branch master, which we will eventually forcibly overwrite; we stash that branch as debian for later use.

Now a couple complications arose about upstream's git repo.

1. Upstream releases seperate source tarballs for unix, mac, and windows. Each of these is constructed by deleting a large number of files from version control, and occasionally some last minute fiddling with README files and so on.
2. The history of the release tags is not completely linear. For example,

rocinante:~/projects/racket  (git-svn)-[master]-% git diff --shortstat v4.2.4  git merge-base v4.2.4 v5.0 
 48 files changed, 242 insertions(+), 393 deletions(-)
rocinante:~/projects/racket  (git-svn)-[master]-% git diff --shortstat v4.2.1  git merge-base v4.2.1 v4.2.4 
 76 files changed, 642 insertions(+), 1485 deletions(-)

The combination made my straight forward attempt at constructing a history synched with release tarballs generate many conflicts. I ended up importing each tarball on a temporary branch, and the merges went smoother. Note also the use of "git merge -s recursive -X theirs" to resolve conflicts in favour of the new upstream version. The repetitive bits of the merge are collected as shell functions.

import_tgz()  
    if [ -f $1 ]; then
        git clean -fxd;
        git ls-files -z   xargs -0 rm -f;
        tar --strip-components=1 -zxvf $1 ;
        git add -A;
        git commit -m'Importing ' basename $1 ;
    else
        echo "missing tarball $1";
    fi;
 
do_merge()  
    version=$1
    git checkout -b v$version-tarball v$version
    import_tgz ../plt-scheme_$version.orig.tar.gz
    git checkout upstream
    git merge -s recursive -X theirs v$version-tarball
 
post_merge()  
    version=$1
    git tag -f upstream/$version
    pristine-tar commit ../plt-scheme_$version.orig.tar.gz
    git branch -d v$version-tarball
 

The entire merge script is here. A typical step looks like

do_merge 5.0
git rm collects/tests/stepper/automatic-tests.ss
git add  git status -s   egrep ^UA   cut -f2 -d' ' 
git checkout v5.0-tarball doc/release-notes/teachpack/HISTORY.txt
git rm readme.txt
git add  collects/tests/web-server/info.rkt
git commit -m'Resolve conflicts from new upstream version 5.0'
post_merge 5.0

Finally, we have the comparatively easy task of merging the upstream and Debian branches. In one or two places git was confused by all of the copying and renaming of files and I had to manually fix things up with git rm.

cd racket   /bin/true
set -e
git checkout debian
git tag -f packaging/4.0.1-2  git svn find-rev r98 
git tag -f packaging/4.2.1-1  git svn find-rev r113 
git tag -f packaging/4.2.4-2  git svn find-rev r126 
git branch -f  master upstream/4.0.1
git checkout master
git merge packaging/4.0.1-2
git tag -f debian/4.0.1-2
git merge upstream/4.2.1
git merge packaging/4.2.1-1
git tag -f debian/4.2.1-1
git merge upstream/4.2.4
git merge packaging/4.2.4-2
git rm collects/tests/stxclass/more-tests.ss && git commit -m'fix false rename detection'
git tag -f debian/4.2.4-2
git merge -s recursive -X theirs upstream/5.0
git rm collects/tests/web-server/info.rkt
git commit -m 'Merge upstream 5.0'

I've been buying quite a lot of (usually cheapo) gadgets recently, which I'll probably introduce / review in various blog posts sooner or later. Let me start with a fun little gadget, a digital USB-based microscope. I found out about it via this thread over at lostscrews.com. You can get this (or a very similar device) e.g. on eBay for roughly 50 Euros. Mine seems to be from a company called Oasis (though they're probably just the reseller, not sure). The device doesn't seem to have a nice name, but I can see UMO19 MCU003 on the microscope, so I guess that's the name or model number. It can focus on magnifications of 20x or 400x. The image resolution is said to be a max. of 1600x1200, but in practice most of my images are 640x480, maybe I have to change some settings and/or the resolution depends on the magnification factor and lighting conditions. The device acts as a simple UVC webcam when attached to USB, so you can view the images easily via any compatible webcam software, e.g. luvcview and also save screenshots of the magnified areas (see images).

First three from left to right: SMD LED (400x), clothes/jacket (400x), random PCB (20x). The other two below: A via on a PCB (400x), and the "pixels" of a TFT screen (400x). It worked out of the box on Linux for me, the uvcvideo kernel driver was loaded automatically.

 $ lsusb
 Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp.

I set up a wiki page for more details (including full lsusb -vvv) and sample images at: http://randomprojects.org/wiki/Oasis_UMO19_MCU003_USB_microscope I will also post some more images there over the next few days.

This is a really fun device for having a look at stuff you'd normally not see (or not well enough), and also useful for e.g. checking PCB solder joints, checking all kinds of electronics for errors or missing/misaligned parts, finding the chip name / model number of very tiny chips etc. etc. I can also imagine it's quite nice for biological use-cases, e.g. for studying insects, tissue, plants, and so on. Anyway, definately a nice toy for relatively low price, I can highly recommend a device like this. Check eBay (search for e.g. "usb mikroskop 400") and various online shops for similar devices, there seem to be a large number of them with different names and from different vendors. Just make sure it has at least 400x magnification, there are also some with only 80x or 200x which is not as useful as 400x, of course.

Petter suggests to make the dhcpHost LDAP objectClass an auxiliary one, to make it possible to combine it with the dNSDomain objectClass in one and the same object. Unfortunately, you can't do that. Well not if you want Debian-edu to remain compatible with everything else under the sun. You see, one of the features of LDAP is that each and every objectClass is well-defined, and that you cannot change it. As such, once a tool knows about an objectClass, it can make assumptions about objects in that class, for any such object, in any LDAP-server anywhere. Change an objectClass, and some tools will break. The proper fix is, first, to verify that you are using the proper objectClasses. To me, an objectClass called dhcpHost and one called dNSDomain don't sound like they were meant to be used together; I would suspect that there is another DNS-related objectClass that is meant for hosts rather than domains. If that isn't the case, then one can create a new objectclass say, auxiliaryDhcpHost or some such that is the same as dhcpHost in all but name, OID, and the fact that you make it an auxiliary rather than a structural objectClass. Because luckily, what's true for an objectClass is also true for an attributeType: if it is assigned to an LDAP object, tools may assume that their meaning is what they think it is...

In the local dialect here in Padova, Italy, "ovi" means "eggs". For those who aren't native English speakers, "to lay an egg" means to fail at something or do it poorly. The connection is very appropriate.
To see what it was about, and if it was worth pursuing, I decided to submit a couple of simple applications to Nokia's OVI store. Nothing fancy, or that I'd spent much time developing, and they were actually little things I'd done for myself before the ovi.com store came out, but I had hoped to see about making a bit of money out of the time invested nonetheless.
So I went ahead and started adding them, with a quick glance the publisher guidelines. Too quick, as it turns out. A month after submitting my application, their "QA" process lets me know my application is not going to be accepted because it's not signed. Uh... yeah? Couldn't you have simply run a script on the file I uploaded to tell me the same damn thing? It's not exactly as if you have to have a human look at the file with a hex editor to determine whether it's signed or not. My phone can tell, of course - presumably Nokia ought to be able to figure it out programmatically and let me know? Sure, I should have read their big, long document prior to starting, but come on, it would have saved everyone time if their software had simply informed me that my application, being unsigned, was not ok. Now, when it comes to signing, Java ME is pretty much the worst in the business, although Apple is giving them a run for their money. At least Apple does it to make the applications good for their users (for their definition of good).

• Java ME: Ovi suggests using http://javaverified.com/ - where it costs $200 to sign up, and then something like at least 75 euros to run an application through *their* whole process. For each version. The hell with that!
• Android: you have to pay $25 to get access to the marketplace, but can self-sign applications. For free. Put that in your pipe and smoke it, Nokia & Larry.
• BlackBerry: I was sure this one was going to be expensive and painful given that BB is mostly aimed at big companies that could certainly spare the money. It's not: $20 gets you a certificate that you can sign everything you want with, and it's pretty quick and painless to get it. This is how Nokia ought to be doing things in terms of signing applications.
• Apple: $100 gets you the dev kit and then you can submit your apps to the somewhat bureaucratic and slow apple approval process. Plus you have to own a mac to develop on, if you don't already have one. But still, only $100 a year, and you can do as many apps as you want.

So there you have it, Java ME involves more fees than the other ones, and is probably as slow and bureaucratic to boot. I'm not going to find out, though, this pretty much concludes my experiment with ovi.com - there's no way I'm going to spend all that money on a little fun application that I'd only sell for a few euros. Being a fan of open source and openness in general, my next phone will certainly be Android based. I think someone at Nokia probably realizes things are broken: they appear to be working on a way to make it not cost anything to sign Symbian apps. But I don't have a Symbian app, so that's pretty useless for me. Oh, and while I'm bitching about their whole process, their publisher interface was down all of last weekend in order to "add a new set of metadata which will improve the Ovi Store user experience". It took a whole weekend of downtime to add that?
Furthermore, I signed up for Ovi as soon as it came out - I was going to push Hecl to it (but didn't bother at the time) but now it appears they want 50 euros from you just to sign up. Here's a hint: save your money.

Over the past few years I've amassed a collection of a few thousand images taken with a succession of digital cameras. I'm pretty good at organising images, in a directory hierarchy which makes sense to me, in a few simple and broad categories:

skx@birthday:~$ tree -L 1 ~/Images/
/home/skx/Images/
 -- Misc
 -- Parties
 -- People
 -- Pets & Animals
 -- Travel

Beneath ~/Images/People, for example, I have subdirectories for specific individuals (or a "Debian/" folder for Debian-people who've been snapped but don't warrant their own folder.) ~/Images/Travel has things like Travel/Local/2010, Travel/Vienna/2008, etc. In summary I have images of people, places, and things stored beneath what should be a reasonably discoverable directory hierarchy, however this just doesn't work. I still struggle to find images - for example images of myself might be located in ~/Images/People/Self/*, but in practise I'm often included in ~/Images/Travel/* as well. A few times I've looked at using f-spot, digikam, and similar tools to perform image-organisation (but not editing, or timelines, or anything else. Just organisation). I've found I didn't like being locked into their formats, didn't want them to copy my images to a second location, and other gripes. In the end I've forced myself to come up with a Steve-Specific-Solution. Not for the first time, but I think I have just cause... I'm now using the User-Comment field in the image's EXIF data to store tags. (When it comes to EXIF data I keep camera-generated fields, but sometimes update/set "Copyright", "Comment", and "Title" fields. So UserComment is one I've never used until now, and thus I run no risk of trashing existing meta-data.) I've put together a simple perl script, called itag, which will:

• Index the tag information from all images beneath ~/Images into a DBM file.
• Show the filenames of all images matching a tag, or tags.
• Allow me to add tag(s) to an image (which both updates the EXIF data and updates the DBM "cache").

This is enough for me to be able to see all images of "Edinburgh", via:

~$ qiv --fullscreen --slide --delay 5 $(itag --search=edinburgh)

Similarly I could find myself:

~$ itag --search=steve --search=people

I'm not sure it is useful to others, mostly on the basis that people probably fall into their own routine when it comes to filing, and I suspect that people with vast collections of images will just get annoyed by the obscenely slow indexing process I've got. (Hint: run "exiftool" on every /.jpe?g$/i file..) Still its a simple enough idea and I think it should scale in the future - I can even see myself writing a wee GUI to do tag exploration and similar. Just not today. ObFilm:Aeon Flux ObRandom: Apologies for people waiting on email - it's been that kind of week.

on the interaction of FOSS communities with EU research projects The 7th Framework Programme (or FP7) is a well-known European program to fund research projects and promote the creation of the European Research Area. For some European countries, FP7-funded projects are so important that they can make the difference between an institution that has the resources to pursue its research & teaching activities and an institution that doesn't, which will then have hard time surviving. As part of FP7 and its previous editions, the European Commission (EC) has been funding research into FOSS for a while now, with different degrees of "FOSS-involvement". Some projects routinely use FOSS products, some fund the development of relevant FOSS projects (e.g. PyPy), some try to address shortcomings of specific communities (e.g. EDOS and Mancoosi, on which you surely are aware of my bias ...), some others try to remove barriers to FOSS adoption in various contexts (e.g. FLOSSinclude). A nice overview of EU-funded FOSS projects is available as a leaflet. As with all project funding initiatives: having a project funded does not mean it will be successfully. By analogy: the fact that the project (proposal) mentions FOSS does not mean it will be successful in interacting with FOSS communities. Luckily, the EC is well aware of existing difficulties and is now seeking input from FOSS communities to understand how to better interact with them, from the standpoint of FP7 research projects. That is why last week I've joined, upon invitation and as a Debian representative, a meeting at the EC in Brussels on the above topics. At the table we were about a dozen people, including representatives of ongoing research projects (both from academia and large industries), EC commissioners, ... and Debian (i.e. yours truly). Beside joining the brainstorming, what I've brought to the table are some thoughts on best and worst practices on the interaction between research projects and FOSS communities, answering to some working questions. There is probably little to see in the slides for people belonging to FOSS communities, as all suggestions would seem fairly obvious (e.g.: do not invent/use yet another FOSS license, do not jail people into specific forges, do not expect people to work at your place, etc.). Still, I assure you that most of them were not obvious for EC commissioners and that they have been very much interested in hearing Debian feedback, which is perceived has having no other interest than serving Free Software. I'm personally very proud of the fact that Debian was there, as a purely community-driven project run by volunteers, whose opinion is clearly valued by an important program as FP7 is. Various possible next steps have been discussed: from drafting guidelines that will help reviewers in evaluating the commitment of project proposals to FOSS communities, to create a scenario-based license chooser based on the needs of FP7 projects. While I did not volunteer to take part in all such initiatives, I'll keep you posted of advancements.

I ve been watching the June budget and pondering its effects on me, our co-op, co-ops in general and the wider community.

IT Taxes

I just want to flag this one up as a special interest: the telephone tax is killed off before it starts. Yippee! But now we get to wait and see how the government will support private investment to get universal provision of fast broadband. I ve no problem with tax relief for the video games industry being scrapped - why should any type of software get special treatment?

VAT up 2.5% to 20% from 4 January 2011

This seems bad for everyone. It s a bit less bad for our co-op because we have some international suppliers, whose sales tax rates won t change, but we buy a lot from the UK too and it hurts all our workers.

Personal Taxes

The basic income tax allowance rise of 1,000 is welcome, as is restoring the pension-earnings links. More widely, the freezes in various things, increase in Capital Gains Tax and drop in cider tax all seem broadly good ideas. The housing benefit 400 maximum is a bit mixed - how bad it is may depend how lenders react when borrowers get into difficulty.

Business Taxes

At a time when a VAT increase is called unavoidable , it stinks a bit to cut corporation tax, extend the 10% capital gains tax allowance and raise the employers National Insurance threshold. Of course, our co-op pays none of those, so it also hurts us by giving our competitors an advantage.

Business Incentives

George Osborne said he wants to tackle regional economic differences, but the big change in this budget is bad for all existing businesses outside London, the South-East and East: National Insurance exemptions for new businesses. Once again, existing co-ops take it in the neck from another government obsessed with capitalism and employment instead of businesses and work. Meanwhile, increasing the Enterprise Finance Guarantee props up debt-laden business and a new Growth Capital Fund encourages capitalist businesses, while both appear useless to good co-ops at first glance. I don t mind being ignored, but could we please elect a government which doesn t actively hinder co-ops? Where s the fabled commitment to fairness ? Promises around the Green Investment Bank and Green Deal sound good, but are in the future.

Council Tax

Council Tax will be frozen for a year. I wonder if that applies to parish councils, because our village planned a cut after a one-year project-based increase last year. The Budget Document has pretty much no detail.

So, how was it for you? Have I missed some friendly changes?

First of all, THANKS Rhonda for pushing me to do that! I did plan to integrate the Debian menubar for a long time, but it never made it high enough on my todo lists up to now.

So, what am i talking about? For those of you who don't follow debian-www@l.d.o too closely, there was a recent thread about debian.org's page layout, where Rhonda pointed the initial poster to the layout proposals from Kalle S dermann. Rhonda was so kind and mainly documented in the recent blog post how to convert the gitweb theme to that layout.

I took that documentation and sat down Friday evening and converted the layout of my local instance of the DSA internal wiki to that new layout. While not everything looks perfect yet, it took me less than an hour. WOW, that was fast.

Now i became megalomaniac. After copying over the current list archive to an other machine (to not destroy the current archive while playing with mhonarc), I started playing with the same layout for lists.debian.org. The whole scripts for lists.debian.org were a bit more complex than the ikiwiki code we use for dsa.debian.org, but i managed to render usefull pages yesterday early morning.

Not everything was easyly convertable, and I still have some smaller issues to work on, but if you compare for example the following posting using the old and the new layout, i think we can use my work as basis for further improvements of the layout. Eg. i am aware that the new HTML code does not fullly validate using the w3c validator.

Many thanks also go to Kalle, who responded to my problems with the CSS immediatly.

Not all lists are converted to the new layout yet, as a full list archive rebuild seems to run about 24 hours. Also i adjusted some minor stuff in the templates while the rebuild was running, so you will see some smaller differences in the breadcrumbs. That will go away when I start the next rebuild.

So what is next? Rhonda, do we want to see if we can take over qa.d.o? ;-)

PS: if someone wants to generate new icons for the thread view arrows, i am happy to integrate them.

From 2nd to 4th of July 2010 the FAI developer workshop will take place at the Linuxhotel in Essen/Germany. FAI? FAI is the abbreviation for Fully Automatic Installation. It s a non-interactive system to install, customize and manage Linux systems and software configurations on computers as well as virtual machines and chroot environments, from small networks to large-scale infrastructures and clusters. As the name states the workshop is targeted towards FAI developers. We the FAI developers want to get FAI into shape for squeeze, discuss pending issues like Ubuntu packaging, release management and of course meet in real life for networking and socializing. Our rough roadmap for the FAI weekend looks like this: Friday:

• Setup of the network
• Introduction round, hello to everybody
• Define things that need to be worked on with high priority for the squeeze release
• Start of work

Saturday:

• Work on things for squeeze release
• Discussion: Features for squeeze
• Read access from /dev/beer

Sunday:

• Work on things for squeeze release
• Final round: What did we manage to do this weekend

Further details are available in the FAI wiki at http://faiwiki.informatik.uni-koeln.de/index.php/DeveloperWorkshopJuly2010. The meeting wouldn t be possible without sponsors so special thanks to:

• Debian
• Linuxhotel
• Netways
• Spotify

If you are interested in sponsoring the FAI Developer Workshop as well please contact FAI lead developer Thomas Lange.

Linode has just announced a significant increase in the amount of RAM in each of their plans [1]. The last time I compared virtual hosting prices in a serious manner was over two years ago [2], so it seems like a good time to compare the prices again. Now there are some differences between these providers that make things difficult to compare. Gandi used to not include the OS in the disk allocation presumably they did de-duplication, I m not sure if they still do that. OpenVZ/Virtuozzo and Xen can t be directly compared. OpenVZ is an Operating System Level Virtualisation that allows virtual machines to share resources to some extent which should allow better overall utilisation of the system but may allow someone to hog more resources than they deserve I prefer virtual machines so tend to avoid that. Virtuozzo is a technology I m not familiar with so with all things being equal I would choose Xen because I know it better. Years ago Vpsland deleted one of my DomUs without good notification and without keeping a backup and I m not about to forgive them. XenEurope and Gandi get good reviews, but I have no personal experience with them so in my personal ranking they are below Linode and Slicehost. RapidXen offers native IPv6 a very noteworthy feature. But they are quite expensive. Note that I have only included providers that advertise in English. I could use Google translation to place an order on a non-English web site but I am not going to risk a situation where Google translation is needed for technical support. In the price comparison tables I have used $US for price comparisons, where the price was advertised in another currency I put the $US price in brackets. For every provider that doesn t advertise prices in $US I used XE.com to get a spot price. Note that if you convert between currencies you will not get that rate, I used the spot rate because most of my readers don t use the $US as their native currency (either due to living in a country that uses it or having business interests based on the $US) converting from $AU to $US has about the same overhead for me as converting to the Euro or pound. The bandwidth is listed as either a number of Gigabytes per month that can be transferred or as a number of Megabits per second that the connection may use. I have tried to roughly order the offerings based on how good they seem to be. But as there are so many factors to consider it s quite obvious that no provider can be considered to be universally better than the others. The biggest surprise for me was how well Xen Europe compares to the others. Last time I did the comparison they were not nearly as competitive. Finally note that I am comparing the options for low-end servers. These are services that are useful for hobbyist use and low-end servers for commercial use. Some providers such as Xen Europe exclude themselves from consideration for serious commercial use by not offering big servers Xen Europe only supports up to 1GB of RAM. Prices of Xen virtual servers:

ISP	RAM	Disk	Bandwidth	Price
XenEurope	128M	10G	1TB	E5 ($6.15)
XenEurope	512M	30G	1TB	E17.50 ($21.52)
Linode	512M	16G	200GB	$20
RackVM	128M	10G	100GB	#4UK ($5.90)
RackVM	512M	30G	300GB	#16UK ($23.62)
Slicehost	256M	10G	150GB	$20
Slicehost	512M	20G	300GB	$38
Gandi	256M	8G	5Mb/s	$16
Gandi	512M	16G	10Mb/s	$32
RapidXen	256M	20G	2Mb/s	$20
RapidXen	512M	20G	2Mb/s	$30
Rimuhosting	160M	4G	30GB	$20
Rimuhosting	400M	8G	150GB	$30

Prices of non-Xen virtualisation systems:

ISP	Virtualisation	RAM	Disk	Bandwidth	Price
Quantact	OpenVZ	256M	15G	300GB	$15
Quantact	OpenVZ	512M	35G	600GB	$35
FreeVPS	VMWare	256M	10G	100GB	#10UK ($14.76)
FreeVPS	VMWare	512M	20G	200GB	#15UK ($22.14)
Vpsland	Virtuozzo	512M	10G	250GB	$20
Vpsland	Virtuozzo	1024M	20G	500GB	$35

Update: Added RackVM to the listing, and removed the ambiguous part about Gandi disk allocation.

• [1] http://blog.linode.com/2010/06/16/linode-turns-7-big-ram-increase/
• [2] http://etbe.coker.com.au/2008/05/28/xen-hosting/

This is the obligatory Hello world post. I m a developer both in Ubuntu and Debian. In Debian most of my work has been in the Python world where I co-maintain python-defaults and python3 defaults as well as several modules, extensions, and applications. I ve been contributing to Debian development for about 3 years now and recently became a DD.
Just so this post won t be completely free of technical content
Most of you will have heard that Python 2.6 is now the default in Sid. Once this transition is complete and migrated, the Python system that s planned for Squeeze will be in place (I know this is a topic that is very dear to some people, but I don t care to discuss the history of it in my blog and won t approve comments in that direction).
Of more technical interest, I think, is that the core system around Python 3 is starting to appear. The current version of Debian Python Policy begins to address Python 3 issues for the first time and we now have a supported and default Python 3. There is more work coming between now and freeze time to more completely define how the Debian Python 3 system should work. While many upstreams don t support Python 3 yet, we want to provide a solution that makes it easy for maintainers to provide Python 3 packages where they do.

Hello You may have noticed a drop in my activity lately. This is not due to reduced interest in contributing to Debian and Perl. This comes from personal changes: we ve bought a house recently and I m spending most of my free time renovating the house (revamping electric circuits, installing new ones, preparing for internet cables, wall paper, paints, etc etc ) and preparing to move at the end of the week. Starting from next month, I expect to be able to slowly resume a normal schedule. The top priority will be GSoC mentoring (hi random_nick ) Now, it s time to go back packing stuff All the best

Having invested in some introspection into my reading habits, I made up my mind to dial down my consumption of bite-sized nuggets of online information, and finish a few books. That s where my bottleneck has been for the past year or so. Not in selecting books, not in acquiring books, and not in starting books either. I identify promising books, I buy them, I start reading them, and at some point, I put them down and never pick them back up again. Until now. Over the weekend, I finished two books. I started reading both in 2009, and they each required my sustained attention for a period measured in hours in order to finish them. Taking a tip from Dustin, I decided to try alternating between fiction and non-fiction. Jitterbug Perfume by Tom Robbins This was the first book I had read by Tom Robbins, and I am in no hurry to read any more. It certainly wasn t without merit: its themes were clever and artfully interwoven, and the prose elicited a silent chuckle now and again. It was mainly the characters which failed to earn my devotion. They spoke and behaved in ways I found awkward at best, and problematic at worst. Race, gender, sexuality and culture each endured some abuse on the wrong end of a pervasive white male heteronormative American gaze. I really wanted to like Priscilla, who showed early promise as a smart, self-reliant individual, whose haplessness was balanced by a strong will and sense of adventure. Unfortunately, by the later chapters, she was revealed as yet another vacant vessel yearning to be filled by a man. She s even the steward of a symbolic, nearly empty perfume bottle throughout the book. Yes, really. Managing Humans by Michael Lopp Of the books I ve read on management, this one is perhaps the most outrageously reductionist. Many management books are like this, to a degree. They take the impossibly complex problem domain of getting people to work together, break it down into manageable problems with tidy labels, and prescribe methods for solving them (which are hopefully appropriate for at least some of the reader s circumstances). Managing Humans takes this approach to a new level, drawing neat boxes around such gestalts as companies, roles, teams and people, and assigning them Proper Nouns. Many of these bear a similarity to concepts which have been defined, used and tested elsewhere, such as psychological types, but the text makes no effort to link them to his own. Despite being a self-described collection of tales , it s structured like a textbook, ostensibly imparting nuggets of managerial wisdom acquired through lessons learned in the Real World (so pay attention!). However, as far as I can tell, the author s experience is limited to a string of companies of a very specific type: Silicon Valley software startups in the dot com era. Lopp (also known as Rands) does have substantial insight into this problem domain, though, and does an entertaining job of illustrating the patterns which have worked for him. If you can disregard the oracular tone, grit your teeth through the gender stereotyping, and add an implicit preface that this is (sometimes highly) context-sensitive advice, this book can be appreciated for what it actually is: a coherent, witty and thorough exposition of how one particular manager does their job. I got some good ideas out of this book, and would recommend it to someone working in certain circumstances, but as with Robbins, I m not planning to track down further work by the same author.

(This is partly a repost of material I've posted to bug reports and to debian-release, put together with some more detail for a wider audience.) You could be forgiven for looking at the RC bug activity on grub2 over the last couple of days and thinking that it's all gone to hell in a handbasket with recent uploads. In fact, aside from an interesting case which turned out to be due to botched handling of the GRUB Legacy to GRUB 2 chainloading setup (which prompted me to fix three other RC bugs along the way), all the recent problems people have been having have been duplicates of one of these bugs which have existed essentially forever:

• #554790 - grub-pc/install_devices uses unstable device names
• #583271 - device.map uses unstable device names

When GRUB boots, its boot sector first loads its "core image", which is usually embedded in the gap between the boot sector and the first partition on the same disk as the boot sector. This core image then figures out where to find /boot/grub, and loads grub.cfg from it as well as more GRUB modules. The thing that tends to go wrong here is that the core image must be from the same version of GRUB as any modules it loads. /boot/grub/*.mod are updated only by grub-install, so this normally works OK. However, for various reasons (deliberate or accidental) some people install GRUB to multiple disks. In this case, grub-install might update /boot/grub/*.mod along with the core image on one disk, but your BIOS might actually be booting from a different disk. The effect of this will be that you'll have an old core image and new modules, which will probably blow up in any number of possible ways. Quite often, this problem lies dormant for a while because GRUB happens not to change in a way that causes incompatibility between the core image and modules, but then we get massive spikes of bug reports any time the interface does change. Since these bugs sometimes bite people upgrading from testing to unstable, they get interpreted as regressions from the version in testing even though that isn't strictly true (but it tends not to be very productive to argue this line; after all, people's computers suddenly don't boot!). Any problem that causes the core image to be installed to a disk other than the one actually being booted from, or not to be installed at all, will show up this way sooner or later. On 2010-06-10, there was a substantial upstream change to the handling of list iterators (to reduce core image size and make code clearer and faster) which introduced an incompatibility between old core images and newer modules. This caused a bunch of dormant problems to flare up again, and so there was a flood of reports of booting problems with 1.98+20100614-1 and newer, often described as "the unaligned pointer bug" due to how it happened to manifest this time round. In previous cases, GRUB reported undefined symbols on boot, but it's all essentially the same problem even though there are different symptoms. The confusing bit when handling bug reports is that not only are there different symptoms with the same cause, but there are also multiple causes for the same symptom! This takes a certain amount of untangling, especially when lots of people have thought "ooh, that bug looks a bit like mine" and jumped in with their own comments. Working through this was a worthwhile exercise, as it came up with an entirely new cause for a problem I thought was fairly well-understood (thanks to debugging assistance from Sedat Dilek). If you had set up GRUB 2 to be automatically chainloaded from GRUB Legacy (which happens automatically on upgrade from the latter to the former), never got round to running upgrade-from-grub-legacy once you confirmed it worked, and then later ran grub-install by hand for one reason or another, then the core image you installed by hand would never be updated and would eventually fall over the next time the core/modules interface changed. Fixing future cases of this was easy enough, but fixing existing cases involved figuring out how to detect whether an installed GRUB boot sector came from GRUB Legacy or GRUB 2, which isn't as easy as you might think. Fortunately, it turns out that there are a limited number of jump offsets that have ever been used in the second byte of the boot sector, and none of the GRUB 2 values clash with the only value ever used in GRUB Legacy; so, if you still have /boot/grub/stage2 et al on upgrade, we scan all disks for a GRUB 2 boot sector, and if we find one then we offer to complete the upgrade to GRUB 2. Unless anything new shows up, that just leaves the problems that were already understood. Today, I posted a patch to generate stable device names in device.map by default. If this is accepted, then we can do something or other to fix up device.map on upgrade, switch over to /dev/disk/by-id names in grub-pc/install_devices at the same time, and that should take care of the vast majority of this kind of upgrade bug. I think at that point it should be feasible to get a new version into testing, and we should be down from 18 RC bugs towards the end of last month to around 6. We can then start attacking things like the lack of support for mdadm 1.x metadata. Since my last blog entry on GRUB 2, improvements have included:

• Substantial work on info grub, with, among other things, new sections on /etc/default/grub and on configuring authentication.
• A workaround for GRUB's inability to probe dm-crypt devices, thanks to Marc Haber.
• Several build fixes for architectures I wasn't testing, and a fix for broken nested partition handling on Debian GNU/kFreeBSD. I'm now testing GNU/kFreeBSD locally.
• Rather less cruft in fs.lst, partmap.lst, and video.lst, which should speed up booting a bit by e.g. avoiding unnecessary filesystem probing.
• upgrade-from-grub-legacy actually now installs GRUB 2 to the boot sector (!).
• Ask for confirmation if grub-pc/install_devices is left empty.

The next upstream snapshot will bring several improvements to EFI video support, mainly thanks to Vladimir Serbinenko. I've been working on making grub-install actually work on UEFI systems as one of my goals for the next Ubuntu release, and I hope to get this landed in the not-too-distant future.

How to have a (Debian) summit without turning into a secret cabal It seems rather uncontroversial that sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.) is a good way to spend, actually invest, Debian money. Historically, that has not always saved the Debian community from muttering about "cabal-ish" meetings in very few specific occasions. (No, there is no cabal, in case you wonder.) I've always believed in the good faith of people and I don't think that we have ever had "secret meetings" on purpose. Nevertheless the question of how to have meetings in a community-compatible way is a sound one. Answering properly to such a question is something that it's harder than what it might seem at first sight (at least for me). In particular, organizers have to carefully balance the high efficiency that meetings offer (e.g.: communication bandwidth is higher than when working remotely, people have less distractions, more enthusiasm, more fun!, etc.) with the risk of cutting out the rest of the community which cannot attend the meeting, for whatever reason. Note also that since Debian is not a company, we cannot just require that everybody who is interested attend the meeting. As DPL, I'm starting to get quite some requests for meeting sponsorship, and that's just wonderful: it means that we have thrilling groups of people that are eager to get together and hack to improve Debian! Still, in doing so, we should all try to minimize the above risk; that's why I've started to apply the following Debian meeting guidelines, as a kind of prerequisite for sponsoring.

1. Before the meeting: the meeting should be announced to the most relevant public mailing list(s); ideally, the tentative agenda of the meeting should be included in the announcement.
   That will enable people interested in the meeting topics to provide their inputs and more generally to know what is going on.
2. During the meeting (preparation): expenses should be minimized, as a form of respect for all people that donate to Debian. Since we value their contributions, we do our best not to waste them. (TTBOMK, we've always done that, but making it explicit won't hurt.)
3. After the meeting: meeting minutes should be sent to the most relevant public mailing list(s), usually to d-d-a for meetings that cover topics of general development interest.
   As an obvious consequence, minutes should be taken during the meeting; it is a bit of extra burden, but the risk of leaving the rest of the community in the dark is just not acceptable a community as wide and diverse as ours.
4. In general, think about communication, e.g.: (micro)blog about the meeting, contact press/-publicity to prepare a news item about it, enable others to attend virtually on IRC or other media, etc.

For now, the above is just a brain dump.
Now, what do you think? Are the above reasonable demands? What else should we ask for?
Feel free to leave a comment or mail me about that.

Father's Day in the US has always been a weird one for me. I've been pottering through the day oblivious, when a friend who is a father will tell me that they've been thinking of me especially today because of our loss. Then I'm reminded that Father's Day is in June and not September. I wonder what the deal is with that? It seems very few countries observe it on the first Sunday in September. Weird. Zoe hits the 7 week mark tomorrow, and I return to work. Boy is that going to be a shock to the system for all of us. The 7 weeks of paternity leave has been absolutely wonderful. Google's Paternity Leave benefit is now firmly my number one favourite employee benefit. Co-workers had complained that taking it all at birth was a bit of a waste, because all the baby does is sleep, but it's definitely been worthwhile taking it all now. Because we've been predominantly bottle feeding with pumped breast milk, I've been able to be very involved with the feeding, and I've been able to do a lot of the running around helping Sarah, so I wouldn't have done it any other way. It's also been great to watch Zoe grow and develop. She's interactive enough at this age, and it's just great to cuddle with her, or share a nap with her. On the sleeping front, things are a bit all over the place. She definitely gets fussy in the evenings, at around 5pm to 7pm. Often we have trouble getting her to go back to sleep after a feeding around this time. Sometimes the trouble can extend past the 10pm to midnight feeding. She sleeps magnificently during the day, and travels fairly well. She sleeps quite well in her car seat, and stays asleep in it when we're at a cafe or restaurant. We had our first overnight trip while Sarah's Mum was visiting. We went down to San Simeon to take her to Hearst Castle. It was fun having Zoe in a hotel room with us. Whenever she fussed during the night, we'd just grab her and bring her into bed with us. She spent quite a lot of time in our bed asleep on our chests. It was very sweet. It was like a little baby vacation. Zoe also had her first outing to the California Academy of Sciences, and we managed to spend about 5 hours there without any major meltdowns from anybody. It was absolutely fantastic having Sarah's Mum here for 4 weeks too. She's great to have around. She was a big help in cleaning up the back yard significantly, and generally helping out around the house. It was great having her take care of the 7am feeding when Sarah and I were both zonked out from overnight interruptions. It was also nice not to have to think so much about how dinner was going to materialise. My parents have decided they will come and visit in September, which is excellent, as they won't have to wait until February to meet Zoe. One of the other nice things about the Google Paternity Leave is that you keep accruing vacation time while you're on it, so I should have enough vacation time to take a couple of weeks off while they're here, as well as in February when we go back to Australia for Sarah's residential school at the University. The next big event will be Zoe's vaccinations at 8 weeks. Hopefully that will be as uneventful as possible.

Turns out that the football is insufficiently engaging to distract me from picking up the laptop, but sufficiently noisy that I don't get time to think about more complex problems (leave those for weekday evenings), so weekends seem to offer a brief window to relax and do some QA/RC uploads.

As we're not yet in freeze, I'm not doing 0-day NMU's (although I am offering 7 day NMU's), but QA uploads can all be 0-day. Overall, it's proving to be quite useful and a lot easier than sponsoring NEW packages.

So far, RC uploads:

• 572464: ceferino


• 572470: gregorio

RC offers:

• 582422 : bacula


• 579378 :dibbler

QA uploads:

• gnome-pilot


• gnome-pilot-conduits


• rezound


• filerunner


• cdcover

Didn't think I'd get time to stuff like that with Squeeze.