Just recently arrived from DHL, a solid-run CuBox. I guess nobody who knows me will be surprised when I tell it features an ARM cpu. Specifically an Marvell Armada 510. It features ARMv7 compatibility, with a slight twist of replacing NEON extensions with iWMMX extensions. On the boasting side Armada 510 promises 1080p video decoding and OpenGL ES graphics acceleration (closed source, unfortunately).
The tiny form factor of CuBox is pretty much more than the impressive amount of connectors included;

* Gigabit ethernet
* 2*USB
* eSATA
* HDMI out
* s/pdif optical audio out
* microSD slot
* microUSB serial/jtag port

The last item being important as it makes CuBox unbrickable.. Some will probably lament the lack of WiFi/Bluetooth, but get everything in one device ;). Besides, the USB slots are there to be filled..
Getting started was an slightly rough ride, as in the included Ubuntu (10.04 LTS), X refused to start. After wrongly suspecting that my Display was at fault, turned out the microSD included was slightly corrupted, and some critical contents of xkb-data package were garbage. After reinstall of that package, everything worked, including playing Big Buck Bunny in FullHD with totem.
Biggest disappointment so far is the non-mainline kernel, based on old 2.6.32.9. Some mainline support of Armada 510 exist, but will it work with the proprietary graphics code?

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!

I was on the brink of mindlessly clicking through the ACLU action center as usual to send an email opposing SOPA. But then I read their boilerplate text, and ended up cancelling the letter to my rep and instead sending this quick note to the ACLU:

Your SOPA suggested letter text supports current copyright law, and also backhandedly supports PIPA (the Senate version of the bill). This is far too weak of a position. As a donor, I ask you to take a stronger position that current copyright law unjustly restricts free speech, and that no further enforcement measures should be instituted until that fundamental problem is addressed. At least take on BOTH of these bills strongly. Most of the significant Internet is blacked out today to oppose both bills -- why would you cede so much ground to copyright maximalists? We have the support to oppose and defeat both bills.

For reference, here was their text:

While I believe it's important to protect copyrighted material online, the language of the Stop Online Piracy Act (SOPA) is flawed and will lead to the blocking of lawful content. Unlike the Senate version of the bill, SOPA eliminates the concept of sites 'dedicated to infringing activity' and enables law enforcement to target all sites that contain some infringing content -- no matter how trivial. The potential for impact on non-infringing content is much greater under SOPA than under other versions of this bill. Sites with user-generated content, like YouTube, Twitter, and Facebook, would be especially vulnerable, as one small piece of infringing content could lead to blocking the entire site. Even though proposed changes would narrow the amount of lawful content impacted, the changes don't go far enough. It is still likely that search engines will end up blocking access to perfectly legal online content. Congress should focus not just on the goal of protecting copyright owners, but also protecting the speech rights of consumers and providers who are reading and producing wholly non-infringing content. Congress must eliminate the collateral damage to protected non-infringing content. Only in that way will Congress truly achieve its goal of protecting authors while respecting the constitutional right to free speech.

Maybe I'm overreacting, but I dislike it when good organizations take weak positions unnecessarily. Usually this is not a problem with the ACLU, for me. It doesn't help that I keep seeing this meme everywhere in the anti-SOPA/PIPA conversation: "I agree we need to do something about piracy, but not this..." I don't think we need to do anything to fix violations of an extraordinarily unjust law until the law itself is fixed. I don't find that to be a very radical position.

Those lovely people over at Flickr have finally bitten the bullet and are turning off FlickrAuth in the summer, meaning that all applications that use the Flickr API need to use OAuth. This is something I totally agree with, whilst FlickrAuth works and was clearly an important influence on OAuth, it's a single-service protocol when OAuth has managed to get massive adoption and a huge developer base. The problem I've got is libsocialweb, which has a Flickr module that allows both fetching of your contact's recent photos and uploading images. This uses FlickrAuth so at the end of July will suddenly stop working. I've got enough on my plate at the moment and would love for more people to understand how the entire social spagetti works, so this is a call for a volunteer to work on this, for which I'll obviously be available to offer any guidance and mentoring required. There are two ways of approaching this, the easy way and the slightly harder way. The easy way is to update libsocialweb to use an OAuthProxy instead of a FlickrProxy, and update the module metadata so that Bisho uses the generic OAuth flow instead of a Flickr-specific flow. This should be fairly simple and needs to happen soon so that any distributions that are using libsocialweb don't break in the summer. The harder way is to add Flickr support to gnome-online-accounts, using the Twitter service as an example, and then port the Flickr service in libsocialweb to use gnome-online-accounts to authenticate. I've a proof of concept for the librest-goa integration which will be a useful starting point. This is more of a proof of concept for libsocialweb, we've been looking at moving away from Bisho but haven't done anything substantial yet. Ideally both of these happen, so the current code will continue to work in the future and the GOA work demonstrates how GOA and libsocialweb would work together. So, anyone interested?

The increasing storm of localization NMUs and uploads, related to debconf translations, has an interesting effect: some teams are now incredibly active at pushing translations for their language towards the magic 100%. So, after Danish (effort lead by Joe Hansen) and Dutch (effort lead by Jeroen Schot) which I already mentioned, it seems that the Italian localization team started engines and is now taking off. It will be interesting to watch these teams competing (in a friendly way) to climb in statistics over next months..:-) So, if you're Italian (or speak it well) and want to help, please join the Italian l10n mailing list (debian-l10n-italian on lists.debian.org. If you're Danish or Dutch and want to stay ahread the two others, please joind debian-l10n-danish or debian-l10n-dutch. PS: why did I write "Zou" in this post's title? Because this is a common French interjection for "Whoooosh" and because this is part of the nickname of the tireless and incredibly active, in many places, Francesca Ciceri, aka MadameZou, who's is doing so much for Italian localization (and many other areas in Debian such as the publicity and web team). And that really deserves some lights, trumpets, etc.

I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit.
Secure boot requires that all code that can touch hardware be trustedRight now, if you can run unstrusted code before the OS then you can subvert the OS. Secure boot gives you a mechanism for making sure you only run trusted code, which protects against that. So your UEFI drivers have to be signed, your bootloader has to be signed, and your bootloader must only load a signed kernel. If you've only booted trusted code then you know that your OS is safe. But, unlike trusted boot, secure boot provides no way for you to know that only trusted code was executed. That has to be ensured by OS policy.

This doesn't sound like too much of a problem. But it is. Imagine we have a signed Linux bootloader and a signed Linux kernel, and that these signatures are made with a globally trusted key. These will boot on any hardware using secure boot. Now imagine that an attacker writes a kernel module that sets up a fake UEFI environment, stops the kernel from running code and then executes the Windows bootloader - kind of like kexec, but a little more fiddly. The Windows bootloader believes that it's performing a secure boot, but in fact everything that it believes is trustworthy is the attacker's fake UEFI code. The user's encryption passphrase is logged, the Windows kernel is modified to hide the Linux code and despite everything looking fine your credit card details are on their way to China. In this scenario, the signed Linux kernel is simply used as a malware loader. The only sign that anything is wrong is that boot will be slightly slowed down.

Signing the kernel isn't enough. Signed Linux kernels must refuse to load any unsigned kernel modules. Virtualbox on Linux? Dead. Nvidia binary driver on Linux? Dead. All out of tree kernel modules? Utterly, utterly dead. Building an updated driver locally? Not going to happen. That's going to make some people fairly unhappy.

(The same applies to Windows, of course. Windows 7 allows you to disable driver integrity checks. Windows 8 will have to forbid that when the system's using secure boot)
LicensingGPLv3 has various requirements for signing keys to be available. Microsoft's new requirement that systems support the installation of user keys would let users boot their own modified bootloaders, so that may end up being sufficient to satisfy the license. But we're then beholden on Microsoft - if they remove that requirement then users lose that freedom, and suddenly we're in an awkward licensing situation. There are ongoing conversations about exactly what we're able to do here, but it's not a solved problem.
Key distributionThe UEFI spec doesn't describe or mandate a central certifying authority. Microsoft require that everyone carry their key. We could generate our own, but we have much less sway with vendors. There's no way to guarantee that all hardware vendors will generate our key. And, obviously, if we generate a key, we can't just hand the private half out to others. That means that it becomes impossible for people to produce derivative versions of Linux distributions without getting their own key. The kind of identity verification that would be required for getting such a key is likely to be expensive, and also fairly likely to require that the distribution have a legally registered company in order to facilitate the identity verification. Think Extended Validation certificates, not Startssl Free. Hobbyist Linux distributions will be a thing of the past.
Doesn't custom mode fix this?Microsoft's certification requirements now state that all systems must support a custom mode, implying that it will be possible for a user to install their own keys. Linux vendors would then be able to ship with their own keys on the install media and impose their own policies. Everyone's happy. It's not really good enough, though. People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users. And it's even worse than that. This is the full description of the requirement for custom mode:

1. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
   
2. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
   
3. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

There's a few things missing from this, namely:

• Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Vendors are using the UEFI transition to differentiate themselves by coming up with their own unique firmware interfaces. Custom mode is going to look different everywhere.
• Any description of the key format. A raw binary representation of the key? An EFI_SIGNATURE_DATA struct? A base64 encoding of one, further protected with ROT13? We just don't know.
• Any way to use custom mode for unattended installs. It's a firmware interface that requires a physically present user. Want to install a few thousand machines over the network? This isn't a scalable approach
• and this one's nitpicking, but there's not actually any requirement that the user be able to add keys - a vendor could conform to this language by only letting users delete keys. This is actually ok as long as the user deletes Pk, because then we'll effectively be back in setup mode and can install our own keys from the installer, but it still results in some practical problems

So no, custom mode doesn't make everything ok. Custom mode with a mandated UI and a documented key format would be much closer, but it wouldn't solve the problem of unattended automated installs.
SummaryWe can write the code required to support secure boot on Linux in a minimal amount of time - in fact, most of it's now done. But significant practical problems remain, and so far we have no workable solutions for any of them.

comments

For some reason my involvement with Fosdem is going up, not down.

So I will certainly be there, find me hacking the network again. Learning QoS in a trial by fire :).

This entry was originally posted at http://pvaneynd.dreamwidth.org/147845.html. Please comment there using OpenID.

Yesterday, I've unpacked new toy - ColorHug. It came in small packet with CD (which is unfortunately not that useful as it should be), mini USB cable and a letter from Richard Hughes. First attempt to use was of course just connect and make it work :-). The basic access works out of the box:

$ /usr/lib/colorhug-client/colorhug get-firmware-version
1.0.3
$ /usr/lib/colorhug-client/colorhug get-hardware-version
Hardware Version 1
$ /usr/lib/colorhug-client/colorhug get-serial-number
000019

Unfortunately calibration with colord does not yet work out of the box on Debian due to bug 655888. Hopefully it will be fixed soon and it will work nicer. For now you have to rebuild Argyll with Colorhug support (with extra pain caused by Debian package using different build system than upstream). I won't provided binary packages as I pretty much gave up after effort to build clean packages from same sources on i386 and amd64, which always failed on patched autoconf based build system. Side note: I somehow hoped that I won't hit new (in meaning that I don't know them) open source projects which do not use some version control. Unfortunately Argyll CMS is one of such projects... After this update (and restarting GNOME), when connecting ColorHug, the Gnome Color Manager pops up and man can calibrate the screen. The biggest problem is to make ColorHug hold on desired place on screen, if it is not close enough to screen, you will get really bad results. The first result is of course far from being perfect, but colors are definitely better than without calibration or with ICC profile shipped with notebook.

Filed under: Debian English Photography 0 comments Flattr this!

Yesterday, I've unpacked new toy - ColorHug. It came in small packet with CD (which is unfortunately not that useful as it should be), mini USB cable and a letter from Richard Hughes. First attempt to use was of course just connect and make it work :-). The basic access works out of the box:

$ /usr/lib/colorhug-client/colorhug get-firmware-version
1.0.3
$ /usr/lib/colorhug-client/colorhug get-hardware-version
Hardware Version 1
$ /usr/lib/colorhug-client/colorhug get-serial-number
000019

Unfortunately calibration with colord does not yet work out of the box on Debian due to bug 655888. Hopefully it will be fixed soon and it will work nicer. For now you have to rebuild Argyll with Colorhug support (with extra pain caused by Debian package using different build system than upstream). I won't provided binary packages as I pretty much gave up after effort to build clean packages from same sources on i386 and amd64, which always failed on patched autoconf based build system. Side note: I somehow hoped that I won't hit new (in meaning that I don't know them) open source projects which do not use some version control. Unfortunately Argyll CMS is one of such projects... After this update (and restarting GNOME), when connecting ColorHug, the Gnome Color Manager pops up and man can calibrate the screen. The biggest problem is to make ColorHug hold on desired place on screen, if it is not close enough to screen, you will get really bad results. The first result is of course far from being perfect, but colors are definitely better than without calibration or with ICC profile shipped with notebook.

Filed under: Debian English Photography 0 comments Flattr this!

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?

Last year I shared my Debian related goals for 2011 . I tend to put more goals than what I can reasonably complete alone and this year was no exception. Let s have a look.

1. Translate my Debian book into English: PARTLY DONE
   It took more time than expected to prepare and to run the fundraising campaign but it has been successful and the translation is happening right now.
2. Finish multiarch support in dpkg: DONE BUT NOT ENTIRELY MERGED YET
   Yes, multiarch support was already in the pipe last year in January. I completed the development between January and April (it was sponsored by Linaro) and since then it has mostly been waiting on Guillem to review it, tweak it, and integrate it.
3. Make deb files use XZ compression by default: TRIED BUT ABANDONED
   After discussing the issue with Colin Watson and Joey Hess during debconf, I came to the conclusion that it was not really desirable at this point. The objections were that debian-installer was not ready for it and that it adds a new dependency on xz for debootstrap to work on non-Debian systems. I believe that the debian-installer side is no longer a problem since unxz is built in busybox-udeb (since version 1:1.19.3-2). For the other side, there s not much to do except ensuring that xz is portable to all the other OS we care about. DAK has been updated too (see #556407).
4. Be more reactive to review/merge dpkg patches: PARTLY DONE
   I don t think we had any patch that received zero input. We still have a backlog of patches, and the situation is far from ideal but the situation improved.
5. Implement the rolling distribution proposed as part of the CUT project and try to improve the release process: NOT DONE
   We had a BoF during debconf, we discussed it at length on debian-devel, but in the end we did nothing out of it. Except Josselin Mouette who wrote a proof of concept for his idea. For me testing is already what people are expecting from a rolling distribution. It s just a matter of documenting how to effectively use testing, and of some marketing by defining rolling as alias to testing.
6. Work more regularly on the developers-reference: PARTLY DONE
   I did contribute some new material to the document but not as much as I could have hoped. On the other hand, I have been rather reactive to ensure that sane patches got merged. We need more people writing new parts and updating the existing content.
7. Write a 10-lesson course called Smart Package Management : NOT DONE
8. Create an information product (most likely an ebook or an online training) and sell it on my blog: NOT DONE
   This was supposed to happen after the translation of the Debian Administrator s Handbook. Since the translation is not yet over, I did not start to work on this yet.
9. By the end of the year, have at least 1/3 of my time funded by donations and/or earnings of my information products: NOT REACHED
   My target was rather aggressive with 700 each month, and given that I did not manage to complete any information product, I m already very pleased to have achieved a mean amount of 204 of donations each month (min: 91 , max: 364 ). It s more than two times better than in 2010. Thank you! Note that those figures do not take into account the revenues of the fundraising of the Debian Administrator s Handbook since they will be used for its translation.

That makes quite a lot of red (for things that I did not achieve) on the other hand I completed projects that I did not foresee and did not plan. For instance improving dpkg-buildflags and then merging Kees Cook work on hardened build flags was an important step for Debian. This was waiting for so long already

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

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 m also changing all of my disk layouts from being block devices per each guest partition to one block device hypervisor side per each /dev/xvd* guest side. The block devices all live on a single storage server and are being served via iSCSI. One of the guests is making use of AoE, but I m thinking I m going to move it to iSCSI, too, so there s one less d mon I need to maintain. It s currently xen on squeeze. I want to experiment with kvm. I will miss xen-create-image, though. Okay. Zelda wants to watch a movie, so I m going to stop blathering now. Moo, C.J.

Today I released two entirely different pieces of software with the identical version number 3.20120115. Debian developers also will be soon noticing a piece of software I released with the version number 9.20120115. I expect to move more of my software to this version number scheme over time, unless I find something badly wrong with it. It reflects how I think about versions for my software; there's a kind of continual "now" that development progresses through, in which individual releases have little discrete meaning and at the same time, there can also be significant discontinuities, that require the user to do something to deal with (such as a new debhelper compat version, or a new git-annex repository format). Those two things are really all that I need a version number for my software to communicate. I can do without the rest of the things that version numbers are used for:

• The marketing of version 1.0 and 2.0.
• The comparative nuances such as whether 1.0 to 1.1 is a relatively big change, and 1.0 to 1.0.1 is a relatively small change
• The implication that 0.99 is almost 1.0 ready, and 1.1a is some kind of alpha release.

There is so much software, with so many version numbers that any signal encoded in such version numbers is swamped in the noise. Even on projects that I develop a version number like 2.88 is meaningless to me. All I care about is, how long ago was that version? Has there been a major change breaking compatibility since that version? "2.88" doesn't answer these questions well; "3.20111111" does. It is a little wordy to have the full year in there, and it can be annoying to remember to set the version to the right date on release day (TODO: automate). This is balanced with the version not being so wordy as to include the time of day, which means I might have to do a 3.20120115.1 if I goof up. These minor problems are worth it to instantly know how old a version is when a user pastes it into a bug report. And that is probably all I will ever have to say about version numbers. :)

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!

The old machine that I installed Windows XP on in 2009 is now under a desk next door. 1GHz Athlon 32 bit, 40G hard drive, old Radeon card and 512MHz of memory.

It does have 2 removable media drives: one DVD rewriter and one DVD drive.

This is, now, the sort of machine you'd throw away - it won't handle Windows 7 well: it barely handled Windows XP It flies under Debian 6.0 with libreoffice from debian-backports.

It will soon go on to a friend of mine whose computers are even older: he's likely to use this machine extensively because it has real serial ports.

Use Linux - it makes sense on any hardware.

Just upgraded one of the computers here to Wheezy (currently Debian Testing).

The machine is an HP Proliant Microserver - 1.3GHz AMD Neo II processor, integrated graphics and 250G disk - so low power and low spec. I' ve added three more 250G hard disks.

Very impressed indeed by KDE 4.6 and the general speed of response of a desktop environment on a low spec system. No audio subsystem on the system - it's a server - so I can't speak for sound quality.

I say this every time round about now in the release cycle: the next release of Debian (due later this year sometime) will be excellent :)

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.