Did you ever wonder where the web trafic really flow to reach the web servers, and who own the network equipment it is flowing through? It is possible to get a glimpse of this from using traceroute, but it is hard to find all the details. Many years ago, I wrote a system to map the Norwegian Internet (trying to figure out if our plans for a network game service would get low enough latency, and who we needed to talk to about setting up game servers close to the users. Back then I used traceroute output from many locations (I asked my friends to run a script and send me their traceroute output) to create the graph and the map. The output from traceroute typically look like this:

traceroute to www.stortinget.no (85.88.67.10), 30 hops max, 60 byte packets
 1  uio-gw10.uio.no (129.240.202.1)  0.447 ms  0.486 ms  0.621 ms
 2  uio-gw8.uio.no (129.240.24.229)  0.467 ms  0.578 ms  0.675 ms
 3  oslo-gw1.uninett.no (128.39.65.17)  0.385 ms  0.373 ms  0.358 ms
 4  te3-1-2.br1.fn3.as2116.net (193.156.90.3)  1.174 ms  1.172 ms  1.153 ms
 5  he16-1-1.cr1.san110.as2116.net (195.0.244.234)  2.627 ms he16-1-1.cr2.oslosda310.as2116.net (195.0.244.48)  3.172 ms he16-1-1.cr1.san110.as2116.net (195.0.244.234)  2.857 ms
 6  ae1.ar8.oslosda310.as2116.net (195.0.242.39)  0.662 ms  0.637 ms ae0.ar8.oslosda310.as2116.net (195.0.242.23)  0.622 ms
 7  89.191.10.146 (89.191.10.146)  0.931 ms  0.917 ms  0.955 ms
 8  * * *
 9  * * *
[...]

This show the DNS names and IP addresses of (at least some of the) network equipment involved in getting the data traffic from me to the www.stortinget.no server, and how long it took in milliseconds for a package to reach the equipment and return to me. Three packages are sent, and some times the packages do not follow the same path. This is shown for hop 5, where three different IP addresses replied to the traceroute request. There are many ways to measure trace routes. Other good traceroute implementations I use are traceroute (using ICMP packages) mtr (can do both ICMP, UDP and TCP) and scapy (python library with ICMP, UDP, TCP traceroute and a lot of other capabilities). All of them are easily available in Debian. This time around, I wanted to know the geographic location of different route points, to visualize how visiting a web page spread information about the visit to a lot of servers around the globe. The background is that a web site today often will ask the browser to get from many servers the parts (for example HTML, JSON, fonts, JavaScript, CSS, video) required to display the content. This will leak information about the visit to those controlling these servers and anyone able to peek at the data traffic passing by (like your ISP, the ISPs backbone provider, FRA, GCHQ, NSA and others). Lets pick an example, the Norwegian parliament web site www.stortinget.no. It is read daily by all members of parliament and their staff, as well as political journalists, activits and many other citizens of Norway. A visit to the www.stortinget.no web site will ask your browser to contact 8 other servers: ajax.googleapis.com, insights.hotjar.com, script.hotjar.com, static.hotjar.com, stats.g.doubleclick.net, www.google-analytics.com, www.googletagmanager.com and www.netigate.se. I extracted this by asking PhantomJS to visit the Stortinget web page and tell me all the URLs PhantomJS downloaded to render the page (in HAR format using their netsniff example. I am very grateful to Gorm for showing me how to do this). My goal is to visualize network traces to all IP addresses behind these DNS names, do show where visitors personal information is spread when visiting the page.

When I had a look around for options, I could not find any good free software tools to do this, and decided I needed my own traceroute wrapper outputting KML based on locations looked up using GeoIP. KML is easy to work with and easy to generate, and understood by several of the GIS tools I have available. I got good help from by NUUG colleague Anders Einar with this, and the result can be seen in my kmltraceroute git repository. Unfortunately, the quality of the free GeoIP databases I could find (and the for-pay databases my friends had access to) is not up to the task. The IP addresses of central Internet infrastructure would typically be placed near the controlling companies main office, and not where the router is really located, as you can see from the KML file I created using the GeoLite City dataset from MaxMind.

I also had a look at the visual traceroute graph created by the scrapy project, showing IP network ownership (aka AS owner) for the IP address in question. The graph display a lot of useful information about the traceroute in SVG format, and give a good indication on who control the network equipment involved, but it do not include geolocation. This graph make it possible to see the information is made available at least for UNINETT, Catchcom, Stortinget, Nordunet, Google, Amazon, Telia, Level 3 Communications and NetDNA.

In the process, I came across the web service GeoTraceroute by Salim Gasmi. Its methology of combining guesses based on DNS names, various location databases and finally use latecy times to rule out candidate locations seemed to do a very good job of guessing correct geolocation. But it could only do one trace at the time, did not have a sensor in Norway and did not make the geolocations easily available for postprocessing. So I contacted the developer and asked if he would be willing to share the code (he refused until he had time to clean it up), but he was interested in providing the geolocations in a machine readable format, and willing to set up a sensor in Norway. So since yesterday, it is possible to run traces from Norway in this service thanks to a sensor node set up by the NUUG assosiation, and get the trace in KML format for further processing.

Here we can see a lot of trafic passes Sweden on its way to Denmark, Germany, Holland and Ireland. Plenty of places where the Snowden confirmations verified the traffic is read by various actors without your best interest as their top priority. Combining KML files is trivial using a text editor, so I could loop over all the hosts behind the urls imported by www.stortinget.no and ask for the KML file from GeoTraceroute, and create a combined KML file with all the traces (unfortunately only one of the IP addresses behind the DNS name is traced this time. To get them all, one would have to request traces using IP number instead of DNS names from GeoTraceroute). That might be the next step in this project. Armed with these tools, I find it a lot easier to figure out where the IP traffic moves and who control the boxes involved in moving it. And every time the link crosses for example the Swedish border, we can be sure Swedish Signal Intelligence (FRA) is listening, as GCHQ do in Britain and NSA in USA and cables around the globe. (Hm, what should we tell them? :) Keep that in mind if you ever send anything unencrypted over the Internet. PS: KML files are drawn using the KML viewer from Ivan Rublev, as it was less cluttered than the local Linux application Marble. There are heaps of other options too. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Debian LTS November marked the 20th month I contributed to Debian LTS under the Freexian umbrella. I had 8 hours allocated which I used by:

• some rather quiet frontdesk days
• updating icedove to 45.5.1 resulting in DLA-752-1 fixing 7 CVEs
• looking whether Wheezy is affected by xsa-202, xsa-203, xsa-204 and handling the communication with credativ for these (update not yet released)
• Assessing cURL/libcURL CVE-2016-9586
• Assessing whether Wheezy's QEMU is affeced by security issues in 9pfs "proxy" and "handle" code
• Releasing DLA-776-1 for samba fixing CVE-2016-2125

Other Debian stuff

• Allow travis.debian.net to start services when running autopkgtests
• Usual bunch of libvirt and related uploads
• Uploaded git-buildpackage 0.8.8 and 0.8.9 to unstable (list of changes)

Some other Free Software activites

• Some fixes to libvirt's configure.ac for merged /usr
• Made some progress on getting the merkur board clones to life. The first stage bootloader and contiki are working now.
• Some ansible_spec fixes for roles in non default directories and robustness
• Due to excessive XMPP spam started a jabber-spam-blacklist
• Unbroke ansible-module-foreman
• Added support to configure Foreman settings via ansible-module-foreman and python-foreman
• Speed up VM removal with Foreman and VMware ESX
• Started foreman_serverspec a Foreman plugin to store serverspec reports in the Foreman. This is in a very early stage.

A new version, now at 0.2.0, of RcppCCTZ is now on CRAN. And it brings a significant change: windows builds! Thanks to Dan Dillon who dug deep enough into the libc++ sources from LLVM to port the std::get_time() function that is missing from the 4.* series of g++. And with Rtools being fixed at g++-4.9.3 this was missing for us here. Now we can parse dates for use by RcppCCTZ on Windows as well. That is important not only for RcppCCTZ but also particularly for the one package (so far) depending on it: nanotime. CCTZ is a C++ library for translating between absolute and civil times using the rules of a time zone. In fact, it is two libraries. One for dealing with civil time: human-readable dates and times, and one for converting between between absolute and civil times via time zones. It requires only a proper C++11 compiler and the standard IANA time zone data base which standard Unix, Linux, OS X, ... computers tend to have in /usr/share/zoneinfo -- and for which R on Windows ships its own copy we can use. RcppCCTZ connects this library to R by relying on Rcpp. The RcppCCTZ page has a few usage examples, as does the post announcing the previous release. The changes in this version are summarized here:

Changes in version 0.2.0 (2017-01-08)

• Windows compilation was enabled by defining OFFSET() and ABBR() for MinGW (#10 partially addressing #9)
• Windows use completed with backport of std::get_time from LLVM's libc++ to enable strptime semantics (Dan Dillon in #11 completing #9)
• Timezone information on Windows is supplied via R's own copy of zoneinfo with TZDIR set (also #10)
• The interface to formatDouble was cleaned up

We also have a diff to the previous version thanks to CRANberries. More details are at the RcppCCTZ page; code, issue tickets etc at the GitHub repository.

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

I use openssh every day, be it the ssh command for connecting to remote hosts, or the scp command for uploading/downloading files. Once a day, or more, I forget that scp uses the non-obvious -P flag for specifying the port, not the -p flag that ssh uses. Enough is enough. I shall not file a bug report against the Debian openssh-client page, because no doubt compatibility with both upstream, and other distributions, is important. But damnit I've had enough. apt-get source openssh-client shows the appropriate code:

    fflag = tflag = 0;
    while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q12346S:o:F:")) != -1)
          switch (ch)  
          ..
          ..
            case 'P':
                    addargs(&remote_remote_args, "-p");
                    addargs(&remote_remote_args, "%s", optarg);
                    addargs(&args, "-p");
                    addargs(&args, "%s", optarg);
                    break;
          ..
          ..
            case 'p':
                    pflag = 1;
                    break;
          ..
          ..
          ..

Swapping those two flags around, and updating the format string appropriately, was sufficient to do the necessary. In other news I've done some hardware development, using both Arduino boards and the WeMos D1-mini. I'm still at the stage where I'm flashing lights, and doing similarly trivial things:

• Absolute Arduino Basic Tutorial
  • Recognizing the board.
  • Getting the development environment setup.
  • Running your first project.
• Absolute WeMos D1 Mini (ESP8266) Basic Tutorial
  • Recognizing the board.
  • Getting the development environment setup.
  • Installing the libraries/headers/examples
  • Writing your first WiFi project.

I have more complex projects planned for the future, but these are on-hold until the appropriate parts are delivered:

• MP3 playback.
• Bluetooth-speakers.
• Washing machine alarm.
• LCD clock, with time set by NTP, and relay control.

Even with a few LEDs though I've had fun, for example writing a trivial binary display.

Finding a Libc for tiny embedded ARM systems You'd think this problem would have been solved a long time ago. All I wanted was a C library to use in small embedded systems -- those with a few kB of flash and even fewer kB of RAM. Small system requirements A small embedded system has a different balance of needs:

• Stack space is limited. Each thread needs a separate stack, and it's pretty hard to move them around. I'd like to be able to reliably run with less than 512 bytes of stack.
• Dynamic memory allocation should be optional. I don't like using malloc on a small device because failure is likely and usually hard to recover from. Just make the linker tell me if the program is going to fit or not.
• Stdio doesn't have to be awesomely fast. Most of our devices communicate over full-speed USB, which maxes out at about 1MB/sec. A stdio setup designed to write to the page cache at memory speeds is over-designed, and likely involves lots of buffering and fancy code.
• Everything else should be fast. A small CPU may run at only 20-100MHz, so it's reasonable to ask for optimized code. They also have very fast RAM, so cycle counts through the library matter.

Available small C libraries I've looked at:

• Clibc. This targets embedded Linux systems, and also appears dead at this time.
• musl libc. A more lively project; still, definitely targets systems with a real Linux kernel.
• dietlibc. Hasn't seen any activity for the last three years, and it isn't really targeting tiny machines.
• newlib. This seems like the 'normal' embedded C library, but it expects a fairly complete "kernel" API and the stdio bits use malloc.
• avr-libc. This has lots of Atmel assembly language, but is otherwise ideal for tiny systems.
• pdclib. This one focuses on small source size and portability.

Current AltOS C library We've been using pdclib for a couple of years. It was easy to get running, but it really doesn't match what we need. In particular, it uses a lot of stack space in the stdio implementation as there's an additional layer of abstraction that isn't necessary. In addition, pdclib doesn't include a math library, so I've had to 'borrow' code from other places where necessary. I've wanted to switch for a while, but there didn't seem to be a great alternative. What's wrong with newlib? The "obvious" embedded C library is newlib. Designed for embedded systems with a nice way to avoid needing a 'real' kernel underneath, newlib has a lot going for it. Most of the functions have a good balance between speed and size, and many of them even offer two implementations depending on what trade-off you need. Plus, the build system 'just works' on multi-lib targets like the family of cortex-m parts. The big problem with newlib is the stdio code. It absolutely requires dynamic memory allocation and the amount of code necessary for 'printf' is larger than the flash space on many of our devices. I was able to get a cortex-m3 application compiled in 41kB of code, and that used a smattering of string/memory functions and printf. How about avr libc? The Atmel world has it pretty good -- avr-libc is small and highly optimized for atmel's 8-bit avr processors. I've used this library with success in a number of projects, although nothing we've ever sold through Altus Metrum. In particular, the stdio implementation is quite nice -- a 'FILE' is effectively a struct containing pointers to putc/getc functions. The library does no buffering at all. And it's tiny -- the printf code lacks a lot of the fancy new stuff, which saves a pile of space. However, much of the places where performance is critical are written in assembly language, making it pretty darn hard to port to another processor. Mixing code together for fun and profit! Today, I decided to try an experiment to see what would happen if I used the avr-libc stdio bits within the newlib environment. There were only three functions written in assembly language, two of them were just stubs while the third was a simple ultoa function with a weird interface. With those coded up in C, I managed to get them wedged into newlib. Figuring out the newlib build system was the only real challenge; it's pretty awful having generated files in the repository and a mix of autoconf 2.64 and 2.68 version dependencies. The result is pretty usable though; my STM 32L discovery board demo application is only 14kB of flash while the original newlib stdio bits needed 42kB and that was still missing all of the 'syscalls', like read, write and sbrk. Here's gitweb pointing at the top of the tiny-stdio tree: gitweb And, of course you can check out the whole thing

git clone git://keithp.com/git/newlib

'master' remains a plain upstream tree, although I do have a fix on that branch. The new code is all on the tiny-stdio branch. I'll post a note on the newlib mailing list once I've managed to subscribe and see if there is interest in making this option available in the upstream newlib releases. If so, I'll see what might make sense for the Debian libnewlib-arm-none-eabi packages.

Today, Rcpp passed another milestone as 900 packages on CRAN now depend on it (as measured by Depends, Imports and LinkingTo declarations). The graph is on the left depicts the growth of Rcpp usage over time. The easiest way to compute this is to use the reverse_dependencies_with_maintainers() function from a helper scripts file on CRAN. This still gets one or two false positives of packages declaring a dependency but not actually containing C++ code and the like. There is also a helper function revdep() in the devtools package but it includes Suggests: which does not firmly imply usage, and hence inflates the count. I have always opted for a tighter count with corrections. Rcpp cleared 300 packages in November 2014. It passed 400 packages in June 2015 (when I only tweeted about it), 500 packages in late October 2015, 600 packages last March, 700 packages last July and 800 packages last October. The chart extends to the very beginning via manually compiled data from CRANberries and checked with crandb. The next part uses manually saved entries. The core (and by far largest) part of the data set was generated semi-automatically via a short script appending updates to a small file-based backend. A list of packages using Rcpp is kept on this page. Also displayed in the graph is the relative proportion of CRAN packages using Rcpp. The four per-cent hurdle was cleared just before useR! 2014 where I showed a similar graph (as two distinct graphs) in my invited talk. We passed five percent in December of 2014, six percent July of last year, seven percent just before Christmas eight percent this summer, and nine percent mid-December. 900 user packages is a really large number. This puts more than some responsibility on us in the Rcpp team as we continue to keep Rcpp as performant and reliable as it has been. At the rate things are going, the big 1000 may be hit some time in April. And with that a very big Thank You! to all users and contributors of Rcpp for help, suggestions, bug reports, documentation or, of course, code.

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

Short summary:My eyes hurt when I use my home desktop computer - but only with this computer. This has been very long and frustrating for me, so if you think you can help, read the whole story just below, or skip to what I've tried and what I suspect might be the problem, and post comments below, or send me a mail (my adress should be quite obvious in this page).

Whole story:Two years ago, I bought myself a new fancy motherboard (a Asus B85M-G C2) with a new fancy Intel-based processor with built-in graphics (an Intel Core i7-4770) and memory to go with it. I installed it in the place of my old AMD-based motherboard, keeping everything else (my hoard of hard drives and such) excepted the graphics card, which was not needed anymore. I immediately noticed my eyes were aching when using the computer. I was quite surprised since I had been using the screen very heavily for almost 10 years before that, without any problems. I attributed that to Intel Graphics, so I tried putting back the old graphics card, but it did not help. The situation was very frustrating, since working on the computer for an hour or so was making my eyes hurt for several days. This problem was specific to this computer, I could keep on using my computer at work and my laptop without problems.I could use the computer using SSH from my laptop, so I could profit from the faster processor, but, hey, that wasn't how it was meant to happen. I bought another screen, also tried with one from the work, without any change. I tried using two screens at the same time (this is what I have at work), also without success, so I just kept not using the computer directly. I moved recently to a new place and tried to get that working back again, but didn't get any luck. Frustrated, I got another desktop computer and another screen, and I still have the same problem ! I also tried remounting the old motherboard with the AMD processor and the old graphics card, but that didn't bring any improvement. I just don't get it. This situation is rather frustrating for me, and it's been holding me back in my software projects for two years now (which partly explains my lack of involvement in Debian over the past few years). This post is here in the hope someone will have a idea, but also for me to keep track of what I've done and what I should.

What is puzzling me is that the computer I had before was perfectly fine, and that I have a very very similar setup at work (also with a NVIDIA graphics card) that doesn't hurt my eyes at all.

What I've tried:Here is what I tried, you need to keep in mind that when a trial fails, my eyes keep on hurting for several days, and might trigger false positives.

• putting back the old (NVIDIA) graphics card, buying a new one (NVIDIA as well);
• putting back the old motherboard (but with a new OS, but maybe my eyes were too sore for a clean test);
• using another screen (a new one from the same brand, Samsung), a Dell and a HP from my work, and a brand new Phillips;
• using two screens at the same time;
• using a completely different (new, based on Xeon processors and a NVIDIA graphics card) computer (with new mouse, keyboard, hard drives and so on);
• changing house, including changing the lighting conditions, the desk, the internet provider (no, I didn't do that just because of my computer problems !);
• changing the way I drive the screens between VGA, DVI and HDMI;
• copying the system I have in my workplace to the new computer and booting from that system (after a few adaptations, though).

As you can guess, none of those brought any improvement.

Wild hypotheses:

• Is that a software thing ? Is there something wrong for me in the versions of Debian dating from August 2014 and after ?
• Is that a BIOS problem with recent computers ?
• Is that linked to some waves (bluetooth shoudln't be on, but maybe I didn't check well enough ?)
• Is that linked to EFI (but I also have the problems when I use legacy BIOS for booting)
• Something weird in my home ?
• Anything else ?

Any help will be greatly appreciated, but please don't advise going to see a doctor, I don't see how this could be a medical condition specific to my home desktop computer, unless this is a very specific psychosomatic problem.

Candy from Strangers

A few days ago I gave a talk at ESC https://www.endsummercamp.org/ about some reasons why I think that using software and especially libraries from the packages of a community managed distribution is important and much better than alternatives such as pypi, nmp etc. This article is a translation of what I planned to say before forgetting bits of it and luckily adding it back as an answer to a question :)

When I was young, my parents taught me not to accept candy from strangers, unless they were present and approved of it, because there was a small risk of very bad things happening. It was of course a simplistic rule, but it had to be easy enough to follow for somebody who wasn't proficient (yet) in the subtleties of social interactions.

One of the reasons why it worked well was that following it wasn't a big burden: at home candy was plenty and actual offers were rare: I only remember missing one piece of candy because of it, and while it may have been a great one, the ones I could have at home were also good.

Contrary to candy, offers of gratis software from random strangers are quite common: from suspicious looking websites to legit and professional looking ones, to platforms that are explicitly designed to allow developers to publish their own software with little or no checks.

Just like candy, there is also a source of trusted software in the Linux distributions, especially those lead by a community: I mention mostly Debian because it's the one I know best, but the same principles apply to Fedora and, to some measure, to most of the other distributions. Like good parents, distributions can be wrong, and they do leave room for older children (and proficient users) to make their own choices, but still provide a safe default.

Among the unsafe sources there are many different cases and while they do share some of the risks, they have different targets with different issues; for brevity the scope of this article is limited to the ones that mostly concern software developers: language specific package managers and software distribution platforms like PyPi, npm and rubygems etc.

These platforms are extremely convenient both for the writers of libraries, who are enabled to publish their work with minor hassles, and for the people who use such libraries, because they provide an easy way to install and use an huge amount of code. They are of course also an excellent place for distributions to find new libraries to package and distribute, and this I agree is a good thing.

What I however believe is that getting code from such sources and using it without carefully checking it is even more risky than accepting candy from a random stranger on the street in an unfamiliar neighbourhood.

The risk aren't trivial: while you probably won't be taken as an hostage for ransom, your data could be, or your devices and the ones who run your programs could be used in some criminal act causing at least some monetary damage both to yourself and to society at large.

If you're writing code that should be maintained in time there are also other risks even when no malice is involved, because each package on these platform has a different policy with regards to updates, their backwards compatibility and what can be expected in case an old version is found to have security issues.

The very fact that everybody can publish anything on such platforms is both their biggest strength and their main source of vulnerability: while most of the people who publish their libraries do so with good intentions, attacks have been described and publicly tested, such as the fun typo-squatting http://incolumitas.com/2016/06/08/typosquatting-package-managers/ one (archived on http://web.archive.org/web/20160801161807/http://incolumitas.com/2016/06/08/typosquatting-package-managers) that published harmless malicious code under common typos for famous libraries.

Contrast this with Debian, where everybody can contribute, but before they are allowed full unsupervised access to the archive they have to establish a relationship with the rest of the community, which includes meeting other developers in real life, at the very least to get their gpg keys signed.

This doesn't prevent malicious people from introducing software, but raises significantly the effort required to do so, and once caught people can usually be much more effectively prevented from repeating it than a simple ban on an online-only account can do.

It is true that not every Debian maintainer actually does a full code review of everything that they allow in the archive, and in some cases it would be unreasonable to expect it, but in most cases they are at least reasonably familiar with the code to do at least bug triage, and most importantly they are in an excellent position to establish a relationship of mutual trust with the upstream authors.

Additionally, package maintainers don't work in isolation: a growing number of packages are being maintained by a team of people, and most importantly there are aspects that involve potentially the whole community, from the fact that new packages that enter the distribution are publicity announced on a mailing list to the various distribution-wide QA efforts.

Going back to the language specific distribution platforms, sometimes even the people who manage the platform themselves can't be fully trusted to do the right thing: I believe everybody in the field remembers the npm fiasco https://lwn.net/Articles/681410/ where a lawyer letter requesting the removal of a package started a series of events that resulted in potentially breaking a huge amount of automated build systems.

Here some of the problems were caused by some technical policies that caused the whole ecosystem to be especially vulnerable, but one big issue was the fact that the managers of the npm platform are a private entity with no oversight from the user community.

Here not all distributions are equal, but contrast this with Debian, where the distribution is managed by a community that is based on a social contract https://www.debian.org/social_contract and is governed via democratic procedures established in its https://www.debian.org/devel/constitution.

Additionally, the long history of the distribution model means that many issues have already been met, the errors have already been done, and there are established technical procedures to deal with them in a better way.

So, shouldn't we use language specific distribution platforms at all? No! As developers we aren't children, we are adults who have the skills to distinguish between safe and unsafe libraries just as well as the average distribution maintainer can do. What I believe we should do is stop treating them as a safe source that can be used blindly and reserve that status to actual trustful sources like Debian, falling back to the language specific platforms only when strictly needed, and in that case:

actually check carefully what we are using, both by reading the code and by analysing the development and community practices of the authors;
if possible, share that work by becoming ourselves maintainers of that library in our favourite distribution, to prevent duplication of effort and to give back to the community whose work we get advantage from.

Edit: fixed broken typosquatting url

This weekend Toby Churchill kindly hosted a hacking weekend for OpenTAC myself, Michael Grzeschik, Steve McIntyre and Andy Simpkins got together to bring up the remaining bits of the hardware on the current board revision and get some of the low level tooling like production flashing for the FTDI serial ports on the board up and running. It was a very productive weekend, we verified that everything was working with only few small mods needed for the board . Personally the main thing I worked on was getting most of an initial driver for the EMC1701 written. That was the one component without Linux support and allowed us to verify that the power switching and measurement for the systems under test was working well. There s still at least one more board revision and quite a bit of software work to do (I m hoping to get the EMC1701 upstream for v4.8) but it was great to finally see all the physical components of the system working well and see it managing a system under test, this board revision should support all the software development that s going to be needed for the final board. Thanks to all who attended, Pengutronix for sponsoring Michael s attendance and Toby Churchill for hosting!

Idea via Roger. Roughly chronological order. Some things were obvious inclusions but it was interesting to go back and look at the year to get to the full 50 words. Speaking at BelFOSS. Earthlings birthday. ATtiny hacking. Speaking at ISCTSJ. Dublin Anomaly. Co-habiting. DebConf. Peak Lion. Laura s wedding. Christmas + picnic. Engagement. Car accident. Car write off. Tennent s Vital. Dissertation. OMGWTFBBQ. BSides. New job. Rachel s wedding. Digital Privacy talk. Graduation. All The Christmas Dinners. IMDB Top 250. Shay leaving drinks. (This also serves as a test to see if I ve correctly updated Planet Debian to use https and my new Hackergotchi that at least looks a bit more like I currently do.)

Big news: RcppTOML now works on Windows too! This package had an uneventful 2016 without a single update. Release 0.0.5 had come out in late 2015 and we had no bugs or issues to fix. We use the package daily in production: a key part of our parameterisation is in TOML files In the summer, I took one brief stab at building on Windows now that R sports itself a proper C++11 compiler on Windows too. I got stuck over the not-uncommon problem of incomplete POSIX and/or C++11 support with MinGW and g++-4.9. And sadly ... I appears I wasn't quite awake enough to realize that the missing functionality was right there exposed by Rcpp! Having updated that date / datetime functionality very recently, I was in a better position to realize this when Devin Pastoor asked two days ago. I was able to make a quick suggestion which he tested, which I then refined ... here we are: RcppTOML on Windows too! (For the impatient: CRAN has reported that it has built the Windows binaries, they should hit mirrors such as this CRAN package for RcppTOML shortly.) So what is this TOML thing, you ask? A file format, very suitable for configurations, meant to be edited by humans but read by computers. It emphasizes strong readability for humans while at the same time supporting strong typing as well as immediate and clear error reports. On small typos you get parse errors, rather than silently corrupted garbage. Much preferable to any and all of XML, JSON or YAML -- though sadly these may be too ubiquitous now. But TOML is making good inroads with newer and more flexible projects. The Hugo static blog compiler is one example; the Cargo system of Crates (aka "packages") for the Rust language is another example. The new release updates the included cpptoml template header by Chase Geigle, brings the aforementioned Windows support and updates the Travis configuration. We also added a NEWS file for the first time so here are all changes so far:

Changes in version 0.1.0 (2017-01-05)

• Added Windows support by relying on Rcpp::mktime00() (#6 and #8 closing #5 and #3)
• Synchronized with cpptoml upstream (#9)
• Updated Travis CI support via newer run.sh

Changes in version 0.0.5 (2015-12-19)

• Synchronized with cpptoml upstream (#4)
• Improved and extended examples

Changes in version 0.0.4 (2015-07-16)

• Minor update of upstream cpptoml.h
• More explicit call of utils::str()
• Properly cope with empty lists (#2)

Changes in version 0.0.3 (2015-04-27)

• First CRAN release after four weeks of initial development

Courtesy of CRANberries, there is a diffstat report for this release. More information and examples are on the RcppTOML page. Issues and bugreports should go to the GitHub issue tracker.

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

It's been over a year since my colleagues and I at the Progressive Technology Project abandoned Skype, first for IRC and soon after for XMPP. Thanks to the talented folks maintaining conversations.im it's been a breeze to get everyone setup with accounts (8 Euros/year is quite worth it) and a group chat going. However, our group chats have not been using end-to-end encryption... until now. It wasn't exactly painless, so I'm sharing some tips and tricks.

• Use either Conversations for Android (f-droid or Play) or Gajim for Windows or Linux. At the time of this writing, these are the only two applications I know of that support OMEMO, the XMPP extension that supports end-to-end encryption. Chat Secure for iOS, however, is just a release away. We managed to get things working with most of us using both Gajim and Conversations. It would probably have been much easier and smoother if everyone were only using Conversations because OMEMO is built-in to core, rather than Gajim, where OMEMO support is provided via an extension.
• If you are using Gajim... After installing the OMEMO plugin in Gajim, fully restart Gajim. Similarly, if you add or remove a contact from your group, it seems you have to fully restart Gajim. Not sure why. If something is not working in Gajim, try restarting it.
• Ensure that everyone in your group has added everyone else in the group to their roster. This was the single biggest and most confusing part of the process. If you are missing just one contact in your roster, then messages you type into the group chat will not show up without any indication as to what happened or why (on Gajim). Take this step first or prepare for confusing failures. Remember: everyone has to have everyone else in their roster.
• Create the group in the android Conversations app, not in Gajim. There are strict requirements for how the group needs to be setup (private, members only and non-anonymous). I tried creating the group in Gajim and followed the directions but couldn't get it to work. Creating the group in Conversations worked right away. Remember: don't add members to the group unless everyone has them in their roster!
• You can give your group a easy to remember name in your Gajim bookmarks, but under the hood, it will be assigned a random name. Conversations will show you the random name via "Conference Details" and Gajim will show it under the tab in the Messages window. When inviting people to the group you may need to select the random name.
• Trust on First Use. In our experiment, we created a group for four people and we were all on a video and voice chat while we set things up. Three out of the four of us had both Gajim and Conversations in play. That meant 4 different people had to verify between 5 and 6 fingerprints each. We decided to use Trust on First Use rather than go through the process of reading out all the fingerprints (for the record, it still took us an hour and 15 minutes to get it all working). See Daniel Gultsch's interesting article on Trust on First Use.
• If you get an error "This is not a group chat" it may be because you accidentally added the group as a contact to your roster. Click View -> Offline contacts. And if you see your group listed, delete it and close the tab in your Messages window (if one is open for it). You may also need to restart Gajim. Repeat until it no longer shows up in your roster.

Anyone interested in secure XMPP may also find the Riseup XMPP page useful.

My Monthly report for December 2016 gives an extended list of what were my Free Software related activities during this month. Personal projects:

• I released the version 0.8 of the Feed2tweet project, allowing to get RSS feed entries and sending them to the social network Twitter (check out my Twitter account!)
• I released the version 0.4 of the PersistentList project, a Python persistent list with limited number of allowed entries, the first ones being dropped to add the lastest ones at the end of the list. This is now a dependency for Feed2tweet.

That s all folks! See you next month!

Weblate probably would not exist (or at least would be much harder to manage) without several services that help us to develop, improve and fix bugs in our code base. Over the time the development world has become very relying on cloud services. As every change this has both sides - you don't have to run the service, but you also don't have control on the service. Personally I'd prefer to use more free software services, on the other side I really love this comfort and I'm lazy to setup things which I can get for free. The list was written down mostly for showing up how we work and the services are not listed in any particular order. All of the services provide free offerings for free software projects or for limited usage. GitHub I guess there is not much to say here, it has become standard place to develop software - it has Git repositories, issue tracker, pull requests and several other features. Travis CI Running tests on every commit is something what will make you feel confident that you didn't break anything. Of course you still need to write the tests, but having them run automatically is really great help. Especially great for automatically checking pull requests. AppVeyor Continuous integration on Windows - it's still widely used platform with it's quirks, so it's really good idea to test there as well. With AppVeyor you can do that and it works pretty nicely. Codecov When running tests it's good to know how much of your code is covered by them. Codecov is one of the best interfaces I've seen for this. They are also able to merge coverage reports from multiple builds and platforms (for example for wlc we have combined coverage for Linux, OSX and Windows coming from Travis CI and AppVeyor builds). SauceLabs Unit testing is good, but the frontend testing in browser is also important. We run Selenium tests in several browsers in SauceLabs to verify that we haven't screwed up something from the user interface. Read the Docs Documentation is necessary for every project and having it built automatically is nice bonus. Landscape Doing code analysis is a way to avoid some problems which are not spot during testing. These can be code paths not covered by test or simply coding style issues. There are several such services, but Landscape is my favorite one right now.

Filed under: Debian English phpMyAdmin SUSE Weblate 0 comments

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donors (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS I was allocated 10 hours to work on security updates for Debian 7 Wheezy. During this time I did the following:

• I released DLA-741-1 on unzip. This was an easy update.
• I reviewed Roberto Sanchez s patch for CVE-2014-9911 in ICU.
• I released DLA-759-1 on nss in collaboration with Antoine Beaupr . I merged and updated Guido s work to enable the testsuite during build and to add DEP-8 tests.
• I created a git repository for php5 maintenance in Debian LTS and started to work on an update. I added patches for two CVE (CVE-2016-3141, CVE-2016-2554) and added some binary files required by (currently failing) tests.

Misc packaging With the strong freeze approaching, I had some customer requests to push packages into Debian and/or to fix packages that were in danger of being removed from stretch. While trying to bring back uwsgi into testing I filed #847095 (libmongoclient-dev: Should not conflict with transitional mongodb-dev) and #847207 (uwsgi: FTBFS on multiple architectures with undefined references to uwsgi_* symbols) and interacted on some of the RC bugs that were keeping the package out of testing. I also worked on a few new packages (lua-trink-cjson, lua-inotify, lua-sandbox-extensions) that enhance hindsight in some use cases and sponsored a rozofs update in experimental to fix a file conflict with inn2 (#846571). Misc Debian work Debian Live. I released two live-build updates. The second update added more options to customize the grub configuration (we use it in Kali to override the theme and add more menu entries) both for EFI boot and normal boot. Misc bugreports. #846569 on libsnmp-dev to accomodate the libssl transition (I noticed the package was not maintained, I asked for new maintainers on debian-devel). #847168 on devscripts for debuild that started failing when lintian was failing (unexpected regression). #847318 on lintian to not emit spurious errors for kali packages (which was annoying with the debuild regression above). #847436 for an upgrade problem I got with tryton-server. #847223 on firefoxdriver as it was still depending on iceweasel instead of firefox. Sponsorship. I sponsored a new version of asciidoc (#831965) and of ssldump 0.9b3-6 (for libssl transition). I also uploaded a new version of mutter to fix #846898 (it was ready in SVN already). Distro Tracker Not much happening, I fixed #814315 by switching a few remaining URLs to https. I merged patches from efkin to fix the functional test suite (#814315), that was a really useful contribution! The same contributer started to tackle another ticket (#824912) about adding an API to retrieve action items. This is a larger project and needs some thoughts. I still have to respond to him on his latest patches (after two rounds already). Misc stuff I updated the letsencrypt-sh salt formula for version 0.3.0 and added the possibility to customize the hook script to reload the webserver. The @planetdebian twitter account is no longer working since twitterfeed.com closed doors and the replacement (dlvr.it) is unhappy about the RSS feed of planet.debian.org. I filed bug #848123 against planet-venus since it does not preserve the isPermalink attribute in the guid tag Thanks See you next month for a new summary of my activities.

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

Review: Castle of Wizardry, by David Eddings

Series:	The Belgariad #4
Publisher:	Del Rey
Copyright:	May 1984
Printing:	September 1991
ISBN:	0-345-33570-8
Format:	Mass market
Pages:	373

Castle of Wizardry is the fourth book of the Belgariad and very much the middle of the story. Despite coming after an intermediate climax, this isn't the sort of series you can start in the middle. The problem with intermediate climaxes in a long series is that the next book can be a bit of a let-down as the characters do the necessary regrouping and reorienting and determine next steps. I think that hurts Castle of Wizardry quite a lot. The best bits are at the beginning, as the party escapes the consequences of Magician's Gambit, collects one more party member, shows us a lot more of Errand (who is always delightful), and confounds Relg's life and world view considerably. (Although there's a good bit of authorial fiat in the last.) This builds into a major story event, which would normally help avoid the let-down after the climax, but it's the major story event that is so frequently and obviously foreshadowed that you'd have to be as dumb as, well, Garion to not know what's coming. That gives a certain "yes, yes, we know already" tone to proceedings that robs it of its ability to rebuild tension. That said, the appeal of this series continues to be in the small details. While the first major event of this book goes pretty much as expected (including Ce'Nedra's reaction, which is just as irritating as you might be expecting), my favorite part was the endless, bubbly enthusiasm of the incredibly powerful artifact that features heavily. Usually epic fantasy will treat such world-breaking objects with seriousness and awe, as treasures to be admired and sacred (or terrifying) great works. See, for instance, the ur-example of Tolkien's rings, both the One Ring and the elven rings of power. Eddings manages a mix of awe and bemusement that doesn't undermine their power but that adds a delightful human element. This series pulls off treating a powerful magical artifact like an over-enthusiastic puppy without making it feel any less dangerous. It's a very neat, and I think underappreciated, trick to pull off. Another part of this book I liked, if a more stock one, is Garion's reactions after the big story event. This isn't the first book to portray basic decency and thoughtfulness as a major feature in people from humble backgrounds elevated to great power, but I always enjoy seeing that. Garion stops whining (mostly) and starts acting like a decent, level-headed person who doesn't assume he has the right to arrange other people's lives, and is rewarded for it. Real life is often not that fair or ethical, but that's why one reads wish-fulfillment fantasy like this: for a world in which being a good person is rewarded. However, Eddings does have some structural issues here. The narrative arc of this book, as a stand-alone entity, is odd. Its most dramatic event is in the middle, and then has a long traveling section that's, by comparison, much less exciting. The events of that section feel more like random encounters than a coherent part of the story, and are preceded by the most utterly ridiculous temper tantrums. I think the tantrums were meant to be pure humor, but my reaction was primarily eye-rolling. I have a hard time reconciling a screaming fit and breaking furniture with the long life experience and thoughtful planning of the character in question. And then there is the Ce'Nedra section that closes this book, and Ce'Nedra in this book more generally. To be fair, Castle of Wizardry is clearly intended to be Ce'Nedra's moment to grow as a person and stop being a childish brat. This does happen somewhat, and there are moments in the last section of the book where she does admirable things. But I couldn't quite believe in the mechanism, and it doesn't help that it's one of the most ham-handed bits of pre-ordained success in a book that has a tendency towards them. That undermines the real attempts Eddings makes to ground that success in Ce'Nedra's actual skills. Also undermining this is that those skills are manipulating people shamelessly, which Eddings seems to think is charming and attractive and I... don't. But the real problem is that I flatly disbelieve in Ce'Nedra as a character, or, given the apparent existence of such a creature, the level of tolerance that other characters show her. If I'd been Polgara, within fifteen minutes of meeting her I would have been seriously debating whether the destruction of the world might be a small price to pay for the satisfaction of dumping her down the nearest well. And not only is she awful by herself but Garion also descends to the same level whenever he's around her, until both of them are behaving like blithering idiots. I suspect part of my issue is that, to the extent that she is realistic at all, Ce'Nedra is the sort of intensely high-drama person who I have some amount of life experience with, and that life experience says "do not let this person anywhere near your life." Red flags all over everything. Garion needs to nope the hell out, because this will not end well. (Except, of course, it will, because it's that sort of series and the power of the author is strong.) I want female characters with real agency in my fantasy, and I want a female protagonist who is doing things of equal importance as the male protagonist (not that Eddings attempts to go that far). But Ce'Nedra reads like a fictional character written by someone who had never met a woman, but has extensively studied female supporting characters in books about junior-high social cliques and then tried to reconcile that research with the stereotype of women as manipulative seductresses. Yes, this series is full of stereotypes and characters painted in broad strokes, but Ce'Nedra is several tiers below every other supporting character in the book in both believability and in my desire to read about her. It's not that Eddings doesn't know how to write women at all. Polgara still falls into a few stereotyped categories, but she's sensible, opinionated, and has clear agency throughout the story. Taiba is delightful, if minor here. Poledra is absolutely wonderful whenever she appears. Some of the queens are obviously practical and sensible. And this book features a surprisingly good resolution to the subplot around Barak's wife, although the mechanism is a bit eye-rollingly cliched. Ce'Nedra's character is unusual for the series and almost certainly a deliberate authorial choice, and this book is supposed to be her coming of age. But I am baffled by that choice, and there's very little about it that I enjoyed reading. One more minor complaint: Silk gets a "tragic secret" in this book, and I really wish he hadn't. More time with Silk is always a feature, and I still love the character, but his oddities were already adequately explained by both his innate character and his way of dealing with a particularly awkward court situation. (One that ties into Eddings's habit of using some bad relationship stereotypes, but that's a rant for another day.) I think this additional tragic secret was gratuitous and really unnecessary, not to mention weirdly implausible and oddly cruel towards the other character involved. I was hoping that Magician's Gambit had turned a corner for the series, but Castle of Wizardry, despite having some neat moments, has some serious flaws. One more book to go, in which we learn that some of the eastern races have redeeming qualities! Followed by Enchanter's End Game. Rating: 6 out of 10

In one of the good parts of the very mixed bag that is "Lo and Behold: Reveries of the Connected World", Werner Herzog asks his interviewees what the Internet might dream of, if it could dream. The best answer he gets is along the lines of: The Internet of before dreamed a dream of the World Wide Web. It dreamed some nodes were servers, and some were clients. And that dream became current reality, because that's the essence of the Internet. Three years ago, it seemed like perhaps another dream was developing post-Snowden, of dissolving the distinction between clients and servers, connecting peer-to-peer using addresses that are also cryptographic public keys, so authentication and encryption and authorization are built in. Telehash is one hopeful attempt at this, others include snow, cjdns, i2p, etc. So far, none of them seem to have developed into a widely used network, although any of them still might get there. There are a lot of technical challenges due to the current Internet dream/nightmare, where the peers on the edges have multiple barriers to connecting to other peers. But, one project has developed something similar to the new dream, almost as a side effect of its main goals: Tor's onion services. I'd wanted to use such a thing in git-annex, for peer-to-peer sharing and syncing of git-annex repositories. On November 13th, I started building it, using Tor, and I'm releasing it concurrently with this blog post. Now git-annex can serve a repository as a Tor onion service, and that can then be accessed as a git remote, using an url like tor-annex::tungqmfb62z3qirc.onion:42913. All the regular git, and git-annex commands, can be used with such a remote. Tor has a lot of goals for protecting anonymity and privacy. But the important things for this project are just that it has end-to-end encryption, with addresses that are public keys, and allows P2P connections. Building an anonymous file exchange on top of Tor is not my goal -- if you want that, you probably don't want to be exchanging git histories that record every edit to the file and expose your real name by default. Building this was not without its difficulties. Tor onion services were originally intended to run hidden websites, not to connect peers to peers, and this kind of shows.. Tor does not cater to end users setting up lots of Onion services. Either root has to edit the torrc file, or the Tor control port can be used to ask it to set one up. But, the control port is not enabled by default, so you still need to su to root to enable it. Also, it's difficult to find a place to put the hidden service's unix socket file that's writable by a non-root user. So I had to code around this, with a git annex enable-tor that su's to root and sets it all up for you. When two peers are connected over Tor, one knows it's talking to the owner of a particular onion address, but the other peer knows nothing about who's talking to it, by design. This makes authentication harder than it would be in a P2P system with a design like Telehash. So git-annex does its own authentication on top of Tor. With authentication, users would need to exchange absurdly long addresses (over 150 characters) to connect their repositories. One very convenient thing about using XMPP was that a user would have connections to their friend's accounts, so it was easy to share with them. Exchanging long addresses is too hard. This is where Magic Wormhole saved the day. It's a very elegant way to get any two peers in touch with each other, and the users only have to exchange a short code phrase, like "2-mango-delight", which can only be used once. Magic Wormhole makes some security tradeoffs for this simplicity. It's got vulnerabilities to DOS attacks, and its MITM resistance could be improved. But I'm lucky it came along just in time. So, it takes only installing Tor and Magic Wormhole, running two git-annex commands, and exchanging short code phrases with a friend, perhaps over the phone or in an encrypted email, to get your git-annex repositories connected and syncing over Tor. See the documentation for details. Also, the git-annex webapp allows setting the same thing up point-and-click style. The Tor project blog has throughout December been featuring all kinds of projects that are using Tor. Consider this a late bonus addition to that. ;) I hope that Tor onion services will continue to develop to make them easier to use for peer-to-peer systems. We can still dream a better Internet.

---

This work was made possible by all my supporters on Patreon.

Review: Secrets of Productive People, by Mark Forster

Publisher:	Teach Yourself
Copyright:	2015
ISBN:	1-4736-0885-6
Format:	Kindle
Pages:	289

Regular readers of my reviews will know that Mark Forster is my favorite writer on time management and productivity. That's mostly because of his flexible toolkit approach that talks about theory and overall goals and then describes multiple ways to get there, rather than presenting a single system that will solve all your problems. There are a lot of writers who explain productivity tips and tricks or describe systems that work for them. There are fewer who can explain why those tricks work (and why they sometimes don't work), and even fewer who can put them into a meaningful analytical framework for thinking about productivity. Forster has several books, but they're a mixed bag. His clearest and most coherent book prior to this one was Do It Tomorrow. Secrets of Productive People is organized differently, chopped up in to small bite-sized chunks with synopses to an extent that it felt a bit choppy to me, but apart from that it's the closest I've seen to an updating of Do It Tomorrow. His other books can be slight (The Pathway to Awesomeness) or downright weird (How to Make Your Dreams Come True). I still have a soft spot for Do It Tomorrow, and I like how it was organized a bit better than this one, but I think Secrets of Productive People has become my new recommendation for where to start with Forster. Secrets of Productive People is divided into five sections: The basics of productivity, the productive attitude, productive projects, aids to productivity, and productivity in action. Each part is divided into several small chapters, which open with a generous helping of quotes about some productivity topic (and I'm going to go back and save some of those), present some easily-digestible related set of thoughts (usually with an exercise), and conclude with a summary. Each chapter is about the length of a long blog post. I think this structure interferes with developing an idea at greater length, but it does make for good reading material in an environment where you're regularly interrupted or only have five or ten minutes. I think I've mentioned in every review that Forster won me over by being willing to talk about the problems with attempting to do too much, not just presenting a system to allow one to accomplish more. Some other books, such as David Allen's famous Getting Things Done, seem to assume you already know what you need to get done, or will easily be able to figure that out when you think for a while, and just need a system to manage all the things you've decided to do. Forster takes the opposite approach, and this book is the clearest yet on this point: most productivity problems are not from being insufficiently efficient, but from doing the wrong things and too many things. You don't need more time; everyone gets the same amount of time. You need to do the right things with the time you have, and that usually means doing fewer things. Readers of Forster's previous books will recognize many of the themes here. Some of the techniques from Do It Tomorrow and some of the exercises from Get Everything Done show up again here. But Forster has streamlined and focused the advice, discarded some things, made his task management recommendations less elaborate and more focused, and spends much more time hammering home the point that the only prioritization that really matters is whether you commit to doing something or don't. The specific task management system he recommends here is one of the variations he's been talking about in his blog and is much simpler than the Do It Tomorrow system: pick five tasks, work on them until you've finished three of them, and then refill to five tasks. I've been using it since reading this book, replacing one of Forster's more elaborate systems from his blog, and it's surprisingly effective. He breaks down in some detail why this works and how to extract additional useful feedback information from it, and now I want to do some of the additional exercises he describes. (That said, I'm still dubious about his advice to not keep any larger to-do list and only rely on your analysis at the time of refilling the list to decide what to do. I use this system with a supplemental, longer list of ideas for future tasks, and that works better for me, although I do have to fight forming a sense of obligation about the things on the longer list. David Allen still has a point that if you don't write down a complete inventory of the things you're worrying about, your brain will try to obsess over them to keep from forgetting them.) The productive projects section told me some things I needed to hear about time commitments. Projects take regular, focused attention, and starting numerous things without giving them that attention is much worse than doing far fewer things but doing them regularly and reliably. I think Forster's coaching on focus and persistence is very valuable; the trick, of course, is building up your willpower for it and learning to say no. This is in-line with recent psychological analysis of multi-tasking and its various negative effects. The working to-do list capped at five things provides enough variety to mentally shift gears if one runs out of steam on some specific project while maintaining enough focus to not leave things behind half-done. The productivity aids section provides a more random collection of tips and tricks, many of which I've seen before in his previous books. I've mostly not tried these, so can't say much about how effective they are, but Forster's ideas almost always sound interesting and plausible. I thought the weakest part of the book was the last section, on applied productivity. Here, Forster takes various life areas (exercise, parenting, finances, writing, etc.) and talks about how the principles of this book can be applied to them. Each area could be a book in itself, and the short essay format of these chapters doesn't do justice to large topics. The result is a rather repetitive section that just stresses analysis, metrics, and repeated, focused attention all valid points, but ones you can pick up from the previous chapters. I don't think these case studies added much value. Do It Tomorrow is still my favorite Forster book to read, but I think Secrets of Productive People is now the best and most polished overview of his time management and productivity approach. If you're interested in this topic and not already sick of Forster from my previous recommendations, this would be a great place to start. I got a lot out of it even with all the time management reading I've previously done, and will probably re-read sections of it and try more of the exercises. Rating: 9 out of 10

I was in such a different place at the beginning of 2016: I was poised to continue to work to help the world find love. Professionally, I was ready to make a much needed transition and find new projects to work on. The year 2016 sucked. It feels like the year was filled with many different versions of the universe saying "Not interested in what you have to offer." At the beginning of the year, I had the energy to try and reach across large disagreements and help find common ground even when compromise was not possible. Now, my blog lies fallow because I cannot find the strength to be vulnerable enough to write what I would choose to say. Certainly a lot of the global changes of the last year have felt like a strong rejection of the world I'd like to see. However, many of the rejections have been personal. Beyond that, most of the people who stood as pillars of support in my life, together helping me find the strength to be vulnerable, are no longer available. When the universe sends such strong messages, it's a good idea to ask whether you are on the right path. I certainly have discovered training I need and things I need to improve in order to avoid making costly mistakes that hurt others. However, among the rejections were clear demonstrations of the value of reaching out with love and compassion. Besides, this is what I'm called to do. It's what I want to do. I certainly will not force it on anyone. But it looks like the next few years may be a hard struggle to find pockets of people interested in that work, finding people who will choose love even in the current world, along with some difficult training to learn from challenges of the last year. Amongst all this, my life if filled with love. There are new connections even as old connections are strained. There is always the hope of finding new ways to connect when the old ones are no longer right. I will rebuild and regain safety. I have the tools to do that. The process is just long and complicated.

Since I've got a few weeks off I've decided I need to find a project, or two, to occupy me. Happily the baby is settling in well, mostly he sleeps for 4-5 hours, then eats, before the cycle repeats. It could have been so much worse. My plan is to start exploring Arduino-related projects. It has been years since I touched hardware, with the exception of building a new PC for myself every 12-48 months. There are a few "starter kits" you can buy, consisting of a board, and some discrete components such as a bunch of buttons, an LCD-output screen, some sensors (pressure, water, tilt), etc. There are also some nifty little pre-cooked components you can buy such as:

• An MP3-playback module.
  • With integrated SD-card reader.

The appeal of the former is that I can get the hang of marrying hardware with software, and the appeal of the latter is that the whole thing is pre-built, so I don't need to worry about anything complex. Looking over similar builds people have made, the process is more akin to building with Lego than real hardware-assembling. So, for the next few weeks my plan is to :

• Explore the various sensors, and tutorials, via the starter-kit.
• Wire the MP3-playback device to a wireless D1-mini-board.
  • Which will allow me to listen to (static) music stored on an SD-card.
  • And sending "next", "previous", "play", "volume-up", etc, via a mobile.

The end result should be that I will be able to listen to music in my living room. Albeit in a constrained fashion (if I want to change the music I'll have to swap out the files on the SD-card). But it's something that's vaguely useful, and something that I think is within my capability, even as a beginner. I'm actually not sure what else I could usefully do, but I figured I could probably wire up a vibration sensor to another wireless board. The device can sit on the top of my washing machine:

• If vibration is sensed move into the "washing is on" state.
  • If vibration stops after a few minutes move into the "washing machine done" state.
    • Send a HTTP GET-request, which will trigger an SMS/similar.

There's probably more to it than that, but I expect that a simple vibration sensor will be sufficient to allow me to get an alert of some kind when the washing machine is ready to be emptied - and I don't need to poke inside the guts of the washing machine, nor hang reed-switches off the door, etc. Anyway the only downside to my plan is that no doubt shipping the toys from AliExpress will take 2-4 weeks. Oops.