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

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

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

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

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

Run:

host# systemctl reload tor.service

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

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

Install the container debootstrap as always:

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

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

host# chroot ksp

Let's set the hostname:

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

Set up APT:

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

We need dbus to get systemd to work well:

ksp-chroot# apt-get install dbus

Make sure that we can resolve our own hostname:

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

These are dependencies of the keyserver:

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

These ones are needed for the script generating the list:

ksp-chroot# apt-get install bzip2 inoticoming

And we will use the smallest HTTP server available:

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

Finally, let's unconfigure all DNS resolvers:

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

And we are done with the chroot:

ksp-chroot# exit

Let's retrieve the ksp-tools repository now:

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

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

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

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

ksp# systemctl enable systemd-networkd

Let's not forget to set a root password:

ksp# passwd

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

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

Let's configure the keyserver:

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

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

homedir = /var/lib/ksp

Now create the GnuPG homedir for the keyserve:

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

Copy the template list generator:

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

Create the key repository:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

host# systemctl enable systemd-nspawn@ksp.service

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

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

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

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

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

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

All good? Let's start it:

host# systemctl start systemd-nspawn@ksp.service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Review: The Goblin Emperor, by Katherine Addison

Publisher:	Tor
Copyright:	April 2014
ISBN:	1-4299-4640-7
Format:	Kindle
Pages:	446

Maia is the child of the current emperor of the Elflands, but not a favored one. He's the half-goblin son of a political marriage to a goblin princess, quickly orphaned away from the capital and kept in seclusion well out of the way of his father and court politics. And in the care of his cousin Setheris: cruel and abusive companionship. Then the airship Wisdom of Choharo crashes with no survivors, killing everyone in the line of succession. Except Maia. Maia is in no way prepared to be emperor, but the rules of succession are clear: he is now emperor. We all know from medieval history, both real and fantastic, that clear rules rarely got in the way of aggressive political maneuvering, but Maia's short-term survival is helped considerably by complex factions at play at court (of which he is almost wholly ignorant), and a certain lack of bloodthirstiness in elven politics. Rather than disposing of the unexpected heir, people instead start maneuvering to manipulate and control him. The current Lord Chancellor is the first, beginning his play in the message sent informing Maia of his father's death, and his cousin isn't far behind, but they're only the first two. Meanwhile, Maia, who had never been trained for any sort of court life, has to learn nearly everything about his new life: how to interact with servants, the rituals of court, his new duties, and all of the factions in play. One might expect that Maia would quickly be reduced to a pawn of one faction or another, but he has two secret weapons. One is that he is a legitimately nice person with a strongly developed sense of empathy. Early on, he lucks into some opportunities to show this and wins some popularity and some allies of his own, particularly among those people not used to being treated with respect. And two, he's had enough of his cousin controlling and abusing him. He's determined to make his own decisions and not take orders from someone else, and now has enough nominal power to possibly pull this off. The Goblin Emperor is a fantasy of political agency, and a story about political maneuvering, tricky decisions, navigating alliances, and learning politics. There isn't a lot of action here: most of the plot happens in conversation. The tension is high Maia's situation is precarious but it mostly involves second-guessing his decisions and actions, and hoping that his weaknesses and ignorance don't get him into too much trouble. That is an extremely tricky book to write. Addison had to walk a tightrope between letting Maia's new responsibilities come unrealistically easily, making him seem like a Chosen One with special plot powers, and having readers get too frustrated with realistically bad decisions and lose their desire to read about him. Addison walks that tightrope magnificently. I liked Maia throughout this book, and that's the strength of it. He never felt like the typical fantasy coming of age hero who is magically protected by the plot. He's just a genuine, honest person, reacting to his own past as best he can, making the best decisions he knows how to make. He makes mistakes, but Addison wisely avoids making those mistakes cringe-worthy or too obvious. Instead, they're like bad moves in a chess match: they create problems but also some opportunities, and they're realistically recoverable. And it's a delight to see Maia bring empathy and a disinterested outside perspective to the hothouse mess of court politics and come up with some very creative solutions. Obviously, the situation that allows Maia to succeed is artificial. This is a fantasy: Maia happens to be just the right person the empire needs, and that's clearly an authorial construction. It may be impossible to write a political story about a well-meaning, naive outsider that isn't a tragedy without a bit of cheating. But Addison hides the cheating well. Maia may be very lucky in the empire he inherits, but it feels coherent and believable. By the end of the book, Maia has dealt with everything from international diplomacy to the incredibly complex negotiations around further heirs to the empire. And (realistically) he doesn't stay lucky throughout the book: eventually, no matter how careful he tries to be, he angers some powerful people. I enjoyed every step along the way, and would have happily read more about Maia. In my personal ranking, this was second only to Ancillary Sword in the nominees for the 2015 Hugo, and I wouldn't disagree too strongly with someone who argued it was better. It's not a typical sort of fantasy, but it's one I enjoyed very much. Recommended. One warning: consider going to the back of the book and reading the glossary at the start. There may be some mild spoilers in there, but it also explains the title conventions in the empire, and some of those titles look very much like proper names. If, like me, you don't read this until the end of the book, you may find yourself horribly confused by several apparently similarly-named characters. Rating: 8 out of 10

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

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

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

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

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

We've been hard working with the Gnocchi team these last months to store your metrics, and I guess it's time to show off a bit. So far Gnocchi offers scalable metric storage and resource indexation, especially for OpenStack cloud but not only, we're generic. It's cool to store metrics, but it can be even better to have a way to visualize them! Prototyping We very soon started to build a little HTML interface. Being REST-friendly guys, we enabled it on the same endpoints that were being used to retrieve information and measures about metric, sending back text/html instead of application/json if you were requesting those pages from a Web browser. But let's face it: we are back-end developers, we suck at any kind front-end development. CSS, HTML, JavaScript? Bwah! So what we built was a starting point, hoping some magical Web developer would jump in and finish the job. Obviously it never happened. Ok, so what's out there? It turns out there are back-end agnostic solutions out there, and we decided to pick Grafana. Grafana is a complete graphing dashboard solution that can be plugged on top of any back-end. It already supports timeseries databases such as Graphite, InfluxDB and OpenTSDB. That was largely enough for that my fellow developer Mehdi Abaakouk to jump in and start writing a Gnocchi plugin for Grafana! Consequently, there is now a basic but solid and working back-end for Grafana that lies in the grafana-plugins repository. With that plugin, you can graph anything that is stored in Gnocchi, from raw metrics to metrics tied to resources. You can use templating, but no annotation yet. The back-end supports Gnocchi with or without Keystone involved, and any type of authentication (basic auth or Keystone token). So yes, it even works if you're not running Gnocchi with the rest of OpenStack. It also supports advanced queries, so you can search for resources based on some criterion and graphs their metrics. I want to try it! If you want to deploy it, all you need to do is to install Grafana and its plugins, and create a new datasource pointing to Gnocchi. It is that simple. There's some CORS middleware configuration involved if you're planning on using Keystone authentication, but it's pretty straightforward just set the cors.allowed_origin option to the URL of your Grafana dashboard. We added support of Grafana directly in Gnocchi devstack plugin. If you're running DevStack you can follow the instructions which are basically adding the line enable_service gnocchi-grafana. Moving to Grafana core Mehdi just opened a pull request a few days ago to merge the plugin into Grafana core. It's actually one of the most unit-tested plugin in Grafana so far, so it should be on a good path to be merged in the future and have support of Gnocchi directly into Grafana without any plugin involved.

What happened in the reproducible builds effort this week: Media coverage Motherboard published an article on the project inspired by the talk at the Chaos Communication 15. Journalists sadly rarely pick their headlines. The sensationalist How Debian Is Trying to Shut Down the CIA got started a few rants here and there. One from OpenBSD developper Ted Unangst lead to a good email contact and some thorough comments. Toolchain fixes

• Emmanuel Bourg uploaded maven-ant-helper/7.11 which improved the reproducibility of the Javadoc by removing the timestamps and using the English locale.
• Thomas Schmitt uploaded libisoburn/1.4.0-2 which adds to the ISO image creator xorriso new flags for -alter_date to avoid update ctimes. Report by Daniel Kahn Gillmor.
• Florian Schlichting uplodaded libmodule-build-perl/0.421400-2 which makes linked file ordering deterministic. Original patch by Niko Tyni.

The modified version of gettext has been removed from the experimental toolchain. Fixing individual package seems a better approach for now. Chris Lamb sent two patches for abi-compliance-checker: one to drop the timestamp from generated HTML reports and another to make umask and timestamps deterministic in the abi tarball. Bugs submitted by Dhole lead to a discussion on the best way to adapt pod2man now that we have SOURCE_DATE_EPOCH specified. There is really a whole class of issues that are currently undiscovered waiting for tests running on a different date. This is likely to should happen soon. Chris Lamb uploaded a new version of debhelper in the reproducible repository, cherry-picking a fix for interactions between ddebs and udebs. Packages fixed The following packages became reproducible due to changes in their build dependencies: aspic, django-guardian, erlang-sqlite3, etcd, libnative-platform-java, mingw-ocaml, nose2, oar, obexftp, py3cairo, python-dugong, python-secretstorage, python-setuptools, qct, qdox, recutils, s3ql, wine. The following packages became reproducible after getting fixed:

• bochs/2.6-4 by Santiago Vila.
• codec2/0.4-3 by A. Maitland Bottoms.
• coquelicot/0.9.4-1 by Lunar.
• criticalmass/1:1.0.0-3 by Santiago Vila.
• ekg/1:1.9~pre+r2855-3 by Santiago Vila.
• eterm/0.9.6-3 by Santiago Vila.
• fbi/2.10-2 by Moritz Muehlenhoff.
• fsvs/1.2.6-2 by Santiago Vila.
• glhack/1.2-3 by Santiago Vila.
• httraqt/1.4.6-2 by Anton Gladky.
• libapache-authznetldap-perl/0.07-6 by gregor herrmann, original patch by Dhole.
• libkinosearch1-perl/1.01-3 uploaded by Florian Schlichting, original patch by Niko Tyni.
• liblucy-perl/0.3.3-6 uploaded by Florian Schlichting, original patch by Niko Tyni.
• slony1-2/2.2.4-1 by Christoph Berg.
• slrn/1.0.2-3 uploaded by Moritz Muehlenhoff, original patch by Dmitry Bogatov.
• svtplay-dl/0.10.2015.08.24-1 uploaded by Olof Johansson, fixed upstream.
• swh-plugins/0.4.15+1-8 uploaded by Jarom r Mike , original patch by Chris Lamb.
• sysstat/11.1.6-2 uploaded by Robert Luberda, original patch by Chris Lamb.
• uhd/3.9.0-3 by A. Maitland Bottoms.
• volk/1.1-3 by A. Maitland Bottoms.
• yadifa/2.1.3-2 uploaded by Markus Schade, original patch by Santiago Vila.

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

• dict-jargon/4.4.7-3 uploaded by Ruben Molina, original patch by Dhole.
• ferret-vis/6.9.3-3 uploaded by Alastair McKinstry, original patch by Chris Lamb.

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

• #798366 on lilo by Dmitry Bogatov: remove usage of __TIME__ and __DATE__ macros.
• #798557 on libapache-dbi-perl by Dhole: set date of the manpage to the latest debian/changelog entry.
• #798776 on testdisk by upstream!

reproducible.debian.net The configuration of all remote armhf and amd64 nodes in now finished. The remaining reproducibility tests running on the Jenkins host has been removed. armhf results and graphs are now visible in dashboard. We can now test the whole archive in 2-3 weeks using the current 12 amd64 jobs and 3 months using the current 6 armhf builders. We will be looking at improving the armhf sitation, maybe using more native systems or via arm64. (h01ger) The Jenkins UI is now more responsive since all jobs building packages have been moved to remote hosts. (h01ger) A new job has been added to collect information about build nodes to be included in the variation table. (h01ger) The currently scheduled page has been split for amd64 and armhf. They now give an overview (refreshed every minute, thanks to Chris Lamb) of the packages currently being tested. (h01ger) Several cleanup and bugfixes have been made, especially in the remote building and maintenance scripts. They should now be more robust against network problems. The automatic scheduler is now also run closer to when schroots and pbuilders are updated. (h01ger, mapreri) Package reviews 16 reviews have been removed, 54 added and 55 updated this week. Santiago Vila renamed lc_messages_randomness with the more descriptive different_pot_creation_date_in_gettext_mo_files. New issues added this week: timestamps_in_reports_generated_by_abi_compliance_checker, umask_and_timestamp_variation_in_tgz_generated_by_abi_compliance_checker, and timestamps_added_by_blast2. 23 new FTBFS bugs have been filled by Chris Lamb, and Niko Tyni. Misc. Red Hat developper Mike McLean had a talk at Flock 2015 about reproducible builds in Koji. Slides and video recording are available. Koji is the build infrastructure used by Fedora, Red Hat and other distributions. It already keeps track of the environment used for a given build, so the required changes for handling the environment are smaller than the ones in Debian. Fedora is still missing a team effort to fix non-determinism in the package builds, but it is great to see Fedora moving forward.

I haven't posted one of these in a while, but now that I'm finally caught up with writing reviews (although not posting them yet), I've been feeling about reading again. And of course the backlog always grows. Let's see if I can figure out what I've picked up since the last post. Catherine Asaro The Phoenix Code (sff)
Annie Bellet Justice Calling (sff)
Annie Bellet Murder of Crows (sff)
Annie Bellet Pack of Lies (sff)
Zen Cho Sorcerer to the Crown (sff)
J.J. Gribble Steel Victory (sff)
Judith L. Herman Trauma and Recovery (non-fiction)
Janis Ian & Mike Resnick Stars: The Anthology (sff anthology)
Megg Jensen Hidden (sff)
T. Kingfisher Bryony and Roses (sff)
T. Kingfisher The Seventh Bride (sff)
Nancy Kress Crossfire (sff)
Edmond Lau The Effective Engineer (non-fiction)
Yoon Ha Lee The Fox's Tower and Other Tales (sff collection)
Lozzi Roma Rome and the Vatican (non-fiction)
Elizabeth Lynn The Dancers of Arun (sff)
Elizabeth Lynn The Northern Girl (sff)
Rhonda Mason Empress Game (sff)
Vonda N. McIntyre Starfarers (sff)
Linda Nagata Memory (sff)
Jody Lynn Nye Strong Arm Tactics (sff)
Cat Rambo Near + Far (sff)
Kristine Kathryn Rusch The Diving Bundle (sff collection)
Kristine Kathryn Rusch Recovering Apollo 8 (sff)
L. Shelby Serendipity's Tide (sff)
L. Shelby Treachery's Harbor (sff)
L. Shelby Fealty's Shore (sff)
K.B. Spangler Digital Divide (sff)
Judith Tarr Forgotten Suns (sff)
Greg van Eekhout California Bones (sff) Hm, that's quite a lot. Most of it is various ebooks I picked up from various places, including a Humble Bundle. I've been impulse-buying a lot of stuff based on James Nicoll's reviews. The travel guide was a gift from a friend from a vacation in Italy.

Review: My Real Children, by Jo Walton

Publisher:	Tor
Copyright:	May 2014
ISBN:	0-7653-3265-5
Format:	Hardcover
Pages:	317

Patricia, the one form of her name that she's never used, is what the staff in the nursing home call her. "VC" is the frequent annotation on her daily chart: very confused. She's old, and forgetful, and trying very hard not to be her mother, and she remembers two lives. Not only remembers but lives: the nursing home isn't the same from day to day. They keep misplacing the lift, and the staff keep changing. But the memories are the strongest. She has two lives, two sets of children, all of whom she recognizes. When someone from one life visits, the other feels like a dream, but both of them persist. Two lives that divided at the most significant decision of her life. My Real Children is one of those books that fits in the broader speculative fiction genre as alternate history, but also has many of the virtues of mimetic fiction. It's the story of one woman's life, told, except for the opening frame, chronologically from start to finish. At the start, it's simple biography, telling Patty's story from childhood, through World War II, until the moment of her fateful decision in 1949. From there the narrative splits, and she lives two lives. And the world splits as well: in one, Kennedy was assassinated by a bomb; in another, the Cuban Missile Crisis escalated into something much worse. Much is still unchanged, including the general lives of people Patty knew well in one life and not in another, but the worlds keep diverging from each other and from ours. The exact nature of the divergence is not, however, a significant part of the book. This is not the type of alternate history that is obsessed with the point of change, or even the implications for the world. Rather, this novel is about one woman, one decision, and two very different paths through life. Different friends, different challenges, different careers... different hopes and dreams, and different children. But always the same person, the same sense of practicality, the same ethics. It's beautifully told, striking just the right balance of showing important moments in detail and passing quickly, but smoothly, over some years. And, as with Among Others, Walton strikes the perfect emotional balance, leaving some reactions understated, letting the reader bring their own reactions to the book, and filling it with small bits of telling, factual detail rather than internal monologues. This is also one of the most heart-wrenching books I've ever read. My Real Children is a whole life, and not an easy one, complete with the heartaches and betrayals, the good and bad decisions, care for elderly relatives, dementia, tragedy, and even abuse. And moments of shining joy or profound satisfaction, but made all the more poignant because they're fleeting. The reader knows, in a sense, how the story ends, which casts a shadow over the rest of the book. But, even without that shadow, life can be hard, or cruel, alongside the wonder and joy. And it ends, and the ending is not neat and clean and uplifting, although one can choose how one meets it. This is the story of a life, all of it, and how choices can divide that life, and how they can cast a long shadow over how one later defines oneself. This book hurts. A lot. Enough that I want to warn you in advance I was in tears through the last third of the book. But it hurts because it's so very real and deep, not via a blow-by-blow description of daily actions, but by striding unafraid into the deep complications of choice and consequence. It's also a profoundly feminist book, in a quiet and descriptive way. It shared the Tiptree award for 2015 and fully deserved it. Both of the protagonist's lives are struggles against expectations, around gender, sexuality, and the role of women in society. Those struggles take very different forms, but they share some deep similarities. Walton shows the impact from the bottom up: the effects on specific lives, specific people, specific situations. It's brilliantly done. One can't help but think of The Female Man given the telling of parallel lives, but this is a case study, whereas Russ's novel was a battle cry. It gets under your skin instead of in your face. (Use of subtlety on this topic is easier now, forty years of occasional progress past when Russ wrote her classic.) This is a much harder book to read than Among Others. It's less forgiving, less reassuring, less willing to provide a happy ending. Lives rarely have clean, happy endings; one has to construct them, by choosing the material to build the ending on. But it's a brilliant, profound book, in that way that stories about people in all their complexity can be. Be cautious about your mood when you read this, particularly if you've had the experience of caring for a dying relative, but it's a book I will remember for a very long time. Rating: 9 out of 10

Although I've been writing a bit recently about file-storage, this post is about something much more simple: Just making a random file or two available on an ad-hoc basis. In the past I used to have my email and website(s) hosted on the same machine, and that machine was well connected. Making a file visible just involved running ~/bin/publish, which used scp to write a file beneath an apache document-root. These days I use "my computer", "my work computer", and "my work laptop", amongst other hosts. The SSH-keys required to access my personal boxes are not necessarily available on all of these hosts. Add in firewall constraints and suddenly there isn't an obvious way for me to say "Publish this file online, and show me the root". I asked on twitter but nothing useful jumped out. So I ended up writing a simple server, via sinatra which would allow:

• Login via the site, and a browser. The login-form looks sexy via bootstrap.
• Upload via a web-form, once logged in. The upload-form looks sexy via bootstrap.
• Or, entirely seperately, with HTTP-basic-auth and a HTTP POST (i.e. curl)

This worked, and was even secure-enough, given that I run SSL if you import my CA file. But using basic auth felt like cheating, and I've been learning more Go recently, and I figured I should start taking it more seriously, so I created a small repository of learning-programs. The learning programs started out simply, but I did wire up a simple TOTP authenticator. Having TOTP available made me rethink things - suddenly even if you're not using SSL having an eavesdropper doesn't compromise future uploads. I'd also spent a few hours working out how to make extensible commands in go, the kind of thing that lets you run:

cmd sub-command1 arg1 arg2
cmd sub-command2 arg1 .. argN

The solution I came up with wasn't perfect, but did work, and allow the seperation of different sub-command logic. So suddenly I have the ability to run "subcommands", and the ability to authenticate against a time-based secret. What is next? Well the hard part with golang is that there are so many things to choose from - I went with gorilla/mux as my HTTP-router, then I spend several hours filling in the blanks. The upshot is now that I have a TOTP-protected file upload site:

publishr init    - Generates the secret
publishr secret  - Shows you the secret for import to your authenticator
publishr serve   - Starts the HTTP daemon

Other than a lack of comments, and test-cases, it is complete. And stand-alone. Uploads get dropped into ./public, and short-links are generated for free. If you want to take a peak the code is here:

• https://github.com/skx/go-experiments/tree/master/publishr

The only annoyance is the handling of dependencies - which need to be "go got ..". I guess I need to look at godep or similar, for my next learning project. I guess there's a minor gain in making this service available via golang. I've gained protection against replay attacks, assuming non-SSL environment, and I've simplified deployment. The downside is I can no longer login over the web, and I must use curl, or similar, to upload. Acceptible tradeoff.

Categories:

• Debian-Blog
• Rant

Keywords:

• Google
• Encryption
• Privacy
• Cloud

Like: