UPDATE I removed tracker, when I rebooted my machine again my memory cache got ~1000M again, and again, and again. I didn t knew it existed until recently, that I saw all my memory was eaten up and suddenly I was using my SWAP instead of my memory, and it was fully loaded. What s my surprise? I have 2G in memory and 1113M of it was cache, and 1G of swap full as well. The worst thing is that I reboot my machine and without starting anything I get 903M of cache full, out of nowhere! I start to track what s the issue, where s the leak, and found that if I killed tracker-store early then my memory stopped being loaded of cache. There s a bug, already reported, it s #612242 and the workaround given is to nuke the database with tracker-control -r. It worked. Now my cache is not full, but since I just did it I don t know if in some days my tracker-cache will be full again and eating all my memory. Just wanted people know there was a work-around at least and you could use your computer again.

... when you join a team and then every other team member stops working.

(There's a possibility that you are doing such a great job that there's no need of the others, but think about the case when your work or your way of working is killing them.)

Farnell are now shipping in volume worldwide and will shortly be relaxing the restriction to one Raspberry Pi per customer: RS are also in the process of inviting those with expressions of interest in time order.

The OS of choice is currently Debian - the developers at Broadcom in Cambridge are releasing SD card images fairly regularly at the moment.

There is a large amount of interest worldwide and this before release for education - this can only be good.

[Mine is due week beginning 28 May :) ]

Every year my parents buy a book of vouchers for various businesses in Victoria. It s one of those deals where businesses (mostly restaurants) pay for advertising space to have their tear-off vouchers in the book (which typically allow a discount of between $5 and $30) and the customers buy the book for something like $40 (I m not really sure as I don t pay). Every year I take my pick of the vouchers that don t suit my parents, the Nando s chain of chicken and chips restaurants that specialises in Peri-Peri spicy sauce [1] is one that doesn t suit my parents (they prefer the traditional English-Australian food). The Nando s vouchers say Enjoy one complimentary 1/4 flame-grilled peri-peri chicken item when another 1/4 flame-grilled peri-peri chicken item is purchased with no explanation of exactly what an item is. Every Nando s store that I ve been to in the past has interpreted item as chicken and chips, usually they include the drink that comes with the quarter chicken meal in the item that is free. I can do without a second soda as it s really cheap from the supermarket and I m not going to drink two at one meal anyway so I m not bothered when someone interprets the voucher as not involving a free drink. But the lack of chips is annoying. At the Nando s store on Swanston St between La Trobe St and Little Lonsdale St they interpret item as being just the 1/4 chicken. I think that most people would regard this as an unusual interpretation. If the intent was to only offer 1/4 chicken then the voucher could have stated that a free 1/4 chicken was offered and removed all doubt. The fact that the voucher says a free 1/4 flame-grilled peri-peri chicken item instead of offering a free Quarter Chicken (which is the description for chicken on it s own on the Nandos menus) seems to be a reasonable indication that more than just the free chicken is offered. I won t be attending the Nandos store on Swanston St again and recommend that others avoid it too. Failing to offer the full value on the voucher is annoying, it decreases the value for money (which is a problem given how expensive Nandos is), and it makes me wonder what other cost-saving measures might be used at that store. I ve got a stack of vouchers (many of which will expire before being used) and the Melbourne CBD has many places to eat.

• [1] http://www.nandos.com.au/

No related posts.

• Hebrew completes level 1
• Marathi completes level 1
• Lao completes level 1
• Slovenian back from hell and completes level 1..:-)
• More progress for Hungarian

Status for D-I level 1 (core D-I files):

• 45 languages 100%: ar ast be bg bn bs ca cs de el eo es et fa fr gu he hi id it ja kk km kn ko lo mr nb nl pl pt pt_BR ru si sk sl sr sv te th tr uk vi zh_CN zh_TW
• 2 languages 99%: da ta
• 4 languages 97%: eu fi ga hu
• 4 languages 95%: dz is mk ro
• 1 language 92%: ml
• 1 language 91%: pa
• others are 90% or below

Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.):

• 29 languages 100%: ast be bg ca cs da de eo es fa fr gu he id is it ja kk km nl pl pt ru si sk sv tr uk zh_CN
• 3 languages 99%: nb sl th
• 5 languages 98%: dz eu hr pt_BR ro
• 1 language 97%: ta
• 2 language 96%: vi zh_TW
• 2 langauges 95%: el fi
• 2 languages 94%: ar gl
• 6 languages 92%: bn bs hu ko ne sr
• 6 languages 91%: ga ka lt mk mr te
• others are 90% or below

Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

• 35 languages 100%: ast be bg bs ca cs da de el eo es fa fi fr ga gl he hr id is it ja kk km nb nl pl pt ru sk sr sv th tr zh_CN
• 2 languages 98%: hu uk
• others are 90% or below

Full 100% completeness (hall of fame) for 22 languages: Asturian, Belarusian, Bulgarian, Catalan, Czech, German, Esperanto, Spanish, French, Indonesian, Italian, Japanese, Kazakh, Khmer, Dutch, Polish, Portuguese, Russian, Slovak, Swedish, Turkish, Simplified Chinese

I have no idea if the literal translation carries over, but to be on the safe side: I like what I've seen up to now. First impressions are always the most honest (and I may have sketchy access to the Internet at best in the coming days) so here goes. I haven't even been here for 24 hours so take everything I say with a sack of salt.

• I was told, repeatedly, that Russians tend to keep even more to themselves than us Germans; unless they see a reason to open up, that is. By and large, that seems to be true. Thankfully, "a reason to open up" seems to include "these guys look lost and I want to practice my English". This led to a Russian asking me what the best German beer in a random supermarket was while I ended up with what he thinks is the best Russian beer. Yay.
• As expected, most Russians don't speak even the tiniest shred of English. Sometimes, they even keep talking in Russian after you've made it clear again and again that you don't understand them. The same thing happened to me in the middle of nowhere in India; it's strange, but I suspect (I don't know!) that some people are simply not very firm with the concept of different people speaking different languages and that someone can't speak their own.
• Moscow's Metro system is very nice
  • They have a circle line. Why doesn't Munich have a circle line? Again: why doesn't Munich have a circle line?
  • All lines have two dedicated tracks, one for each direction
  • Trains arrive and leave every few minutes. I don't think we waited more than two minutes for the subway today, even though we saw the prior train depart. The monorail has longer waiting times, but I'd say that's five to ten minutes, tops.
  • Once you figure out how their signs etc. work, it's very simple and quite efficient to follow them:
    • Every line has a color. Follow the colored bars on signs.
    • Once you reach the color/line you want, look at the tunnel walls. There's an arrow depicting the stations in the direction of this tunnel; your station is marked red. Below every station where you can board other trains, there's a list of possible destinations right underneath the station name. The newer trains have the same arrow (sans transit lists) with a blinking indicator of where you are.
  • The tunnels are deeply underground. I knew those tunnels were designed to function as atomic bomb shelters if the need arose. Now I believe that this would actually work.
  • One big minus is that people in a wheelchair or similar are SOL. Escalators, stairs, uneven ground, gaps and height differences between station floor and train, you name it. Everything that shouldn't be there is there and plenty. Things that should be there are not. Accessibility does not seem to be a concern at all.
• Labour must be incredibly cheap. Every escalator has its own operator, watching the moving stairs in theory and a tablet/smartphone in practice. You have one person selling metro tickets and right beside that someone who watches the ticket-checking gates.
• The local McDonalds (we needed a trusted default) is swarming with employees. It looks chaotic, but it's quick. Also, they put tons of onions and different sauces into and onto stuff. Me gusta.
• Once you start getting the hang of converting Cyrillic into Latin characters in your head, you can read the words out as if they were German. People will understand you without problem. Useful, that...
• There seems to be a social or religious agreement to not inflate car tires properly. I have literally never in my life seen so many cars zipping around with half-flat tires.
• (Many) Russians are tall. I am used to being the tallest person around; I will meet someone taller every few weeks or months, in Germany. Today, I saw three people who were taller than me; two of similar size. Again, this is literally the first time in my adult life that this has happened in such a short time.
• Stuffing things into your checked-in shoes to save space is good. Not removing a piece of cloth from a shoe and not realizing it while walking all around Moscow... hurts.
• Before buying anything at a street stall, ask for the price; also, carrying a calculator to show numbers to others is useful.
• Blueberries don't seem to be very special. While Nordic countries tend to have saner prices than Germany, Russia is cheap when it comes to blueberries.
• All food that's been imported from Germany is priced insanely high. 20 for a box of cheap chocolates? Check. 50 for four packets of dried fruit? Check.
• As an amusing aside, the supermarket was swarmed with and subsequently deadlocked by Chinese (yes, they spoke Mandarin as far as I could tell) who were stockpiling chocolate in ridiculous quantities. We were in line for about 45 minutes; the store, a two-story, higher-end location, ran out of change. As we paid by card, that didn't affect us other than the long waiting time. Chocolate in China must be really bad, really expensive, practically unavailable or a mix of the three. I guess we will find out in two weeks :)

Cross Compiling with MultiArch Congrats to the Ubuntu Folk for the new LTS release. Incidentally this is also the first release where our work on MultiArch bears fruit. We can now cross-compile relatively easily without resorting to hacks like scratchbox, qemu chroot or dpkg-cross/xdeb. Lets show short practical guide on cross-building Qemu for armhf. The instructions refer to precise, but the goodiness is on the way to Debian as well. Biggest missing piece being the cross-compiler packages, which we have an Summer of Code project. The example is operated in a chroot to avoid potentially messing up your working machine. Qemu-linaro is not a shining example, as cross-building it doesn't work out of box. But that is educational, it allows me to show what kind of issues you can bump into, and how to fix them.

 $ sudo debootstrap --variant=buildd precise /srv/precise

Edit the /srv/precise/etc/apt.sources.list to the following (replace amd64 with i386 if you made an i386 chroot)

deb [arch=amd64] http://archive.ubuntu.com/ubuntu precise main universe
deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports precise main universe
deb-src http://archive.ubuntu.com/ubuntu precise main universe

Edit the /srv/precise/etc/dpkg/dpkg.cfg.d/multiarch by adding the following line:

foreign-architecture armhf

Finally disable install of recommends by editing /srv/precise/etc/apt/apt.conf.d/10local:

APT::Install-Recommends "0";
APT::Install-Suggests "0";

Install the armhf crosscompiler the chroot

 $ sudo chroot /srv/precise/
 # unset LANG LANGUAGE
 # mount -t proc proc /proc
 # apt-get update
 # apt-get install g++-arm-linux-gnueabihf pkg-config-arm-linux-gnueabihf

Get the sources and try to install the cross-buildeps:

 # cd /tmp
 # apt-get source qemu-linaro
 # cd qemu-linaro-*
 # apt-get build-dep -aarmhf qemu-linaro

As we see, the build-dep bombs out ugly, with a them of "perl" being unable to be installed. This is because apt-get can't figure out if we should install and armhf or amd64 version of perl. We don't use the required syntax yet in Build-Dep line, "perl:any", as dpkg and apt in previous released don't support it. Thus back porting would no longer be possible. One way to fix it, would be to drop perl build-dep, as perl is already pulled by other build-deps. But lets instead show howto install it the build-deps manually. First we build system build-deps, then target architecture ones:

 # apt-get install debhelper texinfo
 # apt-get install zlib1g-dev:armhf libasound2-dev:armhf libsdl1.2-dev:armhf libx11-dev:armhf libpulse-dev:armhf libncurses5-dev:armhf libbrlapi-dev:armhf libcurl4-gnutls-dev:armhf libgnutls-dev:armhf libsasl2-dev:armhf uuid-dev:armhf libvdeplug2-dev:armhf libbluetooth-dev:armhf

And try the build[1]:

 # dpkg-buildpackage -aarmhf -B

Which sadly errors out. Turns out the cross-build support in debian/rules is broken. Instead of --cc we need to feed an --cross-prefix to the ./configure of qemu. Edit the debian/rules with replacing

-  conf_arch += --cc=$(DEB_HOST_GNU_TYPE)-gcc --cpu=$(QEMU_CPU)
+  conf_arch += --cross-prefix=$(DEB_HOST_GNU_TYPE)-

Optional: Since we are cross-compiling from a multicore machine, lets also add parallel building support, by changing the override_dh_auto_build: rule to have --parallel flags in debian/rules as well:

override_dh_auto_build:
        # system build
        dh_auto_build -B system-build --parallel
ifeq ($(DEB_HOST_ARCH_OS),linux)
        # user build
        dh_auto_build -B user-build --parallel

        # static user build
        dh_auto_build -B user-static-build --parallel

Try the build again:

 # export DEB_BUILD_OPTIONS=parallel=4 # I have dual-core hyperthreading machine, build with all four threads
 # time dpkg-buildpackage -aarmhf -B
 ...
dpkg-buildpackage: binary only upload (no source included)

real    18m53.425s
user    65m42.570s
sys     2m50.383s

The Native build of qemu-linaro took 4h 11min. [1] You should not build as root - but to keep instructions short, I'm not explaining howto add and use a unprivileged user in a chroot. Do as I *say*, not as I *do*!

Debian, free software, and critical consumption As mentioned in my last report, about a month ago I've been interviewed (in Italian) for la Repubblica, a major general-interest Italian newspaper. Matteo Cortese has kindly contributed an English translation of the interview (thanks!), which I've just made available. If you're a Free Software enthusiast, there is probably nothing new in there for you. But for a different public the story is quite another. In many countries it is still very difficult to find room on general-interest newspapers to explain why Free Software matter to people, and how not caring about it will lead consumers to progressively lose their rights while software become more and more common in the stuff they buy. So many thanks to journalist like Giulia Belardelli who show a genuine interest in these topics and try to bring them "to the masses".

Learning from the Future of Component Repositories ( Pietro Abate, Roberto Di Cosmo, Ralf Treinen and Stefano Zacchiroli ) has been accepted to be presented at CBSE 2012 (26-28 June, Bertinoro, Italy)

Abstract

  An important aspect of the quality assurance of large component repositories
  is the logical coherence of component metadata. We argue that it is possible
  to identify certain classes of such problems by checking relevant properties
  of the possible future repositories into which the current
  repository may evolve. In order to make a complete analysis of all possible
  futures effective however, one needs a way to construct a finite set of
  representatives of this infinite set of potential futures. We define a class
  of properties for which this can be done.
  We illustrate the practical usefulness of the approach with two quality
  assurance applications: (i) establishing the amount of  forced upgrades''
  induced by introducing new versions of existing components in a repository,
  and (ii) identifying outdated components that need to be upgraded in order to
  ever be installable in the future. For both applications we provide
  experience reports obtained on the Debian distribution.

The tools presented in this paper (outdated and challenges) are already in Debian as part of the 'dose-extra' package.

LWN has an interesting article comparing recent developments in the Linux world to the Unix Wars that essentially killed every proprietary Unix system [1]. The article is really interesting and I recommend reading it, it s probably only available to subscribers at the moment but should be generally available in a week or so (I used my Debian access sponsored by HP to read it). A comment on that article cites my previous post about the reliability of RAID [2] and then goes on to disagree with my conclusion that using the filesystem for everything is the right thing to do. The Benefits of Layers I don t believe as strongly in the BTRFS/ZFS design as the commentator probably thinks. The current way my servers (and a huge number of other Linux systems) work of having RAID to form a reliable array of disks from a set of cheap disks for the purpose of reliability and often capacity or performance is a good thing. I have storage on top of the RAID array and can fix the RAID without bothering about the filesystem(s) and have done so in the past. I can also test the RAID array without involving any filesystem specific code. Then I have LVM running on top of the RAID array in exactly the same way that it runs on top of a single hard drive or SSD in the case of a laptop or netbook. So Linux on a laptop is much the same as Linux on a server in terms of storage once we get past the issue of whether a single disk or a RAID array is used for the LVM PV, among other things this means that the same code paths are used and I m less likely to encounter a bug when I install a new system. LVM provides multiple LVs which can be used for filesystems, swap, or anything else that uses storage. So if a filesystem gets badly corrupted I can umount it, create an LVM snapshot, and then take appropriate measures to try and fix it without interfering with other filesystems. When using layered storage I can easily add or change layers when it s appropriate. For example I have encryption on only some LVs on my laptop and netbook systems (there is no point encrypting the filesystem used for .iso files of Linux distributions) and on some servers I use RAID-0 for cached data. When using a filesystem like BTRFS or ZFS which includes subvolumes (similar in result to LVM in some cases) and internal RAID you can t separate the layers. So if something gets corrupted then you have to deal with all the complexity of BTRFS or ZFS instead of just fixing the one layer that has a problem. Update: One thing I forgot to mention when I first published this is the benefits of layering for some uncommon cases such as network devices. I can run an Ext4 filesystem over a RAID-1 array which has one device on NBD on another system. That s a bit unusual but it is apparently working well for some people. The internal RAID on ZFS and BTRFS doesn t support such things and using software RAID underneath ZFS or BTRFS loses some features. When using DRBD you might have two servers with local RAID arrays, DRBD on top of that, and then an Ext4 filesystem. As any form of RAID other than internal RAID loses reliability features for ZFS and BTRFS that means that no matter how you might implement those filesystems with DRBD it seems that you will lose somehow. It seems that neither BTRFS nor ZFS supports a disconnected RAID mode (like a Linux software RAID with a bitmap so it can resync only the parts that didn t change) so it s not possible to use BTRFS or ZFS RAID-1 with an NBD device. The only viable way of combining ZFS data integrity features with DRBD replication seems to be using a zvol for DRBD and then running Ext4 on top of that. The Benefits of Integration When RAID and the filesystem are separate things (with some added abstraction from LVM) it s difficult to optimise the filesystem for RAID performance at the best of times and impossible in many cases. When the filesystem manages RAID it can optimise it s operation to match the details of the RAID layout. I believe that in some situations ZFS will use mirroring instead of RAID-Z for small writes to reduce the load and that ZFS will combine writes into a single RAID-Z stripe (or set of contiguous RAID-Z stripes) to improve write performance. It would be possible to have a RAID driver that includes checksums for all blocks, it could then read from another device when a checksum fails and give some of the reliability features that ZFS and BTRFS offer. Then to provide all the reliability benefits of ZFS you would at least need a filesystem that stores multiple copies of the data which would of course need checksums (because the filesystem could be used on a less reliable block device) and therefore you would end up with two checksums on the same data. Note that if you want to have a RAID array with checksums on all blocks then ZFS has a volume management feature (which is well described by Mark Round) [3]. Such a zvol could be used for a block device in a virtual machine and in an ideal world it would be possible to use one as swap space. But the zvol is apparently managed with all the regular ZFS mechanisms so it s not a direct list of blocks on disk and thus can t be extracted if there is a problem with ZFS. Snapshots are an essential feature by today s standards. The ability to create lots of snapshots with low overhead is a significant feature of filesystems like BTRFS and ZFS. Now it is possible to run BTRFS or ZFS on top of a volume manager like LVM which does snapshots to cover the case of the filesystem getting corrupted. But again that would end up with two sets of overhead. The way that ZFS supports snapshots which inherit encryption keys is also interesting. Conclusion It s technically possible to implement some of the ZFS features as separate layers, such as a software RAID implementation that put checksums on all blocks. But it appears that there isn t much interest in developing such things. So while people would use it (and people are using ZFS ZVols as block devices for other filesystems as described in a comment on Mark Round s blog) it s probably not going to be implemented. Therefore we have a choice of all the complexity and features of BTRFS or ZFS, or the current RAID+LVM+Ext4 option. While the complexity of BTRFS and ZFS is a concern for me (particularly as BTRFS is new and ZFS is really complex and not well supported on Linux) it seems that there is no other option for certain types of large storage at the moment. ZFS on Linux isn t a great option for me, but for some of my clients it seems to be the only option. ZFS on Solaris would be a better option in some ways, but that s not possible when you have important Linux software that needs fast access to the storage.

• [1] http://lwn.net/Articles/494248/
• [2] http://etbe.coker.com.au/2012/02/06/reliability-raid/
• [3] http://www.markround.com/archives/37-ZFS-as-a-volume-manager.html

Related posts:

1. Starting with BTRFS Based on my investigation of RAID reliability [1] I have...
2. ZFS vs BTRFS on Cheap Dell Servers I previously wrote about my first experiences with BTRFS [1]....
3. Reliability of RAID ZDNet has an insightful article by Robin Harris predicting the...

Some more progress since my last entry.... Hungarian, Hebrew, Lao, Marathi completed. Got signs of life from Galician, Croatian, Georgian, Malayalam, Nepali translators. Got offers to help for Welsh, Lithuanian, Romanian. At this very moment, it means that I would deactivate 17 languages:

• Amharic (9f59u, 14f17u)
• Welsh (54f118u, 32f47u)
• Galician (24f42u, 6f9u)
• Croatian (33f51u, 6f9u)
• Georgian (34f79u, 10f21u)
• Kurdish (29f57u, 6f22u)
• Lithuanian (24f27u, 12f20u)
• Latvian (40f40u, 6f9u)
• Malayalam (5u in sublevel 2 only!)
• Nepali (33f86u, 10f21u)
• Norwegian Nynorsk (30f66u, 13f23u)
• Punjabi (28f58u, 1f)
• Romanian (2f1u, 1f)
• Slovenian (21f10u, 6f9u)
• Albanian (36f82u, 13f23u)
• Tamil (2f2u, 1f)
• Tagalog (35f86u, 24f39u)

In the late 90s, google became popular for one reason: because they had a no-nonsense frontpage that loaded quickly and didn't try to play with your mind. Well, at least that was my motivation for switching. The fact that they were using a revolutionary new search algorithm which changed the way you search the web had nothing to do with it, but was a nice extra. Over the years, that small hand-written frontpage has morphed into something else. A behind-the-scenes look at the page shows that it's no longer the hand-written simple form of old, but something horrible that went through a minifier (read: obfuscator). Even so, a quick check against the Internet Wayback machine shows that the size of that page has increased twenty-fold, which is a lot. But I could live with that, since at least it looked superficially similar. Recently, however, they've changed their frontpage so that search-as-you-type is enabled by default. Switching that off requires you to log in. So, you have a choice between giving up your privacy by logging in before you enter a search term, or by having everything you type, including any typos and stuff you may not have confirmed yet, be sent over to a data center god knows where. Additionally, at the first character you type, the front page switches away to the results page, causing me to go "uh?!?" as I try to find where they moved my cursor to. This is annoying. Duckduckgo doesn't do these things; and since they also don't do things like combining my typing skills, phone contact list, calendar, and chat history to figure out that I might be interested in a date, I'm a lot more comfortable using them. So a few days ago, I decided to switch my default search engine in chromium to duckduckgo. It still feels a bit weird, to be using a browser written by one search engine to search something on another; but all in all, it's been a positive experience. And the fact that wikipedia results are shown first, followed by (maybe) one ad, followed by other search results, is refreshing. We'll see how far this gets us.

I have been working since a long time on trying to solve random crashes on the OCaml Forge. I have first suspected failing hardware to be the cause of it, but found no evidence about that. In despair of a solution, I have installed cacti to investigate the issue. The good news is that it has allowed me to catch a pretty nice graph of a crash. Just before the crash the average load was 200... My conclusion was that too many processes were running at the same time. So I start to hunt processes that load the server for nothing. One of them was darcsweb. This process doesn't really create a load, but it calls darcs for various operations and most of them are quite expensive. The most expensive one is darcs diff. I first turn on the caching of darcsweb, which already reduce the number of invocation of darcs. But it doesn't make a real difference (except that the website was faster to load). I continued to investigate. In order to reduce globally the load of the server, I installed various robots.txt to prevent crawler to call diff for all VCS on the forge. Crawler traffic is 10 times the normal traffic and indexing diff in Google is not very interesting. It doesn't make a real difference. I installed a script to analyze all the peak load above 2. The peaks happen every hour and are more or less important (from 4 to 10). I discovered that this peak were related to the hourly cronjob of FusionForge that fixed repository permissions. I was pretty surprise because updating permissions should no generate this load. This morning, I had a simple idea. There are a lot of process on the server and one of them (the bzr daemon, loggerhead) eats a big chunk of memory (at least never frees it). I just had a quick at the "buffers" memory... Only 4MB ! I just restarted loggerhead. The improvement made on robots.txt makes it a lot more stable with regard to memory consumption, since we don't run bzr diff anymore. The "buffers" memory is now at 100MB and guess what ! No more peaks... Here is the result: Conclusion: sometimes the cause of a high load lies in a single number...

Shogun has received an outstanding 9 slots in this years google summer of code. Thanks to google and the hard work of our mentors ranking and discussing with the applicants - we were able to accept 8 talented students (We had to return one slot back to the pool due to not having enough mentors for all tasks. We indicated that octave gets the slot so lets hope they got it and will spend it well :). Each of the students will work on rather challenging machine learning topics. The accepted topics and the students attacking them with the help of there mentors are

• Kernel Two-sample/Dependence test
  • Student: Heiko Strathmann
  • Mentor: Arthur Gretton, Soeren Sonnenburg
  • Abstract
• Implement multitask and domain adaptation algorithms
  • Student: Sergej Lisityn
  • Mentor: Christian Widmer
  • Abstract
• Implementation of / Integration via existing GPL code of latent SVMs.
  • Student: Viktor Gal
  • Mentor: Alexander Binder
  • Abstract
• Bundle method solver for structured output learning
  • Student: Michal Uricar
  • Mentor: Vojtech Franc
  • Abstract
• Built generic structured output learning framework
  • Student: Fernando Jose Iglesias Garcia
  • Mentor: Nico Goernitz
  • Abstract
• Improving accessibility to shogun
  • Student: Evgeniy Andreev
  • Mentor: Soeren Sonnenburg
  • Abstract
• Implement Gaussian Processes and regression techniques
  • Student: Jacob Walker
  • Mentor: Oliver Stegle
  • Abstract
• Built generic multiclass learning framework
  • Student: Chiyuan Zhang
  • Mentor: Cheng Soon Ong
  • Abstract

We are excited to have them all in the team! Happy hacking!

In an article today published by Computerworld Norway, the photographer Eirik Helland Urke reports that the video editor application included with HTC One X have some quite surprising terms of use. The article is mostly based on the twitter message from mister Urke, stating:

"Dr y brukeravtale: HTC kan bruke MINE redigerte videoer kommersielt. Selv kan jeg KUN bruke dem privat."

I quickly translated it to this English message:

"Arrogant user agreement: HTC can use MY edited videos commercially. Although I can ONLY use them privately."

I've been unable to find the text of the license term myself, but suspect it is a variation of the MPEG-LA terms I discovered with my Canon IXUS 130. The HTC One X specification specifies that the recording format of the phone is .amr for audio and .mp3 for video. AMR is Adaptive Multi-Rate audio codec with patents which according to the Wikipedia article require an license agreement with VoiceAge. MP4 is MPEG4 with H.264, which according to Wikipedia require a licence agreement with MPEG-LA. I know why I prefer free and open standards also for video.

This project is about extension of the Debian infrastructure with ability to build packages with clang. The key idea is to have an alternative way to build packages and easily switch between clang and gcc/g++. Clang is faster than gcc, uses less memory, and produces faster code. It is getting better with time. It is available under the BSD license. It is well documented. It can help programmers find and analyze easily their errors, because clang has much more detailed error and warning messages and it allows better diagnostics. It also provides a good alternative for programmers using gcc in the coding and compiling processes. It enforces better code quality. In the compiling process, compiler choice is usually done by setting the environment variable CC. When Makefile is generated, it contains initialization of the CC variable based on the current environment. If CC is not set, the default compiler is gcc. CC is always used by make. I proved this with tests (I set CC=/usr/bin/clang).
There must be an easy way to switch the default compiler between gcc/g++ and clang. One way would be by issuing a command like
dpkg-reconfigure default-compiler . I think that debuild, sbuild can be changed to take optional compiler argument (something like clang gcc). If this argument is not specified, the default compiler is used (according to CC)
Also I think that when the default compiler is set to clang, some special cases should be checked.
Example: There is gcc hard coded in the Makefile. In this case there should be a dialog box that offers several options to choose from:
1. Leave gcc in this line.
2. Change gcc with the CC variable.
3. Edit with the default text editor.
I have seen the 3rd option in many applications, like svn or crontab. When some file modification is required, the default editor is launched to modify the file.
Also, I ll check what are the compiling problems of the current packages that can t compile by just changing gcc with clang. This way I ll see what checks for special cases to implement.

Over the past months we have seen the end of two Debian derivatives. In January the news came that Junta de Extremadura (Spain) were abandoning the development of LinEx and switching to Debian itself. Early in March the Debian derivatives census scripts noted that the Vanillux apt repository was down. Fabrice Quenneville then confirmed that he had to put a hold on the Vanillux project due to the cost of bandwidth and servers. In addition the future of StormOS is in doubt after Illumian was created. StormOS is a port of Debian to the OpenSolaris kernel and Illumian is similar but uses only apt/dpkg and repackages everything else. The LinEx page in the Debian derivatives census did not reveal much information about the project that would have been useful to Debian, in particular it does not list any apt repositories. As a result it is quite hard to say what has potentially been lost. Two mails from people close to or involved in the project indicate that much of the LinEx distribution was already merged into Debian. It is probably safe to say that everything of value has been merged into Debian, including at least one of the developers involved in LinEx. Vanillux was a small distribution with few developers according to the Google caches of their website. If we look at the patches created by the derivatives census scripts, we can see that the 5 source packages that were possibly derived from Debian source packages were simply imported from Christian Marillat's repository of non-free, patented, legally restricted and multimedia-related packages. The patches indicate that 3 source packages were forked from Debian and that 2 source packages were done from scratch. The forked packages seem to be mainly about enabling support for proprietary and patented codecs in several programs. This is a surprisingly small number of altered/differing packages, so what else could Vanillux folks have been working on? It appears that there were 12 new source packages that were not derived from Debian source packages. These appear to be mainly multimedia-related packages, one font imported from an Ubuntu PPA, some syslinux themes and a metapackage. The multimedia packages are all from Christian Marillat's repository. The Debian multimedia team is working hard on bringing multimedia related software to Debian and welcomes help with that. The font (Cantarell) is now in Debian under a different source package name. The metapackage appears to be very similar to from the ubuntu-meta source package from Ubuntu that uses germinate. So at first glance, the contribution of Vanillux to the world of Linux distributions appears to be in the area of artwork and package selection. The artwork produced is basically Vanillux branding and is thus not usable by Debian, although we would like more artists involved in Debian. The meta-package is not easily useful to Debian since we use a different mechanism for our task packages and our task packages have already been updated for the GNOME 3 transition. Still, the amount of difference between to source packages is relatively small. So, what else? Perusing the diff between the list of source packages exposed by the Packages and Sources files, I noted that a number of binary packages in the Packages files reference source packages not listed in the Sources files. When I saw picasa in that list, it occurred to me that Vanillux might have directly imported some binary packages without their corresponding source packages. Perusing their apt metadata confirms that they have imported some binary packages of non-free software directly from vendors. These include Google Desktop, Opera, Picasa and VirtualBox 3.2. The rest of the packages in the diff appear to be caused by some sort of issue with the import process from Debian and other apt repos. Most of the above could be achieved by adding some external commerical repositories to a normal Debian system or by merging some of those repositories (such as the Opera one) into Debian. The interesting thing about the Debian derivatives census is that it allows us to perform analyses like these and figure out what patches and packages we might like to integrate into Debian. In this way we can salvage some of the value of our derivatives if they abandon ship. If you have any ideas or code for improving the census or are running a Debian derivative, please join us at the Debian derivatives frontdesk.

The work on my bathroom is complete. The two weeks of noise and mess were well worth it. The old and unpleasant room is now completely different. The only issue I see is that I've managed to fill up the storage already. I'm particularly impressed with the sink, but special mention must go to the step, and the light switch (this is touch-sensitive and apparently incapable of electrocuting me). Rest assured that despite all the changes none of my dinosaurs are missing! Oh well I can always mount a new shelf, or three. ObQuote: - "Tell me of your homeworld, Usul.", Dune.

I ve uploaded yesterday the rakudo package version 0.1~2012.01-1 to unstable. It ships the Rakudo upstream release from January, running on top of the Parrot stable release 4.0.0 (which was uploaded earlier). Rakudo is a compiler that implements the Perl 6 specification and runs on top of the Parrot virtual machine (if you are interested on Perl 6 you may have a look at some nice articles, and at the talk of Damian Conway, about Perl 6). This is the first upload since a few months, and the first release being uploaded to Debian based on the nom (New Object Model) development branch of Rakudo, which opened the door for substantial performance improvements. This release brings other nice things too, such as the support for meta-programming, better package and exception handling and more. The latest upstream release 2012.04 (which brings, among other things, improvements in startup times thanks to bounded serialization) has been released a few days ago and uses the new Parrot stable release 4.3.0 (which has been released about a week ago), so we hope to test and upload both in time for the Wheezy freeze (and hopefully we ll be a bit more timely for future updates too).