The XDG Basedirectory specification proposes default homedir folders for the categories DATA (~/.local/share), CONFIG (~/.config) and CACHE (~/.cache). One category however is missing: STATE. This category has been requested several times but nothing happened.
Examples for state data are:

• history files of shells, repls, anything that uses libreadline
• logfiles
• state of application windows on exit
• recently opened files
• last time application was run
• emacs: bookmarks, ido last directories, backups, auto-save files, auto-save-list

The missing STATE category is especially annoying if you're managing your dotfiles with a VCS (e.g. via VCSH) and you care to keep your homedir tidy.
If you're as annoyed as me about the missing STATE category, please voice your opinion on the XDG mailing list.
Of course it's a very long way until applications really use such a STATE directory. But without a common standard it will never happen.

Enrico and me have just started a census on Debian Services floating around, and we want YOU to participate!

Today was another Kindergarten day. Zoe was complaining about being sweaty before we even left the house this morning, so I gave her the choice of going by car or by bike, and she chose car, which was fine by me. It's been stinking hot the last few days. Summer is going out with a bang. Drop off went pretty smoothly. It was another morning where she was happy to have me hang out with her for a little bit, and then I was allowed to leave without any issues. I decided to use this Monday as a Debian day as planned. I mostly ran into a snag with my email setup, but I did manage to do some bug triage and upload one package. It had been hot all day, and I was feeling sapped by it, so I picked up Zoe in the car as well. I was surprised to find she wasn't asleep and hadn't had a nap at all. She seemed in good spirits despite this. Megan's Dad has quit his job, so I don't need to pick her up any more on Mondays and Wednesdays. We dropped by the post office to check my PO box on the way home. Zoe enjoyed peering through the mailbox into the post office. Today's TV diversion was to build a rocket ship out of one of the big moving boxes I've kept aside from the move back. Zoe had great fun blinging up the inside and outside with various craft "gems", and drew a bunch of aliens on the outside. I could have quite easily strung this out until Sarah arrived to pick her up, but I let her watch a little bit of TV right at the end. It was a pretty good afternoon. I liked how Zoe ran with the rocket ship idea and added her own embellishments all by herself. After Sarah picked up Zoe I went for a run. I'd intended to do 10km, but the heat took it out of me, and I lacked the willpower, so I stopped at 5km. After that I had the sweatiest yoga class yet.

(Or "Today's yak shaving exercise") I'm trying to get back into some Debian work today, which involved trying to send an email from my laptop, relayed through daedalus, which is in a colo facility. Then I started shaving my yak. daedalus rejected the email, because the relay attempt wasn't authenticated. It wasn't authenticated because Exim on my laptop wasn't happy about the Diffie-Hellman parameters Sendmail on daedalus was advertising, and had failed STARTTLS, and like a sensible person, I only allow encrypted authentication. Along the way, I figured I'd need to address the fact that the host certificate has expired long ago (truth is, I probably just needed to fix the Diffie-Hellman parameters file), but my whole CA certificate expired over a year ago. I couldn't find the encrypted USB key with my CA on it, so I decided to cut my losses and start from scratch. It's good to see OpenSSL hasn't got any more user friendly with time. I futzed around and generated a new CA key and certificate, a new CSR for Sendmail, signed it, did the appropriate sacrifices, and confirmed that STARTTLS now worked using OpenSSL s_client. Still couldn't send an email. Still had some bleating in the Exim logs:

2014-02-17 11:29:26 1WFD1M-00086p-KI TLS error on connection to daedalus.andrew.net.au [203.33.60.161] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

Back on daedalus, /etc/mail/tls/sendmail-common.prm has been an empty file since time immemorial. I managed to find something in Google's cache suggesting I should put something in it with openssl dhparam -out /etc/mail/tls/sendmail-common.prm -2 1024 I initially went for 4096 bits, because it must be better, right? I'm still waiting for the key generation to come back, while I'm writing this. At least it warned me in advance it was going to take a long time. How thoughtful. What would be more thoughtful was verifying the write permission to the file before the long operation so it could fail fast, rather. Sigh. I ended up giving up on 4096 and sticking with 1024, because I was getting old waiting. Yak shaved, I can send mail from my laptop now.

I've started backporting some Perl modules to wheezy-backports - for starters, libbread-board-perl, which is now waiting in BACKPORTS-NEW. At work I've recently been trying to automate the deployment of our platform, and was originally trying to use Carton to manage the CPAN dependencies for us. It seems like it ought to be possible to make this work using CPAN-only tools. However, in practice, I've seen two strong negatives with this approach:

• it's a lot of work for developers to manage the entire dependency chain, and
• it takes forever to get the environment running.

Consider, when you spin up a fresh VM, you need to build Perl from source, and then compile every CPAN module you depend on. This includes all the modules needed to run all the test suites. That's not going to be fast. All that, and you still need a solution that works with the distro's package management, because you still need to install all the build dependencies. So, I'm trying a new approach - if someone else benefits from the packages I backport, even better.

This is the 2nd point release of OpenStack Havana (this is the name of the current stable release of OpenStack). It was out on Thursday (US time), and I uploaded it on Friday (Chinese time). Unfortunately, I realized that the latest python-keystoneclient didn t support the token and endpoint command line options, effectively breaking Keystone itself, and all automated endpoint registration in all core packages. So after fixing Keystone and openstack-pkg-tools, I had to re-upload a 2nd Debian release. However, after this glitch, the packages passed successfully our CI testing suite: my friends at eNovance and I run the tempest functional test suite each time there s this kind of major update, so that we can validate the packages are working as expected. And all went well after the new keystone command line options were fixed in the postinst scripts. As a side note, I fail to see consistency on deprecating these interfaces. While we still have the old glance index thing in the Glance client (this is really old), keystoneclient just broke backward compatibility, when keystone is quite recent. So, it looks to me that it wasn t a great idea to just remove token and endpoint this way (though I can understand the need of consistency). Hopefully, this will all be fixed anyway, when we move to the unified python-openstackclient command lines instead of per-project clients. I realized today that the pkg-openstack team now maintains more than 100 packages. This of course includes general purpose Python modules, which probably will move to the Python module team if it one day supports Git (life is too short: I do not wish to learn such a deprecated technology as SVN). Though this is still a lot of packages, and some more are coming: as per the OpenStack TODO list wiki page, Ironic (a replacement for nova-baremetal), TripleO (OpenStack on OpenStack), Tuskar (contols where things are deployed with TripleO) and Designate (DNS as a Service) are already packaged, and I am waiting for the Icehouse (this is the name of the next stable release) beta3 to be out to upload them to Experimental. This is scheduled for the 6th of March. I believe I am currently nearly up-to-date with the current global-requirements.txt (eg: python dependencies of OpenStack), pending a few Python module upgrades, so hopefully, packaging OpenStack Icehouse beta3 will smooth.

Init system I am happy that Debian's Technical Committee was able to reach a very good decision with the choice of systemd as the default init system for the Linux ports. In particular, I was very pleasantly surprised by the lucidity of Russ Allbery's analyses and, above all, his patience even with people that, in my understanding, were just being trolls or trying to cause confusion and disrupt a process that was already chaotic. Russ, thank you for your exemplary role. (Also, you type fast or what? You fill whole e-mails seemingly faster than I can read!)

Unexpected union of forces It seems to me that Mark Shutterworth's decision of (perhaps?) embracing Debian's decision in the init system is a good thing. I think that one way where Ubuntu did a great thing with respect to Debian was their initial attitude towards cherry-picking the best of breed of Free Software from Debian's archive and polishing that to create a really "for human beings" operating system. I hope that this means that, at least in part, money (Mark's?) can be channeled in the best of the interests so that we all gain from it. (And, to be honest, I see no problem in making money with Free Software and I welcome a well done integration job).

More polarizing things I feel that, now, I may even have some hope of sending another potentially polarizing bug to the Tech Ctte (that is ffmpeg vs. libav) and have faith that some rational decision would be made. I was not even aware of it, but the ffmpeg folks even featured a news item in their page of me having filed the RFP bug mentioned above.

DebConf 14 If everything goes as expected, I hope to attend this year's DebConf. In fact, I am anticipating this, since I would love to, e.g., talk with Joey Hess and discuss a better way of having GNU parallel and the parallel program in moreutils have amicable co-installability among many, many other things with respect to my packages. And, quite probably, work on packaging ffmpeg with other interested people (which seem to be numerous).
Edit: Fix markdown link pointing twice to the ffmpeg site. Thanks Marius Gedminas for pointing this out.

Today was another busy day. Zoe had a check up at her dentist first thing this morning. This dentist was such a good find, and although it's a trek (it's over an hour round trip for a 15 minute appointment) I think it's well worth it to instill a positive view of dentists into Zoe, and it's all covered by insurance, so really the only expense is time and petrol. After we got home, Zoe was a bit sick of being in the car, and wanted to watch TV. I'm trying to restrict TV to just the late afternoon, while I'm preparing dinner, so I thought this was a good opportunity to break out the Goldie Blox set that I haven't introduced her to yet. That went pretty well, but Mum and Dad (aka Grandma and Grandpa) arrived early for lunch, so we didn't finish working our way through the book. I think it was more of a hit than Robot Turtles is at the moment. We all jumped in the car, and drove down to Bulimba, and caught the cross river ferry over to the CityGlider bus and had Yum Cha for lunch. That went pretty well, and we returned the same way. Zoe had a little play in the park at Bulimba with her grandparents while I popped over to the florist, and then we came home and Zoe gave them a demonstration of the kinetic sand and then Grandma and Grandpa went home and I managed to convince Zoe to take a late nap. We didn't get much of an opportunity for something Science Friday-related today, with all of the other activities. Zoe didn't wake up from her nap until close to 5pm, just after my girlfriend arrived for dinner. Zoe watched a bit of TV and then the three of us walked down to collect pizza for dinner, and that was pretty much how the evening ended. I let Zoe stay up a little bit later, because she'd napped so late.

After so many attempts to have my shiny Movistar Peru (Internet M vil) 3G ZTE MF193 modem to work out-of-the-box in Debian jessie (unstable) with NetworkManager, the word frustration was hitting on my head. Even trying to do the right thing, led me to craziness. I gave up on fanzines and decided to take the old-school route. Release wvdial and friends! Trying different combinations for wvdial.conf was no heaven for sure, but I ve found this wonderful guide from Christian Ams ss from Vienna, Austria! that really made a difference. Of course he s talking about the MF180 model but you get the idea. So I m sharing what was different for the MF193. Basically, I ve done the eject and disable CD-ROM thing already, but still no progress. I ve also tried using wvdial to send AT commands to the evasive /dev/ttyUSBX device. Starting from scratch confirmed that I ve done such things properly indeed. I was amused by the fact that I could use screen to talk to the modem! (yo, all the time wasted trying to have minicom and friends play nice) So, let s get to the point. After following this procedure, you should be able to use NetworkManager to connect to the Interwebs using the 3G data service from Movistar Peru.

1. Step 1 follow the guide
2. Step 2 Here I had to use /dev/ttyUSB4
3. Step 3 follow the guide
4. Unplug your USB modem
5. Plug your USB modem. This time you should see only /dev/ttyUSB 0,1,2 and /dev/gsmmodem should be missing (not sure if this is a bug). Now /dev/ttyUSB2 is your guy.
6. Step 4 use /dev/ttyUSB2
7. Run wvdial from CLI it should connect successfully.
8. Stop wvdial
9. Select the Network icon on GNOME3, click on the Mobile Broadband configuration you have, if not create one.
10. Voil . Happy surfing!

I m pasting my wvdial.conf, just in case.

[Dialer Defaults]
Modem = /dev/ttyUSB2
Username = movistar@datos
Password = movistar
APN = movistar.pe
Phone = *99#
Stupid Mode = 1
Init2 = AT+CGDCONT=4,"IP","movistar.pe"

An NSA employee reminded me that I've been on IRC for 20 years.

I ve written a lot lately about ZFS, and one of its very nice features is the ability to make snapshots that are lightweight, space-efficient, and don t hurt performance (unlike, say, LVM snapshots). ZFS also has zfs send and zfs receive commands that can send the content of the snapshot, or a delta between two snapshots, as a data stream similar in concept to an amped-up tar file. These can be used to, for instance, very efficiently send backups to another machine. Rather than having to stat() every single file on a filesystem as rsync has to, it sends effectively an intelligent binary delta which is also intelligent about operations such as renames. Since my last search for backup tools, I d been using BackupPC for my personal systems. But since I switched them to ZFS on Linux, I ve been wanting to try something better. There are a lot of tools out there to take ZFS snapshots and send them to another machine, and I summarized them on my wiki. I found zfSnap to work well for taking and rotating snapshots, but I didn t find anything that matched my criteria for sending them across the network. It seemed par for the course for these tools to think nothing of opening up full root access to a machine from others, whereas I would much rather lock it down with command= in authorized_keys. So I wrote my own, called simplesnap. As usual, I wrote extensive documentation for it as well, even though it is very simple to set up and use. So, with BackupPC, a backup of my workstation took almost 8 hours. (Its incremental might take as few as 3 hours) With ZFS snapshots and simplesnap, it takes 25 seconds. 25 seconds! So right now, instead of backing up once a day, I back up once an hour. There s no reason I couldn t back up every 5 minutes, in fact. The data consumes less space, is far faster to manage, and doesn t require a nightly hours-long cleanup process like BackupPC does zfs destroy on a snapshot just takes a few seconds. I use a pair of USB disks for backups, and rotate them to offsite storage periodically. They simply run ZFS atop dm-crypt (for security) and it works quite well even on those slow devices. Although ZFS doesn t do file-level dedup like BackupPC does, and the lz4 compression I ve set ZFS to use is less efficient than the gzip-like compression BackupPC uses, still the backups are more space-efficient. I am not quite sure why, but I suspect it s because there is a lot less metadata to keep track of, and perhaps also because BackupPC has to store a new copy of a file if even a byte changes, whereas ZFS can store just the changed blocks. Incidentally, I ve packaged both zfSnap and simplesnap for Debian and both are waiting in NEW.

It's been quite a busy, varied day today. Lot's of fun as usual. Zoe has a dentist appointment tomorrow morning, so we went to the Thursday offering of her Brazilian Jiu-Jitsu class instead, and skipped Playgroup. We biked over extra early this morning, to make sure we were on time. There were two other kids in the class today, a 3 year old boy and a 2 and a half year old girl. The class went really well. We biked home the scenic way again, and grabbed a BBQ chicken for lunch along the way. The box of kinetic sand that I'd ordered was sitting on the doorstep. That still left us with about 45 minutes to kill before lunch, so I thought I'd start on making a second miniature clothes line with Zoe. Bunnings were selling these little kids safety sets at half price because they were a deleted product, and the set came with proper fitting eye protection, hearing protection and some gloves. The gloves are currently too big, but the glasses and hearing protection is great. I introduced her to the power drill and the hand saw. She liked drilling, and marking, but mostly was happy just watching. We managed to make most of the top of the clothes line before lunch, and then I whipped up some chicken quesadillas for lunch. We had a few disruptions during quiet time, so Zoe didn't nap. After quiet time, we did a mix of cleaning up the house a bit, some more wood working, and some self-directed play. After that, Zoe's friend Mackensie and her little sister came over for a play date after her Kindergarten class. She goes to the same Kindergarten as Zoe, but in the second half of the week. Mackensie's mum brought me a coffee, and we had some afternoon tea, and then I busted out the kinetic sand. It was a real hit with all the girls, as well as the adults. A very good product. That kept them occupied for a while. Zoe had found a Wallace and Gromit DVD while we were cleaning up, and she hasn't watched it for a while, so she was very keen to watch it. I told her she could watch it after Mackensie went home, and so we've kicked back on the couch to watch that while we wait for Sarah to arrive.

FOSDEM is over, and it has been a great time! I talked to many people (thanks to full devrooms Graph Databases and Config management was crazy, JavaScript as well ) and there might be some cool new things to come soon, which we discussed there
I also got some good and positive feedback on the projects I work on, and met many people from Debian, Kubuntu, KDE and GNOME (haven t seen some of them for almost 3 years) one of the best things of being at FOSDEM is, that you not only see people of your own kind for example, for me as Debian developer it was great to see Fedora people and discuss things with them, something which rarely happens at Debian conferences. Also, having GNOME and KDE closely together again (litterally, their stands were next to each other ) is something I missed since the last Desktop Summit in 2011. My talks were also good, except for the beamer-slides-technical-error at the beginning, which took quite some time (I blame KScreen ). In case you re interested in the slides, here they are: slides for FOSDEM 14 AppStream/Listaller talks. The slides can likely be understood without the talk, they are way too detailed (usually I only show images on slides, but that doesn t help people who can t see the talk ^^) I hope I can make it to FOSDEM 15 as well I ve been there only once, but it already is my favourite FOSS-conference (and I love Belgian waffles)

Recently I've been thinking about getting a new laptop. I have this rule that a laptop should last me at least 3 years (ideally more) and my old laptop was bought in September 2010. So for the past few months I've been trying to work out if there's something suitable on the market that is a good replacement (last time I didn't manage to find something that ticked all the boxes, but did pretty well for the price I paid). To start with I decided to track my laptops over time - largely because one of my concerns was about the size of a replacement, because I have a significant leaning towards subnotebooks. In the end the reason I decided to upgrade was for some extra CPU grunt; my old machine had a tendency to get pretty hot under any sort of load.

Date	Model	CPU	Screen	RAM	Storage	W (mm)	H (mm)	D (mm)	Weight	Cost
1991	Amstrad PPC 640D	NEC V30 8MHz	9" 640x200 non-backlit green LCD	640k	2 x 3.5" FDD	450	230	100	10kg	???
August 1997	Compaq Aero 4/33c	486sx33	7.8" 640x480 CSTN LCD	4MB	80MB	260	190	43	1.6kg	???
July 2002	Compaq Evo N200	P-III 700MHz	10.4" 1024x768 TFT	192MB	20GB	251	198	20	1.1kg	939.99
August 2005	Toshiba Portege R200	Pentium M 753 1.2GHz	12.1" 1024x768 TFT	1280MB	60GB	286	229	20	1.29kg	1313.58
September 2008	Asus EEE 901	Atom N270 1.6GHz	8.9" 1024x600 TFT	2GB	4GB + 16GB SSD	248	175	23	1.1kg	299.99
September 2010	Acer Aspire 1830T	Core-i5 470UM 1.33GHz	11.6" 1366x768 TFT	8GB	500GB	284	203	28	1.4kg	$699.99 (~ 480)

The EEE didn't actually replace the Toshiba, but I mention it for completeness. It was actually the only machine I moved to the US with, but after about a month of it as my primary machine I realized it wasn't an option for day to day use - though it was fantastic as a machine to throw in an overnight bag, especially when coupled with a 3G dongle. I wasn't keen on significantly increasing the size of my laptop. There are a number of decent 13" Ultrabook options out there, and I looked at a few of them, but nothing grabbed me as being worth the increase in size. Also I wanted something better than the Acer - one of the major problems was finding something smaller than 13" that had 8G RAM, let alone more. There's a significant trend towards everything soldered in for the smaller/slimmer notebooks, which makes some sense but means that the base spec had better be right. Much to my surprise the Microsoft Surface Pro 2 looked like an option. It comes with an i5-4300U processor (at least since around Christmas 2013), and the 256/512G SSD models have 8G RAM. Screen resolution is an attractive true HD (1920x1080) and the 10" display means it's smaller than the Aspire. Unfortunately the keyboard lets it down. It's fine given a flat surface, but not great if you want to support the whole thing on your lap. Which is something I tend to do with my laptop, whether that's on the sofa, or in bed, or on a bus/train. Another option was the Sony Vaio Pro 11. This is a pretty sweet laptop (I managed to get to play with one at a Sony store in the US). Super slim and light. 8GB RAM. True HD screen. However I have bad memories of the build quality of the older Vaios and the fact that there was /no/ user replaceable parts put me off - it's a safe bet that a laptop battery is going to need replaced in a 3 year lifespan. What I managed to find, and purchase, was a Dell Latitude E7240. I admit that the Dell brand made me wary - while I've not had any issue with their desktops I didn't associated their laptops as being particularly high quality. Mind you, I could say the same for Acer and I've been very pleased with the Aspire (if they'd had a more up to date model I'd have bought it). I bought the E7240 with the Core-i5 4300U (so the same as the Surface Pro 2) and True HD touch screen. It has a replaceable battery, expandable RAM (up to 16G) and the storage is an mSATA SSD. It also came with a built in 3G card. At 12.5" it's a little bigger than my old machine, but I decided that was a reasonable idea given the higher resolution. I'm typing this article on it now, having finally completed the setup and migration of the data from the old laptop to it this evening. More details once I've been using it for a little bit I think.

Hello Planet Mozilla I started as a new employee a few weeks ago. I am working as Release Manager for the next releases of Firefox (both on desktop + android).
As a start, Lukas and I will be working on Firefox 29 (no pressure at all to start with Australis + Firefox account).
I grew up with the first versions of Netscape, followed the Phoenix/Firebird adventures and I have been a supporter of Firefox since then.
I am glad to join such an important project, especially in the perspective of the recent privacy scandals. I think that Mozilla is in the best position to communicate to the public, to denounce certain activities and provides technologies to bypass them. Besides that, let me introduce myself. I have been in free software for almost a decade.
My previous work as working on Scilab (from Inria to Scilab Enterprises) where I stayed for almost 8 years. Over the years, I worked on various development (C, C++, Java, Python, Scilab, etc), user experience, roadmap definition, release management, R and D / customer project management, management, board member, etc. During this period, I learnt tons of things from coding, release and product management, QA, etc. In parallel, I worked part time at IRILL, a free software research center (hosted by Inria). I was involved as community management ie organizing event like GNU Hacker meeting, FOSDEM, Euro LLVM, etc and recording them. I had the chance to meet plenty of people from the FLOSS world (including folks from Mozilla who suggested me to join the adventure). I am also involved in two communities: Debian and LLVM. The first one is Debian. I started to contribute in Debian to get Scilab properly packaged. 7 years
after, I am now maintaining
important packages like LLVM, Clang, libedit, emscripten (!) or BLAS/LAPACK, treasurer of the French representative association and organizing the French mini Debian Conference (Debconf) / Meetup. For the last couple of years, I contributed to LLVM, Clang and LLDB. I participated to the release 3.3 and 3.4. My technical contributions were mainly driven by the packaging, the nightly Debian/Ubuntu packages and also by the rebuild of the Debian archive using Clang (instead of gcc). And when I am not behind my laptop, I am teaching scuba diving with my girlfriend or hiking, mountaineering, ski touring, climbing, etc. Yeh, I am a bit hyperactive.

Zoe woke up pretty early today, at around 5:30am. I also officially became a Xoogler at some point overnight. I used this transition as the opportunity to move from my Nexus 4 to my Nexus 5, so I could have a clean start on a phone that had never had work credentials on it. I started that process before breakfast, and mostly had a usable phone by the time we biked to Kindergarten. Zoe was a bit more like her usual clingy self at drop off today, so I spent a bit longer getting her settled. I got home and pretty much spent the rest of the day sorting out my phone. I can say many good things about Android, but seamless device migration isn't one of them. I'll probably factory reset my Nexus 4 tomorrow. I biked back to Kindergarten to pick up Zoe, and sure enough, she was fast asleep again. It turned out that she'd gone down about 30 minutes later today, so she was deeply asleep, and didn't take too kindly to being woken up. She was very sad, and it took forever just to leave the Kindergarten. We were well and truly the last ones out. Then she saw Megan having a trial tennis lesson at the tennis courts on the way to the bike, and wanted to do that too, and we burned some more time, while I tried to talk her out of that. Zoe had a make up swim class today to cover the one she'd missed on Saturday when she went down to Canberra with Sarah. That was at 3:15pm. We were a tad late for it. Weekday swim classes are much quieter than the weekend ones, so I used the opportunity to talk to one of the swim school staff about progressing Zoe to the next level. They conducted an assessment on the spot, and graduated her! She's moving from "Platypus" to "Octopus", starting next week. The class time options were pretty crappy though, something like 11:45am on Saturday, or a late afternoon weekday. We've opted for a weekday class after Kindergarten for the rest of this quarter and will try and get an earlier Saturday class next quarter. There's a reasonable gap between the end of Kindergarten and the start of swim class, so I'll have to figure out how best to use that time. I might make our library visit in between, even though it means a bit of back and forth. The upside is Saturday mornings are now wide open. We had a celebratory ice cream when we got home from swim class, and went out for a babyccino after dinner. I think it's important to celebrate achievements. I managed to get Zoe to bed slightly early tonight in light of her reduced nap time, but she just woke up briefly at 10:30pm. She seems to be particularly sensitive to mosquitoes, and has a bite on her forehead, right at the hairline, and it was giving her some grief. I gave her some antihistamine and she's gone back to bed fairly easily. Fingers crossed she sleeps okay for the rest of the night.

Late last week, and just before leaving to participate in this crazy thing, I managed to get a new version of RcppSMC onto CRAN. RcppSMC combines the SMCTC template classes for Sequential Monte Carlo and Particle Filters (Johansen, 2009, JSS) with the Rcpp package for R/C++ Integration (Eddelbuettel and Francois, 2011, JSS) and thereby allows for easier and more direct access from R to the computational core of the Sequential Monte Carlo algorithm. This release regroups a few minor changes we accumulated over the last few months, but was triggered by the Rcpp 0.11.0 release last week. The NEWS entry is below:

Changes in RcppSMC version 0.1.2 (2014-02-06)

• Updated for Rcpp 0.11.0 with explicit importFrom in NAMESPACE and corresponding versioned Imports: in DESCRIPTION; also removed linking instruction from src/Makevars as no it is longer needed with this new Rcpp version
• Addded GitHub / Travis CI support
• Use more portable dev.new() rather than x11() in pfLinearBS.R
• Applied some corrections to pfNonlinBS.R example
• Converted NEWS to NEWS.Rd

Courtesy of CRANberries, there is also a diffstat report relative to the previous release. As always, more detailed information is on the RcppSMC page,

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

I spent last week looking into the firmware configuration protocol used on current IBM system X servers. IBM provide a tool called ASU for configuring firmware settings, either in-band (ie, running on the machine you want to reconfigure) or out of band (ie, running on a remote computer and communicating with the baseboard management controller - IMM in IBM-speak). I'm not a fan of using vendor binaries for this kind of thing. They tend to be large (ASU is a 20MB executable) and difficult to script, so I'm gradually reimplementing them in Python. Doing that was fairly straightforward for Dell and Cisco, both of whom document their configuration protocol. IBM, on the other hand, don't. My first plan was to just look at the wire protocol, but it turns out that it's using IPMI 2.0 to communicate and that means that the traffic is encrypted. So, obviously, time to spend a while in gdb.

The most important lesson I learned last time I did this was "Check whether the vendor tool has a debug option". ASU didn't mention one in its help text and there was no sign of a getopt string, so this took a little longer - but nm helpfully showed a function called DebugLog and setting a breakpoint on that in gdb showed it being called a bunch of the time, so woo. Stepping through the function revealed that it was checking the value of a variable, and looking for other references to that variable in objdump revealed a -l argument. Setting that to 255 gave me rather a lot of output. Nearby was a reference to --showsptraffic, and passing that as well gave me output like:

BMC Sent: 2e 90 4d 4f 00 06 63 6f 6e 66 69 67 2e 65 66 69
BMC Recv: 00 4d 4f 00 21 9e 00 00

which was extremely promising. 2e is IPMI-speak for an OEM specific command, which seemed pretty plausible. 4d 4f 00 is 20301 in decimal, which is the IANA enterprise number for IBM's system X division (this is required by the IPMI spec, it wasn't an inspired piece of deduction on my behalf). 63 6f 6e 66 69 67 2e 65 66 69 is ASCII for config.xml. That left 90 and 06 to figure out. 90 appeared in all of the traces, so it appears to be the command to indicate that the remaining data is destined for the IMM. The prior debug output indicated that we were in the QuerySize function, so 06 presumably means query the size. And this is supported by the response - 00 (a status code), 4d 4f 00 (the IANA enterprise number again, to indicate that the responding device is speaking the same protocol as you) and 21 9e 00 00 - or, in rational endianness, 40481, an entirely plausible size.

Once I'd got that far the rest started falling into place fairly quickly. 01 rather than 06 indicated a file open request, returning a four byte file handle of some description. 02 was read, 03 was write and 05 was close. Hacking this together with pyghmi meant I could open a file and read it. Success!

Well, kind of. I was getting back a large blob of binary. The debug trace showed calls to an EfiDecompress function, so on a whim I tried just decompressing it using the standard UEFI compression format. Shockingly, it worked and now I had a 345K XML blob and presumably many more problems than I'd previously had. Parsing the XML was fairly straightforward, and now I could retrieve the full set of config options, along with the default, current and possible values for them.

Making changes was pretty much just the reverse of this. A small XML blob containing the new values is compressed and written to asu_update.efi. One of the elements is a random identifier, which will then appear in another file called config_log along with a status. Just keep re-reading this until the value changes to CM_DONE and we're good.

The in-band configuration appears to be identical, but rather than sending commands over the wire they're send through the system's IPMI controller directly. Yes, this does mean that it's sending compressed XML through a single io port. Yes, I'd rather be drinking.

I've documented the protocol here and hope to be able to release this code before too long - right now I'm trying to nail down the interface a little, but it's broadly working.

comments

Hello, World! I ve got two upcoming talks - one at LibrePlanet 2014 about OpenPGP, and one at PyCon US 2014 (in Canada) on Hy. Slides will be posted as I give the talks. Hope to see folks there!

I started running Friendica instance on my VPS. With help of Jonas Smedegaard I managed to run Friendica in a uWSGI container. The site was running at samsargika.copyninja.info and is no longer accessible. Since VPS itself was running Debian Wheezy I couldn't run uWSGI with PHP support on it. (support for PHP in uWSGI landed after Wheezy). But Jonas was kind enough for me to provide a backported version. Recently Wheezy got a security update for PHP and thats where all the problem started. The backported uwsgi-plugin-php was not recompiled to use security updated PHP and I couldn't upgrade the things. After few days I noticed first freeze on my VPS and I had to reboot the VPS to get it online again. The fact I noticed was uWSGI being killed due to a OOM in syslog but I didn't explore much and consulted Jonas to get a updated uWSGI. But that didn't happen as Jonas himself is facing some problem with uWSGI builds. While again checking with aptitude for upgrade I accidentally confirmed removal of uwsgi-plugin-php for getting security updates :-/. But nothing happened to my running service as upgrade of libs in Debian doesn't cause the restart of all services which are using that lib (desired effect is restart of service but I don't know the side affects involved). Second freeze happened yesterday and on the reboot uwsgi-plugin-php was missing there by taking my Friendica instance down. More closer investigation showed the same OOM but this time I noticed each OOM occurred just after cronjob was running poller.php a script which is actually causing all federation in Friendica. So it was clear there is something wrong either in poller.php or in my setup which was making it eat memory and freeze my VPS. But I also found some stupidity I did during configuration which Jonas also pointed me out.

1. Installing cronjob inside crontab rather than cron.d
2. Installing poller.php crontab for root user :-/

I basically violated the basic rule by running a unsafe script as root user, good that script didn't do some crazy stuff. So even though my instance went down I learnt my lessons

1. Don't ever ever ever run a unsafe script as root that too through cron
2. Sandbox the unsafe script so it can be killed on time rather than it taking the whole system down.
3. PHP is not really secure, if it was secure there wouldn't be security updates and atleast my site would be still running :-D

So I now need to wait till Jonas get me new shiny backported uWSGI linked against new PHP on Wheezy and till that time I need to explore on how I can sandbox the poller.php script.