I wrote that I would double-check how secure the module selection and downloading is in Puppet. Well, puppet module resolves, fetches and downloads unsigned tarballs from a HTTP source and unpacks them without any verification whatsoever. Related: I've been looking at rpm/yum GPG behaviour. rpm supports checking the signature of RPMs as a separate operation from installing them. You can't ask it to not install a package if the signature is absent or not correct. yum is better when dealing with repositories. It can be told to check the GPG signature on all RPMs both globally (the [main] section of yum.conf) and on a per-repository basis. GPG signature checking can be disabled on the command line with --nogpgcheck. It cannot be selectively enabled on the command line. However, yum install can install local RPMs and RPMs on web servers as well as from repositories. In both of these cases, it will not check the GPG signature at all, no matter what you've put in your yum.conf. Finally, even if all the above worked properly, the GPG keys published by Fedora have almost no public signatures (none at all for EPEL), so neither you nor I could establish a trust path to them. Luckily I can establish a trust path to the RH security key.

So as previously mentioned I gave a talk at FOSDEM this year on the future of paravirtualisation under Xen. I thought the talk was reasonably well attended despite being at six o'clock in the evening. In the end I underran my half hour slot but fortunately people had plenty of interesting questions! I've posted my slides on my xenbits space. I spent a fair chunk of the rest of the time on the Xen.org booth, which is hard work but it is always nice to speak to users and other developers. I also managed to catch up with various friends from other projects and managed to meet a few folks who I've only ever met in email before. I didn't get to see as many talks as I wanted (for example I missed pretty much all of the ARM track :-() due to clashes with my stints on the booth, my own talk, and talks clashing with each other. Still it was all in all a worthwhile, hopefully I'll be able to make it again next year! Next up: LinaroConnect in Hong Kong!

Over the last few days I've done quite a lot of work to try and get our puppet configuration up to modern best practises. The Puppet Labs folks strongly encourage you to make as much use of puppet modules as possible. A puppet module gathers together puppet manifests, facter facts and other bits and pieces into a reusable component that you could potentially share with others. Many modules (of very mixed quality) are available on the web, in particular at github and via Puppet Lab's own Forge. Since version 2.7.14, the puppet command-line tool has built-in support for managing modules:

# puppet module list
/etc/puppet/modules
  auth (???)
  interfaces (???)
 
# puppet module install puppetlabs-apt
 

However, they have not provided support for managing modules in puppet manifests themselves. This strikes me as a bit odd: the whole point of using puppet to manage your machines is to capture the configuration in one place. If your configuration depends on a collection of modules and module versions, you'd ideally record that in the puppet configuration itself. Otherwise building a new puppet master is a mixture of manually installing modules and setting it up as a client of your existing master. Other people to the rescue: Ryan Coleman (and Pieter van de Bruggen) have written puppet_module_provider which does exactly this. (Note that they both work for Puppet Labs). Now I can define which modules and what versions are necessary:

class puppetmaster  
   
  module   'rcoleman/puppet_module': ensure => '0.0.3',  
  module   'puppetlabs/firewall':    ensure => '0.0.4',  
  module   'puppetlabs/lvm':         ensure => '0.1.1',  
  module   'puppetlabs/ntp':         ensure => '0.2.0',  
   

I've decided to pin specific versions given the highly variable nature of module quality. There's no guarantee of backwards compatibility except by reputation of the publisher. The puppetlabs modules are likely to be of higher quality than average, so over time I'll probably gain confidence to change the specific versioning to 'latest' or similar. I also want to double-check how secure the module selection and downloading is (whether it's over HTTPS or cryptographic signatures are checked etc.)

We are searching a motive for a painting or a painting itself for a quite while now. This should find it's place in our living room. Unfortunately we didn't found one, which matched our both prospect and/or wasn't compatible with the rest of our living room. Yesterday we stumbled upon a motive which was quite nice, but was too small and it was neighter possible to get it in a bigger size nor to find out who was the origin painter of the picture. Now we are searching for the name of the picture and/or the painter. Any hints appreciated at 'blog - at - waja - dot - info'. A photo with higher resolution can be found here Update: Okay ... an unknown people (many thanks) hinted me, that google image search is the tool that could be very usefull. Google revealed that the painter is Inna Panasenko. P.S. Is it noticeable that I'm in vacation mode? ;)

Hey y all, As some may have seen, I ve taken a shine to a project called Firehose, and plan on helping this format support Debian. I really enjoy how it s looking so far, and plan on slowly building out scripts to output this format. The idea here is I d use it to help with debuild.me, and eventually support larger archive runs. More to come.

On Friday, I uploaded an initial package for squishyball to Debian experimental. It's now in the NEW queue. squishyball is a command-line tool to help you compare two audio files. It supports basic A/B testing, A/B/X testing and X/X/Y ("triangle") tests to help rule out various selection, confirmation and ordering biases. I'm using it to figure out the optimal lossy audio codec and bitrate to encode my music collection with. It can be a little fiddly to use if you also use pulseaudio. I specify a specific ALSA device via -d, identified via aplay -L, and keep alsamixer running in a separate window to adjust volume if necessary, since GNOME's volume control shortcuts effect the pulseaudio mixers only. This way I can use headphones via the onboard analog stereo output and leave my desktop session configured to use HDMI output. For the time being, I've disabled support for the OPUS audio format. This is to prevent squishyball (GPL) from linking against libssl, which is pulled in by libopusfile. A future version of the package might manage to make this work.

The above two pictures show me holding a Samsung Galaxy S3 which has a 4.8 display in my left hand and a Sony Ericsson Xperia X10 which has a 4.0 display in my right hand. I am holding both phones in a manner that allows me to touch the top opposite corner with my thumb the position I need for one-handed phone use. The Xperia X10 can be completely enclosed by my hand, when I have a bottom corner resting in my palm it won t slide down while the Galaxy S3 can slide. Also one thing I didn t realise before having the pictures taken is that my posture is quite different when using the two phones. With the Galaxy S3 my wrist is clearly bent and this seems more likely to cause me to have more problems with Carpal Tunnel Syndrome [1]. I haven t had any serious problems with CTS for the last 2.5 years but I have had minor problems that suggest that I will have to be careful about my posture for the rest of my life. So it seems that a 4.8 phone is just too big for ideal one-handed use (grasping the vertical phone from the bottom). As I had CTS problems with my left hand I will try to use my new phone with my right hand as much as possible. Also I can reach further than the width of the phone screen when I grasp it from the side, so for me a size of about 5.2 would be better than the 4.8 of the Galaxy S3. It s quite likely that the Samsung Galaxy Note with it s 5.3 screen would be a better device for me to grasp from the side. But the Galaxy Note 2 might be a little too large for me. Note that I am only considering ways of holding the device that permit full operation. Anything that involves changing position for different uses or occasionally using two hands for a mostly one-hand operation doesn t count. The above picture is of me holding a 7 Android tablet (which I have just returned to Aldi [2]). When holding it from the sides I can reach more than half the screen with one hand so it seems that the ideal size for a tablet to be held in two hands for me would be 8 or even a little larger. A tablet larger than that could only be properly used if resting on my lap or a desk so for me 8 is the size that differentiates things which can be strictly used as tablets (holding with two hands and using thumbs for input) and things which are more like Netbooks (on desk typing). Ideal Device Sizes for people based on Height I am about 190cm tall. If we assume that height and hand size are strongly correlated then we can look at median heights of various age groups and determine what might be a good device size. I am also assuming that everyone wants to have the largest possible device, but some people have other criteria such as the size of their pockets. For me it s 8 tablet, 5.2 side-grip phone, and 4 bottom-grip phone. I used data from a chart of the average heights of American boys [3] and a chart of the average heights of American girls [4] to determine what size devices might suit children of various ages. Note that before the age of 12 the height of boys and girls is near enough to identical.

Device	Two Hand Tablet Use	Phone Grasp from Side	Phone Grasp from Below
7 tablet	14yo boy or 17yo girl	noone	noone
Galaxy Note 5.3	10yo	95th percentile 17yo boy	noone
Galaxy S3 4.8	6yo	17yo boy or 95th percentile 17yo girl	almost noone
Galaxy S and iPhone 5 4.0	3yo	10yo	95th percentile 17yo boy
iPhone 4 3.5	noone	8yo	14yo boy or 16yo girl

One thing that particularly interests me is the educational use of Android devices for children. As few people buy new phones and tablets for young children that largely means that children borrow devices from their parents or are given older phones when relatives no longer need them. So it seems that if all other things are equal then an adult might choose a phone with a 4.8 display to allow it to be used as a tablet by children in the 6-10 age range. Conclusion It seems that the iPhone 4 is a good size for one-handed use by women of average height. By the standards of the people who don t regard gripping a phone from below as a significant feature the iPhone 4 would be designed for the hand of an 8yo. By any standards all iPhones other than the iPhone 5 were not the ideal size for most adults to use maybe they are well designed to fit in a pocket while unused. Charles Stross criticised the iPhone because it s too small to be seen well by people with poor vision [5], he also makes many other interesting points about the use of phones and I recommend reading his article (and the rest of his blog). The common tablet size of 7 seems like it might be ideal for women to hold with both hands, but for men of average height a 7.5 tablet might be better suited, it sounds like a small difference but it changes button size (good for people with thicker fingers) and allows displaying more data at once (15% greater screen area). Of course if you want to use a tablet on a desk then something much bigger would be better, maybe 12 or 14 . I think that there is a real market for 14 tablets that are designed to be carried around the home or office and then used on a table or lap which differs from the tablets that are designed to be more portable. There is also the use case of holding the phone in one hand while typing with the other which I haven t considered in this post. I don t think it s interesting because in that case almost everyone will find that the limitation is the size of their pockets and the size of an object that can be held to one s face for a phone call not the size of their hands. I ve previously written about my search for Geeky jeans and the ability to put a 7 tablet in my jeans pocket [6]. So I think that pocket size isn t a phone selection issue for men. The fact that women s clothing tends to have tiny pockets is another issue, if someone knows of a good analysis of phone size vs pockets in women s clothes then please let me know.

• [1] http://etbe.coker.com.au/2010/06/16/carpal-tunnel-getting-better/
• [2] http://etbe.coker.com.au/2012/12/10/returning-aldi-tablet/
• [3] http://www.halls.md/on/boys-height-w.htm
• [4] http://www.halls.md/chart/girls-height-w.htm
• [5] http://tinyurl.com/3c4kqh5
• [6] http://etbe.coker.com.au/2012/11/17/geeky-jeans/

In April of 2012 I bought a ColorHug colorimeter. I got a bit discouraged when the first thing I realized was that one of my monitors needed replacing, and put the the colorhug in a drawer until today. With quite a lot of help and encouragment from Pascal de Bruijn, I finally got it going. Pascal has written an informative blog post on color management. That's a good place to look for background. This is more of a "write down the commands so I don't forget" sort of blog post, but it might help somebody else trying to calibrate their monitor using argyll on the command line. I'm not running gnome, so using gnome color manager turns out to be a bit of a hassle. I run Debian Wheezy on this machine, and I'll mention the packages I used, even though I didn't install most of them today.

1. Find the masking tape, and tear off a long enough strip to hold the ColorHug on the monitor. This is probably the real reason I gave up last time; it takes about 45minutes to run the calibration, and I lack the attention span/upper-arm-strength to hold the sensor up for that long. Apparently new ColorHugs are shipping with some elastic.
2. Update the firmware on the colorhug. This is a gui-wizard kindof thing.

    % apt-get install colorhug-client
    % colorhug-flash 
   

3. Set the monitor to factory defaults. On this ASUS PA238QR, that is brightness 100, contrast 80, R=G=B=100. I adjusted the brightness down to about 70; 100 is kindof eye-burning IMHO.
4. Figure out which display is which; I have two monitors.

    % dispwin -\?
   

   Look under "-d n"
5. Do the calibration. This is really verbatim from Pascal, except I added the ENABLE_COLORHUG=true and -d 2 bits.

    % apt-get install argyll
    % ENABLE_COLORHUG=true dispcal -v -d 2 -m -q m -y l -t 6500 -g 2.2 test
    % targen -v -d 3 -G -f 128 test
    % ENABLE_COLORHUG=true dispread -v -d 2 -y l -k test.cal test
    % colprof -v -A "make" -M "model" -D "make model desc" -C   "copyright" -q m -a G test
   

6. Load the profile

    % dispwin -d 2 -I test.icc           
   

   It seems this only loads the x property _ICC_PROFILE_1 instead of _ICC_PROFILE; whether this works for a particular application seems to be not 100% guaranteed. It seems ok for darktable and gimp.

The UEFI bootloader that the Linux Foundation have been working on has just been released. That means we now have two signed bootloaders available - this one and shim.
Does this mean Linux distributions can now support Secure Boot?They've actually been able to for a while. Ubuntu shipped with Secure Boot support last October, and Fedora shipped with Secure Boot support in January. Both used Shim rather than the Linux Foundation loader, and Shim's also being used by a variety of smaller distributions. The LF loader is a different solution to the same problem.
Is the Linux Foundation the preferred loader for distributions?Probably not in most cases. One of the primary functional differences between Shim and the LF loader is that the LF loader is based around cryptographic hashes rather than signing keys. This means that the user has to explicitly add a hash to the list of permitted binaries whenever a distribution updates their bootloader or kernel. Doing that involves being physically present at the machine, so it's kind of a pain.
Why use it at all, then?Being hash based means that you don't need to maintain any signing infrastructure. This means that distributions can support Secure Boot without having to change their build process at all. Shim already supports this use case (and some distributions are using it), but the LF loader has nicer UI for managing it.
Any other reasons?Actually, yes. Shim implements Secure Boot loading in a less than entirely ideal way - it duplicates the firmware's entire binary loading, validation, relocation and execution code. This is necessary because the UEFI specification doesn't provide any mechanism for adding additional authentication mechanisms. The main downside of this is that the standard UEFI LoadImage() and StartImage() calls don't work under Shim. The LF loader hooks into the low-level security architecture and installs its own handlers, which means the standard UEFI interfaces work. The upshot is that you can use bootloaders like Gummiboot or efilinux without having to modify them to call out to Shim.
Why doesn't Shim do the same?The UEFI architecture is slightly complicated. The UEFI specification itself defines the upper layers of the firmware, basically covering everything that UEFI applications and operating systems need. It doesn't define the lower layers of a UEFI implementation. Those are contained in the UEFI Platform Initialization spec, and that's what defines the security architecture interfaces that the LF loader hooks into. The problem is that it's completely valid to implement the UEFI specification without implementing the Platform Initialization specification, and if anyone does that then the LF loader will fail.
Can't you try both approaches?Yes, and that's actually pretty much the plan now. I'm working on integrating the LF loader's UI and security code into Shim with the aim of producing one loader that'll satisfy the full set of use cases, and James is happy with this.
Which should I use?Depends. If you want to support gummiboot (and aren't willing to patch it to call out to Shim), you'll need to use the LF loader. If you want to use key-based signing setups to avoid forcing re-enrolment on updates, you'll need to use Shim. If you're somewhere in the middle, you can probably use either. Once we've got the code merged, you won't have to make a choice.

comments

As I did not find a nice explanation of Debian version numbers to point people at, here some random collection of information about: All our packages have a version. For the package managers to know which to replace with which, those versions needs an ordering. As version orderings are like opinions (everyone has one), none of them would match any single one chosen for our tools to implement. So maintainers of Debian packages sometimes have to translate those versions into something the Debian tools understand. But first let's start with some basics: A Debian version string is of the form: [Epoch:]Upstream-Version[-Debian-Revision] To make this form unique, the Upstream-Version may not contain an colon if there is no epoch and not contain a minus, if there is no Debian-Revision. The Epoch must be an integer (so no colons allowed). And the Debian-Revision may not contain a minus sign (so the Debian-Revision is everything right of the right-most minus sign, or empty if there is no such sign). Two versions are compared by comparing all three parts. If the epochs differ, the biggest epoch wins. With same epochs, the biggest upstream version wins. With same epochs and same upstream versions, the biggest revision wins. Comparing first the upstream version and then the revision is the only sensible thing to do, but it can have counter-intuitive effects if you try to compare versions with minus signs as Debian versions:

$ dpkg --compare-versions '1-2' '<<' '1-1-1' && echo true   echo false
true
$ dpkg --compare-versions '1-2-1' '<<' '1-1-1-1' && echo true   echo false
false

To compare two version parts (Upstream-Version or Debian-Revision), the string is split into pairs of digits and non digits. Consecutive digits are treated as a number and compared numerrically. Non-digit parts are compared just like ASCII strings with the exception that letters are sorted before non-letters and the tilde is treated specially (see below). So 3pl12 and 3pl3s are slit into (3, 'pl', 12, '') and (3, 'pl', 3, 's') and the first is the larger version. Comparing digits as characters makes not sense at least at the beginning of the string (otherweise version 10.1 would be smaller than 9.3). For digits later in the string there are two different version schemes competing here: There is GNU style 0.9.0 followed by 0.10.0 and decimal fractions like 0.11 < 0.9. Here a version comparison algorithm has to choose one and the one chosen by dpkg is both the one supporting the GNU numbering and also the one easier supporting the other scheme: Imagine one software going 0.8 0.9 0.10 and one going 1.1 1.15 1.2. With out versioning scheme the first just works, while the second has to be translated into 1.1 1.15 1.20 to still be monotonic. The other way around, we would have to translate the first form to 0.08 0.09 0.10, or better 0.008 0.009 0.010 as we do not know how big those numbers will be, i.e. one would have to know beforehand where the numbers will end up, while adding zeros as needed for our scheme can be done with only knowing the previous numbers. Another decision to be taken is how to treat non-numbers. The way dpkg did this was assuming adding stuff to the end increases numbers. This has the advantage to not needing to special case dots, as say 0.9.6.9 will be bigger than 0.9.6 naturally. I think back then this decision was also easier as usually anything attached was making the version bigger and one often saw versions like 3.3.bl.3 to denote some patches done atop of 3.3 in the 3th revision. But this scheme has the disadvantage that version schemes like 1.0rc1 1.0rc2 1.0 do not map naturally. The classic way to work arround this is to translate that into 1.0rc1 1.0rc2 1.0.0 which works because the dot is a non-letter (it also works with 1.0-rc1 and 1.0+rc1 as the dot has a bigger ASCII number than minus or plus). The new way is the specially treated tilde character. This character was added some years ago to sort before anything else, including an empty string. This means that 1.0~rc1 is less than 1.0:

dpkg --compare-versions '1.0~rc1-1' '<<' '1.0-1' && echo true   echo false

This scheme is especially useful if you want to create a package sorting before a package already there, as you for example do want with backports (as a user having a backport installed upgrading to the next distribution should get the backport replaced with the actual package). That's why backport usually having versions like 1.0-2~bpo60+1. Here 1.0-2 is the version of the un-backported version; bpo60 is a note that this is backported to Debian 6 (AKA squeeze) and the +1 is the number of the backport in case there are multiple tries necessary. (Note the use of the plus sign as the minus sign is not allowed in revisions and would make the part before a part of the upstream version). Now, when to use which technique?

• Usually try to stick to the upstream version if it is sane. (With the exception of data based versions, as experience shows upstreams later change their mind, so a version of 20130210 is best translated to 0.20130210 in order to have a future 1.0 sort higher).
• If there are some suffixes in the version that denote a "before", prefix them with a tilde.
• Compare a version to your last version and put zeros or .0 at the end (or the ends of parts) where necessary to increase them.

Some common examples:

• You want to package 2.0 but you need to repack the .orig.tar because it contains a file with some non-free license (for example no license at all). Then you can call it 2.0~dfsg-1. If the file is later relicensed, you can do a 2.0-2 with the original file which sorts higher.
• You need to repack 2.0 but it was already in the archive. then you can do 2.0+dfsg-1 as this is higher. (using the plus has the advantage that you can later use the 2.0.0 trick if the file is relicensed, while the older 2.0.dfsg-1 made this impossible). (One can also use -dfsg-1 here, but + might be easier to parse for humans).
• You package a git snaphost of a version 2.0 not yet released, then you can use 2.0~gitXYZ-1
• You package a git snapshot of upstream doing some works on top of 1.9, then you can use 1.9+gitXYZ-1

I bricked a Samsung laptop today. Unlike most of the reported cases of Samsung laptops refusing to boot, I never booted Linux on it - all experimentation was performed under Windows. It seems that the bug we've been seeing is simultaneously simpler in some ways and more complicated in others than we'd previously realised.

So, some background. The original belief was that the samsung-laptop driver was doing something that caused the system to stop working. This driver was coded to a Samsung specification in order to support certain laptop features that weren't accessible via any standardised mechanism. It works by searching a specific area of memory for a Samsung-specific signature. If it finds it, it follows a pointer to a table that contains various magic values that need to be written in order to trigger some system management code that actually performs the requested change. This is unusual in this day and age, but not unique. The problem is that the magic signature is still present on UEFI systems, but attempting to use the data contained in the table causes problems.

We're not quite sure what those problems are yet. Originally we assumed that the magic values we wrote were causing the problem, so the samsung-laptop driver was patched to disable it on UEFI systems. Unfortunately, this doesn't actually fix the problem - it just avoids the easiest way of triggering it. It turns out that it wasn't the writes that caused the problem, it was what happened next. Performing the writes triggered a hardware error of some description. The Linux kernel caught and logged this. In the old days, people would often never see these logs - the system would then be frozen and it would be impossible to access the hard drive, so they never got written to disk. There's code in the kernel to make this easier on UEFI systems. Whenever a severe error is encountered, the kernel copies recent messages to the UEFI variable storage space. They're then available to userspace after a reboot, allowing more accurate diagnostics of what caused the crash.

That crash dump takes about 10K of UEFI storage space. Microsoft require that Windows 8 systems have at least 64K of storage space available. We only keep one crash dump - if the system crashes again it'll simply overwrite the existing one rather than creating another. This is all completely compatible with the UEFI specification, and Apple actually do something very similar on their hardware. Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here - it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.

This is pretty obviously a firmware bug. Writing UEFI variables is expressly permitted by the specification, and there should never be a situation in which an OS can fill the variable store in such a way that the firmware refuses to boot the system. We've seen similar bugs in Intel's reference code in the past, but they were all fixed early last year. For now the safest thing to do is not to use UEFI on any Samsung laptops. Unfortunately, if you're using Windows, that'll require you to reinstall it from scratch.

comments

MicroPeak USB Interface now available. Altus Metrum is pleased to announce the immediate availability of the MicroPeak USB interface.

• Connects the MicroPeak altimeter to USB.
• Records 48 seconds of flight
• Barometric pressure values recorded about 5 times per second.
• Save, graph and export pressure, height, speed and acceleration data.
• Supports Linux, Mac OS X and Windows. The software is available on the MicroPeak web page.
• Learn more at http://www.altusmetrum.org/MicroPeakUSB
• Buy these for $35 at the gag.com web store for Altus Metrum products. Or get one bundled with a MicroPeak and save $10.

MicroPeak USB Interface MicroPeak and the MicroPeak USB Interface MicroPeak is fun to use all by itself, providing a quick way to know how high your rocket has flown. But, for those people itching for more data, MicroPeakUSB offers a way to download raw flight data and analyze that on your computer. MicroPeakUSB doesn t require any changes to the MicroPeak hardware new MicroPeak firmware transmits the entire flight log through the on-board LED to a phototransistor on the MicroPeakUSB Interface and then to the USB port on your computer. Existing MicroPeak owners can contact us for a special deal on the MicroPeak USB interface and upgrading the MicroPeak firmware.

Redland/librdf offers powerful features like being able to persist an RDF model to a relational database (only PostGreSQL seems to work on my setup with 1.0.16, but I may have misconfigured it). You can then do SPARQL queries over the model, and lots of other nice things. Unfortunately, the default PHP bindings are not really object-oriented, so the code isn t looking so good. But thanks to a gentleman named David Shea, there is an object-oriented library named LibRDF (case is sensitive), that helps write nice looking PHP. I discovered it via the blog post of Felix Ostrowski, who took over the maintenance of the LibRDF library (still the docs live on the original author s site). In his post, Felix illustrates how you may use it to parse Richard Cyganiak s FOAF profile. But the examples he gives don t illustrate the full potential of persistence of the RDF graph into the DB. Here s my contribution in 2 examples that will hopefully help : first, one that load Richard s FOAF to the DB, and one, that later retrieve the saved model and perform the same query (both pushed to my github clone of the library). There may be some problems with the use of librdf, including its availability, as it is not full PHP of course and I ve heard of memory management problems, but, depening on your needs, this may be quite handy for writing Linked Data applications.

Update: I apologise for spamming all the nice people on Planet Debian with this unrelated post in foreign language it got mis-tagged and (although I tried classifying it correctly and removing it from the separate Debian-only RSS feed going to the Debian Planet) Planet software just keeps it around until admins get a spare moment to remove it manually. The basic idea of the post is that there is a e-government service by the Latvian government that provides any citizen a way to check what their pension would be, but it is kinda useless, because it calculates what you pension would be if you decided to retire right now. So in the post below I provide a few simple steps on how to estimate what the real pension could be (in todays currency values) if a person kept paying into the system at the same rate until the normal retirement age. Latvija.lv ir r ks savas n kotnes pensijas prognoz anai, ta u tas ir, maigi izsakoties, bezj dz gs tiem, kas nepl no iet pensij tuv k gada laik . tri apskatoties atteic gos likumus un noteikumus es nonacu pie lietder g kas metodes. Vispirms m s varam dro i ignor t pensiju indeks ciju un visas ar to saist t s pensiju kapit la p rr in anas vai iemaksu palielin anos ir skaidrs, ka gadiem ejot uz priek u b s kaut k ds infl cijas procents, kura d palielin sies algas, palielin sies iemaksas pensiju kapit l un tiks p rr in tas vis das izmaksas, ta u t pati infl cija tie i ietekm s ar to cik v rt gs b s katrs gala pensijas lats taj br d , kad pensija tiks sa emta, l dz ar to infl cijas efekts tiek neitraliz ts, ja m s v rt jam gala ciparu br a cenu kontekst t.i. ja gal san ks, ka pensija b s 400Ls, tad to vai tas ir daudz vai maz j dom br a cen s, nevis m inot izdom t k das b cenas p c 30 gadiem. To visu emot v r pensijas apr ins stipri vienk r ojas:

1. Pa emam atskaiti no t Latvija.lv pakalpojuma. Tas mums dos uz o br di uzkr to pensijas kapit lu (U) un aptuvenu ciparu par to k ds ir kapit la ikgad jais piaugums (P)
2. Apr inam cik v l gadi ir paliku i l dz pension an s vecumam (t) t.i. l dz 62 gadiem. Es pat r in tos ar to, ka ap to laiku m r a vecums jau b s 65.
3. Sar inam to cik b s aptuvenais pensijas kapit ls pension anas vecuma, ja m s turpinam iemaksas k tagad K = U + ( P * t )
4. Apr inam k da san k ikm ne a pensija no da pensijas kapit la Pensija = K / G / 12, kur G ir emts no pension an s vecumam atbilsto s rindi as MK noteikumos, piem ram 62 gadiem tas ir 18.43

Piez me: G ir statisti u apr in ta prognoze par to cik vid ji gadus Latvijas iedz vot ji nodz vo ja vi i ir sasniegu i attiec go pension an s vecumu, t.i. t ir prognoze par to cik gadus vid ji jums b s tas prieks baud t pensiju. Ja rezult ts san k par k mazs, tad j em v r , ka summa neiek auj dividendes no 2 un 3 pensijas l me a, kas p ris gadu desmitu laik var b t t ri iespaid gs. Da as prognozes ir t das, ka 2ais un 3ais pensijas l menis kop var tu dod v l aptuveni t du pa u pensiju kl t k 1ais l menis. Ta u tas ir stipri atkar gs no fondu tirgus ilglaic gas dinamikas. Man to visu apr inot san k ap 400 Ls pensijas prognoze. Ja piepild s paredz jumi par 2o un 3o pensijas l meni, tad, ja es iedom jos sevi tagad k pension ru ar 600-800 Ls pensiju zin nav ne vainas.

It has been so very long since I have left a trace here. I guess moving to two new countries (Canada and Quebec), starting a new job, working on Anonymous, and finishing my first book was a bit much. I miss this space, not so much because what I write here is any good. But it a handy way for me to keep track of time and what I do and even think. My life feels like a blur at times and hopefully here I can see its rhythms and changes a little more clearly if I occasionally jot things down here. So I thought it would nice to start with something that I found surprising: famed information designer, Edward Tufte, a professor emeritus at Yale was a phone phreak (and there is a stellar new book on the topic by former phreak Phil Lapsley. He spoke about his technological exploration during a sad event, a memorial service in NYC which I attended for the hacker and activist Aaron Swartz. I had my wonderful RA transcribe the speech, so here it is [we may not have the right spelling for some of the individuals so please let us know of any mistakes]:

Edward Tufte s Speech From Aaron Swartz s Memorial
Speech starts 41:00 [video cuts out in beginning]
We would then meet over the years for a long talk every now and then, and my responsibility was to provide him with a reading list, a reading list for life and then about two years ago Quinn had Aaron come to Connecticut and he told me about the four and a half million downloads of scholarly articles and my first question is, Why isn t MIT celebrating this? .
[Video cuts out again]
Obviously helpful in my career there, he then became president of the Mellon foundation, he then retired from the Mellon foundation, but he was asked by the Mellon foundation to handle the problem of JSTOR and Aaron. So I wrote Bill Bullen(sp?) an email about it, I said first that Aaron was a treasure and then I told a personal story about how I had done some illegal hacking and been caught at it and what happened. In 1962, my housemate and I invented the first blue box, that s a device that allows for free, undetectable, unbillable long distance telephone calls. And we got this up and played around with it and the end of our research came when we concluded what was the longest long distance call ever made, which was from Palo Alto to New York time-of-day via Hawaii, well during our experimentation, AT&T, on the second day it turned out, had tapped our phone and uh but it wasn t until about 6 months later when I got a call from the gentleman, AJ Dodge, senior security person at AT&T and I said, I know what you re calling about. and so we met and he said You what you are doing is a crime that would , you know all that. But I knew it wasn t serious because he actually cared about the kind of engineering stuff and complained that the tone signals we were generating were not the standard because they record them and play them back in the network to see what numbers they we were that you were trying to reach, but they couldn t break though the noise of our signal. The upshot of it was that uh oh and he asked why we went off the air after about 3 months, because this was to make long distance telephone calls for free and I said this was because we regarded it as an engineering problem and we made the longest long distance call and so that was it. So the deal was, as I explained in my email to Bill Bullen, that we wouldn t try to sell this and we were told, I was told that crime significance would pay a great deal for this, we wouldn t do any more of it and that we would turn our equipment over to AT&T, and so they got a complete vacuum tube isolator kit for making long distance phone calls. But I was grateful for AJ Dodge and I must say, AT&T that they decided not to wreck my life. And so I told Bill Bullen that he had a great opportunity here, to not wreck somebody s life, course he thankfully did the right thing.
Aaron s unique quality was that he was marvelously and vigorously different. There is a scarcity of that. Perhaps we can be all a little more different too.
Thank you very much.

In a previous entry I wrote about the technology of additive manufacture and the use in printing three dimensional objects.

It is now almost two years since I built my own 3D printer and I keep getting asked by colleagues and friends about the technology and often what printer to buy.

I will answer the purchase question first and then describe my experiences which have lead to the conclusion in another post. This may seem a bit backwards but the explanation is long and is not necessary if you are happy to learn from my mistakes.

Of all the options available right now, and there are many, I would choose a Mendal90 kit from Chris Palmer. The complete kit including everything to build the machine is 499 plus shipping. If I could afford it this is what I would buy myself to replace my current machine.

This is a Fused deposition modelling (FDM) printer similar to my Prusa Reprap but better engineered to produce repeatable results without the numerous issues of the other models. In Europe I would also recommend faberdashery as a materials source as their product is first rate every time.

Yes the kit requires some assembly but the commonly available commercial printers either cost many times more to deliver equivalent results, use an SLS or other print strategy requiring very expensive consumables or are from a company with dubious track record with the community.

If forced to recommend one, the 3DTouch from Bits From Bytes is not awful, but really do not be afraid of the kit, you will learn more about how it all fits together and save lots of money for your materials.

One thing anyone buying a 3D printer right now should understand is that this technology is nowhere near as polished as the 2D equivalent. With the exception of the SLS systems like shapeways and the like use (and have price tags to match) The output will have clear "layering" and some objects simply cannot be created using the FDM process.

I guess what I am saying is do not expect a thousand pound machine to produce output that looks like that of a hundred thousand pound printer. To be clear you will not be printing complex moving machines on an FDM process more simple things that need assembly.

Having said that I have some pretty good results my favourite has to be the working recorder though, I might have said the whistles except my sons have them and they are way too loud.

You will spend a lot of time designing your things in 3D CAD packages and fair warning they all SUCK and I mean really, really badly. Add to that all the rest of the tools in the workflow are also iffy and I do wonder how anyone every gets anything printed.

My (open source) workflow is:

• 3D CAD with OpenSCAD
• STL file
• meshlab to clean up the STL
• slic3r to create a toolpath
• Gcode file
• printrun to run the gcode on the printer.

Which is probably a case of "least bad" tool selection though I warn you now that OpenSCAD is effectively a bad editor (I wish I could use emacs) for a 3D solid macro language with visualisation attached and definitely not a graphical tool.

When I was testing C code coverage analysis tools using WebAuth, I really should have investigated the segfault that I started getting in the test suite before releasing 4.4.1. But since valgrind didn't report any problems, I thought it was something specific to code coverage. Nope, uninitialized variable inside the WebKDC code. Which valgrind didn't catch at all for some reason. Now fixed, and I did check for similar issues, but it's sort of disturbing that valgrind completely missed it, particularly for a variable whose address is taken and therefore which I wouldn't think would be optimized away. Since I hate to release WebAuth to only fix one thing, I also tested out-of-tree builds for the first time in a while and fixed a pile of issues around how the Perl module builds work. There's got to be a better way. Maybe sometime I'll try to come up with some patches to teach Module::Build how to handle VPATH. I also imported some additional Autoconf glue that will hopefully help Hurd builds proceed farther, although I didn't promise anything in NEWS since WebAuth has not yet successfully built on Hurd. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

This post is a quick status update on DebConf13, for those who aren t following the debconf-team mailing list. As you may know, this year s DebConf will be held at Le Camp, in Vaumarcus, Switzerland. Our concept for this DebConf is to hold it in a natural environment, away from distractions. We hope you will enjoy spending time together with other Debian collaborators in this beautiful part of Switzerland, on the shore of Lake Neuch tel. Dates DebConf13 will take place from Sunday 11. August 2013 to Sunday 18. August 2013. (We will use Saturday 10. August 2013 to prepare the venue for the conference.) You may notice that the dates don t cover two weeks like in the last few years (there is no separate DebCamp week). For budget reasons, current plans are to merge the two weeks activities into an 8 day period. If you think that s a pity, it s not too late to change it just join the fundraising team and start working quickly! Travel If you want to start arranging your travel to attend DebConf, some initial travel suggestions may be useful:

• We recommend that people from nearby countries take advantage of the excellent train connections to Switzerland, rather than looking for flights: the Swiss Federal Railways website, provides a very helpful international travel planner which knows about trains, but also about the local bus connections you will need to reach the DebConf venue.
• The best railway station to aim for is Yverdon-les-Bains. To get to the venue from there, take a local bus to the bus stop called Concise, Camp de Vaumarcus , which is very close to the venue. You can also directly use that name as your final destination in the above travel planner.
• Nearby airports include Geneva - GVA (1h30 from the venue by train), Zurich - ZRH (3h from the venue by train) and Basel-Mulhouse - BSL (3h from the venue by train).

The DebConf13 map shows the venue and the bus line (with some stops). Registration We expect to open registration around the start of March. Currently we are still evaluating some possible new conference management systems, which we hope might avoid the frustrations some attendees have had in the past with Pentabarf. Help welcome As always, the DebConf team is looking for volunteers. Some jobs need technical skills (e.g. testing conference management system setups, working on the website), but many DebConf tasks are about working to deadlines on non-technical issues (e.g. fundraising, budgeting, talk scheduling). You can see more information about some of the jobs to be done on the DebConf wiki. Please do think about getting involved and sharing your ideas with us, to help us make DebConf an even more useful event for Debian in the future. We look forward to welcoming you to Vaumarcus!

Lots of exciting things are happening with and around Rcpp. I just added a new page about Upcoming Events to the recently-created Rcpp site. This events page has lots to cover: an upcoming talk at Columbia on March 8 (details still TBD), a day-long workshop in New York on March 9, a possible participation at a CERN / ROOT conference in Switzerland on May 11-14, an upcoming talk in May in Milwaukee, and last but not least the tutorial by Romain and Hadley at UseR! 2013 in Spain. Phew! With that, a few quick words about the upcoming master class in New York. It will be a full day, covering an introduction and motivation, details about the core data types, tools for working with and and extending Rcpp and of course applications galore, including RcppArmadillo and RInside. I have done the same one day class format a few times before, most recently (with Revolution Analytics) in San Francisco in late 2011, and also as a two-part seminar at UseR! 2012. This time, we plan on providing cloud-hosted RStudio instances for participants. Better still, RStudio's own JJ Allaire will be on deck as well for RStudio --- and Rcpp Attributes --- questions. Details and registration information for the New York class are at this page.

After 27 hours of travel, I'm finally back from my first Linux.conf.au. This was a great conference! Some of my favorite highlights:

• Out for dinner the first night, my whole table started spontaneously talking about Haskell, including details of IO management frameworks like conduit and pipes, and a new one that's waiting in the wings. That just doesn't happen in the real world. A lot of us continued to do Haskell stuff in the hallway track, although for some reason there were no Haskell talks on the official schedule. Maybe it's time for a Haskell miniconf at LCA?
• Meeting Josh, Jamie, Sarah, Brendan, Craig, and others I've worked with online but never encountered IRL. Also reconnecting with old friends (some I'd not seen in 13 years) and finding new ones.
• The speaker's dinner in a revolving restaurant overlooking Canberra. Leave it to a restaurant full of geeks to invent an asychronous communications medium in such a setting. (Notes attached to windows to be read and answered by tables as they rotated by.)
• Meeting quite a lot of git-annex users, Kickstarter backers, and people interested in using git-annex. Thanks to everyone who came up to me for a chat.
• The evening pickup board game sessions. Especially my wiping out three other Tsuro players at once by forcing them all to end on the same square. ;) These were where I felt the most at home in Australia.
• Robert Llewellyn dropping in and mingling with fans of Red Dwarf and Scrapheap Challenge. One of the very few actors I could possibly fanboy on, and LCA not only somehow got him, but constructed an atmosphere that allowed for this photo of us.

---

My git-annex talk went ok, despite technical problems with the video output, which the video team did a great job of working around. The first demo went well, and the Q&A was excellent. The demo of the git-annex assistant webapp was marred by, apparently, a bad build of the webapp -- which I ironically used rather than my usual development build because I assumed it'd be less likely to fail. At least I may have a way to reproduce that hang somewhat reliably now, so I can get on with debugging it. I will be redoing a demo of the webapp as a screencast.

---

Here are some of the best talks I attended. (I have quite a lot more queued up to watch still, and had to cut several due to space.) Click titles for videos, or browse all the videos.

• Git for Ages 4 and Up
  Schwern has found a new, excellent way to explain git. I felt rather bad for using up a seat, especially once people were kicked out when the room was filled over capacity. But I enjoyed every minute of it. (Also has the best speaker intro ever. "Schwern once typed git pull --hard and pulled GitHub's sever room across the street.")

  BTW, I must confess: I left the red apple on teacher's desk.

• Radia Perlman's keynote
  Network protocol design and poetry from one of the quiet heros of our field. I knew Spanning Tree Protocol was used in ethernet, but it just works, so like many I never paid much attention to it. This talk felt like the best lectures, where you're learning from a master on multiple levels at once. Well done work often becomes an unremarked part of the landscape, which I sometimes find unrewarding, so it was great to have Radia give some perspective on what that's like over the course of decades.
• Lightning Talks
  A 90 second time limit really helps. Too many conferences have 5 minute talks, which is less exciting. If you still find them boring, skip forward to 13:50, where pjf does two talks in 90 seconds! (If a 20 second talk on depression is too .. manic, there's an encore at the end.)
• The IPocalypse 20 months later
  A reality check, with real data. Very important stuff here. We need to work to avoid this worst case scenario, and we also need to design around it.
• REPENT!!! FOR THE END OF THE UNIX EPOCH IS NIGH!!!
  Wildest talk beginning I've seen since RMS put the hard drive halo on his head. And to an important point: Any programs that deal with dates 25 years in the future already need to be fixed today to deal with the epoch rollover. This got me digging around in Haskell date libraries, to make sure they're ok.
• Building Persona: Federated and Privacy Sensitive Identity for the Web
  This talk and some previous conversation with Francois have convinced me that Persona (AKA Browserid) has a design that can succeed. I will be adding Persona login support to ikiwiki.
• Beyond Alt Text: What Every Project Should Know About Accessibility
  I missed the first half due to giving my talk, but the second half was full of rather a lot of excellent information, some of which I'd only guessed at before.
• Git: Not Just for Source Code Anymore
  Good overview of the new ways to use git. Also kept giving examples from my body of work, which is some nice ego stroking, thanks Josh. ;-)