16 September 2009

[So much for at-least-one-post-a-week : I'm now back online, courtesy of a new router]. In the this week is another announcement from the CoRoT group: CoRoT-7 is the first star (outside our own) known to host two Super-Earths. Two planets of 1.6 and (max.) 21 times Earths' mass, and the smaller one at least is rocky (the outer planet has not been seen in transit, so we can't tell yet). Its not the first Earth-sized planets to be discovered: as my supervisor points out, <http:>PSR 1257+12 holds that record, as well as the one for the first exoplanet to be found. As usual, Exoplanet.eu gives the details: CoRoT-7b has a flurry of papers to its credit already. CoRoT-7b transits its star and is the first Super-Earth with a clear radius measurement. Together with a mass calculated from a radial-velocity measurement by the HARPS spectrometer, they calculate a density of 5.5 g/cm3, and so its shown to be a rocky world. CsoRoT is a hot A-class star, and CoRoT-7b orbits only 2.5 million km from it. Because of this, it is unlikely that it has retained an atmosphere (it'll be way too hot), and is expected to be tidally locked: with one face permanently pointing at the star, one in permanent darkness, the two sides will be both too hot and too cold for life. (Is there a Goldilocks, twilight zone? unlikely: the tidal forces will be too high, and with no atmosphere to moderate matters, there can be little hope for life). Still, while it may not support life, it could help answer important questions, such as how many terrestrial planets are there out there. Most of the planets discovered to date have been gas giants, which are easier to discover. But are there lots of rocky planets hiding between the giants ? One way of answering this might involve the disks from which the planets evolved. One trend we've seen is that (gas giant) planets are more likely to be found around stars with high metallicity (astronomers are strange in calling all elements heavier than helium a metal). But our Sun is strange in being comparatively depleted in 'refractory' elements such as iron or silicon. Is this important for the story of terrestrial planets? Melenendez et al. have a paper on arxiv.org on this topic. They find that most stars similar to our sun found not to have giant planets have elemental abundances similar to our Sun: perhaps they have undiscovered rocky planets instead ? Tags astronomy, exoplanets, planet-of-the-week

Yay! I've done it: 1160 lines of bash script are now 1215 lines of perl, and:

    'debtree aptitude': 1m2.832s -> 0m0.596s

The new release is available as version 0.9.9 from the debtree web site and has been uploaded for the archive as version 1.0.

---

This was the starting position, the run time for my complete test set:

    real    22m33.583s
    user    18m29.709s
    sys     4m21.320s

I began with a pure language conversion from bash to perl, i.e. I kept the call-outs to dctrl-tools. This allowed me to easily identify problems in the language conversion by running my test suite, without having to worry that a change might have been caused by getting different data. The language conversion itself was fairly straightforward; most time was spent on finding all the little errors made during the conversion. This resulted in "only" a 10% speedup:

    real    20m56.368s
    user    18m3.996s
    sys     2m46.986s

So bash itself isn't even horribly slower than perl, even with all the recursion and starting of subshells for calls to grep, sed, etc. Then I replaced the call-outs to dctrl-tools one by one, adding the dependency on libapt-pkg-perl. And that resulted in the amazing:

    real    0m21.350s
    user    0m19.797s
    sys     0m1.372s

So, from 22 minutes to 21 seconds for 22 graphs, including some pretty complex ones. Not bad. I had to keep a call-out to dctrl-tools for build dependencies as it turned out libapt-pkg-perl does not expose architecture conditions. The full conversion process can be seen in the source repository, which was recently moved from my $HOME on alioth to collab-maint.

Email on a desktop Unix system is apparently a hard topic. At least, so far nobody seems to have solved it to my satisfaction... That's where the Pony Express comes in: a sensible /usr/bin/sendmail implementation for desktop sysstems:

• No queue, no running processes.
• pass users' email to a mail hub
• support per user outgoing mail hub and SMTP authentication + TLS.
• still allow local mail delivery, so stuff like cron will deliver to local mailboxes.

Mercurial repository is available; Pony Express is written in Python 3. I'll not upload a Debian package right now since as far as I've seen Python 3 is not supported by the usual Python helper scripts. Status: Lots of missing features and probably lots of bugs, but I use it from kmail to deliver mail, and the commandline "mail" also works. But that's the extent of the testing it has received so far, and in addition it's also one of the first things I've ever done in Python, so consider yourself warned. Still, feedback and patches welcome. Update: Daniel, no, I can't. I missed msmtp when I looked for a solution after I saw that nullmailer and ssmtp wouldn't do what I wanted. Update: cate / simon: my apt-cache search skills obviously suck, I didn't find esmtp either. Oh, well... I wanted to learn Python anyway, and since Pony Express is basically a frontend to Python's smtp library, it was not that much work. lamson sounds interesting for other projects, I'll have to look at it. From the description it's not what I want here, though. Marius: kmail does its own queueing, so I usually use the send later option and send non-local email from the commandline only while connected. I'll have to think about a non-daemon, non-cron queue style that suits my need (event-triggered from if-up.d perhaps), but as soon as I start to accept mail that I can't immediately get out of the system complexity goes up quite a bit. Developing PX into a full MTA would still be a fun project and I've got a few other ideas that I could incorporate. Not tonight, though ;-)

Trying to associate with 00:1c:58:10:1d:30 (SSID='ALMAWIFI' freq=2417 MHz)

Associated with 00:1c:58:10:15:b0

                ^^^^^^^^^^^^^^^^^ WTF?

In other words, my broadcom card won't let me choose the access point to connect to, instead the driver picks one for you (my guess: the one with the best signal) except that autentication on that AP doesn't work.
I'm fine with machines trying by default to be smarter than me, I'm less fine when there's no way to convince said machine to do something supposedly not smart.

Hot from the oven: FusionForge 4.7 was just released. The release notes follow. If you have local enhancements based on a previous version of GForge, now is the time to port them to the 4.7 codebase and submit them, so they can be merged in time for the next version! Release notes for FusionForge 4.7 This is the first public release of FusionForge. FusionForge is based on GForge, and started as an identical copy, with only a name change to avoid confusion with the proprietary versions of GForge (known as GForge Advanced Server or GForge AS). As such, it benefits from mature code and known-good infrastructure, and builds on it for the future. This 4.7 release is focused on bringing the recent evolutions out to the community in an official stable release. This should provide a solid base as a starting point for community-based development, making it easier for enhancements to be maintained. The FusionForge name was chosen to reflect this: this is a community effort, and we hope to hear about your improvements. Contributing these improvements would make their future long-term maintenance easier for everyone. Major changes since previous versions (of GForge) include:

• Support for PHP5.
• Support for PostgreSQL 8.x.
• Translations are now managed by gettext.
• Support for several configurations running on the same code.
• Improved security, no need for PHP register_globals.
• Available as full install CD.
• New wiki plugins (using MediaWiki or phpWiki).
• New online_help plugin.
• New phpwebcalendar plugin.
• New project hierarchy plugin.

Things to keep in mind when installing:

• FusionForge is based on GForge, and the renaming is quite recent. So the code still contains lots of references to GForge. This will be fixed as time passes.
• Full text search using the primitives provided by PostgreSQL 8.3 isn't quite complete yet.
• Not all plugins are packaged for all distributions yet.

Things to keep in mind when upgrading:

• Since internationalisation was changed from a hand-made system to standard gettext, locally customised translations will no longer override standard ones. This will be addressed in a future release.

For more up-to-date information, please visit http://fusionforge.org/ or http://fusionforge.fusionforge.org/ -- you can even join us on IRC from there! -- The FusionForge development team

It's been too long since the last blog post about FusionForge, but we haven't sat on our hands and lots of things happened. This is a brief summary:

• About 900 commits in total over the trunk and the two currently active branches.
• Three minor bugfix versions were released, and the currently stable version is 4.7.3.
• A branch has been started to stabilise the code in prevision for the upcoming 4.8 release. Two release candidates have been published already, the final version should happen in the coming weeks.
• Feature-wise, 4.8 will add a tag cloud for project classification, better reporting for downloads, and a new version of the phpwiki plugin. It will also include the beginnings of an automated test suite.
• 4.7.3 is in Debian unstable, 4.7.2 in testing, 4.8rc1 is in experimental. Don't be fooled by the packages still being called gforge, it's just that they haven't been renamed to fusionforge yet.

Not bad for a start, eh? But we've also kept true to our promise and started merging lots of things from various local branches and patches. Among what's been committed to trunk so far are the following features, coming from various existing or upcoming instances of GForge/FusionForge.

• A script for migrating data from an existing GForge AS instance to FusionForge. It's not a turn-key solution, and it requires some manual intervention for working, but it does most of the job.
• New extratabs plugin, allowing project administrators to define new tabs for their projects, pointing at arbitrary URLs.
• New projectlabels plugin, allowing site administrators to define labels as chunks of arbitrary HTML and stick that HTML onto some projects (useful for "project of the month" stuff).
• Refreshed globalsearch plugin, allowing cross-forge project searches.
• Command-line data injectors to populate a FusionForge database with data coming from another system.
• A more consistent automated self-test suite using Selenium.

Other great things are afoot, and they'll be described here in due time.

Quick heads-up about FusionForge. The main news of course is that 4.8 has been released upstream (and uploaded to Debian experimental). We'll keep fixing major bugs on that branch of course, but our focus is now on trunk. We're finding it tedious to deal with legacy code, so one of the goals we have now is to clean up the codebase to bring it more in line with good practice. That's going to take some time, though, because there's lots of code. Some of that code, however, seems unused (it's been broken for some time without anyone complaining), so it's likely that we'll deprecate and/or remove bits of code unless someone steps forward to maintain it (or at least bring it into shape). In particular, we're looking at the MySQL support (which hasn't been maintained for years) and some of the old visual themes which are going to require some work to keep working with some changes we're planning in the way the pages are displayed. This should make maintenance easier for the implementation or integration of new features down the line. Which will be the subject of a future post, when a currently undercover French Forge Cabal actually starts producing concrete results. Watch this space.

Welcome to this month's FusionForge news batch. I did a presentation of FusionForge at the Libre Software Meeting (Rencontres Mondiales du Logiciel Libre, in French) earlier this month, to explain where we come from and where we hope to go. Many people attended despite the talk being early on the morning following the formal dinner, and the questions showed interest, which is encouraging for the project as a whole. I don't think the talk has been recorded, but the summary and slides are available on the RMLL website. The big news, though, is that I'm currently at the Debian Conference, Debconf, and that I also attended Debcamp before that. Debcamp is a very productive get-together of developers from all across Debian, and I took the opportunity to get help from them. I spent the first few days refactoring some of the code that was duplicated between the CVS and Subversion plugins, and the result is that version control plugins are now much easier to implement. Case in point: I managed to get the attention of a few users of other tools, and since they only had to implement small specific parts, we now have almost complete plugins for Bazaar, Darcs and Git, and Mercurial will probably follow. CPOLD was done too, but mostly as a proof of concept. If you're around, come and see me, we'll finish the support for your favourite tool together. Or even start it (I haven't started on Arch and Monotone for lack of perceived interest, but I'm quite open to these tools too). In both cases, I promise it won't take long. This code currently only lives on a temporary branch based off FusionForge 4.8, but I'll port that to trunk and commit it in the coming weeks.

As I am attempting to focus on writing projects that are more scholarly and academic on the one hand (i.e., work for my day job at MIT) and more geared toward communicating free software principles toward wider audiences on the other (e.g., Revealing Errors), I have little choice but to back away from technical writing. However, this last month has seen the culmination of a bunch of work that I've done previously: two book projects that have been ongoing for the last couple years or more have finally hit the shelves! The first is the fourth edition (!) of the bestselling Official Ubuntu Book. Much to my happiness, the book continues to do extremely well and continues to receive solid reviews. This edition brings the book up to date for Jaunty/9.04 and adds a few pieces here and there. Although I was less active in this update than I have been in the past, Corey Burger continued his great work and Matthew Helmke of Ubuntu Forums fame stepped up to take a leading role. As I plan to retreat into a more purely advisory role for the next edition of this book, I'm thrilled to know that the project will remain in such capable hands. I'm also thrilled that this edition of the book, like all previous editions, is released as a free cultural work under CC BY-SA For years, I have heard people say that although they like the Official Ubuntu Book, it was a little too focused on desktops and on beginners for their tastes. The newly released Official Ubuntu Server Book is designed to address those concerns by providing an expanded guide to more "advanced" topics and is targeted at system administrators trying to get to know Ubuntu. Kyle Rankin planned and produced most of this book but I was thrilled to help poke it in places, chime in during the planning process, and to contribute a few chapters. Kyle is a knowledgeable sysadmin and has done wonderful job with the book. I only wish I could take more credit. The publisher has promised me that, at the very least, my chapters will be distributed under CC BY-SA. Many barriers to the adoption of free software are technical and a good book can, and often does, make a big difference. I enjoy being able to help address that problem. I also truly enjoy technical writing. I find it satisfying to share something I know well with others and it is great to know that I've helped someone with their problems. I'll assure I'll be able to do things here and there, I'll miss technical writing as I attempt "cut back."

Over the last few years, I've been pretty immersed in the world of wikis. A wiki is like a collaborative web site; it lets several people view and edit a web page and link to other pages, maybe new pages that they themselves create. Wikis let tech-savvy people all over the world collaborate on a single web page, a single document. That's a pretty powerful idea, really. The obvious thing to do once an idea like wikis appears is to attempt to cram all of humanity's knowledge into it. Well that's just crazy enough to work. Wikipedia is the gold standard of wikis. It's a collaborative encyclopedia with lots and lots of articles. As the gold standard, it influences people's thinking about wikis in ways that might not be quite true. If Wikipedia were the only wiki you'd ever heard of, you might think that wikis are used to create encyclopedias. If that were true, you'd really only need one of them. If Wikipedia were the only wiki you'd ever heard of, you might be under the false impression that all wikis everywhere are editable by anyone. So if you create a wiki page, it's no longer yours. Other people can scribble on it. Well, some kinds of documents perhaps just aren't suitable for being edited by anyone, and the good news is that you can build a wiki for you and your classmates, or you and your coworkers, and you can decide who gets to edit what. I want to think about a few distinct uses for wikis in different contexts. The most common use is of course to create a knowledge repository; a collection of information written by people who know what they're talking about. That's what Wikipedia is, mostly. That's what the Haskell Prime wiki (which I run) is. And the excellent wiki about the game of Go, Sensei's Library, is also a knowledge repository. But there are other uses for wikis that are pretty cool. I often have to work on proposals with my coworkers. One (horrible) way to do this is to write the first draft in MS Word, email it to everyone, who might edit it and email it back. Of course, only one person can actually edit it at a time, otherwise I have to figure out what everyone did and merge their changes by hand. That's what we, in the computer industry, call teh suck. A better way to do this is to use a version control system, which lets multiple people work on a document at one time. Of course, if you're editing evil document formats like Word, still only one person can edit it at a time, but at least you cut out email, so things are a bit better organized. But wikis are actually a really great way to work on a document with another person. Two or more people can each collaborate on the document using the wiki software over the web. What becomes of the document at that point depends on its ultimate use. Maybe you have to convert it to MS Word or PDF at the end. That's a bit of a bummer. So there are two uses of wikis that I've mentioned: building a knowledge repository, and collaborative writing. Google started a service for collaborating on documents called Google Docs & Spreadsheets, which is probably useful for collaborative writing, but not knowledge repositories. They also acquired a wiki startup a few days ago, so they are clearly trying to get all over this space. There's another very interesting use of wikis that I'll call situation awareness. You can get a really vivid picture of this use of wikis if you take a look at the wikipedia article on the July 2005 London bombings. By the way, I didn't discover this excellent example of situation awareness using wikis. I saw it in the slides for a talk, but I don't know the original source at this point. If you go to that link, you'll see an excellent and up-to-date encyclopedia article about the London bombings. It's not a news article. Go to Google News and try to find a news article from a major news source which is this detailed, up-to-date, and well organized. Most articles you'll find are a snapshot, taken at a particular point in time (when the article was published) that most likely contains an account of the latest developments, and usually brief background in case you missed previous stories. The wikipedia article isn't a snapshot, it's an article that explains things in a logical order, which isn't necessarily chronological. Each wikipedia article contains a link to its own history. You can look back over time and see the article evolve. If you look at the early edit history of that London bombing article, you'll notice something fascinating. The article was created shortly after the bombing, with an account of the information that was known at that time. Within an hour, many people had edited the article, adding information they know about. If you were refreshing that wikipedia entry over & over (or if you were subscribed to it using RSS), you'd see not an account of just the latest developments, but an evolving, logical understanding of the attacks. The article started evolving right away, and it continues to evolve to this moment. That's what I'm calling situation awareness. Don't get me wrong, the mainstream news media is quite good at situation awareness. They do it a bit differently, and their articles or TV stories don't become integrated into a knowledge repository like wikipedia. I've enumerated three somewhat overlapping uses for wikis that I think are pretty interesting to examine:

Knowledge Repositories, which are a lot like encyclopedias,

Collaborative writing, which is a bit like a more elegant version of emailing word documents, and

Situation awareness, which isn't so different from the news; it draws from the news as a source, it can also be authored by the eye-witnesses themselves, and each story becomes an integral part of a knowledge repository. I don't claim that these are an exhaustive, nor are they a partition: Wikis are also used for bug tracking and as web discussion forums, for instance. What other categories can you think of? Email me if you have ideas.

I really enjoy the book The Pragmatic Programmer. One of the suggestions in this book is to learn one new programming language every year. Since the new year is upon us, I though I'd suggest that this year, everyone should learn Haskell. So please apt-get install hugs, grab Yet Another Haskell Tutorial, and get hacking. You'll probably want to have the Libraries API bookmarked. You might want to install the Glasgow Haskell Compiler after a couple of hours. When you get ready to package your first Haskell library for Debian, be sure to check out the state of the Haskell Cabal (the Common Architecture for Building Applications and Libraries). Here's a basic implementation of cat in Haskell. Compile With: ghc Cat.hs -o myCat

import System
main = do a <- getArgs
          contents <- sequence (map readFile a)
          putStrLn (concat contents)

I'd be very happy if folks email me with suggestions on what programming language, API, technique, paradigm, or whatever I should learn this year. You definitely get extra points if you can give me a link to a good tutorial and if an implementation of the language is packaged for Debian.

The latest terrible story about a voting machine is here. In summary: 19,000 registered voters, 5,352 ballots cast, 144,000 votes counted by the machine. Does anyone remember the bug in Intel chips that came out something like 10 years ago? It looked (at least at first) like it would only affect a few people under very rare circumstances, but the media totally freaked out and Intel was forced to fix the problem (as well they should). Have we become so numb to bad software that we don't care when the machines we are using to help decide elections have such awful bugs in them? Does anyone notice when the bugs aren't so terribly obvious (negative votes, 138,000 delta from actual votes to counted votes).

A couple of weeks ago I updated my Debian Sid setup on the MacBook to use disk encryption; this post is to document what I did for later reference. The system was configured for dual booting Debian or Mac OS X using refit and grub2 as documented on the Debian Wiki; I don't use the Mac OS X system much, but I left it there to be able to test things and be able to answer questions of Mac OS X users when I have to. The Debian installation was done using two primary partitions, one for swap (I used a partition to be able to suspend to disk without troubles) and an ext3 file system used as the root file system. The plan was to use the Debian Installer to do the disk setup and recover the Sid installation from a backup once the encrypted setup was working OK. Backup for later recovery My first step was to install all the needed packages on the original system; basically I verified that I had the lvm2 and cryptsetup packages installed. The second step was to backup the root file system; to do it I changed to run level 1 and copied the files to an external USB disk using rsync. My third step was to boot into Mac OS X to reduce the space assigned to it; I had a lot of free space that I didn't plan to use with Mac OS X and I thought that this was the best occasion to reassign it to the Debian file system. Encrypted Lenny installation Now the machine was ready for the installer. As I formatted the system a couple of weeks ago I used a daily build of the Lenny Debian Installer, now that Lenny is out I would have used the official version. I booted the installer and on the partition disk step I selected the manual method; I left sda1 and sda2 as they were (the Mac OS X installation uses them) and set up sda3 and sda4 as follows:

• sda3: 256 MB, use as ext3, mount point: /boot
• sda4: 86 GB, use as physical volume for LVM

Note that I decided to put /boot on a plain ext3 partition to be able to use grub2 as the boot loader (if we put the kernel on an LVM logical volume we need to use lilo as the boot loader). Once sda4 was adjusted as LVM I entered on the LVM setup and created a LVM Volume Group (VG) with the name debian, using sda4 as the physical volume. Once the VG was defined I created a couple of Logical Volumes (LV):

• root: 82 GB
• swap: 2 GB

I left some space unallocated to be able to create LVM snapshots (I use them to do backups, I'll post about it on the next days). Once the LV were ready I finished with the LVM setup and went back to the partitioner to configure the Logical Volumes:

• debian-root: use as physicals volume for encryption
• debian-swap: use as pascal volume for encryption, encryption key: random

Once both encrypted volumes were ready I entered on the Configure the encrypted volumes menu and the installer formatted the volumes for encryption and asked for the debian-root pass phrase. Back on the main partitioning menu I set up the debian-root_crypt encrypted volume:

• debian-root_crypt: use as ext3, mount point: /.

I didn't need to touch the debian-swap_crypt, it was configured automatically as swap because I choose a random encryption key. At this point I was finished with the partitioning; to finish I installed a minimal system and rebooted to try the system. As I had changed the disk layout I had to re-sync the partition tables from refit; once that was done I was able to boot from the newly installed system. Setting up suspend to disk I was using s2disk to suspend the system; to test if it still worked with the new setup I installed the uswsusp package and adjusted the resume device on the /etc/uswsusp.conf to /dev/mapper/debian-swap_crypt. After my first try I noticed that the resume step failed with the encrypted swap partition because it was using a random key, which means that the swap contents are unrecoverable after a reboot. Looking at the cryptsetup documentation I found that the solution was to use a derived key for the swap partition instead of a random one. The command sequence was as follows:

# disable swap
swapoff -a
# close encrypted volume
cryptsetup luksClose debian-swap_crypt
# change the swap partition setup on the /etc/crypttab file
sed -e -i 's%^debian-swap.*%debian-swap_crypt /dev/mapper/debian-swap debian-root_crypt cipher=aes-cbc-essiv:sha256,size=256,swap,hash=sha256,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap%' /etc/crypttab
# open the encrypted volumes with the new setup
/etc/init.d/cryptdisks start
# enable swap
swapon -a
# update the initrd image
update-initramfs -u

After executing all those commands the suspend to disk system worked as expected. Recovering the original system If I were going to reinstall the system completely I would have finished here, but in my case I wanted to recover my original system setup (except the minimal changes required to use the encrypted passions, of course). To recover my old installation I backed up some files (/etc/fstab, /etc/crypttab, /etc/uswsusp.conf and the current /boot contents to be able to boot in case of failure with my old kernel) from the current installation, after that I recovered all the files from the initial backup (except the ones just saved) using rsync again and regenerated the initrd images of my old kernels:

update-initramfs -u -k all

After that I rebooted and everything worked as on my original installation (except for the disk encryption, of course).

Yesterday I received a mail message from a Debian user called Ekrem Erdem about my previous post, proposing a different partitioning schema that I found interesting. The basic idea is to swap the order of the technologies, that is, use LVM on top of an encrypted partition instead of encrypting logical volumes. I never thought about this schema because I always use LVM on servers and that is one of the fist things I setup (just after software RAID-1, if the machine has two hard drives); when I was evaluating how to setup my system for encryption I started with the LVM setup and never looked back. The advantage of this setup is that there is only one pass phrase (the one used to unlock the encrypted partition, sda4 in my case), eliminating the need of derived keys (i. e. my swap setup) or key files (I use them to mount snapshots of the encrypted partition non interactively). On the negative side I believe that this setup looses some flexibility:

• On my original model crypted and unencrypted partitions can coexist on the same volume group, while the new setup requires a different volume group for unencrypted volumes.
• If the user wants to have multiple partitions each one can use a different pass phrase or key file.
• If a logical volume is expanded through multiple physical volumes the new setup requires a key for each physical volume, while the original setup only needs one key.

Anyway if the plan is to encrypt all the file systems on a laptop the proposed setup is simpler and, IMHO, as safe as my configuration (remember that my keys are related). I'm not going to change my setup now (it works great), but I'll probably try this one in the future if I need an encrypted setup on a different machine.

Percentage of Debian Developers preferring new elections to having AJ as DPL in March/April: 17.3%. Percentage of Debian Developers preferring new elections to having AJ as DPL in October: 14.8% That's right. contrary to what one would expect from merely reading the mailinglists, an even larger majority now finds AJ acceptable as DPL. This does not render the objections of the couple dozen DDs irrelevant though, diversity is a great good. However, diversity can easily escalate to divisiveness when different opinions or more accurately the ways they are voiced start to severely hinder activity by others. I myself have been quite demotived by the whole discussion, as has happened to me multiple times before. We Developers do not seem to be able to have constructive discussion without getting extremely heated up. I believe that this inability to hold discussions about tricky subjects is way more hurting the project than any of the "tricky subjects" themselves. Actually, the tidbit in my DPL-elections platform about Communication among Debian contributors is still equally relevant. Several potential improvements have been proposed in the past, including debating by wiki, debating inside a smaller taskforce, or even having a representative democracy. Let's explore the representative democracy principle a bit further: In general, I consider making decisions by GR (or to draw a parallel to country government, referendum) bad: A majority of voters doesn't have adequate and balanced information to make a reasonable decision, that takes doing quite some research. Instead, any discussion (vote winning?) is going to be significantly depending on emotions. Take the voting-down of the European constitution by France and the Netherlands: Hardly anyone has adequate information to really make a tradeoff, still quite a number of people voted, and supposedly one of most prevalent considerations was fear of this "Europe" thingy. Therefore, I'd really prefer that issues like firmware are dealt with by smallish team of people who really can look into the issue well, consider all arguments either way, and make a decision. As with every decision in Debian, it can be overturned by GR, but still. Note that we don't need any consitutional change for this, the DPL already has the power to delegate a person or group of people to make some decision nobody else specifically is responsible for already. A complicating factor is though that it's hard to compose such a taskforce that will have the project's support once a discussion is 'heated up'. In other news, rumour has it that -private has blown up today. I'm so looking forward to opening that mailfolder.

June is the last month before summer holidays, and at this phase in my study, courses take a lot of time: practical assignments, seminars to give, multiple exams. And mid-June, I'll be attending DebConf in Edinburgh, including delivering a talk about Mole, the subject of my Google Summer of Code project. In the period of April/May students participating in the Summer of Code project had the time to get more familiar with the project they were going to work for. Because I'm already somewhat familiar with Debian, I opted to organize an Etch release party together with some friends, because, well, what better way is there to get to know the community? During the past two weeks I've been really starting with the project. I updated the wiki page, added a new development page where I keep track of my work listing the subtasks I'm working on and their status. The first month will be mostly work on the internals, but starting with the second month I'll also be working on the web interface, meaning that there should be some stuff to show off. At the moment I'm refactoring some bits of Mole that are currently implemented in a hacky way, in order to make it all as extensible as it should be. This includes defining a config file format for mole tables, so that it's no longer necessary to modify the python code for new tables. It also involves some better way of stacking tables to each other, so that the package file extraction code can be moved away from the core of mole into a separate worker to keep mole itself pure and simple and generally applicable. I'll post irregular updates to my blog. I'm looking forward to seeing a lot of you again this Thursday, when I'll arrive in EDI!

So sometime last year Andrew Stribblehill landed a job with Google. This did quite a number on google's mystique among the Durham spods, but soon he started telling us stories about how nice a place it was to work and how they were looking for more people. So when I came back for my final year at Uni, I started looking for a job. No idea what its like at any other uni, but around here people do the following when the real world approaches:

• Hide.
• find themselves another bit of education to do. Masters, PhD...
• sign up for some large graduate training scheme on the grounds they believe themselves to be the smartest person on the planet and they want to be earning a hundred thousand pounds by the time they are twenty five.
• Run around in a mad panic looking for a job.

I was in the second and fourth groups, and when Strib suggested I apply to Google, I went for it. What followed was four months of phone interviews, emails, some fratic revison and a free trip to Dublin. I can't really say much about the process, but it is everything its made out to be... The long and short of it is that they have offered me a job. Having accepted, I now have had a major worry lifted from my mind and replaced by smaller worries, like moving to Ireland. A major thank you is needed, to all the following people:

• Strib
• All my recuiters, of which there has been at least three.
• All my interviewers, They were all pretty interesting interviews, actually.

I'll buy you a beer next time I see you. Note: I'm unsufferable when something like this happens, so free free to thump me when i get annoying... So far the only downside I can think is I can't tell people to Just fecking google it anymore.

I was reading xkcd by clicking on the random link when I noticed that the same cartoons were coming up again and again. I was wondering if this was Confirmation bias on my part or a duff random number generator on the server's part. Randall Munroe is a science geek, and I figured what he would do is test this idea... One python script and 12,000 (approx) requests later, I had a file full of numbers and started trying to remember some statisics. I threw together a quick bit of python to work out the mean and standard deviation (its here). The mean value is 97.4155602788 and the standard deviation is 171.040683155. If they are uniformly distributed from 1 to 361, the expected mean would be 104.211323761 and the standard deviation would be 181.0. So I was lost in thought for a while. However, the following quick check threw some light on the difference.

>>> data = [int(x) for x in open('numbers.data')]
>>> for x in xrange(0, 361):
...   if x not in data:
...     print x
... 
0
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360

So comics numbered about 338 don't appear. And recomputing the mean and standard deviation for 1 to 337 gives a mean of 97.2830920561 and a standard deviation of 169.0, which is about the mean and standard deviation the data gives. I'm now waiting for someone who actually knows stats correcting me in where I went wrong. The conclusion? I suffer from confirmation bias :-(. For those who like pretty pictures, here is one, courtesy of the Google charts API and pygooglechart: code here

For some time now I'm using a dual monitor setup with my Radeon 9200 SE (RV280). Basically this works quite well, except that I need to enter these commands manually:



Without these settings krandr is unable as well to detect both monitors properly. And it's not remembering the settings when I close/save the session by logging out. I tried to add the above code lines in ~/xinitrc as well as in /etc/X11/xinit/xinitrc, but they are not executed as after a restart of X I end up with the wrong monitor being the primary instead of the DVI display.

My xorg.conf is this:



So, dear lazyweb, what's wrong with this setup and how can I fix it?