I recently started getting mails from no-reply@joindiaspora.com. Usually, a mail from no-reply@whatever is enough to make me believe that the admins of said whatever are clueless regarding what e-mail means and how should it work. And in this case, it really amazes me If I get an invite to Diaspora*, right, I should not pester a hypothetical sysadmin@joindiaspora.com to get me off his list, but I should be able to reply to the person mailing me Maybe requesting extra details on what he is inviting me to, or allowing me to tell him why I'm not interested. But yes, Diaspora* has fallen to the ease of requiring me to join their network to be able to communicate back with the "friend" who invited me. Some of the (three?) readers of this site might not be familiar with the Diaspora* project. It is a free reimplementation (as far as I know) of something similar to Facebook Free not only in the sense that it runs free software, but also because it is federated Your data will not belong to a specific company (that is, you are not the value object they sell and make money with), but you can choose and switch (or become) the provider for your information. A very interesting proposal, socially and technically. I find that a gross violation of netiquette. I should be able to reply to the mail - Even if in this case it were to (and sorry As you are spreading my name/mail, you will excuse me if I spread your name ;-) ) fernando.estrada.invite1501335@joindiaspora.com. Such an (fictional FWIW) address would allow for mail to reach back the submitter by the same medium it was sent, without allowing open spamming into the network. Now, what prompted me to write this mail (just before adding no-reply@joindiaspora.com to my blacklist) is the message I got (in an ugly HTML-only mail which erroneously promised to be text/plain, sigh...) is that Fernando sent me as the inviting message, So, at least are you going to give Diaspora a chance? The answer is: No.. But not because of being a fundamentalist. Right, I am among what many people qualify as Free Software zealots, but many of my choices (as this one is) is in no way related to the software's freeness. I use non-free Web services, as much as many of you do. Yes, I tend to use them less, rather than more (as the tendency goes). But the main reason I don't use Twitter is the same reason I don't use Identi.ca, its free counterpart And the reason I'm not interested in Facebook is the same reason I will not join Diaspora* Because I lack time for yet another stream of activity, of information, of things to do and think about. Yes, even if I care about you and I want to follow what's going on in your life: The best way to do it is to sit over a cup of coffee, or have some dinner, or to meet once a year in the most amazing conference ever. Or we can be part of distributed projects together, and we will really interact lots. Or you can write a blog! I do follow the blogs of many of my friends (plus several planets), even if they have fallen out of fashion A blog post pulls me to read it as it is a unit of information, not too much depending on context (a problem when I read somebody's Twitter/Identica lines: You have to hunt a lot of conversations to understand what's going on), gives a true dump of (at least one aspect of) your state of (mind life work), and is a referenceable unit I can forward to other people, or quote if needed. So, yes, I might look old-fashioned, clinging to the tools of the last-decade for my Social Web presence. I will never be a Social Media Expert. I accept it But please, don't think it is a Stallmanesque posture from me. It is just that of a person who can lose too much time, and needs to get some work done in the meantime. (oh, of course: Blog posts also don't have to make much sense or be logically complete. But at least they allow me to post a full argument!)

Oh, boy. Where do I start I postulate that there exists something called the "UI Singularity". Those who spend too much time considering the optimal way to interact with computing devices eventually pass through this singularity and can no longer effectively communicate with those of us on the other side. At least that's one way to explain what seems to be happening to free-software desktop environments. From the outside, it would appear this happened to KDE with KDE 4, and now, unfortunately, it has happened to GNOME, with GNOME 3. I've had GNOME 3.0 running on my Debian laptop for a few months, which I have used casually. At work, we installed Fedora 15 (GNOME 3.0) on our 69-seat Linux lab over the summer, which I have used on occasion to achieve specific things. I haven't dared upgrade my main work machine yet. So, it could be argued that I haven't spent enough time immersed in the GNOME 3 experience to really judge it fairly. On the face of it, I wish 3 was an iterative development from 2, and didn't throw so many babies out with the bathwater. My casual use of it so far has not endeared it to me at all. In the interests of being fair, rather than deliver my opinion of GNOME 3 as it currently stands, I've decided to try and use it in anger for a while to truly see whether I can "get it". Now that we're past the start of term, I am attempting to use a lab-configured Fedora 15 machine as my main work environment. I'll run with this for a while, and then try a Fedora 16 instance (I need to consider whether we should move to F16 for the second semester anyway) to see what improvements GNOME 3.2 brings.

It s seeming increasingly likely that reports regarding the future of Banshee, Tomboy, and the rest of the Mono stack in the default Ubuntu desktop install are accurate. Ubuntu 12.04 will likely be the first Ubuntu release since 5.10 not to ship with any Mono apps in the default install ending a run of 12 releases over 6 years. The decision seems to have come about during the default apps session at the Ubuntu Developer Summit just ended in Orlando, Florida. Prior to heavy vandalism, the only reasons cited for the change in the UDS session log are Banshee not well maintained and porting music store to GTK3 is blocked on banshee ported to GTK3 . Other reasons mentioned but not in the session logs are complaints that it doesn t work on ARM. I m using a lot of conjecture in this first paragraph because the news about the decision appeared on the blogosphere before anywhere else. The first many Banshee or Tomboy developers read about it was reading a flurry of activity on the Tweetosphere from the anti-Mono activists declaring victory. So first, a word on the cited reasoning. Banshee works fine on ARM, since Mono works fine on ARM. Xamarin, the company behind most upstream Mono work, earns their income almost entirely from ARM versions of Mono, running on the varied ARM implementations found in smartphones. Every major Banshee release is personally tested on my Genesi EfikaMX, an ARM system with a Freescale i.mx51 processor. I ve also demonstrated Banshee running in an Ubuntu chroot on my HP Touchpad, an ARM-based tablet. What is known is that Banshee has some problems running on Texas Instruments OMAP4 processors the target ARM platform for Canonical s ARM work. None of the Banshee upstream developers, Mono upstream developers, or Mono Ubuntu team has ever been able to reproduce the cited problems, since problems specific to an exact ARM chip are impossible to reproduce without the requisite hardware and none of us owns an ARM system matching Canonical s target. That Banshee is still a GTK+2 app is true. A port to GTK+3 is almost complete, but blocking on a single technical bug deep within GTK# s guts, which could be fixed by someone with sufficient knowledge of GTK+ semantics. Nobody with the required GTK+ knowledge has stepped forward with a fix at this point in time. As for the final point, that Banshee is not well maintained, this seems like a directed personal insult against the active and responsive Banshee maintainer, Chow Loong Jin, and upstream bug triager David Nielsen, in addition to the immeasurable hours contributed free of charge for the benefit of Ubuntu users by various other members of related Mono app and library teams, including myself. I need to stress at this point that my annoyance with this decision has nothing to do with the actual app changes. Keeping Tomboy and gbrainy, at a cost of about 25 meg of unsquashed disk space, is a hard argument to make compared with those two plus Banshee for 40 meg. Dropping gbrainy and Tomboy, and switching to Rhythmbox, will save about 30 meg of unsquashed space, all told.I m unconvinced that Rhythmbox is a technically superior app to Banshee several features which were gained by the first app swap will be lost again but that s another long tedious argument to be had. No, what has me deeply angered is the shambolic way the changes were made and announced. Significant accommodations were made by Banshee upstream in order to make life easier for Canonical to integrate Banshee into their OS. For one thing, that s why the Ubuntu One Music Store support is a core Banshee feature, not part of the third-party community extensions package. If Banshee was being considered for replacement due to unresolved technical issues, then perhaps it would have been polite to, I don t know, inform upstream that it was on the cards? Or, if Canonical felt that problems specific to their own itches required scratching, then is it completely beyond the realm of possibility to imagine they might have spent developer resources on bug fixing their OS and sending those fixes upstream? Or even and call me crazy providing access for upstream to specialized hardware such as a $174 Pandaboard to empower upstream to isolate and fix unreproducible bugs specific to Canonical s target hardware? And here s where it gets more astonishing for me Canonical paid money to ship one of the community-based packagers responsible for the stack, Iain Lane, to Orlando for UDS, and didn t think it was worth bothering to perhaps inform him hey, the stuff you work on is in danger of being axed from the default install, maybe you should go to this session . So I m not cross that the stuff I work on has been removed from the default install. I intend to continue working on it as I have for the last 4 years, through my work in Debian. No, why I m cross that I heard about it from fucking Boycott Novell. Regardless of your opinions regarding Banshee or its stack, if you read the above and don t see it as an abysmal failure of community engagement by a company whose community manager wrote a book on the damn topic, then there s something seriously wrong with your understanding of how community labour should be seen as a resource. Maybe someone at Canonical should try reading Jono s book. It s not a first-time offence, and this mail from a PiTiVi developer regarding changes in 11.10 makes for useful further reading. [edit] There is some worthwhile discussion going on on the ubuntu-desktop mailing list covering the technical issues surrounding the decision, I would suggest it s a good place for ongoing technical discussion.

I recently purchased a Seagate FreeAgent GoFlex 1 TB hard drive. It is a 2.5" compact disk that you connect over USB. It draws its power from the USB controller. My previous Extern HDDs were all 2.5" laptop drives, for which I bought a USB enclosure. Those devices always worked perfect, as in:

• They were automatically detected
• Partitions/File Systems understood
• Desktop systems would prompt for actions

The typical kernel messages I got for these devices were:

[56063.268107] usb 1-1: new high speed USB device number 13 using ehci_hcd

[56063.401635] usb 1-1: New USB device found, idVendor=14cd, idProduct=6116

[56063.401645] usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2

[56063.401652] usb 1-1: Product: USB 2.0 SATA BRIDGE

[56063.401658] usb 1-1: Manufacturer: Super Top

[56063.401663] usb 1-1: SerialNumber: M6116018VF16

[56063.402857] scsi8 : usb-storage 1-1:1.0

[56064.400896] scsi 8:0:0:0: Direct-Access WDC WD50 00BEVT-24A0RT0 PQ: 0 ANSI: 0

[56064.401576] sd 8:0:0:0: Attached scsi generic sg2 type 0

[56064.402102] sd 8:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)

[56064.402615] sd 8:0:0:0: [sdb] Write Protect is off

[56064.402618] sd 8:0:0:0: [sdb] Mode Sense: 03 00 00 00

[56064.403101] sd 8:0:0:0: [sdb] No Caching mode page present

[56064.403105] sd 8:0:0:0: [sdb] Assuming drive cache: write through

[56064.404861] sd 8:0:0:0: [sdb] No Caching mode page present

[56064.404864] sd 8:0:0:0: [sdb] Assuming drive cache: write through

[56064.419657] sdb: sdb1

[56064.421850] sd 8:0:0:0: [sdb] No Caching mode page present

[56064.421854] sd 8:0:0:0: [sdb] Assuming drive cache: write through

[56064.421857] sd 8:0:0:0: [sdb] Attached SCSI disk

But for my Seagate FreeAgent GoFlex HDD, things were different. The kernel would detect but then it would not mount. The error reported is that the device is busy. My FreeAgent's kernel messages look similar to what the regular one has:

[ 168.520140] usb 1-1: new high speed USB device number 5 using ehci_hcd

[ 168.657424] usb 1-1: New USB device found, idVendor=0bc2, idProduct=5021

[ 168.657433] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 168.657439] usb 1-1: Product: FreeAgent GoFlex

[ 168.657444] usb 1-1: Manufacturer: Seagate

[ 168.657449] usb 1-1: SerialNumber: NA0C1BML

[ 168.659079] scsi5 : usb-storage 1-1:1.0

[ 169.657136] scsi 5:0:0:0: Direct-Access Seagate FreeAgent GoFlex 0148 PQ: 0 ANSI: 4

[ 169.708786] sd 5:0:0:0: Attached scsi generic sg3 type 0

[ 169.709079] sd 5:0:0:0: [sdc] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB)

[ 169.709954] sd 5:0:0:0: [sdc] Write Protect is off

[ 169.709963] sd 5:0:0:0: [sdc] Mode Sense: 1c 00 00 00

[ 169.710567] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[ 169.759942] sdc: sdc1

[ 169.762050] sd 5:0:0:0: [sdc] Attached SCSI disk

As the Device Mapper Multipath Debian Maintainer, I have multipath-tools installed on my laptop. Turns out, for some reason, the device is consumer by the device mapper multipath stack.

20:12:58 rrs@champaran:~$ ls /dev/mapper/

1Seagate@ 1Seagate FreeAgent GoFlex N 1Seagate FreeAgent GoFlex Np1 control LocalDisk-ROOT@ LocalDisk-SWAP@

Also the block device ID listing is enumerated as type SCSI.

19:56:44 rrs@champaran:~$ ls /dev/disk/by-id/

ata-HITACHI_HTS723216L9SA60_091220FC1220NCJASEVG@ scsi-SATA_HITACHI_HTS7232091220FC1220NCJASEVG@

ata-HITACHI_HTS723216L9SA60_091220FC1220NCJASEVG-part1@ scsi-SATA_HITACHI_HTS7232091220FC1220NCJASEVG-part1@

ata-HITACHI_HTS723216L9SA60_091220FC1220NCJASEVG-part2@ scsi-SATA_HITACHI_HTS7232091220FC1220NCJASEVG-part2@

ata-HITACHI_HTS723216L9SA60_091220FC1220NCJASEVG-part3@ scsi-SATA_HITACHI_HTS7232091220FC1220NCJASEVG-part3@

ata-HL-DT-ST_DVDRAM_GU10N_M189CNI1127@ scsi-SSeagate_FreeAgent_GoFle_NA0C1BML@

ata-ST1000LM010-9YH146_W1000ZD8@ usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0@

dm-name-1Seagate@ usb-WDC_WD12_00BEVE-11UYT0_ST_Killer-0:0-part1@

dm-name-LocalDisk-ROOT@ wwn-0x5000c5003d19c8c2@

dm-name-LocalDisk-SWAP@ wwn-0x5000cca586e112bc@

dm-uuid-LVM-buywwzKkpfKG2RegankA2nPkmFBBPFe3D5DepV8w8nLrHfoAjIIQVnakOQJZEqJX@ wwn-0x5000cca586e112bc-part1@

dm-uuid-LVM-buywwzKkpfKG2RegankA2nPkmFBBPFe3k9aJfc9B7wRmVIwfoagffHUZjuN6c4cM@ wwn-0x5000cca586e112bc-part2@

dm-uuid-mpath-1Seagate@ wwn-0x5000cca586e112bc-part3@

raid-1Seagate@

But I'm not sure why the same doesn't happend for my external laptop drive. It gets properly tagged as device type USB. So Laptop or Server, if you have a FreeAgent that you want to connect to your machine, and see the device busy error when accessing the device['s] directly, do the following:First, the ID of the device.

20:17:43 rrs@champaran:~$ /lib/udev/scsi_id --whitelisted --page=0x83 --device=/dev/sdc

1Seagate FreeAgent GoFlex N

Add the ID to /etc/multipath.conf under blacklist section

blacklist

wwid "1Seagate FreeAgent GoFlex*"

wwid "1Seagate FA GoFlex Desk*"

# devnode "^(ram raw loop fd md dm- sr scd st)[0-9]*"

# devnode "^hd[a-z][[0-9]*]"

# device

# vendor DEC.*

# product MSA[15]00

#

Run mulitpath -F to flush the unused maps. Run multipath -v3 to ensure that now the device is blacklisted.

Nov 03 20:19:02 sdc: (Seagate:FreeAgent GoFlex) wwid blacklisted

The front cause for the mis-behavior is:

# Coalesce multipath devices before multipathd is running (initramfs, early

# boot)

ACTION=="add change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/$name"

But something else, maybe the default blacklist table, needs the actual fix.

This is a follow-up on a previous post: I used a bit of a rainy Sunday to read some docs and write some Python, and I now have a script that converts events from a Guitar Hero World Tour drums controller to MIDI. A brief explanation of how it works: in its standard configuration, the drums controller has five pads and a pedal, and it uses a Wiimote to communicate the events (what pad was hit with what force, or what button was pressed/released, or the position of the mini-stick) to the Wii itself. This communication happens over Bluetooth and not over a dedicated cable or protocol, so it is possible to remove the Wii and use a standard computer with Bluetooth (built-in or via a dongle) instead, and the computer will receive messages. There's some decoding to do, but fortunately people have reverse-engineered the frames, and come up with the libcwiid library and its Python binding, which hides the complexity of the decoding and just delivers structured data to the programs that use it. Then we analyze this data and extract the relevant info from it (with some juggling of bits): "the X pad was hit with force Y". From there, it's a simple matter of mapping the pads to a MIDI note and the force to a MIDI velocity, and of sending the appropriate MIDI message to the target, for instance with the libportmidi library. What you do with the MIDI output is your call: I use it to add more pads to my electronic drum kit, but it could equally be used to drive a software synthetizer, or an external sound module. Or a light-show machine. Or fireworks. Or a model railway. Or whatever. Here's the current version of the wiigh2midi.py script (for updated versions, see the Bazaar repository).

#! /usr/bin/python
import cwiid, time, asyncore, pypm
class Wiimidi:
    wiimote = None
    midiout = None
    lastaction = time.time()
    wii2color =   27: 'kick',
                  25: 'red',
                  17: 'yellow',
                  15: 'blue',
                  14: 'orange',
                  18: 'green'  
    color2midi =   'kick': 36, # Bass drum
                   'red': 38, # Snare drum
                   'blue': 48, # High tom
                   'green': 43, # Low tom
                   'yellow': 42, # Closed hi-hat
                   'orange': 52, # Crash cymbal
                    
    def connect_wiimote(self):
        print "Press 1+2 on the Wiimote..."
        try:
            self.wiimote = cwiid.Wiimote()
        except:
            self.wiimote = None
            return None
        print "Connected."
        self.lastaction = time.time()
        self.wiimote.rumble=1
        time.sleep(.2)
        self.wiimote.rumble=0
        return self.wiimote
    def disconnect_wiimote(self):
        if self.wiimote is not None:
            print "Closing connection to the Wiimote."
            self.wiimote.close()
            self.wiimote = None
        return
    def connect_midi(self):
        for i in range(pypm.CountDevices()):
            interf,name,inp,outp,opened = pypm.GetDeviceInfo(i)
            if outp == 1:
                if name == 'UM-1G MIDI 1':
                    self.midiout = pypm.Output(i, 0)
                    return
        for i in range(pypm.CountDevices()):
            interf,name,inp,outp,opened = pypm.GetDeviceInfo(i)
            if outp == 1:
                print i, name," ",
                print
        dev = int(raw_input("Type output number: "))
        self.midiout = pypm.Output(dev, 0)
    def wiimote_callback(self, messages, timestamp):
        self.lastaction = time.time()
        m = messages[0][1]
        # rx = m['r_stick'][0]
        ry = m['r_stick'][1]
        l = m['l']
        # r = m['r']
        which = ( (l << 1) & 16) + (ry >> 1)
        softness = l & 7
        if softness == 7 or which == 0:
            return
        # print "rx=%d\t ry=%d\t l=%d\t r=%d\t rest=%d" % (rx,ry,l,r,rest)
        # print "which = %d, softness = %d" % (which, softness)
        strength = 7-softness
        color = self.wii2color[which]
        midi_vel = 16*strength
        midi_note = self.color2midi[color]
        self.midiout.WriteShort(0x9a,midi_note,midi_vel)
        self.midiout.WriteShort(0x9a,midi_note,0)
        # print "%s %d -> %d %d" % (color, strength, midi_note, midi_vel)
    def main(self):
        self.connect_midi()
        while True:
            if self.wiimote is None:
                self.connect_wiimote()
                if self.wiimote:
                    # Tell Wiimote to display rock sign
                    self.wiimote.led = cwiid.LED1_ON   cwiid.LED4_ON
                    # We only care for the extension data
                    self.wiimote.rpt_mode = cwiid.RPT_EXT
                    self.wiimote.enable(cwiid.FLAG_MESG_IFC   cwiid.FLAG_REPEAT_BTN)
                    self.wiimote.mesg_callback = self.wiimote_callback
                    self.lastaction = time.time()
                else:
                    print "Retrying... "
                    print
            asyncore.loop(timeout=0, count=1)
            if self.lastaction < time.time() - 3600:
                print "An hour passed since last action..."
                self.disconnect_wiimote()
            time.sleep(0.05)
        print "Exited safely."
# Instantiate and run
inst = Wiimidi()
inst.main()

There are a few obvious improvements to be made: first, handling guitar controllers in addition to drums. Second, handling the buttons could provide extra "pads", to trigger sound effects for instance (thunder, lasers, voices ), or to initiate program changes, or to change the mappings of the pads. Maybe storing the mutable parts (default MIDI adapter, pad-to-note mapping) in a configuration file. Maybe add a user interface to ease the configuration. Patches welcome, otherwise maybe I'll do that myself on another rainy Sunday. Notes and references (in other words, the giants on whose shoulders this program stands):

• As mentioned, this script uses the pyPortMidi binding, available in Debian Wheezy as python-pypm (and easily backported to Squeeze).
• It also uses the Python bindings to CWiid, available in Debian as python-cwiid.
• I based the pad-to-MIDI mapping on the relevant part of the General MIDI specification.
• The bit-mangling operations used to map cwiid messages to plain data were worked out by comparing the tables from the Wiibrew wiki on the classic controller and the drums controller.
• The skeleton of the script was initially based on MythPyWii, although not much of it still remains.

More cowbell!

I have published a small article in the November edition of the German electronic magazine freiesMagazin on gtk-vector-screenshot. Their format is especially nice for that, given that the vector screenshots are embedded as such in the PDF version of the magazine, so the reader can zoom in and check for herself that it is indeed a vector screenshot.

Flattr this post

Bike Scheme for Galway From the Galway Advertiser: Galway has emerged as a frontrunner in terms of its suitability for the introduction of a public bike scheme, similar to that already in action in Dublin, and which could see the setting up of 23 docking stations for 250 public bikes across the city at a estimated cost of 1.55 million. Tags: #Galway, #cycling

Dear lazyweb, I was searching through the internet what was I doing wrong, I wrote to the polipo-user list but my email got stuck on moderation, and my connection is really shitty (that s why I m using polipo the way I m using it). I have relaxTransparency and mindlesslyCacheVary set to true, but I don t need so aggresive caching in my development stages that are located under *.local and another development subdomain on the net. Already tried setting uncachableFile to /etc/polipo/uncachable and to ~/.polipo-uncachable, according to the web-config thing is properly setted up, but can t get it to recognize it s content. I first thought it was I was writing bad the regex, .*\.local but it does work in the /etc/polipo/forbidden file. Besides, adding complete domains to the uncachable file doesn t works neither. Could someone confirm this or throw me a hand on this? I m using 1.0.4.1-1.1 version which is the last one on unstable repos.

ERROR: WOUTER+TIMHOTEL@GREP.BE is not a valid email address True, because I entered it in lowercase.

1. Email address local parts (the bit before the @) are case sensitive. That means you can't just convert it to all caps and assume it will arrive.
2. local parts can be composed out of any character from the following list:
• alphanumeric characters (a-z, A-Z, 0-9), and
• !#$%&'*+-/=?^_ ~.

This means that if you're trying to validate an email address by adding a regular expression that does more than check whether there's not exactly one @ in the address, you're almost always wrong. Next time you try to tell me my mail address is invalid, go read the RFC first. Morons.

So, there is some history of organisations doing a poor job at managing security bugs. We saw the This is not really a security hole jokes just to avoid having bad statistics in the front page. We saw the OMFG you must update to the latest version RIGHT NOW and no I m not telling why panic. We still frequently see security fixes hidden in unrelated public commits, just to make them harder to backport for distributors. But really, there is absolutely no match for that. Kudos for setting a new standard in the worse way of dealing with security issues, guys. Update: one of the developers has started insulting a pair of professional IT security experts who came and tried to educate him. Awesome reading, don t forget the popcorn.

There are various presentations that state the goodness of PAV on Linux. Most revolve around using multipath-tools to assemble a volume if you don't have HyperPAV. But it turns out that the DASD device driver does multipathing for them internally in current kernels (which includes the squeeze kernel).

So all you need to do is setting those alias devices online. When you do that the kernel will log that it detected a new device, but you'll find that it won't create any dasd* device nodes for them, nor will it list partitions. lsdasd will only show you "alias" without mentioning the base volume, but you can fetch that information easily from the uid sysfs entry.

This story has been floating around for a week or so. The summary is that someone bought a system that has UEFI and is having trouble installing Linux on it. In itself, not a problem. But various people have either conflated this with the secure boot issue or suggested that UEFI is a fundamentally anti-Linux technology.

Right now there are no machines shipping to the public with secure boot enabled. None at all. If you're having problems installing Linux on a machine with UEFI then it's not because of secure boot. So what is actually causing the problem?

UEFI is a complicated specification, with 2.3.1A being 2214 pages long. It's a large body of code. There's a lot of subtleties. It's very easy for people to get things wrong. For example, we've seen issues where calling SetVirtualAddressMap() resulted in the firmware referencing boot services code, a clear violation of the spec on the firmware authors' part. We've also found machines that failed to boot because grub wasn't aligning its stack properly, a clear violation of the spec on our part.

Software is difficult. People make mistakes. When something mysteriously fails to work the immediate assumption should be that you've found a bug, not a conspiracy. Over time we'll find those bugs and fix them, but until then just treat UEFI boot failures like any other bug - annoying, but not malicious.

comments

There are many system administration and configuration management tools available, I've mentioned them in the past and we're probably all familiar with our pet favourites. The "biggies" include CFEngine, Puppet, Chef, BFG2. The "minis" are largely in-house tools, or abuses of existing software such as fabric. My own personal solution manages my home network, and three dedicated servers I pay for in various ways. Currently I've been setting up some configuration "stuff" for a friend and I've elected to manage some of the setup with this system of my own, and I guess I need to decide what I'm going to do going forward. slaughter is well maintained, largely by virtue of not doing too much. The things it does are genuinely useful and entirely sufficient to handle a lot of the common tasks - and because the server-side requirement is a HTTP server, and the only client-side requirement is CRON it is trivial to deploy. In the past I've thought of three alternatives that would make it more complex:

• Stop using HTTP and have a mini-daemon to both serve and schedule.
• Stop using HTTP and use rsync instead.
• Rewrite it in Javascript. (Yes, really).

Each approaches have their appeal. I like the idea of only executing GPG-signed policies, and that would be trivial if there was a real server in place. It could also use SSL because that's all you need for security (ha!). On the other hand using rsync allows me to trivially implement the only missing primitive I actually miss at times - the ability to recursively download and install a remote directory tree. (I solve this problem by downloading a .tar file and unpacking it. Not good. Doesn't cope with template expansion and is fiddlier than I like). In the lifetime of the project I think I've had 20-50 feature requests or comments, which suggests it might actually be used by 50-100 people. (Ha! Optimism) In the meantime I'll keep a careful eye on the number of people who download the tarball & the binary packages... ObQuote: "I have vermin to kill. " - Kill Bill

[Latest version of these instructions can be found at the SFML Wiki] CMake allows your project to be built in various environments, including command-line make, Code::Blocks project files, Eclipse project files, etc. It's used in SFML 2.0. In this tutorial we'll write a simple CMake configuration file with centralized version numbering, and see how to integrate SFML in it. The source files First, create a cmake_modules directory and copy FindSFML.cmake in it. FindXXXX is automatically searched by CMake's find_package command. Then create a main.cpp, for instance:

#include "config.h"
#include <iostream>
#include <SFML/Window.hpp>
using namespace std;
int main(int argc, char* argv[])  
  cout << "Version " << myproject_VERSION_MAJOR << "." << myproject_VERSION_MINOR << endl;
  sf::Window screen(sf::VideoMode(800, 600), "myproject");
  bool running = true;
  while (running)  
    screen.Display();
   
 

We use a config.h file that is built by CMake, let's also create a config.h.in file:

#define myproject_VERSION_MAJOR @myproject_VERSION_MAJOR@
#define myproject_VERSION_MINOR @myproject_VERSION_MINOR@

And place your project license (such as the GNU GPL) in a file named COPYING. CMake configuration Let's describe our project configuration in the CMakeLists.txt file:

cmake_minimum_required(VERSION 2.6)
project(myproject)
# Set version information in a config.h file
set(myproject_VERSION_MAJOR 1)
set(myproject_VERSION_MINOR 0)
configure_file(
  "$ PROJECT_SOURCE_DIR /config.h.in"
  "$ PROJECT_BINARY_DIR /config.h"
  )
include_directories("$ PROJECT_BINARY_DIR ")
# Define sources and executable
set(EXECUTABLE_NAME "myproject")
add_executable($ EXECUTABLE_NAME  main.cpp)
# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )
# Install target
install(TARGETS $ EXECUTABLE_NAME  DESTINATION bin)
# CPack packaging
include(InstallRequiredSystemLibraries)
set(CPACK_RESOURCE_FILE_LICENSE "$ CMAKE_SOURCE_DIR /COPYING")
set(CPACK_PACKAGE_VERSION_MAJOR "$ myproject_VERSION_MAJOR ")
set(CPACK_PACKAGE_VERSION_MINOR "$ myproject_VERSION_MINOR ")
include(CPack)

The interesting part is:

# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )

• First we specify where we stored the FindSFML.cmake module.
• Then we request CMake to look for it in the system, and search for the specified modules (here I specified them all).
• Last, we tell CMake to link our executable with the SFML libraries that it just found.

Compilation To build with Make and the GCC compiler on the command-line:

cd build/  # a separate directory so we can easily remove all the CMake work files
cmake ..  # generate Makefile's
make

To create Code::Blocks project files:

cmake .. -G "CodeBlocks - Unix Makefiles"

and open project.cbp with Code::Blocks. Installation CMake supports the classic:

make install

It also supports DESTDIR, useful in packaging:

make install DESTDIR= pwd /myworkdir

You can also define CMAKE_INSTALL_PREFIX when invoking cmake to change the default install path (/usr/local under Unix). DESTDIR would still override this setting. Packaging You then can use cpack to make a project release:

# Binary package:
cpack -C CPackConfig.cmake
# Source package:
cpack -C CPackSourceConfig.cmake

You will get a nice myproject-1.0.tar.gz, among others. Further information

• CMake has built-in help, for instance:

$ cmake --help-variable CMAKE_SOURCE_DIR
cmake version 2.8.5
  CMAKE_SOURCE_DIR
       The path to the top level of the source tree.
       This is the full path to the top level of the current CMake source
       tree.  For an in-source build, this would be the same as
       CMAKE_BINARY_DIR.

• Reference for v2.8
• CMake Tutorial

Some days ago, a hacker group, THC, released a denial of service tool for SSL web servers. As stated in its description, the problem is not really new: a complete SSL handshake implies costly cryptographic computations. There are two different aspects in the presented attack:

• The computation cost of an handshake is more important on the server side than on the client side. The advisory explains that a server will require 15 times the processing power of a client. This means a single average workstation could challenge a multi-core high-end server.
• The use of SSL renegotiation allows to trigger hundreds of handshakes in the same TCP connection. Even a client behind a DSL connection can therefore bomb a server with a lot of renegotiation requests.

Mitigation techniques There is no definitive solution to this attack but there exists some workarounds. Since the DoS tool from THC relies heavily on renegotiation, the most obvious one is to disable this mechanism on the server side but we will explore other possibilities.

Disabling SSL renegotiation Tackling the second problem seems easy: just disable SSL renegotiation. It is hardly needed: a server can trigger a renegotiation to ask a client to present a certificate but a client usually does not have any reason to trigger one. Because of a past vulnerability in SSL renegotiation, recent version of Apache and nginx just forbid it, even when the non-vulnerable version is available. openssl s_client can be used to test if SSL renegotiation is really disabled. Sending R on an empty line trigger renegotiation. Here is an example where renegotiation is disabled (despite being advertised as supported):

$ openssl s_client -connect www.luffy.cx:443 -tls1
[...]
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
[...]
R
RENEGOTIATING
140675659794088:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:591:

Disabling renegotation is not trivial with OpenSSL. As an example, I have pushed a patch to disable renegotiation in stud, the scalable TLS unwrapping daemon.

Rate limiting SSL handshakes Disabling SSL renegotiation on the client side is not always possible. For example, your web server may be too old to propose such an option. Since those renegotiations should not happen often, a workaround is to limit them. When the flaw was first advertised, F5 Networks provided a way to configure such a limitation with an iRule on their load-balancers. We can do something similar with just Netfilter. We can spot most TCP packets triggering such a renegotiation by looking for encrypted TLS handshake record. They may happen in a regular handshake but in this case, they usually are not at the beginning of the TCP payload. There is no field saying if a TLS record is encrypted or not (TLS is stateful for this purpose). Therefore, we have to use some heuristics. If the handshake type is unknown, we assume that this is an encrypted record. Moreover, renegotiation requests are usually encapsulated in a TCP packet flagged with push .

# Access to TCP payload (if not fragmented)
payload="0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @"
iptables -A LIMIT_RENEGOCIATION \
    -p tcp --dport 443 \
    --tcp-flags SYN,FIN,RST,PSH PSH \
    -m u32 \
    --u32 "$payload 0 >> 8 = 0x160300:0x160303 && $payload 2 & 0xFF = 3:10,17:19,21:255" \
    -m hashlimit \
    --hashlimit-above 5/minute --hashlimit-burst 3 \
    --hashlimit-mode srcip --hashlimit-name ssl-reneg \
    -j DROP

The use of u32 match is a bit difficult to read. The manual page gives some insightful examples. $payload allows to seek for the TCP payload. It only works if there is no fragmentation. Then, we check if we have a handshake (0x16) and if we recognise TLS version (0x0300, 0x0301, 0x0302 or 0x0303). At least, we check if the handshake type is not a known value. There is a risk of false positives but since we use hashlimit, we should be safe. This is not a bullet proof solution: TCP fragmentation would allow an attacker to evade detection. Another equivalent solution would be to use CONNMARK to record the fact the initial handshake has been done and forbid any subsequent handshakes. If you happen to disable SSL renegociation, you can still use some Netfilter rule to limit the number of SSL handshakes by limiting the number of TCP connections from one IP:

iptables -A LIMIT_SSL \
    -p tcp --dport 443 \
    --syn -m state --state NEW \
    -m hashlimit \
    --hashlimit-above 120/minute --hashlimit-burst 20 \
    --hashlimit-mode srcip --hashlimit-name ssl-conn \
    -j DROP

Your servers will still be vulnerable to a large botnet but if there is only a handful of source IP, this rule will work just fine¹. I have made all those solutions available in a single file.

Increasing server-side power processing SSL can easily be scaled up and out. Since SSL performance increases linearly with the number of cores, scaling up can be done by throwing in more CPU or more cores per CPU. Adding expensive SSL accelerators would also do the trick. Scaling out is also relatively easy but you should care about SSL session resume.

Putting more work on the client side In their presentation of the denial of service tool, THC explains:

Establishing a secure SSL connection requires 15 more processing power on the server than on the client.

I don t know where this figure comes from. To check it, I built a small tool to measure CPU time of a client and a server doing 1000 handshakes with various parameters (cipher suites and key sizes). The results are summarized on the following plot: For example, with 2048bit RSA certificates and a cipher suite like AES256-SHA, the server needs 6 times more CPU power than the client. However, if we use DHE-RSA-AES256-SHA instead, the server needs 34% less CPU power. The most efficient cipher suite from the server point of view seems to be something like DHE-DSS-AES256-SHA where the server needs half the power of the client. However, you can t really uses those shiny cipher suites:

1. Some browsers do not support them: they are limited to RSA cipher suites².
2. Using them will increase your regular load a lot. Your servers may collapse with just legitimate traffic.
3. They are expensive for some mobile clients: they need more memory, more processing power and will drain battery faster.

Let s dig a bit more on why the server needs more computational power in the case of RSA. Here is a SSL handshake when using a cipher suite like AES256-SHA: When sending the Client Key Exchange message, the client will encrypt TLS version and 46 random bytes with the public key of the certificate sent by the server in its Certificate message. The server will have to decrypt this message with her private key. Those are the two most expensive operations in the handshake. Encryption and decryption are done with RSA (because of the selected cipher suite). To understand why decryption is more expensive than encryption, let me explain how RSA works. First, the server needs a public and a private key. Here are the main steps to generate them:

1. Pick two random distinct prime numbers p and q , each roughly the same size.
2. Compute n=pq . It is the modulus.
3. Compute \varphi(n)=(p-1)(q-1) .
4. Choose an integer e such that 1<e<\varphi(n) and \gcd(\varphi(n),e) = 1 (i.e. e and \varphi(n) are coprime). It is the public exponent.
5. Compute d=e^ -1 \mod\varphi(n) . It is the private key exponent.

The public key is (n,e) while the private key is (n,d) . A message to be encrypted is first turned into an integer m<n (with some appropriate padding). It is then encrypted to a ciphered message c with the public key and should only be decrypted with the private key:

• c=m^e\mod n (encryption)
• m=c^d\mod n (decryption)

So, why is decryption more expensive? In fact, the key pair is not really generated like I said above. Usually, e is a small fixed prime number with a lot of 0, like 17 (0x11) or 65537 (0x10001) and p and q are choosen such that \varphi(n) is coprime with e . This allows encryption to be fast using exponentiation by squaring. On the other hand, its inverse d is a big number with no special property and therefore, exponentiation is more costly and slow. Instead of computing d from e , it is possible to choose d and compute e . We could choose d to be small and coprime with \varphi(n) and then compute e=d^ -1 \mod\varphi(n) and get blazingly fast decryption. Unfortunately, there are two problems with this:

• Most SSL implementation expects e to be a 32bit integer.
• If d is too small (less than one-quarter as many bits as the modulus n ), it can be computed efficiently from the public key.

Therefore, we cannot use a small private exponent. The best we can do is to choose the public exponent to be e =4294967291 (the biggest prime 32bit number and it contains only one 0). However, there is no change as you can see on our comparative plot. To summarize, no real solution here. You need to allow RSA cipher suites and there is no way to improve the computational ratio between the server and the client with such a cipher suite.

Things get worse Shortly after the release the denial of service tool, Eric Rescorla³ published a good analysis on the impact of such a tool. He asks himself about the efficiency to use renegotiation for such an attack:

What you should be asking at this point is whether a computational DoS attack based on renegotiation is any better for the attacker than a computational DoS attack based on multiple connections. The way we measure this is by the ratio of the work the attacker has to do to the work that the server has to do. I ve never seen any actual measurements here (and the THC guys don t present any), but some back of the envelope calculations suggest that the difference is small. If I want to mount the old, multiple connection attack, I need to incur the following costs:

1. Do the TCP handshake (3 packets)
2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
3. Send the SSL/TLS ClientKeyExchange, ChangeCipherSpec, Finished messages (1 packet). These can also be canned.

Note that I don t need to parse any SSL/TLS messages from the server, and I don t need to do any cryptography. I m just going to send the server junk anyway, so I can (for instance) send the same bogus ClientKeyExchange and Finished every time. The server can t find out that they are bogus until it s done the expensive part. So, roughly speaking, this attack consists of sending a bunch of canned packets in order to force the server to do one RSA decryption.

I have written a quick proof of concept of such a tool. To avoid any abuse, it will only work if the server supports NULL-MD5 cipher suite. No sane server in the wild will support such a cipher. You need to configure your web server to support it before using this tool. While Eric explains that there is no need to parse any SSL/TLS messages, I have found that if the key exchange message is sent before the server send the answer, the connection will be aborted. Therefore, I quickly parse the server s answer to check if I can continue. Eric also says a bogus key exchange message can be sent since the server will have to decrypt it before discovering it is bogus. I have choosen to build a valid key exchange message during the first handshake (using the certificate presented by the server) and replay it on subsequent handshakes because I think the server may dismiss the message before the computation is complete (for example, if the size does not match the size of the certificate). With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on this page may just be ineffective.

---

1. However, since this rule relies on source IP to identify the attacker, the risk of false positive is real. You can slow down legitimate proxies, networks NATed behind a single IP, mobile users sharing an IP address or people behind a CGN.
2. Cipher suites supported by all browsers are RC4-MD5, RC4-SHA and 3DES-SHA. Support for DHE-DSS-AES256-SHA requires TLS 1.2 (not supported by any browser).
3. Eric is one of the author of several RFC related to TLS. He knows his stuff.

As you will know, every file on a unixoid system has some meta-data like owner, group and permission bits. This is of course also true for files part of some Debian package. And it is not very surprising that different files should have different permissions. Or even different owners or groups. Which file has which settings is of course for the package maintainer to decide and Debian would not be Debian if there were not ways for the user to give their own preferences and have them preserved. This post is thus about how those settings end up in the package and what is to be observed when doing it. As you will also have heard, a .deb file is simply a tar archive stored as part of an ar archive, as you can verify by unpacking a package manually:

$ ar t reprepro_4.8.1-1_amd64.deb
debian-binary
control.tar.gz
data.tar.gz
$ ar p reprepro_4.8.1-1_amd64.deb data.tar.gz   gunzip   tar -tvvf -
drwxr-xr-x root/root         0 2011-10-10 12:05 ./
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/bash_completion.d/
-rw-r--r-- root/root     19823 2011-10-10 12:05 ./etc/bash_completion.d/reprepro
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/share/
--More--

(For unpacking stuff from scripts, you should of course use dpkg-deb --fsys-tarfile instead of ar gunzip. Above example is about the format, not a recipe to unpack files). This already explains how the information is usually encoded in the package: A tar file contains that information for each contained file and dpkg is simply using that information. (As tar stores numeric owner and group information, that limits group and owner information to users and groups with fixed numbers, i.e. 0-99. Other cases will be covered later.) The question for the maintainer is now: Where is the information which file has which owner/group/permissions in the .tar inside the .deb, and the answer is simple: It's taken from the files to be put into the .deb. This means that package tools could simply be implemented first by simply calling tar and there is no imminent need to write you own tar generator. It also means that the maintainer has full control and does not have to learn new descriptive languages or tools to change permissions, but can simply put the usually shell commands into debian/rules. There are some disadvantages, though: A normal user cannot change ownership of files and one has to make sure all files have proper permissions and owners. This means that dpkg-deb -b (or the usually used wrapper dh_builddeb) must be run in some context where you could change the file ownership to root first. This means you either need to be root, or at least to fake being root by using fakeroot. (While this could be considered some ugly workaround, it also means upstream's make install is run believing to be root, which also avoids some -- for a packager -- quite annoying automatisms in upstream build scripts assuming a package is not installed system wide if not installed as root). Another problem are random build host characteristics changing how files are created in the directory later given to dpkg-deb -b. For example an umask which might make all files non-world-readable by default. The usual workaround is to first fix up all those permissions. Most packages use dh_fixperms for this, which also sets executable bits according to some simple rules and has some more special cases so that the overall majority of packages does not need to look at permissions at all. So using some debhelper setup, every special permissions and all owner/group information for owner groups with fixed numbers only needs to be set using the normal command line tools between dh_fixperms and dh_builddeb. Everything else happens automatically. Note that games is a group with fixed gid. So it is not necessary (and usually a bug) to change group-ownership of files withing the package to group games in maintainer scripts (postinst,...). If a user wants to change permissions or ownership of a file, dpkg allows this using the dpkg-statoverride command. This command essentially manages a list of files to get special treatment and ownership and permission information they should get. This way a user can specify that files should have different permissions and this setting is applied if a new version of this file is installed by dpkg. Being a user setting especially means, that packages (that means their maintainer scripts) should not usually use dpkg-statoverride. There are two exceptions, though: Different permissions based on interaction with the user (e.g. asking question with debconf) and dynamically allocated users/groups with dynamic id. In both cases one should note that settings to dpkg-statoverride are settings of the user, so the same care should be given as to files in /etc, especially one should never override something the user has set in there. (I can think of no example where calling dpkg-statoverride --add without dpkg-statoverride --list in some maintainer script is not a serious bug: Either you override user settings or you are using debconf as a registry. Moral To recap, your package is doing something wrong if:

• Your maintainer scripts unconditionally change permissions of files within the package (Those should either be set within the package or you miss user configuration in dpkg-statoverride).
• Your maintainer scripts call dpkg-statoverride --add without having checked first whether the user already has done so with different values.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (130.30 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg work The month started with fixing newly reported bugs to prepare the 1.16.1.1 release:

• #644492: there was a flaw in a change I made to the trigger setup code. This resulted in packages being incorrectly marked as configured while they were only unpacked in a new chroot.
• #642656: dpkg-source s refusal to build when it detects unrecorded changes broke the (mostly unused, except by the lintian test suite apparently) 2.0 source format.
• #644412: the Makefile snippet buildflags.mk did not respect the new maintainer specific environment variables (like DEB_CFLAGS_MAINT_APPEND) because make does not forward environment variable through $(shell ). Fixed that by manually exporting the required variables.
• I also disabled dpkg-buildpackage s output of the build flags since it was confusing several maintainers. dpkg-buildpackage invokes debian/rules and it has no (clean) way to discover the build flags changes that maintainer request by setting the dedicated environment variables in debian/rules. Maintainers expect to see the build flags with the modifications they have requested and not just the default values set by the distribution.

With the help of Guillem, we decided on a proper fix for a race condition sometimes triggered by parallel builds when 2 concurrent dpkg-gencontrol try to update debian/files (see #642608). This ended up requiring a new package (libfile-fcntllock-perl) that the Debian perl team kindly packaged for us. With all this sorted, it was a rather easy fix. Multiarch progress I also spent lots of time on multiarch. I fixed an old bug that requested to support the multi-arch paths in case of cross-building (see #595144), the discussion was not really conclusive on which of the two proposed patches was better so I ended up picking my own patch because it was closer to how we currently deal with cross-building. Then I fixed 2 issues that have been reported on Ubuntu s dpkg. The first one (LP #863675) was rather severe since an installed package ended being disappeared in favor of its foreign counterpart that was removed (but that had some config files left). The second one (LP #853679) only affected dselect users (apparently there are still some!) who had a self-conflicting library (Provides: foo, Conflicts: foo) installed for multiple architectures. But the bulk of the time spent on multiarch has been spent discussing with various parties on how to go forward with multiarch. The release team commented on the schedule of the merge to ensure it makes it into Wheezy, and the Debian project leader also commented on the problems encountered so far. While not the best course of action I could have hoped for, it certainly helped since Guillem started pushing some reviewed commits. Out of the 66 commits that were in my pu/multiarch/full branch one week ago, 20 have been merged in the master branch already. Python-django security update and RC bug Since python-django s maintainer did not manage to prepare the required security updates, I stepped in and prepared version 1.2.3-3+squeeze2 for Squeeze and 1.0.2-1+lenny3 for Lenny. Unfortunately this security update is an example of how an inactive maintainer is likely to result in a severe delay for the release of security updates. Furthermore in this specific case, the security team did not want to release the Squeeze security update until the Lenny one had been investigated (which required some time since upstream no longer supports the version in Lenny) but they did not make this very clear. Later another release critical bug had been filed against the package (#646634) but after investigation, it turned out to be a local configuration problem so I downgraded it. I still forwarded the test suite failure to upstream authors since the test could be enhanced. In any case, co-maintainers for python-django are welcome. I really preferred the situation where I can quietly sit down as backup maintainer WordPress packaging WordPress sounds similar to python-django. I m also only a backup maintainer but Giuseppe has been inactive for many months and I had to step in August because I wanted the new upstream version. I discovered a bit late that I was not subscribed to wordpress bugs and thus the release critical bug #639733 (that I introduced with my new upstream version) went unattended for a rather long time. Once aware, though, I quickly fixed it. I also took the opportunity to start a discussion on debian-devel about how to deal with embedded javascript libraries and proposed a mechanism of opportunistic replacement with symlinks . WordPress is my testbed package for this mechanism, you can check out its debian/dh_linktree that implements the replacement logic. The discussion has not been very interesting but at least I learned that Debian now requires that each source package shipping minified javascript files includes the original files too. It s somewhat of a pain since it s not a license requirement in many cases (many of those libraries are not under the GPL), but just a Debian requirement that many upstreams are not complying with. WordPress is affected and Jakub Wilk thus opened #646729 which is going to be a long-standing RC bug. To give good measures, I spent several hours investigating the case of each javascript file in the WordPress source package and I filed a new ticket on the upstream bugtracker. Dropbox packaging work A few months after the introduction of nautilus-dropbox to Debian and Ubuntu, I can say that the decision to only support the download of dropbox in the postinst has been a mistake. Because of this decision I had to make the postinst fail if the download failed. Even if the error message is relatively clear, this lead to many (mostly automated) bug reports on the Ubuntu side. Various other problems cropped up on top of this (trying to start dropbox while the package was not configured would result in an error because the user did not have the required rights to install the software, reinstalling the package while dropbox was running would result in a failure too, etc.). I have fixed all those issues in the version 0.7.0-2 of the package. Now if the user has to install dropbox, it will use PolicyKit to request the root rights. The postinst will no longer fail if the dropbox download fails since it can be run later by the user. And I fixed the download code to remove the replaced file before unpacking a new file (insead of overwriting the existing file). All this work has been forwarded upstream. The Debian Administrator s Handbook Update I m glad to tell you that the translation will happen because we reached the minimal funding goal on October 22th with the help of 380 supporters. Now the fundraising continues, but this time the goal is the liberation of the resulting book. For this to happen, we need to reach 25000 EUR in the liberation fund. So far we re at 37% of this goal with 9400 EUR in the liberation fund (which means that 59% of the money raised has been put in the liberation fund).

Click here if you want to contribute towards the liberation of this book. With (less than) 27 days left, it s going to be a challenge to meet the goal, but we do like challenges, don t we? Misc work

• I filed #644486 against dh-make so that new packages have proper support of dpkg-buildflags from the start.
• I merged lots of patches from Luca Falavigna in the developers-reference.
• I discussed debtags integration in the PTS with Enrico Zini and Paul Wise.
• I updated publican s packaging for the new upstream version 2.8. I had to write a new patch that I forwarded upstream.
• I filed an upstream bug on hamster-applet because just running hamster-time-tracker no longer brings its window forward.

Thanks See you next month for a new summary of my activities.

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

One of the things I liked about Gnome 2 was the ability to run a background 'slideshow' defined in an XML file with a list of background files to give me a change of scenery from time to time. Switching to XFCE4 I can't seem to find a simple way to do that, but the ingredients are all there:

• I can set the background image to a list
• There's a handy-dandy xfdesktop command-line utility I can call to switch desktops

What's missing from the Desktop Settings is a setting for "switching background ever N minutes", which is kind of odd to not have, given the list thing being there - without my script it's only going to change every couple of weeks when I log in, or something. Not nearly often enough for me! There's lots of stuff on the internet saying "Just run xfdesktop --reload in a cron job", but this does not work for me, since cron is running with a different environment, and so xfdesktop doesn't know where the X server is and doesn't have the necessary XAUTHORITY and DISPLAY settings. If it was just DISPLAY that was needed it would be easy enough to set that in the crontab and be done with it - after all it doesn't change very often. XAUTHORITY is harder, since on Debian systems (and presumably others too) it has a random component in the name of a directory which lives in a directory without read permissions. I solved it with this script, which steals those values from the environmnt of xfce4-panel, which will be running already:

#!/bin/sh
#
PANELPID=" /usr/bin/pgrep -U $ LOGNAME  xfce4-panel "
stealEnvironment()  
  tr '\000' '\012' < /proc/$PANELPID/environ   grep -a "^$1="   cut -f2- -d=
 
export DISPLAY=" stealEnvironment DISPLAY "
export XAUTHORITY=" stealEnvironment XAUTHORITY "
/usr/bin/xfdesktop --reload

So now I have my background image switching among my favourite photos again, and my Desktop is effectively back as it was a week ago.

Volker Theile is well known for his work on FreeNAS. But at one point, he decided to give up on it and to restart from scratch but this time based on Debian (instead of FreeBSD). OpenMediaVault is the name of this new Debian based product. Here s how he defines the project:

OpenMediaVault is the next generation network attached storage (NAS) solution based on Debian Linux. It contains services like SSH, (S)FTP, SMB/CIFS, DAAP media server, RSync, BitTorrent client and many more. Thanks to the modular design of the framework it can be enhanced via plugins. OpenMediaVault is primarily designed to be used in home environments or small home offices, but is not limited to those scenarios. It is a simple and easy to use out-of-the-box solution that will allow everyone to install and administrate a Network Attached Storage without deeper knowledge.

Even though all the work was private, he managed to attract an important following, and I must say that I was looking forward to this project. He regularly blogged on his progress, sharing some good-looking video of the resulting product (example here). The first public release (Version 0.2, codenamed Ix) happened on October 17th. I have yet to try it but I took a look on the website. As a Debian developer, I was keen on seeing the source code and how the project was managed. The GPLv3 license is presented as an important feature and I was expecting a well-managed open source project. The fact that it was a private one-man project up to now did not bother me, we re quite used to the scratch your itch kind of start for free software projects. Enough to say is that I have been very disappointed. First you come across a contributor agreement, it s frowned upon by many free software developers. But why not, maybe he bought the argument of Mark Shuttleworth and wants to give it a try. But then I looked at the subversion repository, it s obvious that it s just a dumping ground of files that are managed somewhere else in another repository. A bit like Android which is not developed in the open but released as a whole from time to time. But the worst was yet to be found on the licensing page:

Beside being freely available for personal end-users, System Builders and System Integrators, in general Installers, require a commercial license for OpenMediaVault.

Besides the fact that I m still not sure what this means, I would like to know how he reconciles this requirement with the terms of the GPLv3. It s a shame that a so promising project ends up being a disaster from a free software perspective. Have you tried OpenMediaVault already? If yes, I d be glad to read your thoughts in the comments.

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

Ron has written an interesting blog post about the US as a lottery economy [1]. Most people won t win the lottery (literally or metaphorically) so they remain destined for poverty. Tim Connors wrote an informative summary of the issues relating to traffic light timing and pedestrians/cyclists [2]. I have walked between Southgate and the Crown Casino area many times and have experienced the problem he describes many times. Scientific American has an interesting article about a new global marketplace for scientific research [3]. The concept is that instead of buying a wide range of research equipment (and hiring people to run it) you can outsource non-core research for a lower cost. Svante P bo gave an interesting TED talk about his work analysing human DNA to determine prehistoric human migration patterns [4]. Among other things he determined that 2.5% of the DNA from modern people outside Africa came from the Neandertals. Lisa wrote an informative article about Emotional Support Animals (as opposed to Service Animals such as guide dogs) for disabled people [5]. It seems that the US law is quite similar to Australian law in that reasonable accommodations have to be made for disabled people which includes allowing pets in rental properties even if such pets aren t officially ESAs. Beyond Zero Emissions has an interesting article about electricity prices which explains how wind power forces prices down [6]. This should offset the new carbon tax . Problogger has an article listing some of the ways that infographics can be used on the web [7]. This can be for blog posts or just for your personal understanding. Petter Reinholdtsen wrote a handy post about ripping DVDs which also explains how to do it when the DVD has errors [8], I haven t yet ripped a DVD but this one is worth noting for when I do. Miriam has written about the Fantastic Park ICT training for 8-12yo kids [9]. It s run in Spain (and all the links are in Spanish but Google Translation works well) and is a camp to teach children about computers and robotics using Lego Wedo among other things. We need to have more of these things in other countries. The Atlantic Cities has an interesting article comparing grid and cul-de-sac based urban designs [10]. Apparently the cul-de-sac design forces an increase in car use and therefore an increase in fatal accidents while also decreasing the health benefits of walking. Having lived in both grid and cul-de-sac based urban areas I have personally experienced the benefits of the grid based layout. Sarah Chayes wrote an interesting LA Times article about governments being taken over by corruption [11]. She argues that arbitrary criminal government leads to an increase in religious fundamentelism. Michael Lewis has an insightful article in Vanity Fair about the bankruptcy of US states and cities [12]. Ben Goldacre gave an interesting TED talk about bad medical science [13]. He starts with the quackery that is published in tabloid newspapers and then moves on to deliberate scientific fraud by medical companies. Geoff Mulgan gave an interesting TED talk about the Studio Schools in the UK which are based around group project work [14]. The main thing I took from this is that the best method of teaching varies by subject and by student. So instead of having a monolithic education department controlling everything we should have schools aimed at particular career paths and learning methods. Sophos has an interesting article about the motion sensors of smart phones being used to transcribe keyboard input based on vibration [15]. This attack could be launched by convincing a target to install a trojan application on their phone. It s probably best to regard your phone with suspicion nowadays. Simon Josefsson wrote a good article explaining how to use a GPG smart-card to authenticate ssh sessions with particular reference to running backups over ssh [16]. C ran wrote a good article explaining how to use all the screen space when playing DVDs on a wide screen display with mplayer [17]. Charles Stross has an informative blog post about Wall St Journal circulation fraud [18]. Apparently the WSJ was faking readership numbers to get more money from advertisers, this should lead to law suits and more problems for Rupert Murdoch. Is everything associated with Wall St corrupt?

• [1] http://rondam.blogspot.com/2011/08/lottery-economy.html
• [2] http://tau-iota-mu-c.livejournal.com/172226.html
• [3] http://www.scientificamerican.com/article.cfm?id=an-ebay-for-science
• [4] http://www.ted.com/talks/svante_paeaebo_dna_clues_to_our_inner_neanderthal.html
• [5] http://chaoticidealism.livejournal.com/99347.html
• [6] http://beyondzeroemissions.org/blog/merit-wind-energy-110913
• [7] http://www.problogger.net/archives/2011/09/16/blogosphere-trends-using-infographics/
• [8] http://people.skolelinux.org/pere/blog/Ripping_problematic_DVDs_using_dvdbackup_and_genisoimage.html
• [9] http://www.miriamruiz.es/weblog/?p=654
• [10] http://www.theatlanticcities.com/design/2011/09/street-grids/124/
• [11] http://www.latimes.com/news/opinion/commentary/la-oe-chayes-corruption-20110925,0,517490.story
• [12] http://www.vanityfair.com/business/features/2011/11/michael-lewis-201111
• [13] http://www.ted.com/talks/ben_goldacre_battling_bad_science.html
• [14] http://www.ted.com/talks/geoff_mulgan_a_short_intro_to_the_studio_school.html
• [15] http://nakedsecurity.sophos.com/2011/10/20/iphone-spyware-snoop-desktop-typing/
• [16] http://blog.josefsson.org/2011/10/11/unattended-ssh-with-smartcard/
• [17] http://www.carbon-project.org/MPlayer__and_no_black_bars.html
• [18] http://www.antipope.org/charlie/blog-static/2011/10/going-down-hard.html