We are happy to announce that the shogun machine learning toolbox will participate in this years google summer of code :-) SHOGUN is designed for unified large-scale learning for a broad range of feature types and learning settings, like classification, regression, or exploratory data analysis. In case you are a talented student interested in implementing and learning about machine learning algorithms - we are looking for you! We have collected a number of ideas [1] that we consider worthwhile implementing. And don't forget to apply [2]!

[1] http://shogun-toolbox.org/page/Events/gsoc2013_ideas

[2] http://google-melange.appspot.com/gsoc/org/google/gsoc2013/shogun

Hello everyone! I am very excited to report about the awesome progress we made with Tanglu, the new Debian-based Linux-Distribution. First of all, some off-topic info: I don t feel comfortable with posting too much Tanglu stuff to Planet-KDE, as this is often not KDE-related. So, in future Planet-KDE won t get Tanglu information, unless it is KDE-related You might want to take a look at Planet-Tanglu for (much) more information. So, what happened during the last weeks? Because I haven t had lectures, I nearly worked full-time on Tanglu, setting up most of the infrastructure we need. (this will change with the next week, where I have lectures again, and I also have work to do on other projects, not just Tanglu ^^) Also, we already have an awesome community of translators, designers and developers. Thanks to them, the Tanglu-Website is now translated to 6 languages, more are in the pipeline and will be merged later. Also, a new website based on the Django framework is in progress. The Logo-Contest We ve run a logo-contest, to find a new and official Tanglu logo, as the previous logo draft was too close to the Debian logo (I asked the trademark people at Debian). More than 30 valid votes (you had to be subscribed to a Tanglu Mailinglist) were received for 7 logo proposals, and we now have a final logo: I like it very much Fun with dak I decided to use dak, the Debian Archive Kit, to handle the Tanglu archive. Choosing dak over smaller and easy-to-use solutions had multiple reasons, the main reason is that dak is way more flexible than the smaller solution (like reprepro or min-dak) and able to handle the large archive of Tanglu. Also, dak is lightning fast. And I would have been involved with dak sooner or later anyway, because I will implement the DEP-11 extension to the Debian Archive later (making the archive application-friendly). Working with dak is not exactly fun. The documentation is not that awesome, and dak contains many hardcoded stuff for Debian, e.g. it often expects the unstable suite to be present. Also, running dak on Debian Wheezy turned out to be a problem, as the Python module apt_pkg changed the API and dak naturally had problems with that. But with the great help of some Debian ftpmasters (many thanks to that!), dak is now working for Tanglu, managing the whole archive. There are still some quirks which need to be fixed, but the archive is in an usable state, accepting and integrating packages. The work on dak is also great for Debian: I resolved many issues with non-Debian dak installations, and made many parts of dak Wheezy-proof. Also, I added a few functions which might also be useful for Debian itself. All patches have of course been submitted to upstream-dak. Wanna-build and buildds This is also nearly finished Wanna-build, the software which manages all buildds for an archive, is a bit complicated to use. I still have some issues with it, but it does it s job so far. (need to talk to the Debian wanna-build admins for help, e.g. wanna-build seems to be unable to handle arch:all-only packages, also, build logs are only submitted in parts) The status of Tanglu builds can be viewed at the provisoric Buildd-Status pages. Setting up a working buildd is also a tricky thing, it involves patching sbuild to escape bug #696841 and applying various workarounds to make the buildd work and upload packages correctly. I will write instructions how to set-up and maintain a buildd soon. At time, we have only one i386 buildd up and running, but more servers (in numbers: 3) are prepared and need to be turned into buildds. After working on Wanna-build and dak, I fully understand why Canonical developed Launchpad and it s Soyuz module for Ubuntu. But I think we might be able to achieve something similar, using just the tools Debian already uses (maybe a little less confortable than LP, but setting up an own LP instance would have been much more trouble). Debian archive import The import of packages from the Debian archive has finished. Importing the archive resulted in many issues and some odd findings (I didn t know that there are packages in the archive which didn t receive an upload since 2004!), but it has finally finished, and the archive is in a consistent state at time. To have a continuous package import from Debian while a distribution is in development, we need some changes to wanna-build, which will hopefully be possible. Online package search The Online-Package-Search is (after resolving many issues, who expected that? ) up and running. You can search for any package there. Some issues are remaining, e.g. the file-contents-listing doesn t work, and changelog support is broken, but the basic functionality is there. Tanglu Bugtracker We now also have a bugtracker which is based on the Trac software. The Tanglu-Bugtracker is automatically synced with the Tanglu archive, meaning that you find all packages in Trac to report bugs against them. The dak will automatically update new packages every day. Trac still needs a few confort-adjustments, e.g. submitting replies via email or tracking package versions. Tanglu base system The Tanglu metapackages have been published in a first alpha version. We will support GNOME-3 and KDE4, as long as this is possible (= enough people working on the packaging). The Tanglu packages will also depend on systemd, which we will need in GNOME anyway, and which also allows some great new features in KDE. Side-effect of using systemd is at least for the start that Tanglu boots a bit slow, because we haven t done any systemd adjustments, and because systemd is very old. We will have to wait for the systemd and udev maintainers to merge the packages and release a new version first, before this will improve. (I don t want to do this downstream in Tanglu, because I don t know the plans for that at Debian (I only know the information Tollef Fog Heen & Co. provided at FOSDEM)) The community The community really surprised me! We got an incredible amount of great feedback on Tanglu, and most of the people liked the idea of Tanglu. I think we are one of the less-flamed new distributions ever started . Also, without the very active community, kickstarting Tanglu would not have been possible. My guess was that we might be able to have something running next year. Now, with the community help, I see a chance for a release in October The only thing people complained about was the name of the distribution. And to be really honest, I am not too happy with the name. But finding a name was an incredibe difficult process (finding something all parties liked), and Tanglu was a good compromise. Tanglu has absolutely no meaning, it was taken because it sounded interesting. The name was created by combining the Brazilian Tangerine (Clementine) and the German Iglu (igloo). I also dont think the name matters that much, and I am more interested in the system itself than the name of it. Also, companies produce a lot of incredibly weird names, Tanglu is relatively harmless compared to that . In general, thanks to everyone participating in Tanglu! You are driving the project forward! The first (planned) release I hereby announce the name of the first Tanglu release, 1.1 Aequorea Victoria . It is Daniel s fault that Tanglu releases will be named after jellyfishes, you can ask him why if you want I picked Aequorea, because this kind of jellyfish was particularly important for research in molecular biology. The GFP protein, a green fluorescent protein (=GFP), caused a small revolution in science and resulted in a Nobel Prize in 2008 for the researchers involved in GFP research (for the interested people: You can tag proteins with GFP and determine their position using light microscopy. GFP also made many other fancy new lab methods possible). Because Tanglu itself is more or less experimental at time, I found the connection to research just right for the very first release. We don t have a time yet when this version will be officially released, but I expect it to be in October, if the development speed increases a little and more developers get interested and work on it. Project Policy We will need to formalize the Tanglu project policy soon, both the technical and the social policies. In general, regarding free software and technical aspects, we strictly adhere to the Dbian Free Software Guidelines, the Debian Social Contract and the Debian Policy. Some extra stuff will be written later, please be patient! Tanglu OIN membership I was approached by the Open Invention Network, to join it as member. In general, I don t have objections to do that, because it will benefit Tanglu. However, the OIN has a very tolerant public stance on software patents, which I don t like that much. Debian did not join the OIN for this reason. For Tanglu, I think we could still join the OIN without someone thinking that we support the stance on software patents. Joining would simply be pragmatic: We support the OIN as a way to protect the Linux ecosystem from software patents, even if we don t like the stance on software patents and see it differently. Because this affects the whole Tanglu project, I don t want to decide this alone, but get some feedback from the Tanglu community before making a decision. Can I install Tanglu now? Yes and no. We don t provide installation images yet, so trying Tanglu is a difficult task (you need to install Debian and then upgrade it to Tanglu) if you want to experiment with it, I recomment trying Tanglu in a VM. I want to help! Great, then please catch one of us on IRC or subscribe to the mailinglists. The best thing is not to ask for work, but suggest something you want to do, others will then tell you if that is possible and maybe help with the task. Packages can for now only be uploaded by Debian Developers, Ubuntu Developers or Debian Maintainers who contacted me directly and whose keys have been verified. This will be changed later, but at the current state of the Tanglu archive (= less safety checks for packages), I only want people to upload stuff who definitely have the knowledge to create sane packages (you can also proove that otherwise, of course). We will later establish a new-member process. If you want to provide a Tanglu archive mirror, we would be very happy, so that the main server doesn t have to carry all the load. If you have experience in creating Linux Live-CDs or have worked with the Ubiquity installer, helping with these parts would be awesome! Unfortunately, we cannot reuse parts of Linux Mint Debian, because many of their packages don t build from source and are repackaged binaries, which is a no-go for the Tanglu main archive. Sneak peek And here is a screenshot of the very first Tanglu installation (currently more Debian than Tanglu):

Something else I am involved in Debian for a very long time now, first as Debian Maintainer and then as Debian Developer and I never thought much about the work the Debian system administrators do. I didn t know how dak worked or how Wanna-build handles the buildds and what exactly the ftpmasters have to do. By not knowing, I mean I knew the very basic theory and what these people do. But this is something different than experiencing how much work setting up and maintaining the infrastructure is and what an awesome job the people do for Debian, keeping it all up and running and secure! Kudos for that, to all people maintaining Debian infrastructure! You rock! (And I will never ever complain about slow buildds or packages which stay in NEW for too long )

We are pleased to announce the 15th annual Debian Conference (DebConf14) is to be held in Portland, Oregon, USA in August 2014, with specific dates yet to be announced. Portland is an open source hotspot in the Pacific Northwest of the US. It is a technologically savvy community, home to Intel and the adopted home of Linus Torvalds. The city plays host to many Free Software conferences including OSCON, and is where Linux Plumbers originated. The local team has been involved in mulitple DebConfs in the past, and is excited to bring their experience and ideas to fruition in a city well-positioned to host such a prestigious event.

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (114.19 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Simple-CDD and debian-cd I tried to use wheezy s version of debian-cd and simple-cdd to generate an automatic installer. In this process, I filed a couple of bugs on simple-cdd (#701963: type-handling package is gone and should not be listed in default.downloads, and #701998: the --keyboard parameter is not working with wheezy s debian-installer) and I commited fixes for a few issues in debian-cd:

• r2518: adjust Makefile for new xorriso requirement
• r2520: add missing depends on dosfstools
• r2521: use --no-check-gpg when querying debootstrap
• r2522: make debian-cd work with a mirror without sources)

Debian France I completed the new website for Debian France and I put it online. Later I merged some supplementary enhancements prepared by Tanguy Ortolo (and I gave him commits rights at the same time). I tried to update our Galette installation to the latest upstream version but I reverted to the former version after having encountered two problems (filed here and here). In the process, I created a Debian package for galette (you can grab it on git.debian.org). I also suggested an idea of improvement for Galette s paypal plugin and it has been quickly implemented. Thus I updated the plugin installed on france.debian.net. Kali related work It s been a few months that I have been helping the Kali team to prepare this new Debian derivative. Now that the derivative has gone public, I can attribute some of my Debian work to my collaboration with the Kali team. This month I contributed a few features and fixes to debian-installer and live-build:

• #702257: new preseed entry to disable CDROM entries
• #703072: hid-generic module is missing from input-modules udeb (affecting experimental kernel only)
• Fix win32-loader support in live-build

After the launch, we registered Kali in the derivative census. Paul Wise quickly reported some misfiled bugs from early Kali users and I discovered that reportbug was not behaving properly even though we correctly updated base-files (see #703678 on reportbug and #703677 on lsb-release). Misc packaging work

• I sponsored a new upstream version of dnsjava because it s required by Jitsi.
• I prepared rebuild 0.4.1.1 and uploaded it to testing-proposed-updates for a RC bug fix.
• I uploaded Publican 3.1.5 to experimental and filed #703514 to request a new upstream version of docbook-xsl that is needed by Publican.
• I filed #703995 to fix apt-setup s handling of the apt-setup/multiarch preseed option.

DPL election I also spent quite some time to read and participate to the discussions on debian-vote since it was campaigning time for the DPL candidates Thanks This was a rather active month if you take into account the fact that I got a second son Lucas on March 6th. See you next month for a new summary of my activities.

4 comments Liked this article? Click here. My blog is Flattr-enabled.

On Monday I took part in my first triathlon, a "sprint" distance race organised by Thames Turbo Triathlon Club.

Besides my RTL work on Libreoffice, every once in a while I just go over the regular commit log to see what have changed. I don t necessary understand each line in the commit, but do get the general idea from the commit message. Being more dependent on the commit messages makes me review them more thoroughly (hence the topic of this post). As many projects, Libreoffice has notifications of commits related to bugs reports when the bug number is properly mentioned in the commit message. This is very useful for other developers and also for QA people. After verification of a bug is fixed, I often use the commits listed on the bug report to cherry pick them to an older branch. Going to search for an unreferenced commit isn t much fun. One of the things I notice is different ways people reference bugs from not referencing them at all to referencing them in various ways like linking to the bugs system, just writing the number (without the fdo# prefix) and other creative ways This is also true for first time contributors, which might not know the standards or the rules . When I see such a case I usually put a manual notification in the bug report, and mail the author of doing so. For new or sporadic contributors this is also an opportunity to welcome and thank them for the commit and even encourage future contributions. I have been asked why aren t that info on the wiki, so I went looking and found out the info is in the right place under the Development/GetInvolved page. The relevant part is:

When you type a commit message:

• start the first line with a bug reference like fdo#12345, if you have one for your commit (see details below)
• use the rest of the first line as a concise summary of your changes
• the 2nd line remains empty
• and starting on the 3rd line you can explain how and what changes have been made for what reasons.

Thanks in advance and happy coding (:
Filed under: LibreOffice

Ben Goldacre (Bad Science), is running a campaign for all medical trials to be published. It seems that best current evidence indicates that about half of the trials for treatments currently in use remain unpublished. That's pretty astounding when you think about it. Given that many of the trials that are published only compare new treatments against placebo, rather than against the best available existing treatment, and often barely show them as being more effective than homeopathy^Wsugar, one has to wonder how dire were the results that are not being published. If you prefer to have science done in the open, then I'd encourage you to visit www.alltrials.net and sign the petition and/or give them a donation. The fix is pretty straight-forward: Simply insist that clinical trials have to register before they start in order to be considered valid, and that all registered trials have to report their results. It need not be expensive to do -- a git repo. shared across the industry, containing a file for each trial in a standard format would do the trick probably. I imagine they'll come up with a more expensive solution, but in comparison to the cost of running a decent sized trial, it'll still be pocket change. (A note from the campaign, sent to existing petition signatories, is what prompted this blog post -- please read it and be inspired to help)

On the weekend of April 20-21, Students for Free Culture is going to be holding its annual conference, FCX2013, at New York Law School in New York City. As a long-time SFC supporter and member, I am enormously proud to be giving the opening keynote address. Although the program for Sunday is still shaping up, the published Saturday schedule looks great. If previous years are any indication, the conference can serve as an incredible introduction to free culture, free software, wikis, remixing, copyright, patent and trademark reform, and participatory culture. For folks that are already deeply involved, FCX is among the best places I know to connect with other passionate, creative, people working on free culture issues. I ve been closely following and involved with SFC for years and I am particularly excited about the group that is driving the organization forward this year. If you will be in or near New York that weekend or if you can make the trip you should definitely try to attend. FCX2013 is pay what you can with a $15 suggested donation. You can register online now. Travel assistance especially for members of active SFC chapters may still be available. I hope to see you there!

Since there's a discussion of packaging software for Debian that uses Git upstream on Planet Debian right now, I wanted to weigh in and advocate for my current workflow for this situation, which I'm quite fond of. It's worth noting that I'm also upstream for quite a few of the packages I maintain, all in Git, and I use (almost) exactly the same structure for packaging my own software as for packaging anyone else's. So I have some experience with both sides of this. First off, I completely agree with Joey: if upstream is already using Git, there's no reason not to base the Debian packaging on the upstream repository, and many, many reasons to do so. One of the biggest advantages is that when repositories share a common basis and have been regularly merged, you can easily cherry-pick commits, which is wonderful for security releases and situations where you need a quick bug fix from an unreleased upstream branch. I make very heavy use of this when packaging OpenAFS. I do, however, like to base the Debian packaging on the released tarball, if for no other reason than that's the artifact that other people can more easily confirm. Yes, you can do the same thing with a Git tag, but the tarball is what upstream considers a release, so if one is available, I think it makes the most sense to base the packaging on it. I do this even for my own software. Thankfully, it's not that difficult to do both. Sam Hartman was the one who showed me this technique, and (after I used a manual script for some time for a couple of packages) Guido G nther incorporated the support into git-import-orig. The key idea is to still import the tarball into the upstream branch, but instead of making that import a simple commit, you make it a merge commit referencing the upstream release tag or commit from their Git repository. This means that you still get the exact contents of the release tarball on the upstream branch (and pristine-tar works as normal), but that branch is also based on the full upstream line of development. Therefore, so is your packaging branch (master or what have you) since you merge upstream into it. You can then charry-pick and take advantage of all of the normal Git features when following upstream development. This is dead simple to do with git-import-orig. Just add the upstream repository as a remote for your Git repository, make sure it's up to date with git fetch and you have the upstream tags, and then pass the flag --upstream-vcs-tag <tag> to git-import-orig whenever importing the upstream release tarball. git-import-orig will handle the construction of the merge commit for you and everything will just work, exactly like it normally does with git-buildpackage except with a more complete history. This support was added in git-buildpackage 0.6.0~git20120324, so it's available in unstable and testing. (I was going to update my notes on Debian packaging with Git to include this information before posting this, but I see that it will require some restructuring and quite a few changes to that document and I don't have time tonight. Hopefully soon.)

Review: Echo, by Jack McDevitt

Series:	Alex Benedict #5
Publisher:	Ace
Copyright:	November 2010
Printing:	November 2011
ISBN:	1-937007-00-6
Format:	Mass market
Pages:	367

This is the fifth book in the ongoing Alex Benedict series, but reading the previous volumes is generally optional. While there are references to earlier events (and indeed I resorted to Wikipedia at one point to refresh my memory of the plot of the the first book in the series), they aren't critical to the plot. They mostly are background for the reactions of other characters to Benedict and his firm. Echo opens with the now-familiar prologue, giving us a fleeting and limited glimpse into the mystery that Benedict and Chase Kolpath will be pursuing for the rest of the book. This time, it features the explorer Somerest Tuttle, who has spent most of his life looking for intelligent alien life. (In the far future setting of these books, humanity has spread through a large region of the galaxy but has only encountered one other alien race.) In the twilight of his career and life, a friend who works as a tour guide for astronomical tours comes to him with a story about something she saw. What, we don't know, and won't for most of the book. But, whatever it is, Tuttle never goes public with it, which is directly contrary to what everyone would expect him to do with any news about alien life. Benedict and Kolpath get involved some years later, after Tuttle's death, when a stone slab with unknown markings that was part of his estate shows up on the future equivalent of Craigslist, free to the first person who will haul it away. Benedict finds that interesting enough to go pick up, but then is really hooked when someone else goes to considerable lengths to try to make the slab disappear before anyone can get a good look at it. This, slowly, leads into poking around Tuttle's life and connections, the star tour industry, and the possible origins of the slab. If you've read any of the previous books in this series, Echo is more of the same, and I mean that in a good way. I think McDevitt is at his best when writing this sort of cross between scientific puzzle, mystery, and non-military adventure, full of people who care deeply about knowing and understanding things and don't like to be thwarted in their efforts. There is McDevitt's trademark halting and red-herring-ridden investigation that succeeds in being engrossing and compelling, plenty of opportunities to guess what's really going on (a bit easier this book than in some others), and a bit of action that I thought was better-handled than the somewhat strained action scenes of The Devil's Eye. The book moves right along, despite multiple reversals in the progress of the investigation, and the final revelation does indeed justify the strange behavior of the various people Benedict encounters. As with McDevitt in general and this series in particular, there is one caveat: the astronomical details are often interesting, but the world building in general is not terribly believable. Despite supposedly taking place millennia into the future, the society is a straight transplant (projection would imply more change than exists) of middle-class American culture, with bonus air cars, space ships, and slightly better computers. Similarly, alien ecologies suffer from severe Star Trek problems: all the planets feel like copies of Earth with a few minor tweaks. This just goes with the territory, and if you're up to the fifth book of the series, you've probably gotten used to it, but the unrealistic lack of divergence is actually used as a plot point here. That strained my suspension of disbelief a bit. That said, this sort of extremely familiar social context does give the books an oddly calm, comfortable feeling. It's tempting to describe McDevitt as cozy science fiction. There's a bit of danger, a bit of suspense, but one is fairly certain that everything will work out in the end and the reader will leave the book knowing the solutions to most of the mysteries raised without having to work very hard at understanding the society or the puzzle. If that's what you're in the mood for (and I was when I read Echo), McDevitt delivers reliably. If you like the Alex Benedict series in general, recommended, as this is an excellent example of the type. Rating: 8 out of 10

After moving from a hard drive to an SSD on my work laptop, I decided to keep the hard drive spinning and use it as a backup for the SSD. With the following setup, I can pull the SSD out of my laptop and it should still boot up normally with all of my data on the hard drive.

Manually setting up an encrypted root partition Before setting up the synchronization between the two drives, I had to replicate the partition setup. I used fdisk, cfdisk and gparted to create the following partitions:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048      499711      248832   83  Linux
/dev/sdb2          501760   500117503   249807872    5  Extended
/dev/sdb5          503808   500117503   249806848   83  Linux

and then loosely followed these instructions to create an encrypted root partition on /dev/sdb5:

$ cryptsetup luksFormat /dev/sdb5
$ cryptsetup luksOpen /dev/sdb5 sdb5_crypt
$ pvcreate /dev/mapper/sdb5_crypt
$ vgcreate akranes2 /dev/mapper/sdb5_crypt
$ vgchange -a y akranes2
$ lvcreate -L247329718272B -nroot akranes2
$ lvcreate -L8468299776B -nswap_1 akranes2
$ mkfs.ext4 /dev/akranes2/root

Finally, I added the new encrypted partition to the list of drives to bring up at boot time by looking up its UUID:

$ cryptsetup luksUUID sdb5_crypt

and creating a new entry for it in /etc/crypttab.

Copying the boot partition Setting up the boot partition was much easier because it's not encrypted. All that was needed was to format it and then copy the files over:

$ mkfs.ext2 /dev/sdb1
$ mount /dev/sdb1 /mnt/boot
$ cp -a /boot/* /mnt/boot/

The only other thing to remember is to install grub on the boot loader of that drive. On modern Debian systems, that's usually just a matter of running dpkg-reconfigure grub-pc and adding the second drive (/dev/sdb in my case) to the list of drives to install grub on.

Sync scripts To keep the contents of the SSD and the hard drive in sync, I set up a regular rsync of the root and boot partitions using the following mount points (as defined in /etc/fstab):

/dev/mapper/akranes-root /           ext4    noatime,discard,errors=remount-ro 0       1
/dev/mapper/akranes2-root /mnt/root  ext4    noatime,errors=remount-ro         0       2
UUID=0b9109d0-... /boot              ext2    defaults                          0       2
UUID=6e6f05fb-... /mnt/boot          ext2    defaults                          0       2

I use this script (/usr/local/sbin/ssd_boot_backup) for syncing the boot partition:

#!/bin/sh
if [ ! -e /mnt/boot/hdd.mounted ] ; then
    echo "The rotating hard drive is not mounted in /mnt/boot."
    exit 1
fi
if [ ! -e /boot/ssd.mounted ] ; then
    echo "The ssd is not the boot partition"
    exit 1
fi
nice ionice -c3 rsync -aHx --delete --exclude=/ssd.mounted --exclude=/lost+found/* /boot/* /mnt/boot/

and a similar one (/usr/local/sbin/ssd_root_backup) for the root partition:

#!/bin/sh
if [ ! -e /mnt/root/hdd.mounted ] ; then
    echo "The rotating hard drive is not mounted in /mnt/root."
    exit 1
fi
if [ ! -e /ssd.mounted ] ; then
    echo "The ssd is not the root partition"
    exit 1
fi
nice ionice -c3 rsync -aHx --delete --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/boot/* --exclude=/mnt/* --exclude=/lost+found/* --exclude=/media/* --exclude=/var/tmp/* --exclude=/ssd.mounted --exclude=/var/lib/lightdm/.gvfs --exclude=/home/francois/.gvfs /* /mnt/root/

To ensure that each drive is properly mounted before the scripts run, I created empty ssd.mounted files in the root directory of each of the partitions on the SSD, and empty hdd.mounted files in the root directory of the hard drive partitions.

Cron jobs The sync scripts are run every couple of hours through this crontab:

10 */4 * * *                root    /usr/local/sbin/ssd_boot_backup
20 0,4,8,12,16,20 * * *     root    /usr/local/sbin/ssd_root_backup
20 2,6,10,14,18,22 * * *    root    /usr/bin/on_ac_power && /usr/local/sbin/ssd_root_backup

which includes a reduced frequency while running on battery to avoid spinning the hard drive up too much.

A proposal to solve gender imbalance in Debian We've done all we can so far: Debian Women, the Diversity Statement, the anti-harassment contact, gender neutral language, lots of education all round, but we still suffer from a strong gender imbalance in Debian. I think that the reason is that the majority group of cisgender men in the project, although they don't actively work /against/ the rest, still have /no incentive/ to be inclusive, and generally do not understand what bearing a female name online is like. I think it is about time we addressed that, and after a lot of thinking and discussing with many other concerned debianers, I think I have just the right proposal, which is twofold. The first part is this: since the goal is to have an equal gender perception in Debian, we can just decide to only approve one obviously-male-named DD for every obviously-female-named one. That's right: no new obviously-male-named DD unless an obviously-female-named DD has just been approved. It may sound like affirmative action gone wild, but please stop a moment to think about it: this would create precisely the right incentive for the currently dominant group of developers to be inclusive! People shouldn't just assume they can get a Debian account regardless of what happens around them. We already ask NM candidates to fix RC bugs and, well, gender imbalance should be treated as an RC bug, and everyone should feel compelled to join the effort to fix it! Now, of course since there currently are many male names in NM but not a single female name, it would not be reasonable to just stop the flow of new developers into the project: that would just have the effect to make us starve on personpower. So here is the second part of the proposal: the one-female-name-one-male-name policy will not be enforced for, say, a year. But during this year, everyone currently in NM or joining NM will be asked to adopt a female identity. Crazy? No, genius! It's about time people understood what it means to get advances in private every time they make a public contribution! What better way than just trying it out for themselves? On top of that, as more and more female names appear in Debian changelogs, fake or not, people will finally start to understand that it does not matter what name is used to sign the contribution, but the contribution itself. I don't know if this will give us a community where people realise female or male contributions are equally valuable, which is what I hope, or a community where people will think that everyone is a cisgender man even if they have female names. In the end, really, it does not matter. Either way, we finally get to have a community where everyone is /guaranteed/ to be treated the same. But gender imbalance isn't the only imbalance we have in Debian. People accrue a reputation over time, good or bad, and this reputation tends to stick on you for years, regardless of how you may change, for better or for worse. When we evaluate the merit a contribution, we should not be biased by the reputation of the contributor! How can new contributors be taken seriously otherwise? I believe we are loosing lots of fresh, good ideas this way. And how much damage could be wrecked on the project by a well-respected contributor, like a Debian Account Manager, who is having a funny day? I think we can address this just as I propose to address gender imbalance: let's swap identities from time to time, like it usually happens with nametags at the end of Debconfs. Let's see gregoa upload a patched versions of python3.2, and enrico upload a new upstream version of eglibc! See if we won't finally have some peer review at last! Reputation and real identities have many merits, but we have come to rely too much on them, and it is hurting us. It is time we did something about it, before it is too late!

seems like the release is imminent, at least I hardly find anything to work on anymore. so this week's "report" contains just an upload for one old bug:

• #697221 motion: "motion: No longer has support for mysql"
  add some info to the bug report, then add a version to the build-dep and upload to DELAYED/1

Russ Allbery wrote an informative post about how to determine which charities are worth donating to [1]. He has a link to another article about the charities to which he donates and concentrates on ways of analysing the effectiveness of charities. So someone who has different ideas about which types of charity are worthy of donation could still learn a lot from his post. Adam Green wrote an interesting article for The New Yorker about Apollo Robbins who is one of the world s best pick-pockets [2]. Apollo picks pockets as a magician to entertain people and always returns what he steals. Now he is working with neuroscientists who are devising experiments to determine why his tricks work. Rick Falkvinge wrote an insightful article describing the way that the copyright monopoly is in direct opposition to the freedom to make contracts [3]. It s a good rebuttal of a common argument in favor of copyright law. Seth Godin gave an interesting TED talk about the problems with the education system, how and why it teaches conformity and little else [4]. One of his suggestions for improvement is to have students spend their evenings watching lectures by experts and class time asking questions. He also says that everything should be open book and that there is no value in memorising anything it s a bit of an overstatement but it s essentially correct. Cory Doctorow wrote an interesting article for The Guardian about positive externalities and copyright law [5]. I think that he didn t choose the best way of framing this issue, but he makes some very interesting points anyway. Andrew Norton wrote an interesting article about how to reduce corruption in the police force and other government agencies [6]. A large part of this is based on making them subject to the same laws as everyone else, which seems to be a radical idea. Valerie Aurora wrote an insightful blog post about suicide [7]. Emily Oster gave an interesting TED talk about the factors that determine the spread of AIDS in Africa [8]. It s quite different to what you probably expect.

• [1] http://www.eyrie.org/~eagle/journal/2012-12/006.html
• [2] http://www.newyorker.com/reporting/2013/01/07/130107fa_fact_green
• [3] http://tinyurl.com/apovrka
• [4] http://www.youtube.com/watch?v=sXpbONjV1Jc
• [5] http://tinyurl.com/a7rutft
• [6] http://tinyurl.com/a227fvg
• [7] http://tinyurl.com/a5zo6tn
• [8] http://tinyurl.com/3f7283s

For one of my classes, the final project is to work on a personal project for four weeks. Since I have never done mobile programming before, I decided I would use this project as a chance to teach myself the basics of Android development. Paul Tagliamonte recently blogged about a Google Summer of Code project idea for a Debian Android application. It was this post that motivated me to create a Debian Android application for my final project. We are only in the middle of week one, but my plan is to have at least a basic BTS and PTS interface done by the end of the project. Then, depending on a few things, I hope to turn it into a Google Summer of Code project or simply continue developing it on my own. As I mentioned, I am only a few days into the project. One of the first hurdles I encountered was interacting with the SOAP interfaces available for the PTS and BTS. There are a few examples available on the wiki, but there are not any for Java. A Google search also failed to return any clear and simple results. As a result, I decided I would create a Python script that would accept requests from the Java Android application via a REST API and pass them on to the SOAP API before returning the result as JSON. Before I could finish writing the script, Paul mentioned that he had already written a similar program a few months ago. I immediately stopped working on my script and began preparing a patch for Paul's program to add support for some missing PTS SOAP functions as well as the entire BTS. After a few hours, I had the ability to query the PTS and BTS via a REST API from Java. While I normally prefer to use VIM for my programming, I decided to follow Google's recommendation and use Eclipse. I was able to follow their guide to get the SDK setup and a simple demo application running. One of the few hurdles I encountered was when I wanted to make web requests. Due to the ability for such requests to stall, you are required to perform them in a separate thread. This only becomes aparant when you try to test your application on an actual device; the emulator will happily run the process in the main thread. Regardless, I was eventually able to modify the demo application to allow me to make requests to my Python REST server and then parse and display the result. Here are some screenshots of the application running. If you have any feature suggestions, questions, or comments, feel free to send me an email (nhandler@debian.org). The source code for the Android application is currently not available, but I plan to put it up in a git repository sometime in the near future. The source code for the Python script that provides a REST API to access the PTS and BTS SOAP interface is available on GitHub.

Recently, I was wondering how many Debian Developers are actively working on RC bugs in some way or another in the time period of the last release (squeeze) to now (shortly? before wheezy). I therefore grabbed the mailing list archives of debian-bugs-dist@ from gmane, used only those messages whose X-Debian-PR-Message header matches an RC bug (list retrieved from UDD) and then attributed the message counts to the appropriate Debian Developer. I am sure that there are subtle mistakes in the data I retrieved and that there most likely is a better way to achieve the same results, but this is only to get a trend and should be good enough for that. So, it turns out that 514 different Debian Developers have sent messages regarding RC bugs since squeeze. That s about half of our 985 total active Debian Developers. I would love to show a good histogram of the actual message counts (not sure how well received showing the raw data is ), but I suck at visualizing such data in a compact way. Is there anyone familiar with R (or other free data visualization tools) and willing to help? I can send you the CSV file, just send me an email to stapelberg@.

The graph below is generated from popcon submissions. Since they include the version of the popularity-contest package, one can determine the Debian release that was used by the submitter (a new version of the popularity-contest package is generally uploaded just after the release to make that tracking possible). The graph is similar to the one found on popcon, except that versions newer than the latest stable release are aggregated as testing/unstable . Comments:

• Popcon submitters might not be representative of Debian users, of course.
• There s quite a lot of testing/unstable users, and their proportion is quite stable:
  • Today: testing/unstable: 43119 submissions (31.4%); squeeze: 75454 (54.9%); lenny: 13603 (9.9%)
  • 2011-02-04 (just before the squeeze release): testing/unstable: 29012 (29.7%); lenny: 57262 (58.6%); etch: 10032 (10.3%)
  • 2009-02-13 (just before the lenny release): testing/unstable: 30108 (36.9%); etch: 49996 (61.2%)
• I don t understand why the number of Debian stable installations does not increase, except when a new release is made. It s as if people installed Debian, upgraded directly to testing, and switched back to tracking stable after the release. Or maybe people don t update their systems? A more detailed analysis could be done by looking at the raw popcon data.
• Upgrading to the next stable release takes time. Looking at the proportion of users still using oldstable one year after the release, it would be better not to remove oldstable from mirrors too early.

Scripts are available on git.debian.org.

The annoucement below just went to the R-SIG-Finance list. More information is as usual at the R / Finance page:

Now open for registrations: R / Finance 2013: Applied Finance with R
May 17 and 18, 2013
Chicago, IL, USA
The registration for R/Finance 2013 -- which will take place May 17 and 18 in Chicago -- is NOW OPEN! Building on the success of the previous conferences in 2009, 2010, 2011 and 2012, we expect more than 250 attendees from around the world. R users from industry, academia, and government will joining 30+ presenters covering all areas of finance with R. We are very excited about the four keynotes by Sanjiv Das, Attilio Meucci, Ryan Sheftel and Ruey Tsay. The main agenda (currently) includes seventeen full presentations and fifteen shorter "lightning talks". We are also excited to offer five optional pre-conference seminars on Friday morning. To celebrate the fifth year of the conference in style, the dinner will be held at The Terrace of the Trump Hotel. Overlooking the Chicago river and skyline, it is a perfect venue to continue conversations while dining and drinking. More details of the agenda are available at:

http://www.RinFinance.com/agenda/

Registration information is available at

http://www.RinFinance.com/register/

and can also be directly accessed by going to

http://www.regonline.com/RFinance2013

We would to thank our 2013 Sponsors for the continued support enabling us to host such an exciting conference:

International Center for Futures and Derivatives at UIC Revolution Analytics
MS-Computational Finance at University of Washington Google
lemnica
OpenGamma
OneMarketData
RStudio

On behalf of the committee and sponsors, we look forward to seeing you in Chicago!

Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich

See you in Chicago in May!!