I spent the bank holiday weekend mostly in Manchester with my brother and a couple of friends, mostly to see Nine Inch Nails perform, but also to enjoy the pleasures of the city. We arrived on the Sunday and after checking in headed out to get some food. I'd booked us a table at the historic Marble Arch - the pub which gives its name to the parent company Marble Beers - and produce my most favourite ales. Whenever a Marble beer ends up as a guest at one of the Newcastle real ale pubs a friend of mine (who is much more on top of this stuff than I am) lets me know and we stop off for a few. Invariably there's a crowd of a dozen or so Manchester expats in bar when we do. I reserved our table over twitter, which is a bit of a novelty for me. My two friends are ale skeptics but - due to lack of choice - we all ended up sampling the Chocolate Marble and the Ginger 5.1, which went down a storm. They are possibly converts now. There was an Earl Grey IPA too, which was nice but a bit on the strong side for sessioning. The gig was great - I prefer club gigs to arena gigs but the sound techs for NIN know what they are doing and the mix was great. The visuals were stunning too. Highlights for me were "The Great Destroyer" - in particular the extended, improvised 5 minute glitch-meltdown coda; the slow build of "Eraser" and "The Day The World Went Away" - played faithfully to the CD mix rather than the traditional extended live arrangement. I miss the former live arrangement, which includes a drawn out drum-backed finish, but this arrangement had a lot of force, with all four of the band bashing guitars into a pummelling wall of sound. I've heard that at least one person has taped the show and it turns out recordings have just recently surfaced for the two club gigs my brother and I attended back in 2005 and 2007 - meaning there are now widely available, high quality ROIO copies for every NIN gig I've ever been to. Afterwards we tried to find a decent club. Manchester is a lot larger than my native city and there's plenty of places to go, if you know where they are. We had originally planned to visit The Factory on Charles Street, but we didn't believe it was open on the Sunday. The Factory is Peter Hook's (formerly of Joy Division/New Order) club - occupying the former office spaces of Factory records. I've chanced in there once before as it's right across the road from the Lass O' Gowrie pub, which is the haunt of choice for HE/tech people whenever we're in Manchester for conferences. Instead we gravitated towards Dry Bar on Oldham street. By coincidence this place also has historic ties to Factory Records. However the doormen wouldn't let us in! Finally we landed at a place which had one name on the door and a different name on the inside (Jack's). Like the aformentioned Lass O' Gowrie and perhaps half of all pubs and clubs in Manchester, the place is decked out as a shrine to the former musical giants of the City, with framed pictures of Mark E Smith, the Ha ienda again, the Stone Roses in their boy-band-looks hay day, John Peel (champion of many of them) and of course Tony Wilson. I can't help but wonder whether people who live here get royally sick of that. This place served some delicious albeit clich -titled Cocktails and played a pretty good set - the obligatory Madchester throwback interlude was followed by a chunk of Northern Soul and a couple of early Rap classics. Setlist wise it was pretty much identical to that of Foundation in Newcastle, 12 years ago, no doubt because Foundation was cribbing heavily from the Ha ienda in the first place. Monday was dedicated to exploring and shopping. Top of my list of places to go was my pilgrimage venue Vinyl Exchange. Whilst waiting for it to open we rolled around in Affleck's Palace, which turned out to have a small record stall within. After Vinyl Exchange we chanced across another record store right across the road - Picadilly Records - which happens to be larger and focuses more on new releases. It didn't take long before we found another small, DIY record shop, then another. We tried out the Fopp branch here - more Vinyl; then Urban Outfitters - more; then an Oxfam branch - even more. I actually got Vinyl snow blind at this point. I've been controlling myself admirably and only picked up a couple of bits and pieces. My best find was Fad Gadget's sophmore album "Incontinent".

As often is the case, the Saturday Morning Breakfast Cereal webcomic (http://smbc-comics.com/ gets it right. And I cannot help but share today's comic. The picture explains it much better than what I ever could.

And again, another KDE-AppStream post If you want to know more about AppStream metadata and why adding it to your project is a good idea, you might be interested in this blogpost (and several previous ones I wrote). Originally, my plan was to directly push metadata to most KDE projects. The problem is that there is no way to reach all maintainers and have them opt-out for getting metadata pushed to their repositories. There is also no technical policy for a KDE project, since KDE is really only about the community right now, and there are no technical criteria a project under the KDE umbrella has to fulfill (at least to my knowledge, in theory, even GTK+ projects are perfectly fine within KDE). Since I feel very uncomfortable in touching other people s repositories without sending them a note first, I think the best way forward is an opt-in approach. So, if you want your KDE project to ship metadata, follow these simple steps: 1. Check if there already is metadata for your project That s right we already have some metadata available. Checkout the kde-appstream-metadata-templates repository at Github. You can take the XML file from there, if you want. Just make sure that there are no invalid tags in the description field (no <a/> nodes allowed, for example the content is not HTML!), check if you have an SPDX-compliant <project_license/> tag, check if the provided public interfaces in the <provides/> tag match your project and also test if the URLs work. Then you can copy the modified AppStream metadata to your project. 2. Write new metadata How to write new metadata is described in detail at this TechBase Wiki page. Just follow the instructions. In case you need help or want me to push the metadata to your project if you don t have the time, you can also write me an email: matthias [ AT ] tenstral . net or alternatively file a bug against the Github project linked above. Don t forget to have CMake install your shiny new metadata into /usr/share/appdata/. All metadata you add to your project will automatically get translated by the KDE l10n scripts, no further action is required. So far, projects like Ark, K3b and Calligra are shipping metadata, and the number of AppStream-aware projects in KDE is growing constantly, which greatly improves their visibility in software centers, and will help distributions a lot in organizing installed software. If you have further questions, please ask! .-)

I managed to spend a few hours doing Debian stuff again today, which was great. Today I learned about blhc, which is sadly not mentioned in the wiki page on hardening, which I always refer to. It turns out that it is mentioned in the walkthrough wiki page linked off it though. I'd not read that page until today. Many thanks to Samuel Bronson on IRC for pointing out the tool to me. Initially I didn't think the tool told me anything I didn't already know, but then I realised it was saying that the upstream Makefile wasn't passing in $(CPPFLAGS) and $(LDFLAGS) when it invoked the compiler. Know that I know all of that, the build warning also mentioned in the PTS made a whole lot more sense. Definitely a case of "today I learned..." So I made a simple patch to the upstream Makefile.in and simpleproxy is now all appropriately hardened. I'm very happy about that, as it was annoying me that it wasn't Lintian-clean. I was able to use the same technique to similarly fix up sma. It's somewhat entertaining when you maintain a package for almost 7 years, and the upstream homepage changes from being the software author's website to what appears to be erotic fiction advertising for London escorts... That made for some entertaining reading this morning. I've now managed to give all my packages a spring clean. I might do another pass and convert them all to debhelper 9 as a way of procrastinating before I touch isc-dhcp.

At one particular customer, increasing storage needs require that we add a large file server which should be as fast as possible. In that context, I'm currently evaluating using Debian GNU/kFreeBSD ("Debian," from now on) on ZFS. Not being hampered by a large degree of knowledge on the subject, here's a blog post with things I've learned so far. For context, the system on which we'll be installing will have 64 gigs of RAM, about two dozen SAS disks connected to a RAID controller of which I'm reasonably sure (though not 100% so) that it supports JBOD mode, and a PCIe-attached solid state storage device of several terabytes. If it turns out the RAID controller doesn't support JBOD mode, I'll probably create as many RAID0 devices as possible and hand those over to ZFS as "hard disks", instead; this wouldn't be an ideal solution, but I don't have much of a choice of hard disk attachment, unfortunately. That being said, the system on which I'm testing right now is the latest incantation of samba, an HP ProLiant ML115 server. A system with far more modest hardware specifications, it has 2G of RAM (which isn't really enough for ZFS), a single 160G SATA hard disk, and a dual-core AMD processor of about half a decade ago. And oh yes, no SSD. So for evaluating ZFS performance it's not ideal, but for evaluating Debian and ZFS features, it will do. Anyway, what I've found so far on samba:

• partman-zfs (that is, the ZFS support in the installer) works, but could use some improvements.
  • It allows me to create a system that boots off a ZFS filesystem, but does not allow me to create nested ZFS filesystems; i.e., if I create a ZFS filesystem for / and one for /home, the /home filesystem won't be a child of the / filesystem, which would be the way you'd usually set this up. Workaround: "zfs rename".
  • I can't set random ZFS options at filesystem creation time. I would like to be able to do things like set the "compression" and/or the "dedup" property for certain filesystems, but that isn't possible from the installer. Workaround: create the filesystem layout in partman, and when choosing the "finish partitioning and continue" option, switch to a shell and issue "zfs set" commands to change things. You'll miss the first few files that way, but this shouldn't matter all that much.
  Given that I've only got one hard disk in this machine, I can't test whether partman-zfs supports many options for creating vdevs. I'll have to see whether that's the case when the actual server arrives.
• ZFS has a "sharenfs" property that's supposed to transparently and automatically share filesystems via NFS. However, this isn't supported in Debian, with the zfs binary issueing a warning to that extent. Digging a bit deeper in how things work, people have told me that setting the "sharenfs" property should simply produce a file "/etc/zfs/exports" that I can pass on to mountd, which should be restarted after every change to that file. I'm not sure why the zfs binary doesn't just do that; after all, it's perfectly possible to hand two exports configuration files to the FreeBSD mountd binary...
• Somewhat disappointingly, NFSv4 is not supported on Debian (it is on vanilla FreeBSD, but a necessary component for NFSv4, nfsuserd, isn't packaged). For my environment, this isn't a showstopper, but it would've been nice had this worked.
• The "sharesmb" property, which also exists, seems to be not supported at all. But that's okay, the environment in which we're working doesn't need SMB, only NFS.
• ZFS seems to have no soft quota, only hard quota. Workaround, valid for our environment (but not necessarily for everyone's environment): use reservations (plus daily warning mails) in place of soft quota, and place the ZFS quota on the level of what would've been the hard quota on ext4 (might be a little higher than what we use on the current fileserver).

We'll see what else I learn.

AAAAHHH! LOOK OUT! A SHARK! Such were the cries a few first graders raised Monday. Laura and I had gone to school to eat lunch with Jacob this was his last week of first grade. We stayed for recess after lunch, and Jacob and his friend told us to pretend to be a shark lurking underneath the bridges and things of the playground. I was told that adults are too old to climb up here. So Laura and I started chasing Jacob and his friend around the playground equipment. And, much to their delight, they were usually able to evade us. And, to their even greater delight, sometimes I could reach up and brush a shoe or leg. Pretty soon Laura had enough of the game, but about then other kids started to notice what was going on. Shark-taunting began ( nana-booboo! ), and pretty soon half a dozen first-graders were running away from the shark! Eventually, it was time to go in, and it had been a great time. Jacob had been proud to have Laura and me there to eat lunch with him. He got to be the first in his class to go to lunch, happily slipping into the tour guide role he loves. Sometimes he would tell us in exacting detail what would happen. Other times, I d ask something like how will we know when lunch is over, and he d get a sly smile and say, You will see! The next day was Jacob s last at school, and Oliver had also recently finished preschool. So Laura and I planned a graduation party . We came up with some ideas of things they might like to do, and let them choose. Thankfully they both agreed on a choice: water slide. My parents gave them water slides one time, and we got one out, hooked it up to the hose, and let them have fun. And boy, did they ever! And after the better part of an hour running with delight on the water slide, they decided to turn another slide into a water slide. So I helped them rig up a hose on our slide, and they d slide down it, and splash into a giant mud puddle at the bottom. Or, as the case may be, just stand in the mud, enjoying it. We then went out to eat at one of their favorite restaurants and even had time to play in a park. Yes, a wonderful celebration. All four of us were wearing smiles that day. It reminded me of Jacob s school year, but also of the past year it was about a year ago that Jacob and Oliver first had the chance to really meet Laura. I have many photos and stories from the past year that I ll be sharing in the next little while. What an incredible year it has been!

Somebody recent got in touch offering to mail me a Cubox, in exchange for me experimenting with it and writing about it. In the past I've written book reviews in exchange for receiving free copies, and while I don't want to make a habit of it I don't see a problem providing I'm up-front and honest. So, what is the cubox-i? It's another one of those "small computers", roughly similar to the Raspberry Pi, but with slightly different hardware, and a really neat little case design, as the name suggests it just looks like a tiny two inch cube, only spoiled by the mass of cabling attached to the back. Me? I was cheeky and said I'd have no use for one, unless it was the fancy-model. The hardware comes in 4 different versions, which you can read about on the Cubox-i product page. Ignoring the smaller/cheaper models the fancy version is the CuBox-i4Pro, and this differentiates itself from the Rasberry Pi:

• It has built in WiFi support.
• It has two USB ports, and a SATA port too.
• It has a built in infrared receiver/transmitter.
• The onboard NIC is 1Gb - though limited to 400Mb or so due to bus-constraints, certainly faster than the Pi.
• The on-board storage is micro SD.
• It looks lovely.

I had two uses for this toy; the first was to be a random NAS-box hosting local backups, the second was to be a media-center. In the past I used a Rasberry PI as a media-box, but unfortunately performance was appalling, largely because of the low-spead of the USB WiFi dongle I bought. The video playback would stall at times, even though the hardware could display full HD-output, the network constraints seemed to be a limiting factor. In the end I abandoned it and these days use it sporadically for emulation, and little else. I've been meaning to do something more interesting with it, but never quite got round to it. By contrast the Cubox-i is wonderful at being a media-box. I've exported some shares of MP4/AVI files from my desktop host, via NFS, then downloaded a binary image of the geexbox (XBMC) distribution which I installed onto the MicroSD card via dd. The box boots in about seven seconds, was configured to use WiFi (via "Programs Settings"), and was streaming media in less than two minutes. There is a Debian disitribution available for download from the cubox-i wiki, but sadly it is an ancient snapshot of Jessie from December last year. It did install, but there was no WiFi out of the box. Gunnar Wolf wrote about bootstrapping an image from sources, rather than using a binary snapshot. He's kindly shared the resulting image he built, but again sadly no WiFi support, so for the moment I'm just enjoying the media-suport. In the future I need to decide what to do:

• Keep the Cubox-i as a media box, using the PI for backup-hosting.
• Avoid having two devices and lose media-streaming.

I also need to look at running Pure Debian, for obvious reasons, but if I can't use WiFi the machine is no good to me. (The TV is in a different room to the office which contains our Linux hosts.) Either way I've not been excited about new hardware for a while, not since I bought a Logitech Squeezebox, and we're both enjoying watching media on the TV.

This post is mostly a sum-up of the Wikipedia page History of Australia, with some content taken from History of the British Empire. Both texts are available under the Creative Commons Attribution-ShareAlike License. I do not seem to be able to learn about a new topic without taking notes: in this case I have decided to publish my work, hoping that someone will find it useful. Some very important themes such as the Gold Rush and Australian History during the World Wars have been impudently ignored.

On May 21st 2014, the two Mikes (Gabriel DePaulo) from the X2Go core developer team were interviewed about X2Go by the famous Randal L. Schwartz (merlyn) and equally famous Randi Harper (freebsdgirl) on the FLOSS Weekly Netcast [1]. If you're having trouble watching the embedded video on that page, try one of the below alternatives: HD Video [2]
SD Video, large [3]
SD Video, small [4]
Audio only [5] light+love,
Mike [1] http://twit.tv/floss295 read more

I ve just had to do yet another backup/format/restore operation on my workstation due to a BTRFS corruption problem, but as usual I didn t lose any data. The BTRFS data integrity features work reasonably well even when the filesystem gets into a state where the kernel will only accept a read-only mount. Given that the BTRFS tag on my blog is mostly about problems with BTRFS I think it s time that I explain why I use it in spite of the problems before people start to worry about my sanity or competence. The first thing to note is that BTRFS is fairly resiliant toward errors when mounted in read-only mode. When mounting a filesystem read-write there are a number of ways in which things can break which are often due to kernel code not being able to handle corrupt metadata I don t know how much of this is inherent to the design of BTRFS and how much is simply missing features in filesystem error handling. Some of the errors that I have had weren t entirely the fault of BTRFS, I twice had to do a backup/format/restore of my workstation due to a faulty DIMM corrupting memory (that has the potential to mess up any filesystem), but I still didn t lose any data AFAIK. The next thing to note is that I don t use BTRFS when doing paid sysadmin work. ZFS is a solid and reliable filesystem and it is working really well for my clients while BTRFS has too many issues at the moment. As an aside I m not interested in any comments about the ZFS license situation from anyone who s not officially representing Oracle. I also don t use BTRFS on systems that I can t access easily. The servers I have running BTRFS are all within an hour s drive from home, while driving for an hour on account of a kernel or filesystem error is really annoying it s not as bad as dealing with a remote server where I have no direct access. Reasons to Use BTRFS The benefits of BTRFS right now are snapshots (which are good for a first-line backup) and the basic data integrity features. I ve found these features to work well in real use. According to the comparison of Filesystems Wikipedia page ZFS and BTRFS are the only general purpose filesystems (IE for disks not tapes, NVRAM, or a cluster) that support checksums for all data and compression. Given that ZFS license issues will never allow it to be included in the Linux kernel tree it seems clear that BTRFS is the next significant filesystem for Linux. More testing of BTRFS is a good thing, while there are a number of known problems that the developers are working on it seems that more testing is needed now to find corner cases. Also we need a lot of testing to find bugs related to interactions with other software. I ve recently filed bug reports against the Debian installer because it can t install to a BTRFS RAID-1 (fortunately BTRFS supports changing to RAID-1 after installation) and because it doesn t support formatting an existing BTRFS filesystem (the mkfs program needs a -f option in that case). I also sent in a patch for the magic database used by file(1) to provide more information on BTRFS filesystems (which is in Debian/testing but not Debian/Wheezy). These are the sorts of things you encounter when routinely using software that you don t necessarily notice in basic testing. As an aside the Debian installation process failed at the GRUB step when I manually balanced a filesystem to use RAID-1 while the Debian installation was in progress. I didn t file a bug report because the best advice is to not mess with filesystems while the installer is running. I ll do a lot more testing of this when the Debian installer supports a BTRFS RAID-1 installation. A final thing that we need to work on is developing sysadmin best practices and scripts for managing BTRFS filesystems. I ve done some work on scripts to create snapshots for online backups but there are issues of managing free space etc. But working out how to best manage a new filesystem is something that takes years because there are many corner cases you may only encounter after a system has been running for a long time. So I really wouldn t want to be in the situation of using a new filesystem on an important server without having practice running it on less important systems, I did that with ZFS and now have a hacky first install that I have to support for years.

I've been working on checking that certificates made by the CAs are following requirements, and how it changes over time. You can see the results here.

I was at the OpenStack Summit this week. The overwhelming majority of OpenStack deployments are Linux-based, yet the most popular laptop vendor (by a long way) at the conference was Apple. People are writing code with the intention of deploying it on Linux, but they're doing so under an entirely different OS.

But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.

The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.

But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.

When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.

If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.

That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.

A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.

I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.

comments

I recently bought a new Lenovo X1 Carbon. It is the new second-generation, type 20A7 laptop, based on Intel s Haswell microarchiteture with the adaptive keyboard. It is the version released in 2014. I also ordered the Thinkpad OneLink Dock which I have returned for the OneLink Pro Dock which I have not yet received. The system is still very new, challenging, and different, but seems to support GNU/Linux reasonably well if you are willing to run a bleeding edge version and/or patch your kernel and if you are not afraid to spend an afternoon or two tweaking things. What follows are my installation notes for Debian testing (jessie) when I installed it in early May 2014. My general impressions about the laptop as a GNU/Linux system and overall are at the end of this write-up.

Yesterday night, we had the opportunity to have for the first time my friend Kaz as a guest in my Operating Systems class. We are about to finish the semester, and he took the opportunity not just to show how the Ext4 filesystem is structured, but how it is implemented in a current Linux release. Kaz took a very different approach from what I do: He did it really hands-on, starting with the explanation on how a hello world module would be created, and then digging in following the code of the ext4 module in Linux 3.14 (and some bits in the general filesystem-related includes). Of course, for a ~2hr session, he did not go into the full details, but did show where the main structures of a filesystem are defined, including a general walkthrough on the general kernel coding style. The class was very enjoyable and clear. We had the bad luck of the projector's lamp burning out at the beginning of the class, but still, you can see in the pictures the students were really into his exposition. I think the exposition did make it through and got the students involved and interested And that makes it really worth it! Now... Sadly, due to a (most probably) human factor, I tried to record this talk but lost most of it :-( I have only the first part, but lost most of the second one. I have some bits recorded by a second camera, but have to check if they make sense by themselves, or do need the whole context. Anyway, I'll be reviewing those bits, and will update this post when I get around to cleaning+fixing+integrating them. Some more photos...

Attachment	Size
Video of the first part of Kaz's class	26.26 MB
Kaz's slides for the ext4 module	40.72 KB

Quoth joeyh: Note that recent versions of git-annex have a reinit command that makes this much simpler:

git clone /existing/repo.annex
git annex info # to refresh your memory about uuid or description of lost repo
git annex reinit uuid description

Old Post: Another half a blog post, half a reminder for my future self. Turns out that pulling an external 3.5" disk off of your nightstand with the help of a tangled USB cable is a surprisingly efficient way to kill a it. On the plus side, this yields instant results and complete success. On the other hand, I kinda lost well over one TiB of personal photographs and other data which I didn't really appreciate a whole lot. Thankfully, all data was annexed and I always maintain at least three copies of all files at all times, so the fix is as easy as getting two new disks and running

badblocks /dev/foo -swo $manufacturer-$model-$(date '+%F--%H-%M-%S-%Z').badblocks-swo # assuming you keep a git repo of this data

followed by partitioning, mkfs etc and

cd /existing/repo.annex
git annex info # not the UUID you need
cd /new/disk
git clone /existing/repo.annex
cd repo.annex
vim .git/config # add the [annex] block and _copy over the UUID of the lost repo_
git annex get # assuming you want a full copy, which I always do for data archival repos
git annex sync

and done. By running git annex get before git annex sync, I managed to avoid (potentially) saving information about missing data; I simply made sure it was all in place before synching again. The second external disk allows me to always get one local disk up to speed and another one off-site. I am able to learn from experience ;)

I previously wrote about the case for a Basic Income in Australia [1]. Since then I read an interesting article by Rutger Bregman in the Dutch site The Correspondent discussing the benefit that such Basic Income schemes have given in various places [2], he makes a great case for giving a Basic Income to poor people. However I believe that it should be provided to everyone. I believe that government payments shouldn t be means tested because the proportion of the population who earn more than the cutoff is usually very small (IE it doesn t save much money), because the money will be recovered from wealthy people in tax, and because the bureaucracy involved in determining who is eligible involves spending tax money to pay bureaucrats and costing everyone time in dealing with the process. The concept of an Attention Economy has been getting some interest recently. But discussions of it seem to be mostly concerned with the needs of fairly wealthy people, how to advertise to them, how to filter out unwanted ads for them, etc. But the costs in attention can be even worse for people on low incomes or social security because they have many attention costs that could be solved by money. Many common essential purchases (EG soap, basic foods, and purely functional clothes) can become difficult decisions if saving a few dollars is important. The amount of thought involved in buying such items can result in someone who s not well off having little energy to concentrate on other things. I think that to have an effective social security system we need to consider how much cognitive effort is being required of people who are receiving benefits. Last month I wrote yet another review of mobile phone plans in Australia [3]. Every time I do this it takes a significant amount of time because the Telcos devise overly complex plans to make it difficult to compare their offerings. It seems that they aim to make their offerings somewhat competitive if you can interpret them but confusing enough to allow many (most?) of their customers to pay needlessly high bills. I could just pick a random telco and pay whatever it takes, spending an extra $10 or $20 per month isn t such a big deal for me. Even though I advise a number of my relatives on the cheapest phone plan it s probably only barely saving enough money to be worth the effort, a major motivation for me is being stubborn and not wanting telcos to rip people off. The Importance of Mobile Phones A mobile phone seems to be essential for most people. Mobile phones are used for making medical appointments and for applying for work, so in almost every case some of the financial assistance paid to a job seeker or person on a disability pension will go towards mobile phone costs. The aims of the social security benefits seem to clearly involve a phone service. Given that most people who receive social security payments spend some of that money on mobile phone bills the government has a direct financial interest in not having such money wasted on needlessly expensive phone plans. As we also don t want to have people on social security spending time and attention trying to find the best phone plan it makes sense to have the government help manage this process. Good communications is regarded as essential to education and economic development. A huge amount of taxpayer money was spent on the NBN (and then wasted by Tony Abbott when he cancelled the original plans) for these benefits. Good phone access is also an issue of personal safety. While it is possible to call emergency services from a mobile phone that doesn t have a valid SIM there are probably few people who keep a spare phone charged for that purpose. Also there are a variety of issues that can impact life or health which can best be resolved by calling friends or relatives. Free Phones I think that the best solution to these problems is for the government to directly pay mobile phone bills. If we are going to have a Basic Income then the government should make the base payment for mobile phone calls for every resident, if not then the government should make the base payment for everyone who receives any form of social security payment. Obviously the amount of data that could be transferred over a 3G network is greatly in excess of the amount that any plans allow and offering true unlimited calling leads to people using mobile phones as baby-monitors, so some limits are necessary. But the government could cheaply pay for a phone plan that exceeds the requirements of most people and then allow anyone who wants more data or calls to pay extra. Which Plan? The cheapest all-inclusive mobile phone plan in recent times was Kogan who charged $299 per annum for 6G of data per month and unlimited calls. The cheapest current offer for unlimited calls seems to be Lebara s $30 per month offer which includes 2G of data. My observation is that people who use 3G Internet just for phone use (as opposed to tethering a laptop or providing home Internet), who use a home Wifi network for installing Android programs and don t play Ingress tend to use a lot less than 1G of data per month. I would use between 400M and 700M per month if I wasn t playing Ingress and didn t use my phone as a Wifi access point. In terms of call volume, 600 minutes a month should be enough to cover the basic needs of most people judging by the number of plans on offer with limits smaller than that. As a current Lebara offer is $30 per month for unlimited calls and 2G of data (and there are similar offers from other telcos), it should be possible for a telco to offer 600 minutes of calls and 1G of data for less than $15 per month. When the government is paying (no bad debts) and many of the users will use much less than the quota such a plan should be profitable at $10 per month or less. Implementation The way to implement this would be to start with a tender that has a hard requirement for the minimum amount of service provided. This would include the number of minutes per month for calls, the number of SMS sent, and the amount of data transfer. To avoid excessive billing (a standard telco scam) there should be a requirement that fees for extra use not exceed some small multiple of the base rate, for example if the government was paying $10 for 600 minutes of calls and 1G of data the excess usage charges could be capped at 3 cents per meg and 5 cents per minute (3* the base rate) which would be profitable for the telco but not a scam. If the telcos act in a market driven competitive manner they will compete to provide the most attractive offerings for $10 per month. If the build cost of the NBN had been invested at government bond rates (for any of the rates used for current bonds) then it would pay for the mobile phone bills for every resident forever, so the cost of providing phones for everyone is in the range of government telecommunications programs. If people who are working were to pay an extra $10 in tax and people who are on social security had their benefits reduced by $10 then that would be a great deal if it saved them the $20 or more that most people spend on a basic phone plan. Government Phone Delays A friend who s a single mother pays for an unlimited mobile phone plan because calls to the social security office are usually kept on hold for more than an hour. It s likely that she could save money over the course of a year by paying for a cheaper plan and just dealing with the occasional big bill, but she needs to budget carefully and feels that she can t take that risk. It seems stupid that government phone delays (partly caused by cutting funds for staff) cause increased expenses for people who are receiving social security payments. If the government implemented a smart queuing system that allowed them to call people back instead of making them wait on hold then it would save money overall. So there are obviously other ways that the government can save money on phone calls and time for everyone.

• [1] http://etbe.coker.com.au/2013/12/08/basic-income-australia/
• [2] http://tinyurl.com/jwj5ahe
• [3] http://etbe.coker.com.au/2014/04/01/comparing-telcos-again/

This is the second post in a series of posts describing a secure alternative to applications like WhatsApp. I started with the following statement:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

In this post, I will outline the concepts behind the most critical component of the architecture: the directory service.

Outline I say this is the most critical component, because here lies what makes this architecture different, but also because this is the weakest link in the whole idea. I expect criticism, specially on some security trade-offs, and I hope that people that know better than me can help me improve it. The directory service is what allows the users to register easily, without using passwords, to be able to receive calls and messages from other users, even if they are not part of the network, and to do all this with a reasonable security model.

Let's get technical The directory service is basically a DNSSEC-protected DNS zone serving ENUM records, along with public keys associated with each user identifier. A TLS-enabled API will enable account creation and validation, DNS records publishing, and encrypted records querying. Applications not supporting that API use standard ENUM querying, and the user manually uses traditional web-based methods for account and records management. This allows interoperability with any existing clients and SIP services. The service will authenticate users by using the usual methods to probe ownership of phone numbers: sending an encrypted SMS with a secret that the client application uses then to claim the phone number. This same method can be used to validate ownership of identifiers that are not phone numbers, like pre-existing SIP or email addresses. Once the user is authenticated, the directory service will publish the user's public key and SIP address, both associated with the phone number. When a user wants to place a call or send a message, it uses a DNSSEC-enabled resolver to get securely the other party's public key and SIP address. The user can also perform bulk look-ups, to discover which people on theirs address book is already in the system. These operations disclose an important amount of private data, and I don't think this can be mitigated in an acceptable manner, and therefore the directory service needs to forget the queries as soon as possible, and not to store any logs of these. Also, DNS queries are not encrypted, and are thus vulnerable to snooping by third parties. To mitigate this, the service needs to implement an encrypted but anonymous API to perform queries, and thus offer extra privacy to clients that support the API. The idea is to have more than one service running on different domain names, but not many: they need to keep consistency and replicate among them, and the security and privacy implications of one service not being properly implemented or administered are too big. Therefore, there must not be more than a handful of these, they need to be properly audited, and must not be operated by any for-profit organisation.

Security The Web of Trust is hard. End users don't like hard. Traditional PKI is prohibitely costly, and broken. OTR is good, but is still not hassle-free. Using one of the proposed extensions to DANE, we can solve this problem: using DNSSEC, we can have each users' public key published where everybody can retrieve it securely. This published key can then be used for end-to-end encryption and client authentication with all the components of this architecture. Who creates the key pair? In the simple case, the client application creates the key pair, and stores it in an appropriate container in the mobile device. It then chooses one of many cooperating directory services, and gets the public key associated with the phone number. If the private key is lost (lost your phone?), a new pair is generated and published, after passing the same checks of number ownership, and the old keys are discarded. This opens the door for some attacks, but those can be mitigated by having the client application verify the public records periodically, and the service requiring extra checks for key replacement. For example, by also using a challenge sent by email. What if I want to do things my way? Perfect, you create your keys, and then use the same mechanisms to register with the identity service. Also, you use the service to tell other users to connect to your own SIP server when they want to talk to your phone number. Does this sound like ENUM? It is ENUM, but better. Just by adding DNSSEC, an unified API, and the capability of publishing key material along with the routing information, you got yourself a reasonably secure way of distributing keys and locating users.

Interaction with other components Once the user records are published, the SIP server can use the public key to authenticate the user, and removes the need for passwords. The same principle applies to account creation: if the user has published key material under a phone number's record, the SIP server must accept account creation requests for the same phone number, provided these are authenticated with the private key. If the user wants to switch providers, it is as simple as creating a new account in the new provider, and then updating the ENUM record. The client application queries the service (and possibly other ENUM providers) before placing a call or sending a message. If the peer has keys published, the client can refuse to communicate if the keys don't match, or the peer is not offering call encryption. When public keys are not found, the client can downgrade to traditional unauthenticated encryption, or unencrypted communications.

To be continued In the next posts, I will talk about the overseeing organisation, the SIP service providers, and the client application, and how they all fit together. Stay tuned!

So I ve configured voice service a number of times, but never using Cisco equipment. There s a business starting up here on Orcas Island and they need a number of lines voice and fax service. I had a spare 2801 router laying around and heard that it s possible to provision voice service using these machines. So I looked on eBay for a module that will provide more than two FXS ports and decided on the VIC-4FXS. When it was delivered, I installed it and booted the router. It told me that it needed a PVDM DSP Module, so I got one of those as well. It has arrived. I have installed it. Now when I boot the router, I don t get a warning or an error. configure the router to send outbound calls to the SIP server configure the router to send inbound calls to FXS ports 2,3,4 in round robin

trunk group FXSlines
!
voice-port 0/2/1
 trunk-group FXSlines
!
voice-port 0/2/2
 trunk-group FXSlines
!
voice-port 0/2/3
 trunk-group FXSlines

configure the router to send inbound calls to the correct ports on the VIC-4FXS

dial-peer voice 1 pots
 preference 7
 destination-pattern 3602987792
 translate-outgoing called 10
 port 0/2/0
 forward-digits all
!
dial-peer voice 2 pots
 preference 2
 destination-pattern 3602987793
 translate-outgoing called 10
 port 0/2/1
 forward-digits all
!
dial-peer voice 3 pots
 preference 3
 destination-pattern 3602987794
 translate-outgoing called 10
 port 0/2/2
 forward-digits all
!
dial-peer voice 4 pots
 preference 4
 destination-pattern 3602987795
 translate-outgoing called 10
 port 0/2/3
 forward-digits all

configure the router to accept inbound calls from the asterisk call server

voice service voip
 allow-connections sip to sip
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
 sip
  registrar server expires max 3600 min 3600
  localhost dns:8.8.8.8

configure the asterisk call server to send inbound calls to the router On asterisk call server, edit sip.conf to register with SIP server on cisco router at 172.16.78.209:

[fhvoice]
type=peer
insecure=port,invite
context=fhvoice
disallow=all
allow=ulaw
language=en
canreinvite=no
host=172.16.78.209
qualify=20000
dtmfmode=rfc2833

On asterisk call server, edit extensions.conf and add extensions to the incoming context:

exten => 3602987792,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987793,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987794,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987795,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()

configure the asterisk call server to accept outbound calls from the router

Random thoughts of a new contributor I've started to contribute to Mozilla - and particularly to the Firefox Desktop QA team - at the end of March, in order to apply for the OPW with Mozilla as Bug Wrangler.
While being already part of the Free Software world as contributor clearly helps, it's always difficult to find your way at first in such a big project, no matter how helpful the people you're working with are. It's about trying to understand how the project is organized and who works on what, what is expected from you as contributor and the specific style of interaction and contribution accepted in the project. So, here's a couple of thought about it: the necessary disclaimer is that I'm a long-time Debian contributor meaning that, inevitably, Debian is my reference model. Also, everything I'm writing here regards only the specific part of the project I've been working in: Desktop QA and Bugmastering. Documentation The first thing that I noticed is the huge amount of documentation. Everything is very well documented and while this is definitely a plus in my book, it's sometimes difficult to keep track of all this resources. AFAICT, there are basically three main sources of documentation:

1. the wiki
2. the Mozilla Developer Network
3. the site of the QA team

Some of the documents on these three different places are sometimes similar, making them redundant and it's difficult to remember where you read what. At least for me. My workaround has been to bookmark pages as a mad woman, and also to make a list on my wikipage of the pages I found more useful.
My top five of useful pages? Here we go!

1. a bug's life: lifecycle of bugs in BMO
2. Tyler's BMO survival guide (parts 1, 2 and 3)
3. Tyler's Triage Guidelines
4. on reducing testcases
5. bug verification walkthrough

And speaking of triage, special shout-out for the most useful addon ever for Mozilla triagers/testers: Nightly Tester Tools. Community interaction For someone coming from Debian, where everything is done via public mailing lists and/or IRC chans, Mozilla was a bit of a cultural shock. The mailing lists are not very much used, at least in the QA community (or I'm not subscribed to the right ones ;)). As for IRC, while there are many channels, they are not very active: meetings and important discussions are held using a proprietary videoconference software (Vidyo), and are mostly restricted to employees (but other people can join if they have a guest URL). On the other hand, every time I asked for help - even the most stupid question - on IRC, I got a useful reply. And thanks to the folks on #testdays and #qa (especially petruta and Aleksej) I was able to speed up the learning process and understand how things work in the project. So, while I'd like to see more public meetings, it's also true that the community is working well on interaction among contributors. Community outreach This is where I think Debian could borrow a couple of ideas. Mozilla basically got me hooked thanks to their Bugdays: every Monday and Wednesday are - respectively - dedicated to Triage and Verification of bugs. The events are open to everyone, the wikipages for the events provide a good tutorial explaining the workflow in detail, and if you have any doubts there are always people willing to help you on the dedicated IRC chan. Every bug worked on during these events is also tagged: so that later it's possible to check how successful the day was in terms of participation. Bugzilla and the triaging/verification workflow About Bugzilla I can only say that I like it. I like how flexible is for search queries, I like the possibility to have custom tags on the whiteboard (as the [bugday-xxxxxx] one) and the smart way to interact among people in the bug without making the bug go stale (ie, mostly the needinfo feature). But beside the software used as BTS, I must admit that I really like the workflow and the whole concept of triaging in Mozilla. The granularity of rights (everyone, canconfirm, editbugs) and the clear procedure for a permission upgrade; the presence of a team constantly working on cleaning the incoming bugs, regardless of the product/component, to make easier for the developers the filtering and the resolution as well; the attention to details of the verification process: each bug marked as Resolved Fixed need to be Verified, to be sure that it's been actually fixed... All these things are really impressive. This, obviously, is something that can be done inside an upstream project where there are people doing paid work, and where the products are not too many. I cannot see how this kind of QA process can be applied to bugs against an entire OS.
But there are some things we (as in Debian) could take inspiration from. Organizing regular Bugdays, for instance. Creating a team of triagers to help both with incoming and with very old bugs. And this, again, is a kind of work that can be done by everyone, not only coding contributors: meaning that an additional effect would be to increase the diversity in the contributors pool. As a side note: I'll start my OPW internship next Monday, and will spend three months playing with bugs and learning how to be a Bug Wrangler! \o/\o/

Did I get your attention with the title? Good. In this post I will outline something that I have been thinking about for some months:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

Introduction This is the first post of a series that I will be publishing in the next few days. Many parts of these posts will be technical, but I expect that the main concepts can be understood by a wider audience. What I am proposing seems like a bold statement, I know. Maybe there is some fatal flaw somewhere in my thinking, and that is why I am publishing this: I hope to get constructive feedback, and maybe get enough traction to start implementing it Real Soon Now . I have been thinking about this problem since February, when I discussed this extensively with friends at FOSDEM. I have already published a critique of Telegram, which had way more impact than I ever imagined, showing that there is people out there interested in this kind of stuff. The last posts about DNSSEC and DANE were part of my musings about this, too. There are many components that need to be built for this to happen. But more importantly, this can only be useful if it gains a critical mass. And that's why I think making this a viable business tool is very important. At the same time, that means I need to think extra carefully to make it impossible for any for-profit company to mutate this effort into Just Another Walled Garden. My goals for this architecture are:

• First and foremost, target the same people that nowadays is using a plethora of walled gardens for their instant communication needs. That is WhatsApp, Viber, Skype, Facebook messenger, etc.
• It must focus on mobile, that is what people care about, without forgetting about other use cases.
• Creating an account and placing the first call/text message should be as easy as it is currently with the competition.
• All communication must be encrypted end-to-end with public-key cryptography; nobody but the user has access to the private keys.
• Most components must be decentralised, and allow for competition.
• There should be as little trust as possible placed on any part of the system.
• Anybody can set up a compatible service provider and offer it to its users, while having full interoperability with other providers.
• Compatible services which are not part of the network must be able to interoperate.
• Contacting a person should happen even if they are not subscribed to the service. The client application must fall-back seamlessly to using interoperability gateways, PSTN termination, or the mobile network.
• Interoperability with the competition is desirable, but possibly is better left to be implemented by the client applications.

Components I have identified a few components needed for this to work, I will expand on each one later.

1. A flagship mobile application for Android and iOS, based on Lumicall or CSIPSimple, but with several important modifications.
2. One or many directory and authentication services, based on ENUM and DNSSEC. These are the most critical piece of this idea, and possibly must only be operated by community-governed non-profits.
3. One or many service providers, that offer simple account creation, registration, and optionally PSTN termination (which can be the main way of generating profit). An API needs to be defined for operations that are not part of the communications protocol, like account creation, credit purchasing, and balance querying.
4. A network governing charter, and a trusted non-profit organisation that oversees that any participating parties are following the charter. This organisation defines which directory services are to be trusted (and possibly operates one of them), and which service providers the client application can use to create accounts.

Key points Some of the issues that need to be solved are:

• How to handle and distribute public keys securely without the user understanding anything about security.
• How to make registration painless and password-free, while offering an acceptable level of security.
• How to fund development of the client application, and maintenance of the directory services.
• How to get companies interested in this, so them would bring users to the network.
• How to allow the user to migrate from one service provider to another, to improve competition.
• How to prevent any party from subverting the spirit of the network.
• How to make the client application work everywhere and have reasonably quality.

To be continued I think I have answers to most of these problems. I will elaborate in the next few days, stay tuned!

Footnotes The name is something I've chosen a name in less than 2 minutes, while starting this post, so probably is awful. The distributed part is only half true, as the directory services need to be centralised, but I think it's good enough. I am aware that Lumicall seems to be trying to build something similar. I only found about that recently, when I was thinking about this design. Sadly, I think it has several shortcomings, but it is definitely one of the building blocks of this project.