Looks like the php-apcu release shipped with Ubuntu 14.04 is really buggy. Since nobody at Ubuntu seems to care about packages in universe I've added a backport of php-apcu 4.0.7 to my ppa. It's just a rebuild, so no magic involved. Update: I've used the requestbackport thingy now to request a backport the Ubuntu way.

I'm lazy. So I sticked to xchat for way too long. It seems to be dead since 2010 but luckily some good souls maintain a fork called hexchat. That's what I moved myself to a few weeks ago. Now looking at the Debian xchat package I feel the urgent need to fill a request for removal. Sine I'm not a member of QA I asked for some advice, but the feedback is a bit sparse so far. Maybe everyone still using xchat could just switch to hexchat so we can remove xchat next year and nobody would notice it? The only obvious drawback I can see at the moment is the missing Tcl plugin. The rest of the migration is more or less reconfiguring everything to your preferences.

Thorsten Glaser reported Debian bug #780000 on Saturday March 7th 2015, against the gcc-4.9 package. Bug #770000 was reported as of November 18th so there have been 10,000 bugs in about 3.5 months, which was significantly slower than earlier. Salvatore Bonaccorso reported Debian bug #790000 on Friday June 26th 2015, against the pcre3 package. Thus, there have been 10,000 bugs in 3.5 months again. It seems that the bug report rate stabilized again. Sorry for missing bug #780000 annoucement. I'm doing this since....November 2007 for bug #450000 and it seems that this lack of attention is somehow significant wrt my involvment in Debian. Still, this involvment is still here and I'll try to "survive" in the project until we reach bug #1000000...:-) See you for bug #800000 annoucement and the result of the bets we placed on the date it would happen.

Here it is. Debian had eight hundred thousand bugs reported in its history. Tomasz Muras guessed, more than 2 years ago, that it would be reported on September 24h, and it has been reported on 25th. Good catch! Chris Lamb is the happy bug submitter for this release critical bug against the vdr-plugin-prefermenu package. Of course, I will soon open the wiki page for the bug #900000 bet, which will again include a place where you can also bet for bug #1000000. Be patient, the week-end is coming..:-) It took two years, 7 months and 18 days to report 100,000 bugs in Debian since bug #700000 was reported.

After a year without a release we finally pushed out a new version of the Japanese font maps. The main addition is support for the fonts shipped in the upcoming El Capitan OSX release, which brings a whole new set of Hiragino fonts, most of them in Truetype collections. The update is available from CTAN and will be in TeX Live within one or two days. For suggestions and improvements, please use the issue system at the github development place.

A bugfix release of RcppEigen is now on CRAN and in Debian. The NEWS file entry follows.

Changes in RcppEigen version 0.3.2.5.1 (2015-09-23)

• Corrected use of kitten() thanks to Grant Brown (#21)
• Applied upstream change to protect against undefined behaviour with null pointers

Courtesy of CRANberries, there is also a diffstat report for the most recent release.

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

VLANd is a python program intended to make it easy to manage port-based VLAN setups across multiple switches in a network. It is designed to be vendor-agnostic, with a clean pluggable driver API to allow for a wide range of different switches to be controlled together. There's more information in the README file. I've just released v0.4, with a lot of changes included since the last release:

• Large numbers of bugfixes and code cleanups
• Code changes for integration with LAVA:
  • Added db.find_lowest_unused_vlan_tag()
  • create_vlan() with a tag of -1 will find and allocate the first unused tag automatically
• Add port numbers as well as names to the ports database, to give human-recognisable references. See README.port-numbering for more details.
• Add tracking of trunks, the inter-switch connections, needed for visualisation diagrams.
• Add a simple http-based visualisation feature:
  • Generate network diagrams on-demand based on the information in the VLANd database, colour-coded to show port configuration
  • Generate a simple website to reference those diagrams.
• Allow more ports to be seen on Catalyst switches
• Add a systemd service file for vland

VLANd is Free Software, released under the GPL version 2 (or any later version). For now, grab it from git; tarballs will be coming shortly.

When I get a new laptop, the battery life time at the start is OK. But this do not last. The last few laptops gave me a feeling that within a year, the life time is just a fraction of what it used to be, and it slowly become painful to use the laptop without power connected all the time. Because of this, when I got a new Thinkpad X230 laptop about two years ago, I decided to monitor its battery state to have more hard facts when the battery started to fail. First I tried to find a sensible Debian package to record the battery status, assuming that this must be a problem already handled by someone else. I found battery-stats, which collects statistics from the battery, but it was completely broken. I sent a few suggestions to the maintainer, but decided to write my own collector as a shell script while I waited for feedback from him. Via a blog post about the battery development on a MacBook Air I also discovered batlog, not available in Debian. I started my collector 2013-07-15, and it has been collecting battery stats ever since. Now my /var/log/hjemmenett-battery-status.log file contain around 115,000 measurements, from the time the battery was working great until now, when it is unable to charge above 7% of original capacity. My collector shell script is quite simple and look like this:

#!/bin/sh
# Inspired by
# http://www.ifweassume.com/2013/08/the-de-evolution-of-my-laptop-battery.html
# See also
# http://blog.sleeplessbeastie.eu/2013/01/02/debian-how-to-monitor-battery-capacity/
logfile=/var/log/hjemmenett-battery-status.log
files="manufacturer model_name technology serial_number \
    energy_full energy_full_design energy_now cycle_count status"
if [ ! -e "$logfile" ] ; then
    (
	printf "timestamp,"
	for f in $files; do
	    printf "%s," $f
	done
	echo
    ) > "$logfile"
fi
log_battery()  
    # Print complete message in one echo call, to avoid race condition
    # when several log processes run in parallel.
    msg=$(printf "%s," $(date +%s); \
	for f in $files; do \
	    printf "%s," $(cat $f); \
	done)
    echo "$msg"
 
cd /sys/class/power_supply
for bat in BAT*; do
    (cd $bat && log_battery >> "$logfile")
done

The script is called when the power management system detect a change in the power status (power plug in or out), and when going into and out of hibernation and suspend. In addition, it collect a value every 10 minutes. This make it possible for me know when the battery is discharging, charging and how the maximum charge change over time. The code for the Debian package is now available on github. The collected log file look like this:

timestamp,manufacturer,model_name,technology,serial_number,energy_full,energy_full_design,energy_now,cycle_count,status,
1376591133,LGC,45N1025,Li-ion,974,62800000,62160000,39050000,0,Discharging,
[...]
1443090528,LGC,45N1025,Li-ion,974,4900000,62160000,4900000,0,Full,
1443090601,LGC,45N1025,Li-ion,974,4900000,62160000,4900000,0,Full,

I wrote a small script to create a graph of the charge development over time. This graph depicted above show the slow death of my laptop battery. But why is this happening? Why are my laptop batteries always dying in a year or two, while the batteries of space probes and satellites keep working year after year. If we are to believe Battery University, the cause is me charging the battery whenever I have a chance, and the fix is to not charge the Lithium-ion batteries to 100% all the time, but to stay below 90% of full charge most of the time. I've been told that the Tesla electric cars limit the charge of their batteries to 80%, with the option to charge to 100% when preparing for a longer trip (not that I would want a car like Tesla where rights to privacy is abandoned, but that is another story), which I guess is the option we should have for laptops on Linux too. Is there a good and generic way with Linux to tell the battery to stop charging at 80%, unless requested to charge to 100% once in preparation for a longer trip? I found one recipe on askubuntu for Ubuntu to limit charging on Thinkpad to 80%, but could not get it to work (kernel module refused to load). I wonder why the battery capacity was reported to be more than 100% at the start. I also wonder why the "full capacity" increases some times, and if it is possible to repeat the process to get the battery back to design capacity. And I wonder if the discharge and charge speed change over time, or if this stay the same. I did not yet try to write a tool to calculate the derivative values of the battery level, but suspect some interesting insights might be learned from those. Update 2015-09-24: I got a tip to install the packages acpi-call-dkms and tlp (unfortunately missing in Debian stable) packages instead of the tp-smapi-dkms package I had tried to use initially, and use 'tlp setcharge 40 80' to change when charging start and stop. I've done so now, but expect my existing battery is toast and need to be replaced. The proposal is unfortunately Thinkpad specific.

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

[As You Like It, Act III, Scene V] Hey Beautiful I thought of you on the Fourth of July; which does not, in and of itself, distinguish the day from any other since I met you. It was remarkable only in that it was justifiable, given our conversation about fireworks displays. Of course, I'm happy to take the flimsiest of displays as an excuse to mark you. I'm home alone right now, after watching The Bad Seed. Truth be told, the shadows keep spooking me. I can't seem to stop myself from imagining precocious blonde murderers in them. It's a manageable silliness, but made a little less so by the fact that I forgot to lock the door. Less troublesome than the night I spent after Ringu (the original Japanese version of The Ring). I finished watching it in the wee hours of the morning, and I wanted to go to sleep. I was in half a stupor, but the incessant inner critic in me kept imagining all the changes that could have been made to make the movie more truly unsettling until visions of Obake were swimming around me. Ordinarily I doubt I'd be bothered particularly by a 50's classic, but went back up to Boston this afternoon. 's at a conference in Finland, so I invited him down to visit while I have the apartment all to myself. It was strange to have a visitor actually in my home for whom I didn't have to play at being contented. At any rate, being around for three days essentially meant carrying on a three-day-long conversaiton, and the abrupt drop of sociability makes me feel my isolation a little more acutely. We watched The Way We Were together, and agreed that it should be remade with casting that actually works. I hadn't seen it before, and was surprised to find it unusually nuanced and substantial, yet still not good. It was nice to have someone around who would dissect it with me afterward. It's been a while since I actually discussed a film with someone. Partly out of my own fault; I don't always enjoy verbalizing my opinions of movies immediately after watching them if I've found them in the least bit moving. I guess I consider the aftertaste part of the experience. In this case, we both felt the film had missed its emotional mark so it wasn't so much of an issue. On the other hand, I don't find most movies moving. I find them frustratingly flawed, and by the time they end I'm raring to rant about their petty contradictions and failures of logic. I think it might give people the impression that I don't actually make any effort to tease out the messages filmmakers weave into their work. Or maybe I'm just making excuses for having uninteresting friends. Either way, it was pleasant to be in the company of someone eager to tolerate the convolutions of my thought process. On Wednesday night, I have a date to meet up with some former co-workers/friends that I've been passively avoiding for several years now. Every time I fail to carefully manage my visibility, people seem to come flooding back into my life. This time the culprit was a day spent logged into instant messaging without stringent privacy settings. I should feel lucky for that, I suppose. I'm not sure how I actually feel. One of the formers is a woman I was very close to, as far as most of the world her included could discern. The other is a Boston boy I admired for the touch of golden child in the air that hung about him. The main theme of his life was (and I suspect still is) getting to drinks with friends at one of his regular bars at the end of every evening. Which did not at all stop him from being productive, interested in the world, and bright. If he had been a girl I would have been hateful with envy. Instead he's always stood out in my memory as the only person I've had a bit of a crush on despite not finding him particularly intellectually stimulating. A month or so ago he sold his company to google. Now he spends a lot of time out of town giving lectures. I suspect I may be generally happy for him, and I'm not quite sure what to do with that. Thursday I'm leaving for a few days in Denver. I wish I hadn't scheduled it for a time when I could have been the sole occupant of my domicile, but other than that I'm looking forward to it. I've no idea what I'll do there, but at least that means I really am going someplace that wouldn't occur to me outside of a peculiar set of constraints. I think it would be advisable to work out the transportation system before I depart, though. I hope this letter finds you relatively satisfied, at a minimum. I don't actually need to tell you how much I miss talking to you, do I? You're wonderful. Affectionally, as always,

This is the first major release of INN in several years, and incorporates lots of updates to the build system, protocol support, and the test suite. Major highlights and things to watch out for:

• Cleanups of header handling in nnrpd, including using the new standardized headers for information about the post origin and rejecting many other obsolete headers.
• nnrpd now treats IHAVE identically to POST when configured to accept IHAVE (a compatibility hack that's only necessary when dealing with some weird news implementations that can only do IHAVE).
• innd authentication now requires a username be sent first, matching the NNTP protocol.

There are also tons of accumulated bug fixes, including (of course) all the fixes that were in INN 2.5.5. There are a lot of other changes, so I won't go into all the details here. If you're curious, take a look at the NEWS file. As always, thanks to Julien LIE for preparing this release and doing most of the maintenance work on INN! You can get the latest version from the official ISC download page or from my personal INN pages. The latter also has links to the full changelog and the other INN documentation.

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

After 3 months of installing an automatic decrufter in DAK, it:

• has removed 689 cruft items from unstable and experimental
  • average removal rate being just shy of 230 cruft items/month
• has become the top 11th remover .
• is expected to become top 10 in 6 days from now and top 9 in 10 days.
  • This is assuming a continued average removal rate of 7.6 cruft items per day

On a related note, the FTP masters have removed 28861 items between 2001 and now. The average being 2061 items a year (not accounting for the current year still being open). Though, intriguingly, in 2013 and 2014 the FTP masters removed 3394 and 3342 items. With the (albeit limited) stats from the auto-decrufter, we can estimate that about 2700 of those were cruft items. One could certainly also check the removal messages and check for the common tags used in cruft removals. I leave that as an exercise to the curious readers, who are not satisfied with my estimate. :)
Filed under: Debian, Release-Team

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.