In a few weeks, I will have the opportunity to offer a weekend workshop to selected and motivated high school students¹ to a topic of my choice. My idea is to tell them something about logic, proofs, and the joy of searching and finding proofs, and the gratification of irrevocable truths. While proving things on paper is already quite nice, it is much more fun to use an interactive theorem prover, such as Isabelle, Coq or Agda: You get immediate feedback, you can experiment and play around if you are stuck, and you get lots of small successes. Someone² once called interactive theorem proving the worlds most geekiest videogame . Unfortunately, I don t think one can get high school students without any prior knowledge in logic, or programming, or fancy mathematical symbols, to do something meaningful with a system like Isabelle, so I need something that is (much) easier to use. I always had this idea in the back of my head that proving is not so much about writing text (as in normally written proofs) or programs (as in Agda) or labeled statements (as in Hilbert-style proofs), but rather something involving facts that I have proven so far floating around freely, and way to combine these facts to new facts, without the need to name them, or put them in a particular order or sequence. In a way, I m looking for labVIEW wrestled through the Curry-Horward-isomorphism. Something like this: So I set out, rounded up a few contributors (Thanks!), implemented this, and now I proudly present: The Incredible Proof Machine³ This interactive theorem prover allows you to do perform proofs purely by dragging blocks (representing proof steps) onto the paper and connecting them properly. There is no need to learn syntax, and hence no frustration about getting that wrong. Furthermore, it comes with a number of example tasks to experiment with, so you can simply see it as a challenging computer came and work through them one by one, learning something about the logical connectives and how they work as you go. For the actual workshop, my plan is to let the students first try to solve the tasks of one session on their own, let them draw their own conclusions and come up with an idea of what they just did, and then deliver an explanation of the logical meaning of what they did. The implementation is heavily influenced by Isabelle: The software does not know anything about, say, conjunction ( ) and implication ( ). To the core, everything is but an untyped lambda expression, and when two blocks are connected, it does unification⁴ of the proposition present on either side. This general framework is then instantiated by specifying the basic rules (or axioms) in a descriptive manner. It is quite feasible to implement other logics or formal systems on top of this as well. Another influence of Isabelle is the non-linear editing: You neither have to create the proof in a particular order nor have to manually manage a proof focus . Instead, you can edit any bit of the proof at any time, and the system checks all of it continuously. As always, I am keen on feedback. Also, if you want to use this for your own teaching or experimenting needs, let me know. We have a mailing list for the project, the code is on GitHub, where you can also file bug reports and feature requests. Contributions are welcome! All aspects of the logic are implemented in Haskell and compiled to JavaScript using GHCJS, the UI is plain hand-written and messy JavaScript code, using JointJS to handle the graph interaction. Obviously, there is still plenty that can be done to improve the machine. In particular, the ability to create your own proof blocks, such as proof by contradiction, prove them to be valid and then use them in further proofs, is currently being worked on. And while the page will store your current progress, including all proofs you create, in your browser, it needs better ways to save, load and share tasks, blocks and proofs. Also, we d like to add some gamification, i.e. achievements ( First proof by contradiction , 50 theorems proven ), statistics, maybe a share theorem on twitter button. As the UI becomes more complicated, I d like to investigating moving more of it into Haskell world and use Functional Reactive Programming, i.e. Ryan Trickle s reflex, to stay sane. Customers who liked The Incredible Proof Machine might also like these artifacts, that I found while looking whether something like this exists:

• Easyprove, an interactive tool to create textual proofs by clicking on rules.
• Domino On Acid represents natural deduction rules in propositional logic with and as a game of dominoes.
• Proofscape visualizes the dependencies between proofs as graphs, i.e. it operates on a higher level than The Incredible Proof Machine.
• Proofmood is a nice interactive interface to conduct proofs in Fitch-style.
• Proof-Game represents proofs trees in a sequent calculus with boxes with different shapes that have to match.
• JAPE is an editor for proofs in a number of traditional proof styles. (Thanks to Alfio Martini for the pointer.)
• Logitext, written by Edward Z. Yang, is an online tool to create proof trees in sequent style, with a slick interface, and is even backed by Coq! (Thanks to Lev Lamberov for the pointer.)
• Carnap is similar in implementation to The Incredible Proof Machine (logical core in Haskell, generic unification-based solver). It currently lets you edit proof trees, but there are plans to create something more visual.
• Clickable Proofs is a (non-free) iOS app that incorporates quite a few of the ideas that are behind The Incredible Proof Machine. It came out of a Bachelor s thesis of Tim Selier and covers propositional logic.
• Euclid the game by Kasper Peulen is a nice game to play with geometric constructions.

When I wrote about TPM attestation via 2FA, I mentioned that you needed a bootloader that actually performed measurement. I've now written some patches for Shim and Grub that do so.

The Shim code does a couple of things. The obvious one is to measure the second-stage bootloader into PCR 9. The perhaps less expected one is to measure the contents of the MokList and MokSBState UEFI variables into PCR 14. This means that if you're happy simply running a system with your own set of signing keys and just want to ensure that your secure boot configuration hasn't been compromised, you can simply seal to PCR 7 (which will contain the UEFI Secure Boot state as defined by the UEFI spec) and PCR 14 (which will contain the additional state used by Shim) and ignore all the others.

The grub code is a little more complicated because there's more ways to get it to execute code. Right now I've gone for a fairly extreme implementation. On BIOS systems, the grub stage 1 and 2 will be measured into PCR 9[1]. That's the only BIOS-specific part of things. From then on, any grub modules that are loaded will also be measured into PCR 9. The full kernel image will be measured into PCR10, and the full initramfs will be measured into PCR11. The command line passed to the kernel is in PCR12. Finally, each command executed by grub (including those in the config file) is measured into PCR 13.

That's quite a lot of measurement, and there are probably fairly reasonable circumstances under which you won't want to pay attention to all of those PCRs. But you've probably also noticed that several different things may be measured into the same PCR, and that makes it more difficult to figure out what's going on. Thankfully, the spec designers have a solution to this in the form of the TPM measurement log.

Rather than merely extending a PCR with a new hash, software can extend the measurement log at the same time. This is stored outside the TPM and so isn't directly cryptographically protected. In the simplest form, it contains a hash and some form of description of the event associated with that hash. If you replay those hashes you should end up with the same value that's in the TPM, so for attestation purposes you can perform that verification and then merely check that specific log values you care about are correct. This makes it possible to have a system perform an attestation to a remote server that contains a full list of the grub commands that it ran and for that server to make its attestation decision based on a subset of those.

No promises as yet about PCR allocation being final or these patches ever going anywhere in their current form, but it seems reasonable to get them out there so people can play. Let me know if you end up using them!

[1] The code for this is derived from the old Trusted Grub patchset, by way of Sirrix AG's Trusted Grub 2 tree.

comments

Back in early 2012 I had been helping with system administration of a number of Debian/Ubuntu-based machines, and the odd Solaris machine, for a couple of years at $DAYJOB. We had a combination of hand-written scripts, documentation notes that we cut n paste d from during installation, and some locally maintained Debian packages for pulling in dependencies and providing some configuration files. As the number of people and machines involved grew, I realized that I wasn t happy with how these machines were being administrated. If one of these machines would disappear in flames, it would take time (and more importantly, non-trivial manual labor) to get its services up and running again. I wanted a system that could automate the complete configuration of any Unix-like machine. It should require minimal human interaction. I wanted the configuration files to be version controlled. I wanted good security properties. I did not want to rely on a centralized server that would be a single point of failure. It had to be portable and be easy to get to work on new (and very old) platforms. It should be easy to modify a configuration file and get it deployed. I wanted it to be easy to start to use on an existing server. I wanted it to allow for incremental adoption. Surely this must exist, I thought. During January 2012 I evaluated the existing configuration management systems around, like CFEngine, Chef, and Puppet. I don t recall my reasons for rejecting each individual project, but needless to say I did not find what I was looking for. The reasons for rejecting the projects I looked at ranged from centralization concerns (single-point-of-failure central servers), bad security (no OpenPGP signing integration), to the feeling that the projects were too complex and hence fragile. I m sure there were other reasons too. In February I started going back to my original needs and tried to see if I could abstract something from the knowledge that was in all these notes, script snippets and local dpkg packages. I realized that the essence of what I wanted was one shell script per machine, OpenPGP signed, in a Git repository. I could check out that Git repository on every new machine that I wanted to configure, verify the OpenPGP signature of the shell script, and invoke the script. The script would do everything needed to get the machine up into an operational stage again, including package installation and configuration file changes. Since I would usually want to modify configuration files on a system even after its initial installation (hey not everyone is perfect), it was natural to extend this idea to a cron job that did git pull , verified the OpenPGP signature, and ran the script. The script would then have to be a bit more clever and not redo everything every time. Since we had many machines, it was obvious that there would be huge code duplication between scripts. It felt natural to think of splitting up the shell script into a directory with many smaller shell scripts, and invoke each shell script in turn. Think of the /etc/init.d/ hierarchy and how it worked with System V initd. This would allow re-use of useful snippets across several machines. The next realization was that large parts of the shell script would be to create configuration files, such as /etc/network/interfaces. It would be easier to modify the content of those files if they were stored as files in a separate directory, an overlay stored in a sub-directory overlay/, and copied into the file system s hierarchy with rsync. The final realization was that it made some sense to run one set of scripts before rsync ing in the configuration files (to be able to install packages or set things up for the configuration files to make sense), and one set of scripts after the rsync (to perform tasks that require some package to be installed and configured). These set of scripts were called the pre-tasks and post-tasks respectively, and stored in sub-directories called pre-tasks.d/ and post-tasks.d/. I started putting what would become Cosmos together during February 2012. Incidentally, I had been using etckeeper on our machines, and I had been reading its source code, and it greatly inspired the internal design of Cosmos. The git history shows well how the ideas evolved even that Cosmos was initially called Eve but in retrospect I didn t like the religious connotations and there were a couple of rewrites on the way, but on the 28th of February I pushed out version 1.0. It was in total 778 lines of code, with at least 200 of those lines being the license boiler plate at the top of each file. Version 1.0 had a debian/ directory and I built the dpkg file and started to deploy on it some machines. There were a couple of small fixes in the next few days, but development stopped on March 5th 2012. We started to use Cosmos, and converted more and more machines to it, and I quickly also converted all of my home servers to use it. And even my laptops. It took until September 2014 to discover the first bug (the fix is a one-liner). Since then there haven t been any real changes to the source code. It is in daily use today. The README that comes with Cosmos gives a more hands-on approach on using it, which I hope will serve as a starting point if the above introduction sparked some interest. I hope to cover more about how to use Cosmos in a later blog post. Since Cosmos does so little on its own, to make sense of how to use it, you want to see a Git repository with machine models. If you want to see how the Git repository for my own machines looks you can see the sjd-cosmos repository. Don t miss its README at the bottom. In particular, its global/ sub-directory contains some of the foundation, such as OpenPGP key trust handling.

Review: Getting Back to Full Employment, by Dean Baker & Jared Bernstein

Publisher:	CEPR
Copyright:	2013
ISBN:	0-615-91836-0
Format:	Kindle
Pages:	116

Getting Back to Full Employment is more of a policy paper than a book. The authors both work for economic think tanks; one of those, the Center for Economic and Policy research (co-founded by Baker), is the publisher of this book. It's also free on the Kindle, another sign that the purpose is more about educating and convincing the public than about selling a non-fiction analysis. I found out about this through Paul Krugman, and if you're a regular reader of Krugman's columns and blog, not much here will be a surprise. Baker and Bernstein are advocating what I would call conventional-liberal economic policy by US standards (which means that it's not really that liberal). The short version is that full employment is vital for improving the economic position of the average person, inflation is nowhere near as much of a risk as people claim, and the best economic action the US government can take at present is to aggressively pursue a full employment strategy without worrying excessively about inflation. If you're at all familiar with this debate, you probably already have an opinion about everything in that summary. I certainly do. If you follow economics at all, this debate has been raging ever since the 2008 financial crisis (and earlier versions of the debate were raging before then). Since I'm a regular Krugman reader, you probably know my opinion: the people who have been crying wolf about the dangers of inflation have been systematically wrong about everything for seven years solid, and it's amazing that anyone is still giving them the time of day. Baker and Bernstein make a similar argument at greater length, and with a more academic tone. The risk of any policy paper like this is that reactions will be almost entirely decided by one's pre-existing opinion about the political actions that each economic policy implies. If you (like me) have already decided that government intervention in the economy is useful to prevent concentration of wealth in the hands of a few and provide support for the most vulnerable, everything Baker and Bernstein say here is going to sound quite convincing. If you've already decided that government intervention in the economy almost always leads to tears, and that a large government with the ability to take economic action is far more dangerous than any of the effects of economic downturns and unemployment, it would surprise me if Baker and Bernstein will change your mind. In other words, I'm skeptical that policy papers like this accomplish much. That said, there are a lot of facts and data here, which at least help ground this ongoing argument in more specifics. The authors show you the math: the evidence for moderate inflation not leading to any serious impact for economies, the very strong correlations between low unemployment rates and rising median wages, the theoretical basis for lower bounds on unemployment rates and our extensive past history of assuming that lower bound is much higher than it actually is, and some pointed comparisons to countries like Germany that have taken many of the specific policy recommendations included here and have a far healthier labor market as a result. All the statistics, charts, and discussion of analysis techniques is fairly dry, but I think the data is compelling. Of course, I was already convinced by earlier reading. There are a few bits here that I hadn't seen before, or at least hadn't internalized. One is a subtle but very important statistical limitation: any uncertainty in measuring the inflation rate will lead to incorrect statistical findings that inflation slows growth. The explanation for this takes several pages and is somewhat technical: the short and somewhat inaccurate version is that growth is measured in inflation-adjusted GDP, so if you get inflation wrong, you magnify the correlation between GDP and inflation. An inaccurately-high measure of inflation rate simultaneously leads to underestimating GDP growth for that country; an inflation rate that's inaccurate on the low side leads to overestimating GDP growth. This is inherent in how this comparison is done, and it's hard to see how to avoid it. It's therefore worth taking any analysis of the growth impact from higher inflation with a grain of salt. (Please note here that we're talking about moderate inflation the typical rates between 1% and 8% that you see in developed economics.) Another bit that was new to me was the analysis of the connection between trade deficits and full employment. I typically dismiss any international trade analysis in macroeconomic policy for the US since international trade is a much smaller part of our economy than most people think it is, and because protectionism has been rightfully discarded as a policy approach. But Baker and Bernstein make an interesting argument here about the effects of a strong currency on increasing unemployment; even with the relatively small amount of trade, reducing the deficit would have a noticeable effect. (Increasing the volume of trade but not changing the balance would not.) The authors certainly don't recommend protectionism; they do recommend being willing to let the value of the dollar drop against other currencies as a good way to reduce the deficit, and to be aware that other central banks have intentional policies of propping up the dollar that we're largely ignoring. They also mention that this is a zero-sum game for the world economy as a whole, although I would have preferred a bit more emphasis on that. You can't get very far via beggar-thy-neighbor economic policy. But it's a good reminder that the obsession in some parts with not "devaluing the currency" is economic nonsense and directly hurts employment. The end of the book discusses a variety of sensible policy recommendations ranging from international currency policy to Germany's work-sharing program where the government subsidies reduction of worker hours the same way that we already subsidize unemployment. They all seemed reasonable to me, although, sadly, I have little faith that the dysfunctional US government will consider any of them seriously, particularly more direct approaches such as government taking on the role of employer of last resort. But they're fun to read about and imagine a US in which the government actually did sensible things like that. Getting Back to Full Employment is pretty dry, and it's hard to shake the feeling that writing things like this is basically pointless, so I'm not sure I can really recommend it. But if you like reading Krugman's columns and are interested in similar material from different people at a longer length, that's basically what this is. Rating: 6 out of 10

Review: Half Life, by S.L. Huang

Series:	Russell's Attic #2
Publisher:	S.L. Huang
Copyright:	2014
ISBN:	0-9960700-5-2
Format:	Kindle
Pages:	314

This is a sequel to Zero Sum Game and the second book about Cas Russell, a mercenary superhero (in a world without the concept of superheroes) with preternatural ability to analyze anything about her surroundings with mathematics. While it reuses some personal relationships from the first book and makes a few references to the villains, it's a disconnected story. It would be possible to start here if you wanted to. Cas is now in the strange and unexpected situation of having friends, and they're starting to complicate her life. First, Arthur has managed to trigger some unexpected storehouse of morals and gotten her to try to stop killing people on jobs. That conscience may have something to do with her willingness to take a job from an apparently crazy man who claims a corporation has stolen his daughter, a daughter who appears nowhere in any official records. And when her other friend, Checker, gets in trouble with the mob, Cas tries to protect him in her own inimitable way, which poses a serious risk of shortening her lifespan. Even more than the first book, the story in Half Life is a mix of the slightly ridiculous world of superheroes with gritty (and bloody) danger. It featuring hit men, armed guards, lots of guns, and quite a lot of physical injury and blood. A nasty corporation that's obviously hiding serious secrets shares pages with the matriarch of a mob family who considers Checker sleeping with her daughter to be an abuse of her honor. The story eventually escalates into more outlandish bits of technology, an uncanny little girl, and a plot that would feel at home in a Batman comic. I like books that don't take themselves too seriously, but the contrast between the brutal treatment Cas struggles through and the outrageous mad scientist villain provokes a bit of cognitive whiplash. That said, the villains of Half Life are neither as freakish nor as disturbing as those in Zero Sum Game, which I appreciated. Huang packs in several plot twists, some inobvious decisions and disagreements between Russell and her friends about appropriate strategy, and Cas's discovery that there are certain things she cares very strongly about other than money and having jobs. Cas goes from a barely moral, very dark hero in the first book to something closer to a very grumbly chaotic good who insists she's not as good as she actually is. It's a standard character type, but Huang does a good job with it. Huang also adds a couple of supporting cast members in this book that I hope will stick around. Pilar starts as a receptionist at one of the companies Cas breaks into, and at first seems like she might be comic relief. But she ends up being considerably more competent than she first appears (or that she seems to realize); by the end of the book, I had a lot of respect for her. And Miri makes only a few appearances, but her unflappable attitude is a delight. I hope to see more of her. The biggest drawback to this book for me is that Cas gets hurt a lot. At times, the story falls into one of the patterns of urban fantasy: the protagonist gets repeatedly beaten up and abused until they figure out what's going on, and spends most of the story up against impossible odds and feeling helpless. That's not a plot pattern I'm fond of. I don't enjoy reading about physical pain, and I had trouble at some points in the story with the constant feeling of dread. Parts of the book I read in short bursts, putting it aside to look at something else. But the sense of dread falls off towards the end of the book, as Cas figures out what's actually going on, and none of it is as horrible as it felt it could be. If you have a similar problem with some urban fantasy tropes, I think it's safe to stick with the story. This was a fun story, but it doesn't develop much in the way of deeper themes in the series. There's essentially no Rio, no further discoveries about the villains of the first book, and no further details on what makes Cas tick or why she seems to be the only, or at least one of the few, super-powered people in this world. The advance publicity for the third book seems to indicate that's coming next. I'm curious enough now that I'll keep reading this series. Recommended if you liked the first book. Half Life is very similar, but I think slightly better. Followed by Root of Unity. Rating: 7 out of 10

I have a Dell E7240. I m pretty happy with it - my main complaint is that it has a very shiny screen, and that seems to be because it s the touchscreen variant. While I don t care about that feature I do care about the fact it means I get FullHD in 12.5 Anyway. I ve had issues with using a dock and an external monitor with the laptop for some time, including getting so far as mentioning the problems on the appropriate bug tracker. I ve also had discussions with a friend who has the same laptop with the same issues, and has some time trying to get it reliably work. However up until this week I haven t had a desk I m sitting at for any length of time to use the laptop, so it s always been low priority for me. Today I sat down to try and figure out if there had been any improvement. Firstly I knew the dock wasn t at fault. A Dell E6330 works just fine with multiple monitors on the same dock. The E6330 is Ivybridge, while the E7240 is Haswell, so I thought potentially there might be an issue going on there. Further digging revealed another wrinkle I hadn t previously been aware of; there is a DisplayPort Multi-Stream Transport (MST) hub in play, in particular a Synaptics VMM2320. Dell have a knowledge base article about Multiple external display issues when docked with a Latitude E7440/E7240 which suggests a BIOS update (I was already on A15) and a firmware update for the MST HUB. Sadly the firmware update is Windows only, so I had to do a suitable dance to be able to try and run it. I then discovered that the A05 update refused to work, complaining I had an invalid product ID. The A04 update did the same. The A01 update thankfully succeeded and told me it was upgrading from 2.00.002 to 2.15.000. After that had completed (and I d power cycled to switch to the new firmware) I tried A05 again and this time it worked and upgraded me to 2.22.000. Booting up Linux again I got further than before; it was definitely detecting that there was a monitor but it was very unhappy with lots of [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up errors being logged. This was with 4.2, and as I d been meaning to try 4.3-rc2 I thought this was a good time to give it a try. Lo and behold, it worked! Even docking and undocking does what I d expect, with the extra monitor appearing / disappearing as you d expect. Now, I m not going to assume this means it s all happy, as I ve seen this sort-of work in the past, but the clue about MST, the upgrade of that firmware (and noticing that it made things better under Windows as well) and the fact that there have been improvements in the kernel s MST support according to the post 4.2 log gives me some hope that things will be better from here on.

What happened in the reproducible builds effort this week: Media coverage Nathan Willis covered our DebConf15 status update in Linux Weekly News. Access to non-LWN subscribers will be given on Thursday 24th. Linux Journal published a more general piece last Tuesday. Unexpected praise for reproducible builds appeared this week in the form of several iOS applications identified as including spyware. The malware was undetected by Apple screening. This actually happened because application developers had simply downloaded a trojaned version of XCode through an unofficial source. While reproducible builds can't really help users of non-free software, this is exactly the kind of attacks that we are trying to prevent in our systems. Toolchain fixes

• Mathieu Malaterre uploaded abi-compliance-checker/1.99.11-1 which drops the timestamps from the generated HTML reports and makes the generated .abi.tar.gz files reproducible. Original patches by Chris Lamb.

Niko Tyni wrote and uploaded a better patch for the source order problem in libmodule-build-perl. Tristan Seligmann identified how the code generated by python-cffi could be emitted in random order in some cases. Upstream has already fixed the problem. Packages fixed The following 24 packages became reproducible due to changes in their build dependencies: apache-curator, checkbox-ng, gant, gnome-clocks, hawtjni, jackrabbit, jersey1, libjsr305-java, mathjax-docs, mlpy, moap, octave-geometry, paste, pdf.js, pyinotify, pytango, python-asyncssh, python-mock, python-openid, python-repoze.who, shadow, swift, tcpwatch-httpproxy, transfig. The following packages became reproducible after getting fixed:

• apparmor/2.10-2 uploaded by intrigeri, fixed upstream by Christian Boltz, with the same change suggested by Reiner Herrmann.
• ardour/1:4.2~dfsg-2 by IOhannes m zm lnig.
• dcmtk/3.6.1~20150629-1 uploaded by Andreas Tille, original patch by akira.
• deap/1.0.1-4 by Daniel Stender.
• firebird2.5/2.5.4.26856.ds4-2 by Damyan Ivanov.
• gamera/3.4.2+svn1437-1 by Daniel Stender.
• genometools/1.5.7-1 by Sascha Steinbiss.
• golang-github-go-xorm-core/0.4.4-1 by Alexandre Viau.
• klibc/2.0.4-4 by Ben Hutchings.
• libgtk2-perl/2:1.2496-3 by intrigeri.
• lsof/4.89+dfsg-0.1 uploaded by Laurent Bigonville, original patch by Lunar.
• monotone/1.1-6 by Markus Wanner.
• ndisc6/1.0.1-4 by Santiago Vila.
• privoxy/3.0.23-4 by Roland Rosenfeld.
• ruby-flexmock/2.0.0~rc1-1 by Antonio Terceiro.
• ruby-html2haml/2.0.0-1 by Lunar.
• tunnelx/20140102-3 uploaded by Wookey, original patch by Chris Lamb.
• wtforms/2.0.2-1 by Orestis Ioannou, original patch by Juan Picca.

Some uploads fixed some reproducibility issues but not all of them:

• maxima/5.37-1 by Camm Maguire, report by akira.

Patches submitted which have not made their way to the archive yet:

• #783152 on kmod by Lunar: export SOURCE_DATE_EPOCH in debian/rules.
• #799010 on 389-ds-base by Chris Lamb: use SOURCE_DATE_EPOCH value as the build date.
• #799206 on python-sqlalchemy-utils by Chris Lamb: sort the list of extra requirement.
• #799330 on cappuccino by Chris Lamb: pass a fixed seed to polygen.
• #799410 on segment by Chris Lamb: use date of the latest debian/changelog entry as build date.

reproducible.debian.net Tests for Coreboot, OpenWrt, NetBSD, and FreeBSD now runs weekly (instead of monthly). diffoscope development Python 3 offers new features (namely yield from and concurrent.futures) that could help implement parallel processing. The clear separation of bytes and unicode strings is also likely to reduce encoding related issues. Mattia Rizolo thus kicked the effort of porting diffoscope to Python 3. tlsh was the only dependency missing a Python 3 module. This got quickly fixed by a new upload. The rest of the code has been moved to the point where only incompatibilities between Python 2.7 and Pyhon 3.4 had to be changed. The commit stream still require some cleanups but all tests are now passing under Python 3. Documentation update The documentation on how to assemble the weekly reports has been updated. (Lunar) The example on how to use SOURCE_DATE_EPOCH with CMake has been improved. (Ben Beockel, Daniel Kahn Gillmor) The solution for timestamps in man pages generated by Sphinx now uses SOURCE_DATE_EPOCH. (Mattia Rizzolo) Package reviews 45 reviews have been removed, 141 added and 62 updated this week. 67 new FTBFS reports have been filled by Chris Lamb, Niko Tyni, and Lisandro Dami n Nicanor P rez Meyer. New issues added this week: randomness_in_r_rdb_rds_databases, python-ply_compiled_parse_tables. Misc. The prebuilder script is now properly testing umask variations again. Santiago Villa started a discussion on debian-devel on how binNMUs would work for reproducible builds.

In order to automatically update my monitor setup and activate/deactivate my external monitor when plugging my ThinkPad into its dock, I found a way to hook into the ACPI events and run arbitrary scripts. This was tested on a T420 with a ThinkPad Dock Series 3 as well as a T440p with a ThinkPad Ultra Dock. The only requirement is the ThinkPad ACPI kernel module which you can find in the tp-smapi-dkms package in Debian. That's what generates the ibm/hotkey events we will listen for.

Hooking into the events Create the following ACPI event scripts as suggested in this guide. Firstly, /etc/acpi/events/thinkpad-dock:

event=ibm/hotkey LEN0068:00 00000080 00004010
action=su francois -c "/home/francois/bin/external-monitor dock"

Secondly, /etc/acpi/events/thinkpad-undock:

event=ibm/hotkey LEN0068:00 00000080 00004011
action=su francois -c "/home/francois/bin/external-monitor undock"

then restart udev:

sudo service udev restart

Finding the right events To make sure the events are the right ones, lift them off of:

sudo acpi_listen

and ensure that your script is actually running by adding:

logger "ACPI event: $*"

at the begininng of it and then looking in /var/log/syslog for this lines like:

logger: external-monitor undock
logger: external-monitor dock

If that doesn't work for some reason, try using an ACPI event script like this:

event=ibm/hotkey
action=logger %e

to see which event you should hook into.

Using xrandr inside an ACPI event script Because the script will be running outside of your user session, the xrandr calls must explicitly set the display variable (-d). This is what I used:

#!/bin/sh
logger "ACPI event: $*"
xrandr -d :0.0 --output DP2 --auto
xrandr -d :0.0 --output eDP1 --auto
xrandr -d :0.0 --output DP2 --left-of eDP1

Review: Magic's Promise, by Mercedes Lackey

Series:	Last Herald Mage #2
Publisher:	DAW
Copyright:	January 1990
ISBN:	0-88677-401-2
Format:	Mass market
Pages:	320

Magic's Promise is the second book of the Last Herald Mage trilogy and a sequel to Magic's Pawn. As tempting as it is to skip the first book, which isn't very good, I think you'd miss a lot of the emotional dynamics between Vanyel and his family if you didn't read it. Magic's Promise opens years after the end of Magic's Pawn. Vanyel has become the most powerful Herald-mage of the kingdom, which is lucky for the kingdom because it's beset on all sides by magical attack. Heralds are being killed, countries on the border are looking for opportunities to spring, and Vanyel is being run ragged. Ragged enough that he's worried he's going to hurt someone by mistake when surprised. It's time for a desperately-needed vacation. Unfortunately for his ability to relax, that vacation means going home to visit his parents, who have never understood him and who disapprove strongly of his sexuality. (Not that he's actually had a lover in years.) It also means being in the same household as the armsmaster who broke his wrist as a child, and his father's deeply disapproving priest. And the border near his parents' lands may be heating up as well. Magic's Promise is the book where this trilogy hits its stride. After the events of the previous book, Vanyel is ridiculously overpowered and will be for the rest of the trilogy, but the problems in this book aren't the sort that raw power can fix. (That's a balance Lackey handles well in general.) There are a few places where Vanyel can simply overpower his problems, but the heart of the plot is a mystery that requires analysis, investigation, and a bit of undercover snooping. I enjoyed the defense of the kingdom plot (more than I had remembered, in fact), but the heart of this book is Vanyel and his family coming to terms with each other. Vanyel is a lot older and more confident than he was in the first book, and his service to the kingdom forces some grudging respect. But the way that grudging respect turns into real affection over the course of this book is a delight to read. This degree of reconciliation is wish-fulfillment most of the Valdemar series is heavy on wish-fulfillment but it's the sort of wish-fulfillment that matches the way that you wish the world would work. People figure out that they've been ignorant and cruel and actually change, and Vanyel learns some important lessons about giving people room to change. I particularly liked that the growth of respect wasn't one-sided. Most of the movement comes (and has to come) from Vanyel's family, but Vanyel gains some new-found appreciation and empathy for some strengths that he'd previously been blind to. Lackey's writing is still not the best here. There's something a bit awkward about the dialogue patterns in places, one gets a bit tired of the repetitive narrative focus on Vanyel's exhaustion, and the sentence-level construction of the story is more workable than delightful. You have to be invested in the characters; the beauty of the writing itself isn't going to win you over. As with a lot of Lackey's writing, I think your enjoyment will depend greatly on whether she happens to hit your emotional buttons. But the story she tells here, of people finding the inner goodness in each other and healing over past wounds, is one that I very much enjoy reading. I think this is the third time I read this book, and it's the first of the Valdemar series in this re-read that held up to my memory. So far, it's the best of the series. Followed by Magic's Price. Rating: 8 out of 10

Two helpful CMS commands to know if the users on the z/VM host you connect to are managed using DIRMAINT:

• DIRMAINT PW: This will ask you for your current password and then for the new one. This way you can change your own user password instead of having to ask the administrator for it.
• DIRMAINT REVIEW: If you want to see the directory entry for your user (i.e. the configuration of your VM), you can issue this command. It will put the directory onto the card stack, from which you can retrieve it onto your A disk using RETRIEVE <number> <USERNAME> DIRECT A. The number is listed after RDR FILE in CP's output.

Review: Magic's Pawn, by Mercedes Lackey

Series:	Last Herald Mage #1
Publisher:	DAW
Copyright:	June 1989
ISBN:	0-88677-352-0
Format:	Mass market
Pages:	349

Continuing my (very slow) re-read of Mercedes Lackey's Valdemar series. I've read all these books before (this series several times, in fact), but long before I started writing reviews. Vanyel is a legendary hero by the time of Talia (the hero of the first Valdemar series, starting with Arrows of the Queen). Talia was reading stories about him at the start of her story: the mage Herald who defended Valdemar against its enemies in the distant past. This is the first book of the trilogy that tells his story, starting (as Lackey's books often do) from rather inauspicious beginnings. Vanyel is the son of a border lord, and about as poorly suited for it as possible. He's small, pretty, entirely uninterested in the hammer-and-tongs sword fighting the arms master wants to teach him, and also gay, not that he has any idea that's even something that exists and has a name. His only ally was his sister, who is now off serving in Valdemar's military. Most of his life is spent hiding, feeling utterly lost and out of place, and wishing he could be a Bard. This is a Valdemar story, so if you're familiar with the series, you know what's coming next. What might come as a surprise is that "next" is quite some time into the story. Vanyel does not get rescued from his situation by a Companion. Instead, his father decides to exile him to the capital under the care of his aunt, who he's only met once and who didn't think highly of him. He expects to be even more miserable, and shuts emotionally down in anticipation. This is one of those books that I remembered as being better than it actually was, and one of the reasons why I enjoyed it less than I expected is that far too much of this book is devoted to describing Vanyel's mental state. This usually involves various elaborate emo analogies (which can be a failing of this series in general), and it's quite hard to maintain sympathy for Vanyel. Lackey gets us to feel for him at the start of the book, when he's really in a bad situation. But once he gets to the capital, he's his own worst enemy, and it's hard to avoid the desire to shake him. I also didn't remember just how much I disliked Tylendel. I'm sure it will come as a surprise to no one that Vanyel eventually meets someone who draws him out of his shell and gives him a reason to want to live. Unfortunately, that person, despite a positive surface impression, is self-obsessed, unstable, and not above manipulating Vanyel into actions that are so obviously catastrophic that it makes one want to yell at the book. I disliked this part of the book so much that even a Companion's choosing was overshadowed. The book does get a bit better after that truly awful middle, but it never hits the emotional stride that other Valdemar books hit. Lackey does introduce the Tayledras, which will be hugely important in later books in this series (and who are some of my favorite characters), but there too I prefer their later appearances. Vanyel's inability to see a good thing when it hits him in the face, punctuated by being occasionally cruel to the people who try to help him, makes it quite hard to enjoy his slow path to becoming a better person. I remember really liking this trilogy, so I think it gets better. But I also remembered liking Vanyel's claiming, and it didn't do much for me on a re-read. I can only recommend this one as a necessary preface to the later books in the trilogy, and expect to need a high tolerance for constant woe-is-me despair. Followed by Magic's Promise. Rating: 5 out of 10

Review: The Three-Body Problem, by Cixin Liu & Ken Liu

Series:	Three-Body Problem #1
Author:	Liu Cixin ( )
Translator:	Ken Liu
Publisher:	Tor
Copyright:	2006, 2014
Printing:	November 2014
ISBN:	1-4668-5344-1
Format:	Kindle
Pages:	399

Liu Cixin ( ) is one of the best-known and most popular SF authors in China, but, due to the paucity of translated SF in the English-speaking world, was largely unknown to English-speaking SF readers. That made this translation by Ken Liu (no relation) highly anticipated: a window into a large world of SF by authors most of us have never read. And Ken Liu is an excellent writer in his own right (see, for instance, "The Literomancer" or "Altogether Elsewhere, Vast Herds of Reindeer"), which was a hopeful sign for a good translation. Indeed, the translation is very good. One can tell that the book comes from a different literary tradition, but primarily from unusual (to US readers, at least) emotional focal points for the characters and lots of Chinese history that the author feels little need to explain. (Ken Liu adds translator notes for the bits most likely to lose non-Chinese audiences.) I found the characters a bit odd and occasionally hard to identify with, but I didn't mind: it added to the feeling of exploring a slightly different literary tradition with different character conventions. Unfortunately, the end of the book went entirely off the rails, at least for me. The Three-Body Problem opens during the Cultural Revolution, with the murder of Ye Wenjie's father, a physics professor, and the suicide of her advisor and friend. Two years later, she's at a work camp in inner Mongolia, cutting trees, numb, keeping her head down. But a traveling journalist smuggles in a secret copy of Silent Spring and gives it to her. The book both hardens her own belief in the evil of humanity and gets her into deeper trouble when she agrees to recopy a draft of a letter to the central leadership about the environmental devastation caused by the logging. Ye Wenjie is forced to choose permanent exile to an experimental radar facility on a remote mountain in Mongolia. Ye Wenjie is vital to the slowly-developing plot of the book, but this is the last the reader sees of her for some time. Part II jumps to present time and to a different protagonist: Wang Miao, a distinguished nanotechnology researcher who is recruited by the PLA and the police into a secret war room. Distinguished scientists are killing themselves in frighteningly large numbers, including one that Wang Miao had a crush on. She left a suicide note before overdosing on sleeping pills, one that says only, cryptically, that physics doesn't exist. The government is desperate to figure out what's going on. The "radar" facility and the suicide of scientists are linked, of course, but it takes much of the book for Wang Miao and his colleagues to piece together how. Key clues come in the form of an odd puzzle virtual reality MMORPG that becomes a popular sensation. In it, players find themselves on an alien world whose suns rise and set at strange and unpredictable intervals: sometimes far too far away and horribly cold, sometimes far too close and destructively hot, and sometimes not seen for long periods of time. The players can somehow dehydrate themselves and the rest of the population to weather the worst seasons, but life is a constant struggle against apparently unpredictable elements. Despite that, players slowly find ways to build civilizations and attempt to predict the strange cycles of heat and cold. It takes the characters a long time to understand what's happening. Readers will probably be much faster, since they have out-of-band information the characters don't. At first, this game seems entirely unrelated to the suicides of the scientists or, for that matter, to Ye Wenjie, who is easy to almost forget. But they all weave together in a way that's almost compelling. I say almost because the motivations of the characters are quite tangled and interesting, but the science is... awful. Those who have read my other book reviews know that I don't insist on hard science in my SF. Usually I'm willing to roll with it, and I can read past even obvious scientific nonsense. But science is critical to the plot of this book; some very specific actions, with a detailed in-book scientific justifications, are the underpinning of the entire plot. And they make utter nonsense of physics. I've rarely had science in a novel destroy my suspension of disbelief this thoroughly. Physics isn't even alone: biology, chemistry, computing, and astronomy are all in for it as Liu reveals the causes of the book's events. I wanted to be engaged by the conflict of ethics and philosophy that drive the plot, and some of that conflict is quite interesting. But every other page would have another colossal pile of scientific nonsense that would throw me out of the book again, usually in the service of a set piece that missed grand and landed on absurdly silly. Be warned that this book also ends on a bit of a cliff-hanger, and there are two more books in the series. The second has been released in a translated edition, but with a different translator, which is disappointing (Ken Liu did an excellent job); the third isn't out yet. If you can get past the awful science, The Three-Body Problem is doing some interesting things. The characters are a bit wooden and forgettable, but the philosophical problems they encounter are ones I don't see often in western SF. This a refreshing change, and I'm interested enough that I'm still considering picking up the sequels. But the science hurts the book so badly. Followed by The Dark Forest. Rating: 6 out of 10

Key signing parties are a pain and hopefully, one day, we will have better ways to authentication keys than reading hexadecimal strings out loud. The Zimmermann Sassaman key-signing protocol makes them much more bearable already by having only one single hexadecimal string read out loud. That string is the cryptographic hash of a document given to every participant listing all participants and their fingerprints. If everyone has the same hash, then we assume that everyone has the same document. Then, participants in turn will confirm that they fully recognize the fingerprint listed in the document. Alexander Wirt wrote a small key server dedicated to receive keys from the participants. There is also a script that will generate the document from the submitted keys and a ready-to-use keyring. The latter can be run automatically using inoticoming when a new key arrives. Finally, it would be nice if participants could confirm that their key has been properly added to the document, e.g. by making the list available on a web server. Setting all this up seemed like a good opportunity to play with Tor hidden services and systemd-nspawn. Here's the setup log with some comments. This was done on a small armhf device with Debian Jessie. Create a new hidden service Edit /etc/tor/torrc on the host to setup the hidden service:

HiddenServiceDir /var/lib/tor/ksp/
HiddenServicePort 80 10.0.0.2:80
HiddenServicePort 11371 10.0.0.2:11371

Run:

host# systemctl reload tor.service

Then, to learn the name of the newly created hidden service name:

host# cat /var/lib/tor/ksp/hostname
ksp123456789abcd.onion

Install the container debootstrap as always:

host# debootstrap --variant=minbase jessie /var/lib/container/ksp

Preliminary container configuration We do the following step simply using chroot as we are going to use the host network configuration for this stage. The container itself will not have access to the Internet.

host# chroot ksp

Let's set the hostname:

ksp-chroot# echo 'ksp' > /etc/hostname

Set up APT:

ksp-chroot# echo 'deb http://httpredir.debian.org/debian jessie main' > /etc/apt/sources.list
ksp-chroot# apt update

We need dbus to get systemd to work well:

ksp-chroot# apt-get install dbus

Make sure that we can resolve our own hostname:

ksp-chroot# apt-get install libnss-myhostname
ksp-chroot# sed -e '/^hosts:/s/files/myhostname \0/' -i /etc/nsswitch.conf

These are dependencies of the keyserver:

ksp-chroot# apt-get install --no-install-recommends libhttp-daemon-perl \
                liblog-loglite-perl libproc-reliable-perl

These ones are needed for the script generating the list:

ksp-chroot# apt-get install bzip2 inoticoming

And we will use the smallest HTTP server available:

ksp-chroot# apt-get install netcat-traditional micro-httpd

Finally, let's unconfigure all DNS resolvers:

ksp-chroot# echo > /etc/resolv.conf

And we are done with the chroot:

ksp-chroot# exit

Let's retrieve the ksp-tools repository now:

host# cd /var/lib/container/srv
host# git clone https://github.com/formorer/ksp-tools

Container setup We will now start the container with a shell to configure it:

host# systemd-nspawn -D ksp --network-veth

Let's ask systemd to configure the network for us:

ksp# systemctl enable systemd-networkd

Let's not forget to set a root password:

ksp# passwd

We add a dedicated user to run the keyserver and the list generation script:

ksp# adduser --system --group --disabled-password --disabled-login --home /var/lib/ksp ksp

Let's configure the keyserver:

ksp# cp /srv/ksp-tools/keyserver.conf /var/lib/ksp/keyserver.conf

Let's edit /var/lib/ksp/keyserver.conf:

homedir = /var/lib/ksp

Now create the GnuPG homedir for the keyserve:

ksp# mkdir /var/lib/ksp/keys
ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/gpg

Copy the template list generator:

ksp# cp -r /srv/ksp-tools/example /var/lib/ksp/keys/ksp123456789abcd_onion

Create the key repository:

ksp# install -d -o ksp -g ksp -m 0700 /var/lib/ksp/keys/ksp123456789abcd_onion/keys

Create a directory accessible to the web server where the participant list will be generated:

ksp# mkdir -p /var/www
ksp# install -d -o ksp -g ksp -m 0755 /var/www/keys

Let's configure the list generation script by editing /var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars:

KS=ksp123456789abcd.onion
export GNUPGHOME=/tmp/ksp-gpg
KSPFILE="/var/www/keys/ksp-event.txt"

Don't forget to adjust the header in /var/lib/ksp/keys/ksp123456789abcd_onion/conf/list-header. Now we create a unit file for the keyserver in /etc/systemd/system/keyserver.service:

[Unit]
Description=Key signing party keyserver
[Service]
Type=simple
Environment="KSP_HOMEDIR=/var/lib/ksp"
ExecStart=/srv/ksp-tools/bin/kspkeyserver.pl --nodaemonize
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/ksp
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target

Another unit for the list generator as /etc/systemd/system/ksp-list-generator.service:

[Unit]
Description=Key signing party list generator
[Service]
Type=simple
EnvironmentFile=/var/lib/ksp/keys/ksp123456789abcd_onion/conf/vars
ExecStart=/usr/bin/inoticoming --foreground /var/lib/ksp/keys/ksp123456789abcd_onion/keys --chdir /var/lib/ksp/keys/ksp123456789abcd_onion bin/generate-list \;
User=ksp
Group=ksp
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=/var/www/keys
CapabilityBoundingSet=
[Install]
WantedBy=multi-user.target

For the web server, we first configure a socket listening on port 80 in /etc/systemd/system/micro-httpd.socket:

[Unit]
Description=micro-httpd socket
[Socket]
ListenStream=80
Accept=yes
[Install]
WantedBy=sockets.target

And then the web server in /etc/systemd/system/micro-httpd@.service:

[Unit]
Description=micro-httpd server
[Service]
ExecStart=-/usr/sbin/micro-httpd /var/www/ksp
StandardInput=socket
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
CapabilityBoundingSet=

Let's now ask systemd to start all of these at boot time:

ksp# systemctl daemon-reload
ksp# systemctl enable keyserver.service
ksp# systemctl enable ksp-list-generator.service
ksp# systemctl enable micro-httpd.socket

One way to kill the container is to type Control+] three times. Boot the container Let's get this party started!

host# systemd-nspawn -b -D /var/lib/container/ksp --network-veth

Hopefully, things should work now. Participants to the KSP should then be able to send their key with:

$ torsocks gpg --keyserver ksp123456789abcd.onion --send-key $KEYID

(Sadly, this is broken with GnuPG 2.1 at the moment.) The participant list should be available at http://ksp123456789abcd.onion/ksp-event.txt. Final steps We need to tell systemd to start the container started at boot time:

host# systemctl enable systemd-nspawn@ksp.service

But the default command-line will not use a dedicated network, so we need to override that part of the configuration. First create a directory:

host# mkdir /etc/systemd/system/systemd-nspawn@ksp.service.d

And edit /etc/systemd/system/systemd-nspawn@ksp.service.d/use-network-veth.conf:

[Service]
# The empty line because we want to override all previous ExecStart
# and not add an extra command
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --directory=/var/lib/container/%i --network-veth

Let's reload systemd and verify that our snippet is there:

host# systemctl daemon-reload
host# systemctl cat systemd-nspawn@ksp.service

All good? Let's start it:

host# systemctl start systemd-nspawn@ksp.service

One should also add a firewall to disallow any outgoing connections from the ve-ksp interface as an extra protection.

A few days ago, the French equivalent of Hacker News, called "Le Journal du Hacker", interviewed me about my work on OpenStack, my job at Red Hat and my self-published book The Hacker's Guide to Python. I've spent some time translating it into English so you can read it if you don't understand French! I hope you'll enjoy it.

Hi Julien, and thanks for participating in this interview for the Journal du Hacker. For our readers who don't know you, can you introduce you briefly?

You're welcome! My name is Julien, I'm 31 years old, and I live in Paris. I now have been developing free software for around fifteen years. I had the pleasure to work (among other things) on Debian, Emacs and awesome these last years, and more recently on OpenStack. Since a few months now, I work at Red Hat, as a Principal Software Engineer on OpenStack. I am in charge of doing upstream development for that cloud-computing platform, mainly around the Ceilometer, Aodh and Gnocchi projects.

Being myself a system architect, I follow your work in OpenStack since a while. It's uncommon to have the point of view of someone as implied as you are. Can you give us a summary of the state of the project, and then detail your activities in this project?

The OpenStack project has grown and changed a lot since I started 4 years ago. It started as a few projects providing the basics, like Nova (compute), Swift (object storage), Cinder (volume), Keystone (identity) or even Neutron (network) who are basis for a cloud-computing platform, and finally became composed of a lot more projects. For a while, the inclusion of projects was the subject of a strict review from the technical committee. But since a few months, the rules have been relaxed, and we see a lot more projects connected to cloud-computing joining us. As far as I'm concerned, I've started with a few others people the Ceilometer project in 2012, devoted to handling metrics of OpenStack platforms. Our goal is to be able to collect all the metrics and record them to analyze them later. We also have a module providing the ability to trigger actions on threshold crossing (alarm). The project grew in a monolithic way, and in a linear way for the number of contributors, during the first two years. I was the PTL (Project Technical Leader) for a year. This leader position asks for a lot of time for bureaucratic things and people management, so I decided to leave my spot in order to be able to spend more time solving the technical challenges that Ceilometer offered. I've started the Gnocchi project in 2014. The first stable version (1.0.0) was released a few months ago. It's a timeseries database offering a REST API and a strong ability to scale. It was a necessary development to solve the problems tied to the large amount of metrics created by a cloud-computing platform, where tens of thousands of virtual machines have to be metered as often as possible. This project works as a standalone deployment or with the rest of OpenStack. More recently, I've started Aodh, the result of moving out the code and features of Ceilometer related to threshold action triggering (alarming). That's the logical suite to what we started with Gnocchi. It means Ceilometer is to be split into independent modules that can work together with or without OpenStack. It seems to me that the features provided by Ceilometer, Aodh and Gnocchi can also be interesting for operators running more classical infrastructures. That's why I've pushed the projects into that direction, and also to have a more service-oriented architecture (SOA)

I'd like to stop for a moment on Ceilometer. I think that this solution was very expected, especially by the cloud-computing providers using OpenStack for billing resources sold to their customers. I remember reading a blog post where you were talking about the high-speed construction of this brick, and features that were not supposed to be there. Nowadays, with Gnocchi and Aodh, what is the quality of the brick Ceilometer and the programs it relies on?

Indeed, one of the first use-case for Ceilometer was tied to the ability to get metrics to feed a billing tool. That's now a reached goal since we have billing tools for OpenStack using Ceilometer, such as CloudKitty. However, other use-cases appeared rapidly, such as the ability to trigger alarms. This feature was necessary, for example, to implement the auto-scaling feature that Heat needed. At the time, for technical and political reasons, it was not possible to implement this feature in a new project, and the functionality ended up in Ceilometer, since it was using the metrics collected and stored by Ceilometer itself. Though, like I said, this feature is now in its own project, Aodh. The alarm feature is used since a few cycles in production, and the Aodh project brings new features on the table. It allows to trigger threshold actions and is one of the few solutions able to work at high scale with several thousands of alarms. It's impossible to make Nagios run with millions of instances to fetch metrics and triggers alarms. Ceilometer and Aodh can do that easily on a few tens of nodes automatically. On the other side, Ceilometer has been for a long time painted as slow and complicated to use, because its metrics storage system was by default using MongoDB. Clearly, the data structure model picked was not optimal for what the users were doing with the data. That's why I started Gnocchi last year, which is perfectly designed for this use case. It allows linear access time to metrics (O(1) complexity) and fast access time to the resources data via an index. Today, with 3 projects having their own perimeter of features defined and which can work together Ceilometer, Aodh and Gnocchi finally erased the biggest problems and defects of the initial project.

To end with OpenStack, one last question. You're a Python developer for a long time and a fervent user of software testing and test-driven development. Several of your blogs posts point how important their usage are. Can you tell us more about the usage of tests in OpenStack, and the test prerequisites to contribute to OpenStack?

I don't know any project that is as tested on every layer as OpenStack is. At the start of the project, there was a vague test coverage, made of a few unit tests. For each release, a bunch of new features were provided, and you had to keep your fingers crossed to have them working. That's already almost unacceptable. But the big issue was that there was also a lot of regressions, et things that were working were not anymore. It was often corner cases that developers forgot about that stopped working. Then the project decided to change its policy and started to refuse all patches new features or bug fix that would not implement a minimal set of unit tests, proving the patch would work. Quickly, regressions were history, and the number of bugs largely reduced months after months. Then came the functional tests, with the Tempest project, which runs a test battery on a complete OpenStack deployment. OpenStack now possesses a complete test infrastructure, with operators hired full-time to maintain them. The developers have to write the test, and the operators maintain an architecture based on Gerrit, Zuul, and Jenkins, which runs the test battery of each project for each patch sent. Indeed, for each version of a patch sent, a full OpenStack is deployed into a virtual machine, and a battery of thousands of unit and functional tests is run to check that no regressions are possible. To contribute to OpenStack, you need to know how to write a unit test the policy on functional tests is laxer. The tools used are standard Python tools, unittest for the framework and tox to run a virtual environment (venv) and run them. It's also possible to use DevStack to deploy an OpenStack platform on a virtual machine and run functional tests. However, since the project infrastructure also do that when a patch is submitted, it's not mandatory to do that yourself locally.

The tools and tests you write for OpenStack are written in Python, a language which is very popular today. You seem to like it more than you have to, since you wrote a book about it, The Hacker's Guide to Python, that I really enjoyed. Can you explain what brought you to Python, the main strong points you attribute to this language (quickly) and how you went from developer to author?

I stumbled upon Python by chance, around 2005. I don't remember how I hear about it, but I bought a first book to discover it and started toying with that language. At that time, I didn't find any project to contribute to or to start. My first project with Python was rebuildd for Debian in 2007, a bit later. I like Python for its simplicity, its object orientation rather clean, its easiness to be deployed and its rich open source ecosystem. Once you get the basics, it's very easy to evolve and to use it for anything, because the ecosystem makes it easy to find libraries to solve any kind of problem. I became an author by chance, writing blog posts from time to time about Python. I finally realized that after a few years studying Python internals (CPython), I learned a lot of things. While writing a post about the differences between method types in Python which is still one of the most read post on my blog I realized that a lot of things that seemed obvious to me where not for other developers. I wrote that initial post after thousands of hours spent doing code reviews on OpenStack. I, therefore, decided to note all the developers pain points and to write a book about that. A compilation of what years of experience taught me and taught to the other developers I decided to interview in the book.

I've been very interested by the publication of your book, for the subject itself, but also the process you chose. You self-published the book, which seems very relevant nowadays. Is that a choice from the start? Did you look for an editor? Can you tell use more about that?

I've been lucky to find out about others self-published authors, such as Nathan Barry who even wrote a book on that subject, called Authority. That's what convinced me it was possible and gave me hints for that project. I've started to write in August 2013, and I ran the firs interviews with other developers at that time. I started to write the table of contents and then filled the pages with what I knew and what I wanted to share. I manage to finish the book around January 2014. The proof-reading took more time than I expected, so the book was only released in March 2014. I wrote a complete report on that on my blog, where I explain the full process in detail, from writing to launching. I did not look for editors though I've been proposed some. The idea of self-publishing really convince me, so I decided to go on my own, and I have no regret. It's true that you have to wear two hats at the same time and handle a lot more things, but with a minimal audience and some help from the Internet, anything's possible! I've been reached by two editors since then, a Chinese and Korean one. I gave them rights to translate and publish the books in their countries, so you can buy the Chinese and Korean version of the first edition of the book out there. Seeing how successful it was, I decided to launch a second edition in Mai 2015, and it's likely that a third edition will be released in 2016.

Nowadays, you work for Red Hat, a company that represents the success of using Free Software as a commercial business model. This company fascinates a lot in our community. What can you say about your employer from your point of view?

It only has been a year since I joined Red Hat (when they bought eNovance), so my experience is quite recent. Though, Red Hat is really a special company on every level. It's hard to see from the outside how open it is, and how it works. It's really close to and it really looks like an open source project. For more details, you should read The Open Organization, a book wrote by Jim Whitehurst (CEO of Red Hat), which he just published. It describes perfectly how Red Hat works. To summarize, meritocracy and the lack of organization in silos is what makes Red Hat a strong organization and puts them as one of the most innovative company. In the end, I'm lucky enough to be autonomous for the project I work on with my team around OpenStack, and I can spend 100% working upstream and enhance the Python ecosystem.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In August, 71.50 work hours have been dispatched among 7 paid contributors. Their reports are available:

• Ben Hutchings did 15 hours.
• Guido G nther did 4 hours.
• Mike Gabriel was assigned 8 hours but did not do them. He will catch up in September.
• Rapha l Hertzog did 6.5 hours.
• Santiago Ruano Rinc n did 17 hours.
• Scott Kitterman did 4 hours.
• Thorsten Alteholz did 17 hours.

Evolution of the situation September is stable compared to August (71.50 hours per month) and has not caught up back to the level of July as I hoped. Again it s because 2 sponsors were not able to pay their renewal invoice on time (one of last month paid, but another bigger sponsor failed this month). Those sponsors will continue to support us and I would like to be able to say that things will be back to normal next month, but I can t say it since we have also been informed of the (hopefully temporary) defection of another bronze sponsor that will affect us next month. Fortunately there are also good news, we have 3 new sponsors in the pipe (2 silver, 1 platinum) who shall join the project soon. And Blablacar increased their support from Silver to Gold (from 4h/month to 8h/month). But we still need more support in particular since we would like to commit to support virtualization related packages in Wheezy: that s clearly an objective for us. I recently published the summary of the work session held during DebConf 15 in Heidelberg (video recording). It would be really nice if we could get closer to the goal of funding a full-time position. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 18 packages awaiting an update (2 less than last month), the list of open vulnerabilities in Squeeze shows about 30 affected packages in total (8 more than last month). Thanks to our sponsors

• Gold sponsors:
• The Positive Internet (for 15 months already)
• Blablacar (for 14 months already)
• Linode LLC (for 4 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 15 months already)
• Domeneshop AS (for 14 months already)
• Universit Lille 3 (for 14 months already)
• Trollweb Solutions (for 12 months already)
• Gandi SAS (for 9 months already)
• University of Luxembourg (for 6 months already)
• Rentabiliweb Group (for 4 months already)
• Bronze sponsors:
• Offensive Security (for 15 months already)
• Seznam.cz, a.s. (for 15 months already)
• Evolix (for 14 months already)
• Freeside Internet Service (for 14 months already)
• MyTux (for 14 months already)
• Linuxhotel GmbH (for 12 months already)
• Intevation GmbH (for 11 months already)
• Daevel SARL (for 10 months already)
• FOSSter (for 10 months already)
• Bitfolk LTD (for 9 months already)
• Megaspace Internet Services GmbH (for 9 months already)
• Gree, Inc. (for 8 months already)
• Greenbone Networks GmbH (for 8 months already)
• NUMLOG (for 8 months already)
• WinGo AG (for 7 months already)
• Ecole Centrale de Nantes LHEEA (for 4 months already)
• Sig-I/O

No comment Liked this article? Click here. My blog is Flattr-enabled.

Usual regular update of the TeX Live packages. Now that Debian/unstable is back to full development speed thanks to the end of the bit gcc transition, probably this TeX Live update will be lost between the hundreds of others. Anyway a few interesting changes are still in there. Most importantly the fix for unicode-math that was broken for a short time, and for the Japanese users it seems that the LaTeX3 packages have gained support for upTeX. Good to hear. Of course, these are not the only updates and newcomers, see the list below. Updated packages abc, acro, alegreya, animate, arabxetex, babel-bosnian, babel-french, babel-greek, babel-latin, babel-welsh, beamer-FUBerlin, bidi, bigfoot, blochsphere, bxjscls, chemformula, chemmacros, chet, classicthesis, crossrefware, csplain, ctable, ctanify, datetime2, datetime2-basque, detlev-cm, disser, doclicense, drm, dtxgen, dtxtut, dvips, ecclesiastic, eledmac, embrac, etex-pkg, etoc, factura, fbb, fithesis, font-change, fontname, glossaries, gothic, greek-fontenc, IEEEtran, l3build, l3experimental, l3kernel, l3packages, latexconfig, lettrine, luatexja, mathastext, mcf2graph, media9, metrix, mhequ, minted, moderntimeline, newtx, ocgx2, pagecolor, pdftex, pgf, pstricks, reledmac, resphilosophica, roboto, shdoc, siunitx, suftesi, tetex, tex4ht, texlive-scripts, tikz-bayesnet, translations, ucharcat, udesoftec, ulthese, unicode-math, ut-thesis, withargs, xint. New packages checklistings, cleanthesis, easyreview, fei, medstarbeamer, mfirstuc, nevelok, old-arrows, proofread, uassign, xebaposter. Enjoy.

This was my ninth month working on Debian LTS. I was assigned 15 hours of work by Freexian's Debian LTS initiative. Front desk I spent another week in the 'front desk' role, largely overlapping with DebConf. I investigated which new CVEs affected LTS-supported packages in squeeze, recorded this in the secure-testing repository, and mailed the package maintainers to give them a chance to handle the updates. I found that one claimed security flaw in glusterfs was actually harmless for all supported Debian releases. conntrack conntrack had one new issue (CVE-2015-6496, possible remote DoS if certain kernel modules aren't loaded). I didn't find a way to reproduce it, but it still seemed to be applicable to squeeze (but for fewer protocols). I was able to backport the upstream fix without difficulty, after which I uploaded and issued DLA-295-1. DebConf I attended the LTS BoF at DebConf 15 to discuss the plans for wheezy LTS. Raphael just posted a summary of these discussions. linux-2.6 I spent some time on kernel security fixes, but haven't uploaded an update yet. That will probably come in September.

Review: Let's Pretend This Never Happened, by Jenny Lawson

Publisher:	Berkley
Copyright:	2012, 2013
Printing:	March 2013
ISBN:	0-425-26101-8
Format:	Trade paperback
Pages:	366

Let's Pretend This Never Happened, subtitled (A Mostly True Memoir), is the closest that I've ever found to the book form of a stand-up comedy routine. Lawson grew up in rural Texas with a taxidermist father, frequent contact with animals in various forms of distress, an undiagnosed anxiety disorder, and a talent for creatively freaking out about things that never occur to anyone else. But, more importantly, she has a talent for putting down on paper the random thoughts that go through her head so the rest of us can read them. Not to mention excellent comic timing and absolute mastery of the strangely relevant digression. It's always tricky to review comedy. I think tastes differ more wildly in this genre than any other. Things some people find hilarious others will find offensive or just boring. That may be particularly true of Lawson, who, similar to some of the best stand-up comics, specializes in taking off filters and saying all sorts of offensive things that people might think but not say. This kind of comedy is a knife's edge, since it can easily turn into punching down. Lawson avoids this (rather well, in my opinion) by making herself the punch line of most of the jokes. A pretty typical paragraph of the book, so that you know the sort of thing that you're in for:

The following is a series of actual events pulled form my journal that led me to believe that our home was possessed by demons and/or built over an Indian burial ground. (Also, please note that the first part of this chapter actually happens just before the previous chapter, and the last part of it happens just after it. This could be viewed as "clunky and awkward," but I prefer to think of it as "intellectually challenging and chronologically surreal. Like if Memento was a book. About dead dogs and vaginas and puppets made out of squirrel corpses." You can feel free to use that quote if you're reviewing this chapter, or if you're a student and your teacher asks you, "What was the author trying to say here?" That was it. That's what I was trying to say. That and "Use condoms if you're going to have sex, for God's sake. There are a lot of skanks out there." That's not really covered in this book, but it's still good advice.)

That has a little bit of everything this book had for me: Lawson's somewhat surreal worries, the extended digression, a rhythm that's quite compelling once you start reading it, random uncomfortable topics, and the occasional miss that I don't find funny (the last few sentences). It's all mixed together in a slightly breathless rush of narrative momentum. For more samples, Lawson's writing started as a blog and she's still actively blogging, so you can get a good advance sample by reading some of The Bloggess. Her tone there matches the book closely. What makes this book more than only comedy is that Lawson is very open about her struggles with mental illness (anxiety and depression). A lot of the humor comes from "this is the ridiculous nonsense that my brain throws out on a regular basis" and inviting you to laugh along with her, but the undertone is use of humor as a coping mechanism to deal with anxiety spirals. And alongside that coping mechanism is an open-hearted message of "you are not the only person to have completely irrational reactions to the world please laugh along with mine and feel better about yours." Due to that, the best comparison I can make to another book I've read is to Allie Brosh's Hyperbole and a Half. Brosh is more serious in places, more analytical, and a bit better at generalizing to experiences the reader can identify with. (And, of course, more graphical.) Lawson is more madcap, a bit more manic, and focused on absurd situations that don't normally happen to people. I loved this book from beginning to end, and it had me laughing out-loud in multiple places. Despite being a collection of disconnected stories, it has a rhythm and flow that kept me reading. Some books of this kind are best read in small segments with a break between, but I devoured Let's Pretend This Never Happened in large chunks (and had to be careful about reading it in public and laughing too loudly). Check first whether the sense of humor works for you, but if it does, highly recommended. Rating: 9 out of 10

Just a few days ago another great font designer has passed away, Adrian Frutiger, 24 May 1928 10 September 2015. Famous in particular for his fonts Frutiger, Avenir, and the Univers family. His fonts are used throughout the worlds for visual communication like road signs. Much has been written about him: Linotype s excellent obituary, Adam Twardoch, David Airey, New York Times article. For an interview conducted with Frutiger in 1999, see this Eye Magazine article. An interesting article on Frutiger s typefaces by Charles Bigelow.
Here I want to recall a different quality of Adrian Frutiger his interest in the visual language of symbols, their development and interaction. His book Der Mensch und seine Zeichen (Signs and Symbols) is a profound study on the development, history, and use of all kind of symbols. In this book, translated into many languages, Frutiger explores the depth and breath of symbols, but the most important part for him, easily to be seen from the German title, is the human part ( Der Mensch ). Symbols are created, changed, and used by and for humans. His studies exhibit connections between various cultures when it comes to sign usage and design.
He also explores signets as modern sign language, and their importance for visual communcation and identity building.
The book also discusses the development of the Roman alphabet, and of course passes the Univers font family.
My favorite piece is this overlay of a s from different fonts, to show that there is a common pattern in these fonts.
He concludes this book with a very wise statement:

Zum Festhalten des Gedankens, zur Vermittlung der Aussage gen gen seit langem schon die Alphabet-Zeichen nicht mehr allein. Orientierung und Kommunikation sind heute unm glich ohne Schemata, Zeichen und Signale. Der geschriebene Ausdruck wird durch die Bildvermittlung notwendig erg nzt.

SInce long the alphabet letters alone do not suffice to take hold of thoughts and to transmit statements. Nowadays, orientation and communication are impossible without schemata, signs and signals. The written expression is necessarily enhanced through image transmission.

(my translation) After Hermann Zapf, this is now the second loss of the typographic world in this year. We will miss both of them.