Recently the upstream Linux kernel released a fix for a serious security vulnerability (CVE-2012-0056) without coordinating with Linux distributions, leaving a window of vulnerability open for end users. Luckily:

• it is only a serious issue in 2.6.39 and later (e.g. Ubuntu 11.10 Oneiric)
• it is only local
• it requires execute access to a setuid program that generates output

Still, it s a cross-architecture local root escalation on most common installations. Don t stop reading just because you don t have a local user base attackers can use this to elevate privileges from your user, or from the web server s user, etc. Since there is now a nearly-complete walk-through, the urgency for fixing this is higher. While you re waiting for your distribution s kernel update, you can use systemtap to change your kernel s running behavior. RedHat suggested this, and here s how to do it in Debian and Ubuntu:

• Download the am I vulnerable? tool, either from RedHat (above), or a more correct version from Brad Spengler.
• Check if you re vulnerable:

  $ make correct_proc_mem_reproducer
  ...
  $ ./correct_proc_mem_reproducer
  vulnerable
  

• Install the kernel debugging symbols (this is big over 2G installed on Ubuntu) and systemtap:
  • Debian:

    # apt-get install -y systemtap linux-image-$(uname -r)-dbg
    

  • Ubuntu:
    • Add the debug package repository and key for your Ubuntu release:

      $ sudo apt-get install -y lsb-release
      $ echo "deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe multiverse"   \
            sudo tee -a /etc/apt/sources.list.d/ddebs.list
      $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECDCAD72428D7C01
      $ sudo apt-get update
      

    • (This step does not work since the repository metadata isn t updating correctly at the moment see the next step for how to do this manually.) Install the debug symbols for the kernel and install systemtap:

      sudo apt-get install -y systemtap linux-image-$(uname -r)-dbgsym
      

    • (Manual version of the above, skip if the above works for you. Note that this has no integrity checking, etc.)

      $ sudo apt-get install -y systemtap dpkg-dev
      $ wget http://ddebs.ubuntu.com/pool/main/l/linux/$(dpkg -l linux-image-$(uname -r)   grep ^ii   awk ' print $2 "-dbgsym_" $3 '   tail -n1)_$(dpkg-architecture -qDEB_HOST_ARCH).ddeb
      $ sudo dpkg -i linux-image-$(uname -r)-dbgsym.ddeb
      

• Create a systemtap script to block the mem_write function, and install it:

  $ cat > proc-pid-mem.stp <<'EOM'
  probe kernel.function("mem_write@fs/proc/base.c").call  
          $count = 0
   
  EOM
  $ sudo stap -Fg proc-pid-mem.stp
  

• Check that you re no longer vulnerable (until the next reboot):

  $ ./correct_proc_mem_reproducer
  not vulnerable
  

In this case, the systemtap script is changing the argument containing the size of the write to zero bytes ($count = 0), which effectively closes this vulnerability. UPDATE: here s a systemtap script from Soren that doesn t require the full debug symbols. Sneaky, put can be rather slow since it hooks all writes in the system. :)

2012, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Bugs I've hit in GNOME 3, in the last 5 minutes:

• gnome-shell's "run" pop-up lost focus and I couldn't get rid of it. Nor could I launch another "run" dialogue, which is my normal route for starting software.
• I tried to coax my web browser into launching a terminal by browsing to file:///usr/bin/gnome-terminal. Instead, it downloaded a copy to ~/Downloads. Fine, no problem, because after another click it launches nautilus to handle the file. (This is not a bug).
• nautilus doesn't know what to do with the file. Apparently I haven't installed a handler for viewing executable files. I'm guessing the copy of gnome-shell isn't +x. nautilus does sensible things when another file (such as a picture) is marked +x, so why doesn't it do so for the opposite case?
• This is such a bizarre error message I try to take a screenshot of it. I take one, then take another (cropped). I try to save the second picture over the first one, but gnome-screenshot complains that it cannot find a file somewhere in /tmp.
• The flash plugin crashed in the middle of streaming an album. I'm almost not allowed to complain about the flash plugin crashing.
• After and around and inbetween all that, I downloaded an .amz file (an Amazon MP3 download file, in fact, of the album I'm failing to stream) which I hoped to run through clamz (a command-line, open source tool that can interpret AMZ files). nautilus offers clamz as a launch option in the right-click menu, but it's not the default handler. If I select "properties" to set the default handler, clamz is not in the list of available handlers.
• After sending the HUP signal to gnome-shell, I've got rid of the "run" pop-up, but now something has happened to it's $PATH and future "run" pop-ups can't find anything in the standard locations, like /usr/bin.
• since the flash plugin died, nothing else seems to be able to make any sound, so I can't play the album I downloaded anyway.

I didn't set out to bug-hunt this morning, I'm actually trying to get some work done. Whilst this is a particularly bad case of stacked-bugs, it's unfortunately, pretty representative of what it's like to try and use a Linux desktop at the moment. Every day I go through a similar experience. I've just had to give up and log out and back in again. The shell path bug above has re-surfaced in a new session. Great. I'm waiting on a delayed laptop at work. I'm very tempted to cancel the order and just use a Mac Air instead (we have one spare). It seems I'm walking the inevitable path of F/OSS desktop frustration and the end for many people seems to be the Mac perhaps I should spare myself the pain of the journey. In the mean time, It's bye-bye to GNOME and off to Xfce for me.

I really should write these a bit more often. Wow, I can't believe it was over 4 years ago that I started having occasional face to face meetings with the ISC DHCP folks. The entire ISC DHCP team (of 5) was in town for an all-hands meeting, and Larissa Shapiro, the Product Manager for DHCP (and BIND) suggested it would be a good opportunity for another catch up. Given the current (bad) state of DHCP 4.2 in unstable, I thought this was an excellent idea, and so we all had lunch on Tuesday. I pretty much set the agenda, and it was

• general state of 4.2.2 in Debian
• situation with GNU/Hurd and their patch to fix an FTBFS (#616290)
• the current FTBFS issues with kFreeBSD (#643569)
• the embedded BIND sources in the DHCP source
• removal of the RFCs from the embedded BIND source (#645760)

The general state of 4.2.2 in Debian In a nutshell, it's a bit of a mess. We've got release critical bugs, build failures, the whole cat and kaboodle. It makes me very sad, because 4.2.2 was the first 4.2 series that I had a chance to upload, and I was very excited to do so, because it contains the hotly desired LDAP patches merged upstream. Unfortunately, it's also got the beginnings of the BIND/DHCP merger that's going to be BIND 10, and that is all a bit of a mess. It's directly responsible for the kFreeBSD FTBFS and the introduction of the RFCs, which are both keeping 4.2.2 out of testing. I gave the ISC folks a high-level overview of how Debian development works, and the normal progression of packages from unstable to testing to stable, and the release process and whatnot, and impressed upon them the implications of the current release critical bugs. I also showed them how Ubuntu development fitted into the picture. Finally, I showed them the popcon statistics for DHCP. I think they found it useful. FTBFS issues on kFreeBSD This was a good segue to #643569. The issue is actually with the embedded BIND sources. I'd already forwarded this bug upstream when it first happened, but I don't know what had happened to it. They seemed to act as if this was the first they'd heard of it. I'm hoping that they can get this fixed in 4.2.3, which is due around the end of the quarter. Embedded BIND sources Since we were already talking about an issue caused by the embedded BIND sources, we moved on to talking about #645760 and the existence of the embedded BIND sources in general. It should be pretty straightforward for them to strip the RFCs out of the source. They've already done it in the past for the DHCP sources, so I'm also hopeful that this will get resolved in 4.2.3. The issue of the embedded BIND sources is apparently a bit more complicated, although the day before our meeting, Michael Gilbert filed #643569 and #645760, so I hope that the ISC folks can take a look at these patches and see if it's feasible to adopt them. Patches for GNU/Hurd Finally we talked about #616290, which I know is near and dear to the GNU/Hurd porters' hearts. We probably spent the most time talking about this. The DHCP developers have concerns about accepting a patch for an OS that they do absolutely no testing on, and also questioned the viability of the OS in general. They stressed that they're fairly thin in numbers relative to what they have on their plate to achieve this year, and so pushed back pretty firmly on accepting the current patch. I relayed the frustration that the Hurd folks were having about a lack of dialogue around the patch (most of the interaction has been via an ISC support person). There was actually a bit of a split between the developers, with one of them appreciating that the Hurd was unlikely to go anywhere as a platform without a working DHCP client, so in some regards, they were condemning the platform by taking the position they were taking. They're going to go away and take another look at the patch and try to come back with some actionable feedback on what needs to change to make it more acceptable to them, so we'll see what comes of this. I'm not particularly optimistic that anything acceptable to the GNU/Hurd folks is likely to happen any time soon, but maybe if the patch gets cleaned up a bit more, I'll just bite the bullet and start applying it to the Debian package. BIND 10 One of the guys is more involved in BIND 10 than DHCP, and asked if I could help out with the packaging of a build dependency for BIND 10. It seemed like #578387 was languishing so I offered to pick it up. I've not packaged a library before, mainly because the library packaging guide has scared me off it (I feel I lack the deep C fu that seems necessary), but I figured that this would be a good learning opportunity, so I'm going to dive in.

A small tutorial I made about an effect I used in the previous interviews (in English), so, for consistency, I had to recreate it, even after Kino was no longer available in Debian Wheezy.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="360" src="http://www.youtube.com/embed/6y-6V1Dj1p0" width="480"></iframe>

I'll probably upload more videos like this about cinelerra, pitivi, gimp, audacity and other software I use for the work I do for our Sceptici n Rom nia / Skeptics in Romania podcast (The podcast is in Romanian, but we are preparing also a project for the international audience, too).

And in case you are wondering, yes, this podcast is part of the reasons I wasn't able to do any work for Debian lately!

In case you've been living under a rock these past years, I shouldn't have to tell you what this is about :). Well, just in case.
The Google Summer of Code (GSoC) is an international program that offers student developers stipends to write code for various open source software projects. Debian has participated since 2006, mentoring dozens of students on Debian projects.

The important part of the 2009 edition of the Google Summer of Code is going to start next week with the Organizations application period (March 9th). By that time, we should have listed a reasonable number of ideas on the dedicated wiki page.

We will try this year to improve on the performance of the previous years, starting first with more and more dedicated manpower. If you have some time to spare to help manage our Summer of Code bid this year, we can make it a much better experience for the students and for Debian.

Help is immediately needed in many areas. Some examples:

• Map out which areas in Debian could benefit from a Summer of Code project and connect the right people with the right projects ideas


• Ideas, Ideas, Ideas for Summer of Code projects

By mid-March, we will need:

• Dedicated documentation to present Debian to the prospective student


• Publicity material to promote the Summer of Code at Debian


• Ideas, Ideas, Ideas for Summer of Code projects

Further in the spring:

• Mentors, people to review proposals, do interviews


• Ideas, Ideas, Ideas for Summer of Code projects

In the summer:

• Mentoring students


• Testing and feedback for projects


• Internal communication with the community

As you can see, there is much work ahead. It's time to pitch out your favorite pet project :)
Remember! The Summer of Code has become a prominent outreach forum for open source organizations. It puts a spotlight on each of them to provide a well-rounded and deep experience of open source development.

Right now, you can help with the Wiki, join us on IRC on #debian-soc on OFTC or join the mailing-list at soc-coordination on alioth.

The short "flyers-friendly" URL for the Summer of Code at Debian is : <http://wiki.debian.org/gsoc>. Publicize it!

See you this summer!

As a Debian administrator, power user or contributor, one often goes to look for information about a package, a bug, a developer or a message from the mailing lists. If you are in this case, you may be interested in the Firefox/Iceweasel extension Debian buttons , written by Damyan Ivanov and packaged by myself. Description When installed, this extension provides five buttons, that you can place in your Firefox or Iceweasel toolbar. These buttons take the text from the X11 PRIMARY selection and act as shortcuts to the web pages corresponding to:

• a package from the archive;
• the development of a package (Package Tracking System);
• a bug report (Bug Tracking System);
• a Debian Developer's packages (Developer's Packages Overview);
• a message from the mailing-lists.

Typical use case Let us imagine you see the following sentence on IRC:

12:42 < Tanguy> I am packaging a cool Firefox/Iceweasel extension (ITP #654896)!

If you want to check out the corresponding ITP report, just double-click on the bug number to select it (do not worry about the leading hash or even the possible trailing bracket, it will be handled), and click on the BTS button on your browser toolbar: here you are! Depending on your needs and habits, this extension may considerably speed up and simplify your quests for information. At least, it does for me, so I hope you will enjoy it too!

Update: I managed to make sound work. For some weird reason, a mute switch option of some the many (and who knows how useful) switches of my sound card was enabled. Now the damn thing works. Did I mention that since I did the upgrade all my sound cards (I have a USB sound card, too) have listed as available inputs all the inputs of my internal sound card (mic, front mic, line in, CD, etc.) in Audacity? That makes for a very confusing and loooong sound input sources list! The upside is that I can finally record clips from televisions that do not provide such a feature and FastVideoDownload doesn't handle.

I also seem to have found a possible fix for the caps-ctrl issue in Xfce4 (obviously, setting "-option ctrl:swapcap" in ~/.Xkbmap, instead of that Alt modifier).

---

As I said in my previous post, I will tell you what do GNOME 3 and Windows 7 have in common.

Before everything else, I want to make it clear that when I am saying GNOME 3, I am referring to Debian Wheezy's GNOME 3, since I recently upgraded from Squeeze on my laptop. I'll probably drop a line or two about that, too.

First, I'll tell you about the (boring, probably for many) experience with Windows 7. As I said before, my new job requires me to use a Windows machine, so up until a few months ago I was using Windows XP with some additional software and tweaks to make it usable. Then came the Windows 7 upgrade . I am using quotes since the more appropriate term would be fresh installation on a new partition , not even close to what Debian users are used to call an upgrade.

So after a fresh Windows 7 installation, my first shock was the fact there was NO Quick Launch*. Some of you might be laughing, but I had never used Windows 7 up until then, just saw it on a laptop of a friend of mine (Ovidiu, one of the guys with whom I am doing this podcast, went to Denkfest with, and made these interviews). That was the first shock. Initial discussions about this with Windows users lead me to believe Quick Launch was dead and for some unexplained reason, I believed them. Later, much later, a week ago, to be precise, I found out that you can bring back the Quick Launch through some convoluted way**. Up until that point I had to have some icons pinned to the task bar, but some others on the desktop (and I hate that) because some of them, like Cygwin, if pinned, would start a cmd console, since Win 7 pins the process, not the starting script.

Among other things which broke in Win 7 and used to work fine in XP, the Virtual Dimension application which provides me with a virtual desktop, was the first one which was broken. I have been using a liniar 4 desktops-wide virtual desktop for over 5 years and I am worthless and inefficient if all my apps are on the same desktop. Mail application is always on the first desktop, work and file managers are on the second, the third is for extras and multimedia editing while the fourth is my gateway to the internet, containing the browser, instant messenger, or whatever.

The shortcuts I use to get to the various desktops are Win+1 ... Win+4 keyboard shortcuts, but the M$ Evil Empire decided that those shortcuts are going to start or bring foreward the first, second and so on applications pinned on the task bar. And you can't change those shortcuts***. Nor is disabling just those possible since they are all disabled through a huge switch which disables ALL Win+x keyboard shortcuts, among which Win+E (file expolrer) and Win+D (Show Desktop) were also. Luckly, Win+L (lock screen) was not disabled. So I disabled al those Win+ shortcuts, since I need virtual desktops.

Now, imagine if I had to start a Cygwin console and I had all sorts of apps open! Win+D was disabled, so I had to minimize the apps covering the desktop shortcut for Cygwin, click on the icon to start it, bring back the minimized windows and go on with my work. What a waste of clicks, mouse movement, energy and time, just because some dudes thought a Quick Launch-like feature was useless****.


You might wonder already what do those '*' sings mean. Well, sadly, that's what GNOME 3 / gnome-shell and Windows 7 have in common.

Gnome 3 was a shock for me. An empty desktop right after upgrade. No panels, no shortcuts*, no power indicators, no wicd indicator, no virtual desktops, no desktop icons, (I have a few dirs and docs there). Sounds like an Evil Empire decision, doesn't it?

Luckly I have been using Tilda as my always-ready console and I could fire up iceweasel from the console in order to understand where my panel disappeared.

I then realised that the upgrade brought me Network Manager, that app which wicd replaced. As a consequence, I had no working wlan since Network Manager made sure to mess up with the network manager I chose.

After looking through the documentation of Network Manager and realising I either had it set up to leave wlan0 alone or I didn't understood NM's documentation, I simply stopped the service, which let Wicd its job flawlessly.

The first thing I searched was Gnome 3 panel or something of that sort and I was confronted with the obvious option to appeal to the Forced Fallback Mode which was disabled. I figured I either had an old version, or Debian disabled this feature (hoping they provided an alternative). There was also the option to conform to this convoluted way of working** with Actions and such uselessness like that. I still wonder, what is the purpose of the Favourites bar on the left side, since it's accessible only after wasting a lot of mouse movement and time? For Joe's Pesci sake, I use focus under mouse just to avoid needless mouse and keyboard manipulation. Why? Why? WHY would I want every time I need to start or SWITCH to another application to move the mouse to the upper-left corner then take my hands off the mouse to type, move the mouse downwards or move across the whole width of the screen to get to my beloved virtual desktops and pick the app I want?

Making a long story short, after even trying XFCE4 (which for some unknown reason resets almost immediately my keyboard layout to the default layout with the Caps on Caps, instead of my preferred and set Ctrl on Caps - yes, it's global), I managed to find GNOME Shell Frippery** which made the experience better.

Later I found out that GNOME 3's file manager, Nautilus, has decided that an up on level button is useless, since the default is to use that uncopy-pastable button location bar instead of a sane text location bar. And it seems the GNOME developers decided this*** and I should conform to it.

To add insult to injury, those icons on my old panel are apparently useless**** and even in the fallback version I can't get them back. Or so the GNOME developers decided.

At some point this sunday, don't know how or why this change happened, producing sound was impossible. I know the problem is pulseaudio since when I kill the pulseaudio daemon from the console I can play audio. BTW, great timing, just when I needed sound the most, before releasing episode 32 of our podcast (yay, I reaslised that xfce just decided to reset my caps to be caps, after setting to ctrl a few minutes ago).

I know I praised pulseaudio when I first tried it, but failing to make it work out of the box or after some tinkering is a deal breaker for me, so I removed it. Now I find it that is a default in GNOME, yet all it manages to do is prevent audio from working. At least on my machine.

Other problems? Gnome Power Manager manages to hang and block my session, GNOME managed somehow to fail to start at some point. Yeah, and that sound problem which I didn't fix yet, didn't went away after removing all the pulseaudio packages which could be removed (e.g.: ryhtmbox depends on libpulse0, same do some other apps like audacity, so I couldn't remove all pulse related packages).

I got involved with Debian and GNU/Linux because it was tweakable and customisable, didn't use to force all sorts of option on me and now I find with its increasing popularity it becomes more and more like a product of a corporation which decides to change some things just to change and totally disregadring user experience and uses.

So, in the light of all of these problems I think it's time to probably consider trying KDE. Is it any good lately?

Our Dear Project Leader, Stefano Zacchiroli, regularly mentions the fact that there's an amount of Debian money available for hardware sponsoring of Debian developers, but it seems that not much people benefit from it. Each time I saw one of this reminder, I wonder if I should apply, and the anser is usually no. The fact is that I don't think any new laptop or desktop to do my Debian stuff, and the last time I bought a box (my x201s last summer) it was not really specifically for Debian tasks so I didn't dare to ask (not to mention the fact I bought it because I did have the money to do so). And I think this is mostly the problem. I might be wrong, but I think that most people which could benefit from this just don't dare asking or don't estimate themselves eligible for it. When I saw Ben Hutchings post, where the first thing he says is about how hardware is expensive, I thought hey, he should get some Debian money for buying new hardware: building kernel is really time consuming and having multiple powerful cores, more ram and fast disks/SSDs really helps . Turns out that Ben just didn't really want to spend too much money there, but the case still stands. We also see from time to time people saying they'll be offline for a while because of broken laptop or something like that. Once again, maybe those people wouldn't mind some help from the Debian project, and maybe they just don't think about asking, or they don't dare. So thinking about it a bit more, I think I wouldn't dare asking money for myself, but maybe I could dare asking money for other people (this is a bit like the flattr posts by Rapha l Hertzog, where he incited people to give money to projects he liked). If I'm not alone in this case, maybe those Debian developers who think some of their peers would benefit some hardware could drop them a mail with leader@ on copy, to propose just that. No need for huge publicity on that (in order to not embarass people), though the transparency rules still apply when it comes to Debian money.

I moved 600km away from Madrid, I quit my job because with all the coming and going I was barely making any money, and in order to keep a healthy, active mind, I'll keep working for Debian. I also started occasionally helping kandinski with sysadmin stuff for Barrapunto (the Spanish SlashDot), also for love, and because of incredible timing.

We also now have a new cat (an orange tabby named named gato, not very original nor practical as it's our fifth cat in the household). We also now have a small garden the cats love, even in bad, evil rain. I also now have a bright new horizon where a vegetable garden, civil marriage, quitting smoking, and motherhood will be slowly making it into my life as the dust settles down.

Last, but not least, I'll try to get back in touch with all the people I lost contact with because of, you know me, another one of my falls through the rabbithole I call depression. I missed two Debconfs in a row, this time it was bad. But I found the way out and I am back. So hurry up and drop me a line before three years (that's when i believe the rabbithole will eat me again). At least now I understand the cycles. It still sucks, but helps feel in control. Or something.

Anyway, if you ever show up close to Seville, I am up for keysigning, beers and rl spammer harassing, as always.

I will be helping to represent the FSF at FOSDEM next month in Brussels. I'm speaking in the Legal Issues Devroom on Saturday 2012-02-04. The presentation is called "Is copyleft being framed?":

This short talk will address the following questions, to inspire discussion and contemplation about how we frame descriptions of the state of licensing in free software.

• Numbers are increasingly being cited to show that the use of copyleft licenses, specifically the GPL, is declining. What do these numbers actually show, who is propagating them, and why? What do or might other numbers show?
• Is the "percentage of free software projects which use copyleft licenses" a useful way to judge the success of copyleft? Does an increase in the percentage of projects using non-copyleft permissive licenses indicate a failure of copyleft?
• As a small related case study, what role have the licensing terms of popular mobile application stores played in this debate, and how have those terms changed the frame of the discussion?

Let me know if you'll be there too!

(This is not quite a Dear lazyweb post. If anything, it's Dear lazyweb, I've done my homework, now what? ) I'm looking for the ultimate distributed filesystem. Something that's simple to use, redundant, fault-tolerant, and still smart enough to avoid the more obvious performance chokepoints. Ideally, it should work for all of the following sets of files:

• Music files. They're currently stored on a plug computer at home and served over DAAP, but DAAP seems to become less and less of a priority for music players (I'll keep the music players suck rant for another post), and it has its inconveniences too. Ideally, the files should be integrated in the filesystem of my work computer, the one that serves as a media player in the living-room, the one I use for playing the backing tracks when I'm practising the drums, and the laptop I use when on the road too.
• Backups. My BackupPC currently runs on the plug computer at home, so backups of my remote servers are in a geographically distinct location; but backups of my home computers are not, and I'd like to change that without having to copy files around by hand. Backups do contain confidential data, so this adds a constraint on the filesystem.
• Bazaar repositories. I do have a script that pushes and pulls stuff across computers for the many repositories I use, but it's still awkward that I need to do that.
• Parts of my home directory, such as my browser preferences and bookmarks, or the database of the Hamster time tracking tool, or the working directories of stuff I do for clients, and so on. Again, each of those can be done with specific means (bookmarks synced to a server, CouchDB-like database, DVCS and regular commits, etc.), but wouldn't it be much simpler if there only was one file to begin with?

The requirements on the ultimate distributed filesystem (which I'll call UDFS for short, otherwise you'll get bored and go look at pictures of kittens) are as follows:

• Availability means redundancy: some of the storage nodes will be on dedicated servers in datacenters, others at home; I can imagine setting up the firewall so that the home computers are reachable from outside, but sometimes network links go down, and the home computers are far from being on 100% of the time.
• Availability/redundancy also means automated replication and rebalancing: if a node is added to the grid (or switched on), it should automatically get its share of the files so as to contribute to availability if another node goes down at a later time.
• Confidentiality: at the very least, network communications must be encrypted and authenticated; ideally, individual storage nodes wouldn't need to be able to access the stored data. If I store bits of my backups on a friend's server, I don't want to have to trust them not to look at the data; also, my friend may actually want to be unable to look at my data (to provide for deniability in case someone else wants to look at it).
• Performance: native disk performance may not be realistically reachable, but the system must be smart enough (or configurable enough) to store files on both sides of the ADSL link, for instance, so not all accesses need to go through the bottleneck.
• Integration with the system: I want a filesystem, not a storage system. All applications know how to navigate a mounted filesystem; very few will interface with an specific application designed to store and fetch chunks of data.
• Scalability would be nice, although my personal needs are still well below the terabyte range and I can't see myself using more than a dozen nodes or so.

Quite a few constraints, eh? I have a feeling they are not mutually incompatible though, so I had a look at several candidates. I started with Wikipedia, and I followed the links to Tahoe-LAFS, XtreemFS and Ceph. The following is my evaluation of these candidates based on much reading of docs and websites and wikis, some questioning on IRC, and very little testing.

• Availability/redundancy 1: all three candidates work on the net, and they all provide for data replication. XtreemFS seems to operate on a fall-back mode while the other two are more distributed (meaning there's no canonical node hosting any particular file). Tahoe uses erasure codes (files can be split across N shares, k of which are enough to reconstruct the whole file; the N/k ratio controls the amount of redundancy); it seems to require the introducer node to be always up, which introduces a single point of failure, but this node can be replaced with no loss of data if it fails (this just requires reconfiguring the storage nodes, which can probably be automated). Ceph can work with any number of meta-data servers, so redundancy is assured there (data itself can be replicated in a configurable way too).
• Availability/redundancy 2: either I'm a fool and I didn't find out about that, or none of the three candidates provides for automated rebalancing. Apparently Tahoe provides a way to repair files without enough redundancy, but that needs to be run manually on each file, rather than being systematic, and it's a kind of add-on to the system rather than being properly integrated. Ceph only does rebalancing of meta-data. XtreemFS seems to work a bit like RAID1 with spare disks, but details are scarce.
• Confidentiality: Tahoe wins, hands down. Neither network sniffers nor storage nodes can see the contents of the stored files. They can't even find out about their name or the directory structure. XtreemFS encrypts the data on the network (but it is still stored in cleartext on the nodes). Ceph doesn't even try.
• Performance: Ceph wins (or loses less, at any rate): it seems possible to configure a topology for the storage nodes, and to drive the storage location policy according to this topology; so I could define sets of nodes ( my servers in datacenters , my plug computer at home , my desktop and laptop computers , my friends' computers ) and decide that each file should be stored at least once on each set of nodes. Tahoe stores shares of files on a number of storage nodes chosed in kind of a round-robin way; read access uses the same round-robin system, which means that you will probably end up fetching a file at least partially over your slow link even when you could fetch it entirely from the local network. The XtreemFS website doesn't seem to acknowledge the possibility of the network being slow.
• Integration: Ceph and XtreemFS win: they're native filesystems. Tahoe is in the storage and retrieval system category; the FUSE layer is marked as experimental and not recommended, and the SFTP layer (which can be mounted as a filesystem with sshfs) has many documented drawbacks. Maybe a WebDAV frontend, combined with fusedav, would provide a working alternative, but it's not implemented yet.
• Scalability: all three candidates boast about scalability (in data size and in number of nodes). Ceph seems to require some configuration every time a new storage node is added. Tahoe seems much more dynamic: new nodes (storage or clients) just need to be told where the introducer node is, and then they merge into the grid seamlessly by being told about other nodes (a bit like Bittorrent, where clients learn about each other by asking the tracker).

The overall picture seems full of good things scattered across different solutions, but unfortunately none of the existing ones seems to address the whole problem; at least, not my whole problem. It would be good if each focused on one layer and did that layer well, but that seems not to be the case either, so they can't be combined to get the best of all worlds. It may be that I'm missing something, or that I failed to read some docs properly, or that I misunderstood the docs, or that the docs themselves are simply lacking; but my ideal UDFS currently doesn't seem to exist as a turn-key solution. However, the main pieces are available, and implementing the remaining parts may be doable. My humble idea of a way forward would be based on Tahoe-LAFS, with the following three changes:

• A configurable dispatch policy, so that administrators could define their own behaviour. The current Tahoe parts already turn files into a number of blobs that only need to be stored on various nodes, and the function that chooses which nodes seems to be reasonably self-contained, so it could maybe even be made pluggable, and an administrator could implement a storage policy that matches the constraints and the network topology. Ditto for the function that picks which nodes the data is read from (which, as far as I can tell, is the same; splitting could bring some benefits here).
• A working FUSE implementation, either on top of SFTP if the drawbacks can be fixed, on top of WebDAV if that gets implemented, or native to Tahoe if that can be done.
• Automatic rebalancing of data when new nodes are added or turned on, or when an intermittent network link comes up. The current script seems to be an afterthought; if it can be made more automated and more reliable, I'll be happy with that.

Also nice to have would be a way to work with multiple introducer nodes, but that seems to be in the works already. This would be pretty damn close to my UDFS; read/write performance would certainly be far from what can be obtained on native filesystems stored on local disks, but my use cases involve reasonably small files for which instant access is not compulsory, and the filesystem cache would probably absorb most of the access times. In case anyone is looking for ideas of things to do in their spare time, here are rough sketches of other possible UDFS implementations I thought of. These are wild ideas, and I'm not even sure they could be doable in practice:

• eCryptfs on top of Ceph. The file contents are still only accessible to those in possession of the adequate key, and replication/distribution is handled by Ceph. That could probably work; the main drawbacks I can see come from Ceph's administrative overhead and manual configuration.
• LUKS and a standard filesystem, on top of the part of Ceph that manages block devices (RADOS). I'm not sure this could be mounted simultaneously by several nodes, though.
• LUKS on top of Ceph's RADOS, and Lustre or GlusterFS on top of that? Am I even making sense?
• A kind of union filesystem with local caching, on top of Tahoe-LAFS. Say we take unionfs-fuse, and add local caching: if the requested file is already in cache, performance is near native; if not, we still get the advantages of Tahoe. I'm not sure how caching works with WebDAV, but once Tahoe gets a WebDAV frontend it might be a simple matter of adding a Squid cache between that and davfs.
• I even thought of building a filesystem on top of the Bittorrent protocol; redundancy would be obtained by ensuring that there are at least N distributed copies of a file among the peers. I gave up even before reaching the details phase, though, but maybe a variant of the idea could be workable.

Such is the state of my research so far. I would welcome feedback, pointers to things I neglected to read, corrections for things I misread or misunderstood, comments on the ideas and so on. I'll probably post an update if my search goes significantly forward. Update: I've already received two pieces of feedback, including a lengthy one with corrections about Tahoe-LAFS. For the sake of fairness, I'll solicit (and wait for) the same from the other candidates I looked at. I was also pointed at HekaFS, GlusterFS and git-annex, which I'll have to look at in more details. Other suggestions are still welcome, but the more I get, the more the full update will be delayed. Thanks already!

I thought it was about time to get a faster machine for... well, mostly for compiling kernels faster, but I'm sure I will find other applications for it. I was originally intending to upgrade my laptop (Thinkpad T61, 1.8 GHz Core 2 Duo) but it seems that in the 3 years since I bought it second-hand laptop prices have not dropped in line with Moore's law. So instead I decided to upgrade (well, replace most of) a desktop PC. The last time I got a new desktop at home was in 2002. It has an Athlon XP, PATA drives and a huge CRT monitor. It has had some upgrades since then (DVD writer, more RAM, slightly faster CPU, replacement fan and PSU). Obviously it was time to replace motherboard, CPU and RAM. Not so obviously, the PSU needed changing again as modern CPUs apparently need more 12V electrons (?!). The DVD writer was salvageable via a USB adapter and its local HD is currently a laptop drive (the only spare SATA HD I had). The monitor is of course reusable, though the firmware setup program doesn't entirely agree with it. Windows Yes, I do sometimes run Windows. It's for games, and also seems to be needed for streaming video with stupid DRM. On the assumption that Windows is less likely to play nice with an existing installation, I tried installing it first. The firmware appear to allow me to boot the DVD in either BIOS or UEFI mode, so I selected the UEFI option. This worked so far as loading the initramfs (or whatever the Windows equivalent is) but then Windows was lacking a driver to access the DVD. This stumped me for a day or so until I realised I had plugged the drive into a USB 3 (XHCI) port. Apparently Windows 7 SP1 still doesn't include an XHCI driver in the installer (but neither does Debian 6.0.3 - we should fix that). The installation was mostly uneventful after this. The Windows installer includes a reasonably capable partition editor. Debian Installation of files was entirely uneventful. The installer correctly detected the GPT (GUID partition table) created by Windows. However, it was not able to install a boot loader. Currently it only includes support for the LILO and GRUB-PC boot loaders that run under BIOS. After much experimentation and cursing, I found instructions for installing Debian Squeeze on XServe 3.1 by Jan Peter Alexander Rajagukguk, which put me on the right track. It seems that the grub-install script for GRUB-EFI in squeeze (and maybe other parts of the package) doesn't actually work. However. JP's direction to build GRUB from source is no longer necessary. Here's what I did (minus the mis-steps):

1. Boot the installer in rescue mode and open a shell on the installed system:

   # # We start in dash, so switch to bash.
   # exec bash
   # mkdir -p /boot/efi
   # # Mount the EFI boot partition by UUID.
   # # It's probably called sda1 now, but is subject to change.
   # ls -l /dev/disk/by-uuid
   ...
   # echo >>/etc/fstab 'UUID=efi-boot-uuid /boot/efi vfat defaults 0 0'
   # mount /boot/efi
   # # Enable unstable sources, but use stable by default
   # echo >>/etc/apt/apt.conf 'APT::Default-Release "squeeze";'
   # echo >>/etc/apt/sources.list 'deb http://cdn.debian.net/debian/ sid main'
   # apt-get update
   ...
   # # Install unstable grub-efi-amd64
   # apt-get install -t unstable grub-efi-amd64
   ...
   # # Install GRUB to the EFI partition.  The '--removable' options
   # # inhibits setting EFI variables, which won't work because we booted
   # # through BIOS emulation.  Instead, it installs as the default boot
   # # loader.
   # grub-install --bootloader-id=GRUB --removable
   # # On the AMI/ASUS firmware, you cannot select a new bootloader
   # # directly but can invoke a 'shell'.  So I made GRUB the shell:
   # cp /boot/efi/boot/grub/grub.efi /boot/efi/shellx64.efi
   # exit
   

2. Reboot and select GRUB as the boot loader if necessary. In my case I had to enter the setup program and select 'EFI shell'. Debian should now boot from the hard drive.
3. Add a non-volatile boot option for GRUB (and make it the default):

   # apt-get install efibootmgr
   ...
   # modprobe efivars
   # efibootmgr -c -l '\efi\grub\grubx64.efi' -L GRUB
   

The bug report Simon McVittie reported in Debian bug #654876 that his laptop running Linux 3.0 or 3.1 would sometimes crash (panic) while idle. He initially suspected a driver bug, but the screen did not show any information about where the original fault occurred. However, using netconsole, he was able to capture a full log of the crash. This showed that a packet received through the wireless interface was being processed by IGMP, which then divided by zero. IGMP IGMP is part of the IPv4 protocol suite, supporting multicast routing. Every multicast address corresponds to a dynamic set of hosts, called a multicast group. Multicast routers can send query messages asking which hosts belong to which groups, and hosts using multicast report back at intervals. Routers can then limit forwarding of multicast packets to the interfaces where the group has members. More sophisticated switches can also snoop IGMP and use it to limit their multicast forwarding. There are unfortunately three different versions with semi-compatible message formats. In version 1, the maximum reporting interval (Max Response Time) is fixed as 10 seconds, but from version 2 it is specified in query messages. The Linux IGMP implementation supports all three versions. It distinguishes query messages as specified in RFC 3376 section 7.1: v3 messages are longer than v1 or v2; v2 messages have a non-zero Max Response Time whereas v1 messages always have zero. It is possible to force use of a specific protocol version, but normally if there are multiple multicast routers using different protocol versions it will respond according to the earliest protocol version in use so that all routers can understand its responses. Source and fix for the bug Linux 2.6.36 included two fixes to the version selection logic. Unfortunately, the second of these introduced the bug in question. While v2 query messages cannot possibly have zero Max Response Time (as that would make them v1), v3 query messages can. What this means is unspecified, but the Linux IGMP code previously treated it as the minimum valid value of 1/10 second. But in the case where a v3 query is received and a v2 query has also recently been received, this is no longer done. This results in a reporting interval of 0 seconds and a division by zero when deciding the initial random delay. The fix for this is pretty obvious. It is included in Linux 3.0.17, 3.1.9, 3.2.1, and the Debian package version 3.1.8-2. Security impact This is easily exploitable for denial of service within a local network. Linux does not check the destination address of IGMP queries, so it may also be possible to attack a target through its unicast address from several hops away. The attacker only needs to send a single IGMPv2 query followed by a single IGMPv3 query with zero Max Response Time. All systems running Linux 2.6.36 or later (up to the above fixed versions) with any active IPv4 multicast listeners (other than for the 'all hosts' address) are vulnerable.

Maybe many people have missed this: Aptitude package manager is undergoing a revival. Two fellows, Daniel Hartwig and Manuel A. Fernandez Montecelo, started triaging bugs and preparing a possible new version. Daniel Burrows, who maintained it for years (and did a really good job in this, given the high exposure of aptitude, which happened to be the recommended package managers during a few years), has currently less free time for doing the work. So, this is really great to see people motivated in taking the job over. In case you want to help, please joing the "aptitude-devel" mailing list on lists.alioth.debian.org. There is an Alioth project but Daniel is currently the only administrator. I might ask for admin privileges so that I can validate new team members. Of course, I personnally can't do much in this (C++ programming, coding, ah ah ah...things that are black magic for me), except my usual help for i18n/l10n. But, at minimum, I can make noise about this effort to encourage the volunteers who commit themselves to revive the project. And, I can certainly help by sponsoring their work (none of them is DD as of now) even if I am not skilled enough to review everything. I don't want to see good work wasted because people insist on nitpicking each and every commit line before "approving" it (any idea what I'm talking about, here? :-)).

As seen on reddit: an old Bill Joy quote often banded about as part of the (largely synthetic) vi-vs.-emacs holy war starts as follows:

vi was written for a world that doesn't exist anymore

The context of that quote is:

I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. 9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think.

(source: the register). Furthermore:

unless you decide to get a satellite phone and use it to connect to the Net at 2400 baud, in which case you'll realize that the Net is not usable at 2400 baud.

You don't need anything as esoteric as a satellite phone: a cellular mobile phone will suffice. I've no idea what the effective/equivalent baud rate of GPRS is (or EDGE), but I have a new-found appreciation for vi's design goals having tried to run an SSH session over such a connection.

Steve McIntyre has been contributing to Debian since 1996, 2 years before I joined! But I quickly stumbled upon Steve: in 1999, he was struggling with getting his debian-cd script to produce 2 ISO images (it was the first time that Debian did no longer fit on a single CD), I helped him by rewriting debian-cd with a robust system to split packages on as many ISO images as required. I remember those times very well because Steve was very supportive of my efforts and it was a real pleasure to get this done. His friendly nature probably also explains why he got elected Debian Project Leader twice! Anyway, enough history, check out his interview to learn more about the great work he s doing nowadays. My questions are in bold, the rest is by Steve. Raphael: Who are you? Steve: I m a professional software engineer, 37, living in Cambridge (England) with my new wife Jo. I studied for the EIST degree at the University of Cambridge, then (like many people here, it seems) I just forgot to go home again afterwards and settled here. I spent more of my study time playing with Linux than working on my degree, so I guess I m lucky that it worked and I found a career in that area! Raphael: How did you start contributing to Debian? Steve: During my time in college, I started hacking on software in my free time, using Slackware as my first Linux distribution from the middle of 1994. After encountering more and more problems with Slackware, I was encouraged by a number of friends to make the jump over to Debian and in October 1996 I did. The installation process back then was much harder than anything people see today, but after a long weekend I finally had my Debian system up and running. I was already one of the main upstream developers for the Mikmod music player at that time, so that very same weekend I applied to be a DD so I could maintain it in Debian too. Back then, the NM process was much simpler: I just mailed a key to Bruce and he set me up with an account almost immediately! I then found that Joey Hess had beaten me to it and already packaged Mikmod. Grrr! Raphael: What s your biggest achievement within Debian? Steve: Without a doubt, my proudest achievement within Debian is being elected Project Leader for 2 years by the other developers. It s a great feeling to have earned the trust of your friends and peers, and also a great responsibility to go and help Debian where needed: talking to the press about Debian, assisting wherever problems crop up, etc. The DPL job is certainly a lot of hard work, and I have nothing but respect for anybody who volunteers for it.

It s a great feeling to have earned the trust of your friends and peers.

Elsewhere, I ve been leading the Debian CD team for years too, both doing most of the maintenance of the debian-cd package and producing and testing the regular installation CDs and DVDs that we ship to the world. Again, this is a time-consuming job but it needs doing and it s worthwhile. Raphael: You re currently employed by ARM. What are you working on and are they supportive of your Debian involvement? Steve: The situation within ARM is very interesting; I m employed in PDSW (Processor Division, SoftWare), a new group founded just a couple of years back to help improve the state of software on ARM. Most of the people in the group are working on Free Software at this stage (e.g. toolchains, browsers, Linux kernel), which is lovely. Some of the engineers have also been seconded into a new non-profit company Linaro, which is a collaboration between ARM and a number of other companies investing in core Linux software and tools for ARM-based CPUs. I m one of the ARM engineers in Linaro, and I m a Technical Architect in the Office of the CTO. My role includes looking at future projects for Linaro to help with (e.g. ARM servers), but for the last few months I ve been concentrating on the new armhf architecture in Debian, Ubuntu and elsewhere. armhf is a new architecture in Debian and Ubuntu terms, but it s not strictly a new type of hardware. Instead, it s a new ABI. We have two reasons for doing this work:

1. It targets the latest version of 32-bit ARM CPUs (v7) and makes better use of the hardware, for better performance. Compare targetting i686 instead of i386, for example. We ll still support the older armel port for the foreseeable future for users with older hardware that can t run armhf.
2. More importantly: we are standardising on the ABI / compiler options / hardware support for future users.

In the past, there has been a huge amount of specialisation (aka fragmentation) in the ARM Linux environment, and that worked OK for specialised devices that only ever ran the software shipped with them. ARM CPUs are now becoming more and more mainstream, so people will expect to be able to install generic software on their machines. That gives a requirement for a standard base platform, and armhf (arm-linux-gnueabihf in GNU triplet terms) is that standard that we are pushing in the community. Debian, Ubuntu, Fedora, Suse and others are all going to use this, making compatibility possible. I ve been working with a small team of people to make armhf happen, helping where needed: putting together build machines; patching Debian packages directly; discussing and fixing toolchain issues with Ubuntu folks; agreeing ABI specifications with people from Fedora; advising people from other distros bootstrapping their new ARM ports. ARM and Linaro are very supportive of this work, and it s been lovely being sponsored to work directly on Free Software like this. It s work that will directly benefit ARM and its partners (of course!), but it s also helping out more generally too: Debian QA work, cross-build support, bootstrapping efforts, multi-arch. More and more of the ARM market is driven by Free Software, and companies are acknowledging that. I should probably also mention that we re hiring ! Raphael: What are your plans for Debian Wheezy? Steve: There are three main tracks here. Obviously, I m interested in seeing armhf release with Wheezy. We ve just been added to Testing last weekend, so that s going well. We ve got over 90% of the archive built now, and we re mopping up the remaining issues. I m the primary maintainer of cdrkit at this point, but I d prefer to have it go away. Xorriso and the associated software in libisoburn is almost capable of replacing all the aging cdrtools-derived software that we have in Debian, The only missing feature that I m aware of is creating the HFS hybrid filesystems that we use for installations on Mac systems. I ve been talking with the upstream folks about this for some time already, and I m hoping we can finish this soon enough that we can get it into Wheezy. Finally, I ve got the ever-growing wishlist of things for debian-cd. We ve got the beginnings of an automated test suite that Mart n Ferrari has written, but it needs integrating and improving. I want to help get regular weekly/daily/release debian-live builds running on the main CD build machine. There s work needed if we want to make good installation media for the new multi-arch world, too. The Emdebian people are asking for help making CD images The list goes on Raphael: The ARM community seems to be very interested in multi-arch. Can you explain why? Steve: There are a number of reasons for ARM people to be interested in multi-arch; two really stand out for me:

• With the historical issues around the plethora of ARM ABIs in the wild, multi-arch will allow us to potentially support multiple ABIs cleanly on one system. That allows users to have (for example) an up-to-date system that makes the most of their current hardware, yet also run legacy programs that might use an older ABI. There s also a new 64-bit architecture coming (ARMv8) which will run older 32-bit software; again, multi-arch makes mixed installation of old and new software reasonable.
• ARM has traditionally been a common target for cross-compilation, and I d expect that to remain the case for a long time to come yet. For a lot of embedded developers, using a big fast i386/amd64 machine to compile is much faster than using a limited-power small ARM CPU. However, setting up sane cross-compilation environments has long been a bugbear for developers. Getting the toolchain and all the cross-architecture libraries to work together correctly can be like black magic. This is potentially the killer app for multi-arch: simply install the libraries for the target architecture directly on your development machine. Install a simple cross-gcc package and (maybe) qemu, and you re all set.

This is potentially the killer app for multi-arch: simply install the libraries for the target architecture [ ], install a simple cross-gcc package [ ] and you re all set.

Raphael: What s the biggest problem of Debian? Steve: For me, Debian s biggest problem has been the same for a long time: we are forever short of enough people to do the work that we re trying to do. That might sound like a weird thing to claim when Debian is one of the largest Free Software projects on the planet, but it s more a statement of just how huge our goals are. Many of the largest things in Debian are developed or controlled by very small teams working very hard, and there s always a risk of losing people due to burnout in those situations.

We are forever short of enough people to do the work that we re trying to do.

Some of the tasks that should be easy given our large membership (e.g. large-scale packaging transitions) can often instead take a very long time. We are fortunate to have more people wanting to join in Debian s work all the time, but we also need to be careful to keep on promoting what we re doing and recruiting new contributors, encouraging them to get more and more involved in core work. Debian gets ever bigger in terms of the size and the number of packages we distribute; we re not currently matching that growth rate elsewhere. Raphael: What motivates you to continue to contribute year after year? Steve: This one is much easier to answer! The thing that first attracted me to Debian was the fact that I could help to develop it, help to decide how things could and should be done within it. Instead of being forced to accept what some corporation decided I could do with my computer, I could change the software to suit my needs and preferences. Alongside that, I could get involved with a strong community of similar people all over the world, all with their own strong opinions about how software should work. I joined in and found it was great fun and very rewarding. That hasn t changed for me in the intervening years, and that s why I m still around. I work on Debian because it helps me to get the OS that I want to use. It seems that lots of people around the world find it useful too, and that s awesome. Raphael: Do you believe that Stefano Zacchiroli will be the first DPL who managed to stay 3 consecutive years on the seat? Would you like him to candidate again? Steve: To be honest, I would be very surprised if Zack stood again for DPL this year. He told me himself that he wasn t planning on it, and I can understand that decision. He s been an awesome DPL in my opinion, and I m glad that he took the job. But: it is also a very difficult and time-consuming task that would be enough to wear down anybody. If Zack does decide to stand again, I would support him 100%. But I know that we also have lots of other good people in Debian who would be ready to take up the challenge next. Raphael: Is there someone in Debian that you admire for their contributions? Steve: There are lots of people I admire in Debian, so many so that I almost don t want to list individuals here for fear of missing people out. But Bdale Garbee has been an inspiration to many of us, for many years. He s technically excellent, a great friend to many of us, an endless source of sage advice and (last but not least) he has some wonderful stories to tell about his experiences over the years. On top of that, he s just cool. Christian Perrier is another exceptional developer, in my eyes he s great at co-ordinating people in translations, working tirelessly to make this very important part of Debian work better and better with every release. He s also a really nice guy and we all love him. I also have to mention Joey Hess here, whether he likes it or not. *grin* He s been responsible for so many good things in Debian over the years, even if he did steal my first package Finally, the teams of people who make sure that Debian is always working: the security team and DSA. The rest of us can choose to take time off from Debian to go and do other things, but these people need to cover things every day. That s a major responsibility, and I salute them for taking on that challenge.

---

Thank you to Steve for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.

One comment Liked this article? Click here. My blog is Flattr-enabled.

I just got confirmed my flight bookings for FOSDEM 2012, so I'm looking to meet all great people there again. This year we've again arranged there meeting of phpMyAdmin developers, now it also includes three new faces from last years GSoC. As for my schedule I did not yet find time to check all the schedule, but what definitely sounds interesting for me is Open Mobile Linux Devroom and some talks in MySQL and Friends Devroom. Rest will be (as usual) scheduled on the fly as I meet people there. This year I decided to deliberately skip keysigning as last year I anyway did not manage to attend it and I expect this year to be equally busy. In case you want to meet me there, just let me know, we can try to arrange something in free slots :-).

Filed under: Debian English Gammu Phpmyadmin Suse 0 comments Flattr this!

I just got confirmed my flight bookings for FOSDEM 2012, so I'm looking to meet all great people there again. This year we've again arranged there meeting of phpMyAdmin developers, now it also includes three new faces from last years GSoC. As for my schedule I did not yet find time to check all the schedule, but what definitely sounds interesting for me is Open Mobile Linux Devroom and some talks in MySQL and Friends Devroom. Rest will be (as usual) scheduled on the fly as I meet people there. This year I decided to deliberately skip keysigning as last year I anyway did not manage to attend it and I expect this year to be equally busy. In case you want to meet me there, just let me know, we can try to arrange something in free slots :-).

Filed under: Debian English Gammu Phpmyadmin Suse 0 comments Flattr this!

Two changes in this release. First, Guido G nther submitted a patch (which I then mangled) to notice if the DIST ends in -backports and git-pbuilder is calling the builder with an action like create and, in that case, passing --othermirror with the Debian backports mirror. This lets one create new build chroots for squeeze-backports with just:

    env DIST=squeeze-backports git-pbuilder create

without any additional configuration required. Second, Rafa D ugo cki pointed out the cause of the weird error message that I'd been noticing for years: "W: /root/.pbuilderrc does not exist". git-pbuilder runs the builder with sudo when performing an action like login or create, but sudo resets the environment including HOME, so it tries to load .pbuilderrc from root's home directory. This isn't very useful, so now git-pbuilder checks if a .pbuilderrc exists in the user's home directory and loads it with an explicit --configfile option if it does. You can get the latest version from my scripts distribution page, and I expect it will turn up in the git-buildpackage package before long.

A new version of RInside, now at 0.2.6, is now available via CRAN. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by the Rcpp R and C++ integration package. This release has an additional fix for the Windows use case, adds cmake support files for the examples, switches to using the same RNG initialization of time and process id that R uses, and other minor fixes. All changes since the last release are summarized below:

2012-01-11  Dirk Eddelbuettel  <edd>
        * DESCRIPTION: Release 0.2.6
        * DESCRIPTION: Updated Description: text 
2012-01-08  Dirk Eddelbuettel  <edd>
        * src/RInside.cpp: Correct console writer on Windows to not use
        Rprintf (with thanks to both James Bates and John Brzustowski)
        * src/RInside.cpp: Update RNG seeding to same scheme now used by
        R which blends both (millisecond) time and process id
        * src/RInside.cpp: Replace fprintf(stderr,...) with Rf_error(...)
        * src/setenv/setenv.c: Idem
        
        * inst/examples/*: Added CMake build support for all example
        directories kindly provided by Peter Aberline; this helps when coding
        inside of IDEs such as Eclipse, KDevelop or Code::Blocks
        * inst/examples/standard/Makefile.win: Allow for an R_ARCH variable
        to be set to enforce either i386 or x64 builds

CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.