Thomas Habets has blogged about using your TPM (Trusted Platform Module) for SSH authentication a few weeks ago. We worked together to get his package simple-tpm-pk11 into Debian, and it has just arrived in unstable :-). Using simple-tpm-pk11, you can let your TPM generate a key, which you then can use for SSH authentication. This key will never leave the TPM, so it is safer than having your key on the filesystem (e.g. ~/.ssh/id_rsa), since file system access is not enough to steal your key anymore. Instead, you ll need remote code execution. To use this software, first make sure your TPM is enabled in the BIOS. In my ThinkPad X200 from 2008, the TPM is called Security Chip . Afterwards, claim ownership of your TPM using tpm_takeownership -z (from the tpm-tools package) and enter a password. You will not need to enter this password for every SSH authentication later (but you may choose to set a separate password for that). Then, install simple-tpm-pk11, create a key, set it as your PKCS11Provider and install the public key on the host(s) where you want to use it:

mkdir ~/.simple-tpm-pk11
stpm-keygen -o ~/.simple-tpm-pk11/my.key
echo key my.key > ~/.simple-tpm-pk11/config
echo -e "\nHost *\n    PKCS11Provider libsimple-tpm-pk11.so" >> ~/.ssh/config
ssh-keygen -D libsimple-tpm-pk11.so   ssh shell.example.com tee -a .ssh/authorized_keys

You ll now be able to ssh into shell.example.com without having the key for that on your file system :-). In case you have any feedback about/troubles with the software, please feel free to contact Thomas directly.

Today was my "clean the house" day. I also had a chiropractic adjustment first thing, and a massage before lunch. I biked to Kindergarten to pick up Zoe, and found her holding court with a bunch of her classmates, giving a show and tell session about the Cinderella snow globe and echidna plush toy she'd taken to Kindergarten. The kids were taking turns to raise their hand and ask questions. I was out of earshot, so I couldn't really make out what was being said, but it all looked very cute from where I was standing. She didn't have a nap today. Sarah's going down to Tasmania until early next month, hiking, and so I've got Zoe for the next 12 nights. This is the longest she will have been away from her mother by quite a significant amount. On top of this, she's been doing rather poorly at bedtime with me the last few nights I've had her. I wanted to try and minimise the emotional impact for both of us as much as possible, so I wanted to make an Advent-style calendar to count down the number of sleeps until Mummy got back. After we got home from Kindergarten, we drove over to Officeworks to pick up some bits and pieces. It ended up being quite a long outing because it took a while for me to figure out how to convince the self-service photo printing kiosk to actually print photos. Zoe parked herself in the kid's colouring area, and she was quite happy there while I went looking for a few things, but after a while wandered off to find me and we spent some time looking for each other. I was pretty impressed with how well she went looking for me. She didn't freak out, and was just wandering around the store looking for me. We had a talk about staying put. Then we called grandma from the carpark to wish her a happy birthday before we headed home. That ended up being quite a lengthy outing, and I started dinner as soon as we got home. Bedtime actually went quite smoothly tonight for a change. No idea if the poster or the lack of a nap helped or not.

In cycling, a ride's Training Stress Score is a function of that ride's duration, average power and the intensity of the ride relative to the rider's capability. This Slowtwitch article provides a good overview on how intensity and TSS is calculated on a bike. However, having TSS values for other sports allows a multisport athelete to take into consideration the physiological cost of activities in different sports. This is achieved by ensuring, say, 50 TSS on the bike "counts" the same as a 50 TSS run. This can be used to simply determine the length, intensity and scheduling of the athletes next workout (to ensure adequate recovery) regardless of the combination of sports, or to identify the athlete's long-term tolerance to and targets for training load using metrics such as Chronic Training Load. To make this possible when using Strava, I wrote a Chrome extension that estimates the TSS score of a run from its Grade Adjusted Pace distribution: Source code is available. If you found this Strava extension useful, you might like my extensions to quickly switch between metric and imperial units or to change the default comparison filter.

Writing this because there seems to be no correct documentation on the relevant google websites and it turns out to be non-trivial. Our goal here is to unsubscribe from a ordinary google group. Mails from the google group contain the quoted footer:

-- 
You received this message because you are subscribed to the Google
Groups "FOO" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to FOO+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/FOO
For more options, visit https://groups.google.com/groups/opt_out.

Seems easy enough, so let's send a Mail to this FOO+unsubscribe address. Back comes a E-Mail:

From: FOO <FOO+unsubconfirm@googlegroups.com>
Subject: Unsubscribe request for FOO [ EJzZjpgFhDHd9seTdRA0 ]
To: Christoph Egger <christoph@example.com>
Date: Tue, 18 Feb 2014 18:55:24 +0000 (38 minutes, 53 seconds ago)
 [Leave This Group]
Visit Go 
[Start] your own group, [visit] the help center, or [report]
abuse.

So click on the [Leave This Group] link and be done? Unfortunately not. Looking at the link you notice it's called http://groups.google.com/group/FOO/subscribe -- no token and "subscribe"? I actually want to unsubscribe! And indeed, clicking gets an Interface that offers to "Enter the email address to subscribe:" + Captcha. And whatever it does, it -- of course -- doesn't unsubscribe. (My guess is, it would actually work if you had a real google account associated with that email address and were logged in to that account but there's no way of verifying this as already the first condition is false in this case) Now if you disable HTML completely for the email, a totally different content emerges:

Hello christoph@example.com,
We have received your request to unsubscribe from FOO. In order for us to complete the request, please reply to this email or visit the following confirmation URL:
http://groups.google.com/group/FOO/subscribe
If you have questions related to this or any other Google Group, visit the Help Center at http://groups.google.com/support/.
Thanks,
Google Groups

Still the non-functional link, however it also mentions a different solution: "please reply to this email" which was not present in the HTML mail at all. And it works.

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.

Debian Women is proud to announce that it will hold a MiniDebConf in Barcelona on 15-16 March 2014, where Debian enthusiasts from far and wide will gather to talk about the latest Debian changes and the Debian community, as well as to meet new and old friends. The MiniDebConf is fast approaching, be sure to make your travel arrangements! It is going to be an exciting event, in a beautiful venue, in one of the most famous European cities! Schedule A draft schedule (still subject to some last minute changes) is already available. The list of talks promises two days packed with great talks! If you have an exciting idea for a talk, but missed the deadline, please get in touch with us, we might still have a slot for you. Crowd-funding We are still raising funds to cover the costs of running the conference and to offer travel sponsorship to people who can't pay for it. Please, consider donating any amount you can, everything helps! Sponsorship If you want to attend the conference, but are unable to cover the costs. Please contact us! We don't have a big budget, but we will make our best to help. Naturally, priority will be given to participants who have an accepted talk. About this MiniDebConf We want to have a MiniDebConf with both talks and social events, to which everyone in Debian is invited but where the speakers in the talks are all people who identify themselves as female. We consider this important to

• Encourage women who haven't yet given their first DebConf talk
• Provide role models for women who are interested in contributing
• Debunk the myth that there are not enough women who can give talks in DebConf

The idea behind the conference is not to talk about women in free software, or women in Debian, but rather to make discussion about Debian subjects more inclusive for women. If you agree with this goal, spread the word. Forward this announcement and help us make this event a great success! About our sponsors This event is possible thanks to the help provided by our generous sponsors. In particular, we'd like to thank our platinum sponsor, Google. We hope to see you in Barcelona! For more information, visit http://bcn2014.mini.debconf.org

I really like to read code written by different people. I've always been the type of learner that can cover a lot of ground by looking at examples. A few of the programming tricks I acquired over time have definitely been learnt by reading programs written by other people. There are of course cases of disagrement with coding style (lets put that very mildly), so not every project is fun to read. But I tend to find projects I like enough to actually look at their source code. Now, if you get into this habit, there is also the occasional spotting of a bug. Many are really cosmetic, like typos in comments or documentation. Others are maybe more serious, who knows what can happen if you read a few lines of code written by someone you have never met in person. This is one of the original arguments of open source and free software. It basically goes like: "People will read your code and report problems." I know that happens, but I also know that there are cases of people finding relatively minor things during a small code review, which they don't report, or which get lost in some developers INBOX. I remember waiting months to see memory corruption fixes for a particular project I submitted by email to actually appear in the development repository. In some cases you really need to track your patches and prod someone to remind them about your contribution if need be. True, some of these issues are probably minor enough to not really hurt if they get lost, but I have a feel that a lot of minor things also sort of add up. This is where GitHub comes into play. We have had project hosting services since at least a decade now, but none of them (to my experience) have ever made it so easy for all involved parties to submit and merge changes into projects. Pull requests are just amazing. Well, at least for me, they are since a few months. I have a sort of mixed hate-love relationship with GitHub when it comes to a topic that is very important to me, Accessibility. The last project hosting site I really liked for their simple web interface (read, still usable with Lynx) was Google Code. That was in the days when Google still seemed to care about such things. These days, their newer services are next to unusable to me (with the tools I prefer). SourceForge was always a catastrophy. Many things were cumbersome to do, because the site is so loaded with links to all sorts of things I never need. However, at the time I was using it, all the things I really needed did work. GitHub is a different beast, in a different era of the internet. While I can read project pages and a few basic things perfectly fine, some parts of the GitHub site are simply unusable for no particular reason. For instance, I can edit (some of my) preferences and even save them. But I can not star a project, nor can I follow other developers. Invoking these links gives me a 404, which seems to indicate that some JavaScript (read, client side code execution) is required which my browser does not perform. However, I really wonder why. Because something like "I want to star this project" will eventually have to end up as a request on the server anyway, so it seems technically unnecessary to rely on Javascript for such an operation to succeed. Luckily, these days, hip projects do have an API. An GitHub is no exception. I want to emphasis that an API alone is not an accessibility fix, since you rarely have the time to implement a clinet for a random API, just to get access to a service you want to use. Sometimes you do, and an API is a great enabler in such situations, but a reference client with a rich feature-set is much better. I have to admit that I haven't evaluated any of the possible alternatives, but one client I found for GitHub's API did really boost my productivity in the last year. I am talking about Hub. It is a simple wrapper around Git that adds a few and enhances some other git commands. Most importantly, hub fork will fork the current checkout on GitHub, and hub pull-request allows you to quickly (and I really mean quickly!) open a pull request for some commits you've just done to your fork of some project. This is very helpful, and very accessible. While it does not solve all my accessibility problems with GitHub, it at least enables me to take part in the GitHub workflow. I can easily fork projects and submit pull reuqests for changes I did. And that is what I did, at least a bit, in roughly the past year. I am not sure exactly, but I think it was spring when someone made me aware of Hub. One approach would be to check my GitHub activity graph, but I probably don't have to mention that it is not accessible. Here is a list of some of my contributions to open source projects on GitHub since I discovered a good client for the GitHub API:

• pelican is the Python based static site generator which runs this blog.
• spirit_x3 is the experimental C++11 implementation of Boost.Spirit.
• music21 is a music notation processing framework for Python from the MIT. They have just recently moved to GitHub. Some of my (small) contributions to the braille music module of music21 predate the move to GitHub.
• teq (and teqqer) aim to provide an API for tracker-style sequencing and a coresponding terminal based client. To me a very exciting project. Clear separation between the Engine and the GUI is rare in the Linux Audio Landscape. Notable good exceptions are SuperCollider. But many end-user oriented tools tend to blend the functionality provided and the user interface into a single program, which makes it very hard to use if there are any accessibility issues. This is not true for teq/teqqer. teq is a tracker engine, and teqqer the coresponding reference user interface. Lets see what comes of it, the project is rather new.

To summarize: I love GitHub for what it does to the free software community. I think the simplicity (and transparency) of contributions is to the benefit of free and open source software. However, I also hate GitHub sometimes when I need to ask a friend to do relatively trivial changes for me. What I actually want, is a command-line client like Hub that makes most or even all functionality provided on the website available. True, some things like graphs are not immediately easy to adapt. But I really shouldn't need to use a modern full-fledged web browser to tell GitHub that I am interested in the activities of a certain user. Or delete a fork. Yes, thats right. I can use Hub to fork a project, but there is no way to delete it again. Sort of strange for casual small-scale contributions. I guess the workflow there is: fork, commit, pull-request, wait for merge, delete. I don't want to have all sorts of forks on GitHub that I actually don't actively use/maintain. So once a pull request was merged, and I don't have any other things I am working on right now, I actually want to get rid of the fork again. It is easy enough to do a fork should I ever need it again.

I really like to read code written by different people. I've always been the type of learner that can cover a lot of ground by looking at examples. A few of the programming tricks I acquired over time have definitely been learnt by reading programs written by other people. There are of course cases of disagrement with coding style (lets put that very mildly), so not every project is fun to read. But I tend to find projects I like enough to actually look at their source code. Now, if you get into this habit, there is also the occasional spotting of a bug. Many are really cosmetic, like typos in comments or documentation. Others are maybe more serious, who knows what can happen if you read a few lines of code written by someone you have never met in person. This is one of the original arguments of open source and free software. It basically goes like: "People will read your code and report problems." I know that happens, but I also know that there are cases of people finding relatively minor things during a small code review, which they don't report, or which get lost in some developers INBOX. I remember waiting months to see memory corruption fixes for a particular project I submitted by email to actually appear in the development repository. In some cases you really need to track your patches and prod someone to remind them about your contribution if need be. True, some of these issues are probably minor enough to not really hurt if they get lost, but I have a feel that a lot of minor things also sort of add up. This is where GitHub comes into play. We have had project hosting services since at least a decade now, but none of them (to my experience) have ever made it so easy for all involved parties to submit and merge changes into projects. Pull requests are just amazing. Well, at least for me, they are since a few months. I have a sort of mixed hate-love relationship with GitHub when it comes to a topic that is very important to me, Accessibility. The last project hosting site I really liked for their simple web interface (read, still usable with Lynx) was Google Code. That was in the days when Google still seemed to care about such things. These days, their newer services are next to unusable to me (with the tools I prefer). SourceForge was always a catastrophy. Many things were cumbersome to do, because the site is so loaded with links to all sorts of things I never need. However, at the time I was using it, all the things I really needed did work. GitHub is a different beast, in a different era of the internet. While I can read project pages and a few basic things perfectly fine, some parts of the GitHub site are simply unusable for no particular reason. For instance, I can edit (some of my) preferences and even save them. But I can not star a project, nor can I follow other developers. Invoking these links gives me a 404, which seems to indicate that some JavaScript (read, client side code execution) is required which my browser does not perform. However, I really wonder why. Because something like "I want to star this project" will eventually have to end up as a request on the server anyway, so it seems technically unnecessary to rely on Javascript for such an operation to succeed. Luckily, these days, hip projects do have an API. An GitHub is no exception. I want to emphasis that an API alone is not an accessibility fix, since you rarely have the time to implement a clinet for a random API, just to get access to a service you want to use. Sometimes you do, and an API is a great enabler in such situations, but a reference client with a rich feature-set is much better. I have to admit that I haven't evaluated any of the possible alternatives, but one client I found for GitHub's API did really boost my productivity in the last year. I am talking about Hub. It is a simple wrapper around Git that adds a few and enhances some other git commands. Most importantly, hub fork will fork the current checkout on GitHub, and hub pull-request allows you to quickly (and I really mean quickly!) open a pull request for some commits you've just done to your fork of some project. This is very helpful, and very accessible. While it does not solve all my accessibility problems with GitHub, it at least enables me to take part in the GitHub workflow. I can easily fork projects and submit pull reuqests for changes I did. And that is what I did, at least a bit, in roughly the past year. I am not sure exactly, but I think it was spring when someone made me aware of Hub. One approach would be to check my GitHub activity graph, but I probably don't have to mention that it is not accessible. Here is a list of some of my contributions to open source projects on GitHub since I discovered a good client for the GitHub API:

• pelican is the Python based static site generator which runs this blog.
• spirit_x3 is the experimental C++11 implementation of Boost.Spirit.
• music21 is a music notation processing framework for Python from the MIT. They have just recently moved to GitHub. Some of my (small) contributions to the braille music module of music21 predate the move to GitHub.
• teq (and teqqer) aim to provide an API for tracker-style sequencing and a coresponding terminal based client. To me a very exciting project. Clear separation between the Engine and the GUI is rare in the Linux Audio Landscape. Notable good exceptions are SuperCollider. But many end-user oriented tools tend to blend the functionality provided and the user interface into a single program, which makes it very hard to use if there are any accessibility issues. This is not true for teq/teqqer. teq is a tracker engine, and teqqer the coresponding reference user interface. Lets see what comes of it, the project is rather new.

To summarize: I love GitHub for what it does to the free software community. I think the simplicity (and transparency) of contributions is to the benefit of free and open source software. However, I also hate GitHub sometimes when I need to ask a friend to do relatively trivial changes for me. What I actually want, is a command-line client like Hub that makes most or even all functionality provided on the website available. True, some things like graphs are not immediately easy to adapt. But I really shouldn't need to use a modern full-fledged web browser to tell GitHub that I am interested in the activities of a certain user. Or delete a fork. Yes, thats right. I can use Hub to fork a project, but there is no way to delete it again. Sort of strange for casual small-scale contributions. I guess the workflow there is: fork, commit, pull-request, wait for merge, delete. I don't want to have all sorts of forks on GitHub that I actually don't actively use/maintain. So once a pull request was merged, and I don't have any other things I am working on right now, I actually want to get rid of the fork again. It is easy enough to do a fork should I ever need it again.

To "pedestal" an aerobar means to elevate the bars above the basebar using risers instead of using headset spacers: You might do this for a few reasons:

• The rider is in a more aerodynamic position when cornering or descending on the basebars.
• Lowers the rider's centre of gravity, improving cornering confidence.
• Less flex when climbing or accelerating under high wattage.
• Teardrop-shaped risers are more aerodynamic than a cylindrical steerer tube:

So, assuming you currently have a bike that uses headset spacers, what would be the effect on your position if you were to replace, say, a 10mm headset spacer with a 10mm armrest riser? First, let us consider the effect of removing the headset spacer. The crucial insight is that removing a 10mm spacer will not lower the stack height ie. the vertical distance relative to the bottom bracket by 10mm. This is because spacers are not oriented perpendicular to the ground; they are stacked along the steerer tube at the head tube angle of the frame. We will assume a head tube angle of 72.5 degrees. We can calculate that removing a 10mm spacer will reduce the stack height by:

sin(72.5 )   10mm = 9.54mm

... and by the same argument it will also increase the effective reach ie. the horizontal distance relative to the bottom bracket by:

cos(72.5 )   10mm = 3.01mm

Next, let us consider the impact of adding the riser. These are oriented perpendicular to the ground, so its addition makes no further change to the reach. However, we can now calculate the overall change in stack height:

  stack = -(sin(72.5 )   10mm) + 10mm = 0.46mm

We can then repeat the calculation for any length of replacement:

Replacement (mm)	stack (mm)	reach (mm)
10	+0.46	+3.01
20	+0.93	+6.01
30	+1.39	+9.02
40	+1.85	+12.0
50	+2.31	+15.0
60	+2.78	+18.0

From this table, I can discover that if I were to replace 30mm of headset spacers with 30mm of risers it would:

1. Increase my effective stack height by 1.39mm (likely neglible).
2. Increase my reach by 9.02mm. This might require me to use a shorter stem to get the same position. If that was undesirable for example, if was already using an extremely short stem I might be forced to abandon the idea altogether.

Three further considerations must be noted:

1. The resultant low height of the base bar could be quite drastic and prevent you breathing properly whilst climbing.
2. Having the steerer tube cut down after to removing headset spacers will reduce the resale value of your bike.
3. You might need to re-cable your brakes as you may have changed the distance the cables must span.

(It may seem odd to provide results for up to 60mm of headset spacers when such a large number of spacers would at the very least void one's warranty. However, I suspect such setups are transiently common within the confines of a fitting studio.)

A couple of days ago, AO3 reached 1 million fanworks in 14,353 fandoms. The AO3 is an archive of fanfiction for multiple fandoms, founded and run by a non-profit organization, Organization for Transformative Works with the aim of "providing access to and preserving the history of fanworks and fan culture in its myriad forms." The code behind AO3 is open source, their servers run Debian and they even have a Diversity Statement! How cool is that? :) And, well, there's also the fact that...

"[...] the Archive is one of a very small number of open-source projects founded and largely staffed by women, another contribution fans have made to the internet as a whole. Many women who were not previously involved in technology have learned new skills in the name of fannish activities, and the AO3 is proud to stand as a shining example of this growth."

So, congratulations AO3!

I wrote in a previous post that Youtube changed their way of delivering videos, with the use of Dynamic Adaptive Streaming over HTTP. On top of that, they started serving both the audio and the video in separate streams, which meant trouble for downloader tools like youtube-dl. As I mentioned in that previous post:

What does this mean in practical terms for users of youtube-dl? Well, if you wanted to download videos in resolutions like the 480p (format 35) that I mentioned, then you will probably have to change your way of doing things, until a more automated solution is in place. You will have to download both the audio and the video and, then, "combine" them (that is, multiplex them) to create one "normal" video file with both the audio and the video.

And latter, I wrote:

Otherwise, to download 480p videos (which I do for lectures and so on with other projects of mine, like edx-dl) I have to call youtube-dl twice: once for format 135 and another for format 140, since the old format 35 files are much smaller than the lower resolution 360p files (due to the former being encoded in High profile vs. the latter being encoded in Constrained Baseline profile).

(...) Well, now, we don't have this problem anymore: The new release of youtube-dl brings us many goodies, including that it is possible to automatically combine/merge/multiplex audio and video formats that Youtube now offers separately (See the previous comments about separate audio and video). Now, if you want a 480p video in H.264 format, High profile, with 128kbps AAC audio (this used to be Youtube's format 35), you can specify format -f 135+140 on the command-line and it will download both the audio, the video and multiplex it with ffmpeg (or avconv, depending on what you have installed). Besides being convenient, this automatic downloading and merging makes it unnecessary to write scripts to, say, retrieve all the videos in a playlist that contains a lot of lectures (see one example here, taught by Benedict Gross). Version 2014.02.17 of youtube-dl will be soon in your favorite mirror of the Debian archives.

I've updated my markdown-pastebin site, to be a little cleaner, and to avoid spidering issues. Previously every piece of uploaded text received an incrementing integer to describe it - which meant it was trivially easy for others to see how many pieces of text had been uploaded, and to spider all past uploads (unless the user deleted them). Now each fresh paste receives a random UUID to describe it, and this means spidering is no longer feasible. I've also posted the source code to Gitub so folk can report bugs, fork, etc:

• https://github.com/skx/markdown.share/

That source code now includes a Dockerfile which allows you to quickly and easily build your own container running this wonderful service, and launch it without worrying about trashing your server ;) Anyway other than the user-interface overhaul it is still as functional, or not, as it used to be!

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

MicroPeak Approved for NAR Contests The NAR Contest Board has approved MicroPeak for use in contests requiring a barometric altimeter starting on the 1st of April, 2014. You can read the announcement message on the contestRoc Yahoo message board here: Contest Board Approves New Altimeter The message was sent out on the 30th of January, but there is a 90 day waiting period after the announcement has been made before you can use MicroPeak in a contest, so the first date approved for contest flights is April 1. After that date, you should see MicroPeak appear in Appendix G of the pink book, which lists the altimeters approved for contest use Thanks much to the NAR contest board and all of the fliers who helped get MicroPeak ready for this!

Process Identifiers (PIDs) are a scarce resource. On Linux they are only 15 bits by default. The Process Identifier Preservation Society (PIPS) aims to reduce abuse and wastage of the PID space. To join the society please read the following advice.

Common issues Several languages generally allow you to run all your code in one process. Some of the code that you might want to incorporate or use is not available in the form of ELF libraries or language specific libraries but only in the form of ELF binaries or interpreted scripts. As a result using additional PID space is sometimes unavoidable. Many languages have multiple methods of starting external processes and usually some of them waste PID space by running commands in a shell. You can avoid those methods or use the exec builtin to preserve the shell PID. It might be tempting to explicitly use shell in languages that don't allow implicit shell use but that just wastes extra PIDs. Several languages allow you to fork one process into two, this uses an extra PID and is to be avoided unless necessary.

Shell Programs written in the shell languages use a lot of PIDs. Even shells that have a lot of shell builtins (like busybox sh) appear to use the PID space by forking a child process. To join PIPS you should just stop writing programs in shell or use as many builtins as possible and use exec to preserve PIDs.

Init Several init systems are written in or use shell extensively and thus eat huge bowls of PIDs for breakfast. To join the PIPS you should switch away from sysvinit, openrc, init=/bin/sh etc.

C/C++ The common issues section applies to the C/C++ language. To join PIPS you should rewrite your code to use fork()+exec(), g_spawn*() or libpipeline instead of the g_spawn_command_line*(), system() and popen() functions.

Perl The common issues section applies to the Perl language. To join PIPS you should rewrite your code to avoid backticks and only pass arrays to the system(), open(), open2(), open3() functions.

PHP The common issues section applies to the PHP language. To join PIPS you should rewrite your code to use pcntl_exec() instead of backticks, exec(), system(), passthru(), shell_exec(), popen() and proc_open(). Apparently pcntl_exec() is disabled by default on Debian and pcntl_* are often unavailable so you should just not spawn processes. You could also just drop PHP already.

Python The common issues section applies to the Python language. To join PIPS you should rewrite your code to use the subprocess module and avoid passing shell=True to the subprocess.Popen() function. The os.system(), os.popen() functions and the commands module all run their commands in a shell, wasting PID space. The popen2 module requires passing arrays instead of strings in order to avoid the command being run in a shell.

Java The common issues section applies to the Java language. To join PIPS you should rewrite your code to use ProcessBuilder or only pass arrays of strings to Runtime.getRuntime().exec().

Haskell The common issues section applies to the Haskell language. To join PIPS you should only ever pass a RawCommand to createProcess and never use the shell, system, runCommand or runInteractiveCommand functions from the System.Process and System.Cmd libraries.

OCaml The common issues section applies to the OCaml language. To join PIPS you should rewrite your code to use fork+exec or the create_process* wrappers instead of system, open_process, open_process_in, open_process_out and open_process_full.

Go Go allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Rust Rust allows running external processes but doesn't allow you to waste PID space by running commands in shell. Avoid explicitly running the shell though.

Erlang The common issues section applies to the Erlang language. To join PIPS you should rewrite your code to use erlang:open_port( spawn_executable, ... , ...) instead of os:cmd or the other options to erlang:open_port.

Node.js The common issues section applies to the Node.js language. To join PIPS you should rewrite your code to use the child_process.execFile() function (or other child_process functions) instead of child_process.exec().

Julia Julia allows running external processes but doesn't allow you to waste PID space by running commands in shell. It emulates a lot of shell features instead. Avoid explicitly running the shell though.

Dart The common issues section applies to the Dart language. To join PIPS simply do not enable the runInShell parameter of the Process object.

PS Let me know if I missed something in one of these languages. You should also do most of the above to avoid shell metacharacter injection attacks that usually allow arbitrary code execution. Dear language authors, don't allow running external processes in shell, kthxbye!

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.

Sarah had her training course again today, so she dropped Zoe around to me to take to Kindergarten. She apparently had a disrupted night's sleep and was a bit emotional this morning. She wasn't cooperative, so we ended up having to drive to Kindergarten instead of take the bike. Drop off itself went pretty well. She just wanted to sit in a teacher's lap, and was otherwise fine. I'm still working through the long tail of document collation for my tax return. I spent most of the day sorting through poorly filed papers. I ended up refiling a bunch of them. I biked to Kindergarten for pickup. My preferred route seems to take me about 13 minutes, door to door. Zoe was still napping today, but woke up pretty well. The hairdresser I take Zoe to does free fringe trims in between haircuts, so we dropped in there on the way home to get a fringe trim. They have a little fenced off children's play area in the corner, and she always likes to have a play. We probably spent 15 minutes there after the fringe trim. I had to use some creative imaginative play to encourage her to leave (Cowie called to ask her to come home and give her a cuddle). Before she left, she had to pack all her toys away again, which I was very impressed by. Once we got home, I was able to use the box rocket as a TV diversion again, and we made a steering wheel for it, and she put more bling on the outside, and also used some water colours to paint it. The water colours didn't work terribly well on the cardboard. After that, we drilled the hole in the base for the second clothes line I made and glued the pole into it, and then Zoe watched a little bit of TV. Sarah finished her course early today. I'm just waiting for my girlfriend to get here and we're going to hang out with my cousin who is having round four of chemotherapy today, and drive her home afterwards.

As an introvert I like - well, I need to - spend time alone. I get my best ideas on my own. But when I truly thrive is when I am connected with others, cocreating. For the last couple of weeks it's been difficult for me to work on the visual design for the MiniDebConf in Barcelona next month. There have been practical reasons, but the real reason was that I was feeling stuck and overwhelmed. Sharing my uncomfortable feelings with my boyfriend finally made me able to see that I have been feeling alone, and feeling that I had to prove myself with my work. I felt disconnected from the people in Debian I want to cooperate with. I'd really benefit from sharing my thoughts and ideas more with others. The unpleasant feeling of "stuckness" dissolved when I said out loud what they were about, and ideas for changing my state appeared. Now I've started hanging out on the irc-channel more, I've asked for help in finding stuff in the huge pile of info, rules and previous examples and experiences at debian.org and my decision to blog and share more is strengthened. Finally the work has begun. Conferences are about meeting up and getting connected. Listening to somebody trying to enlighten you on a subject. Getting inspired. And so my idea of using speech bubbles as a visual identity koncept for the conference has everything to do with my own experience of connection and disconnection. Release, early, release often, I cannot say that I have done that. We really need the peoposals to be ready now. Thankfully I'll have time in the following days to get feedback and finish. I really hope people will accept the idea, but I'm expecting a debate.

(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.