Planet Debian

Subscribe to Planet Debian feed
Planet Debian -
Updated: 24 min 3 sec ago

Russ Allbery: Review: The Philosopher Kings

16 November, 2016 - 11:41

Review: The Philosopher Kings, by Jo Walton

Series: Thessaly #2 Publisher: Tor Copyright: June 2015 ISBN: 0-7653-3267-1 Format: Hardcover Pages: 345

Despite the cliffhanger at the end of The Just City, The Philosopher Kings doesn't pick up immediately afterwards. Argh. It's a great book (as I'm about to describe), but I really wanted to also read that book that happened in between. Still, this is the conclusion to the problem posed in The Just City, and I wouldn't recommend reading this book on its own (or, really, either book separate from the other).

Despite the unwanted gap, and another change at the very start of the book that I won't state explicitly since it's a spoiler but that made me quite unhappy (despite driving the rest of the plot), this is much closer to the book that I wanted to read. Walton moves away from the SF philosophical question that drove much of the second half of The Just City in favor of going back to arguments about human organization, the nature of justice, choices between different modes of life, and the nature of human relationships. Those were the best parts of The Just City, and they're elaborated here in some fascinating ways that wouldn't have been possible in the hothouse environment of the previous book.

I also thought Apollo was more interesting here than in the previous book. Still somewhat infuriating, particularly near the start, but I felt like I got more of what Walton was trying for, and more of what Apollo was attempting to use this existence to understand. And, once the plot hits its stride towards the center of the book, I started really liking Apollo. I guess it took a book and a half for him to mature enough to be interesting.

A new viewpoint character, Arete, gets most of the chapters in this book, rather than following the pattern of The Just City and changing viewpoint characters every chapter. Her identity is a spoiler for The Just City, so I'll leave that a mystery. She's a bit more matter-of-fact and observational than Maia, but she does that thing that I love in Walton's characters: take an unexpected, fantastic situation, analyze and experiment with it, and draw some practical and matter-of-fact conclusions about how to proceed.

I think that's the best way to describe this entire series: take a bunch of honest, thoughtful, and mostly good people, put them into a fantastic situation (at first Plato's Republic, a thought experiment made real, and then some additional fantasy complexities), and watch them tackle that situation like reasonable human beings. There is some drama, of course, because humans will disagree and will occasionally do awful, or just hurtful, things to each other. But the characters try to defuse the drama, try to be thoughtful and fair and just in their approach, and encourage change, improvement, and forgiveness in others. I don't like everyone in these books, but the vast majority of them are good people (and the few who aren't stand out), and there's something satisfying in reading about them. And the philosophical debate is wonderful throughout this book (which I'm not saying entirely because the characters have a similar reaction to a newly-introduced philosophical system as I did as a reader, although that certainly helps).

I'm not saying much about the plot since so much would spoil the previous book. But Walton adds some well-done complexities and complications, and while I was dubious about them at the start of the book, I definitely came around. I enjoyed watching the characters reinvent some typical human problems, but still come at them from a unique and thoughtful angle and come up with some novel solutions. And the ending took me entirely by surprise, in a very good way. It's better than the best ending I could have imagined for the book, providing some much-needed closure and quite a bit of explanation. (And, thankfully, does not end on another cliffhanger; in fact, I'm quite curious to see what the third book is going to tackle.)

Recommended, including the previous book, despite the bits that irritated me.

Followed by Necessity.

Rating: 9 out of 10

Antoine Beaupré: The Turris Omnia router: help for the IoT mess?

15 November, 2016 - 22:28

The Turris Omnia router is not the first FLOSS router out there, but it could well be one of the first open hardware routers to be available. As the crowdfunding campaign is coming to a close, it is worth reflecting on the place of the project in the ecosystem. Beyond that, I got my hardware recently, so I was able to give it a try.

A short introduction to the Omnia project

The Omnia router is a followup project on CZ.NIC's original research project, the Turris. The goal of the project was to identify hostile traffic on end-user networks and develop global responses to those attacks across every monitored device. The Omnia is an extension of the original project: more features were added and data collection is now opt-in. Whereas the original Turris was simply a home router, the new Omnia router includes:

  • 1.6GHz ARM CPU
  • 1-2GB RAM
  • 8GB flash storage
  • 6 Gbit Ethernet ports
  • SFP fiber port
  • 2 Mini-PCI express ports
  • mSATA port
  • 3 MIMO 802.11ac and 2 MIMO 802.11bgn radios and antennas
  • SIM card support for backup connectivity

Some models sold had a larger case to accommodate extra hard drives, turning the Omnia router into a NAS device that could actually serve as a multi-purpose home server. Indeed, it is one of the objectives of the project to make "more than just a router". The NAS model is not currently on sale anymore, but there are plans to bring it back along with LTE modem options and new accessories "to expand Omnia towards home automation".

Omnia runs a fork of the OpenWRT distribution called TurrisOS that has been customized to support automated live updates, a simpler web interface, and other extra features. The fork also has patches to the Linux kernel, which is based on Linux 4.4.13 (according to uname -a). It is unclear why those patches are necessary since the ARMv7 Armada 385 CPU has been supported in Linux since at least 4.2-rc1, but it is common for OpenWRT ports to ship patches to the kernel, either to backport missing functionality or perform some optimization.

There has been some pressure from backers to petition Turris to "speedup the process of upstreaming Omnia support to OpenWrt". It could be that the team is too busy with delivering the devices already ordered to complete that process at this point. The software is available on the CZ-NIC GitHub repository and the actual Linux patches can be found here and here. CZ.NIC also operates a private GitLab instance where more software is available. There is technically no reason why you wouldn't be able to run your own distribution on the Omnia router: OpenWRT development snapshots should be able to run on the Omnia hardware and some people have installed Debian on Omnia. It may require some customization (e.g. the kernel) to make sure the Omnia hardware is correctly supported. Most people seem to prefer to run TurrisOS because of the extra features.

The hardware itself is also free and open for the most part. There is a binary blob needed for the 5GHz wireless card, which seems to be the only proprietary component on the board. The schematics of the device are available through the Omnia wiki, but oddly not in the GitHub repository like the rest of the software.

Hands on

I received my own router last week, which is about six months late from the original April 2016 delivery date; it allowed me to do some hands-on testing of the device. The first thing I noticed was a known problem with the antenna connectors: I had to open up the case to screw the fittings tight, otherwise the antennas wouldn't screw in correctly.

Once that was done, I simply had to go through the usual process of setting up the router, which consisted of connecting the Omnia to my laptop with an Ethernet cable, connecting the Omnia to an uplink (I hooked it into my existing network), and go through a web wizard. I was pleasantly surprised with the interface: it was smooth and easy to use, but at the same time imposed good security practices on the user.

For example, the wizard, once connected to the network, goes through a full system upgrade and will, by default, automatically upgrade itself (including reboots) when new updates become available. Users have to opt-in to the automatic updates, and can chose to automate only the downloading and installation of the updates without having the device reboot on its own. Reboots are also performed during user-specified time frames (by default, Omnia applies kernel updates during the night). I also liked the "skip" button that allowed me to completely bypass the wizard and configure the device myself, through the regular OpenWRT systems (like LuCI or SSH) if I needed to.

Notwithstanding the antenna connectors themselves, the hardware is nice. I ordered the black metal case, and I must admit I love the many LED lights in the front. It is especially useful to have color changes in the reset procedure: no more guessing what state the device is in or if I pressed the reset button long enough. The LEDs can also be dimmed to reduce the glare that our electronic devices produce.

All this comes at a price, however: at \$250 USD, it is a much higher price tag than common home routers, which typically go for around \$50. Furthermore, it may be difficult to actually get the device, because no orders are being accepted on the Indiegogo site after October 31. The Turris team doesn't actually want to deal with retail sales and has now delegated retail sales to other stores, which are currently limited to European deliveries.

A nice device to help fight off the IoT apocalypse

It seems there isn't a week that goes by these days without a record-breaking distributed denial-of-service (DDoS) attack. Those attacks are more and more caused by home routers, webcams, and "Internet of Things" (IoT) devices. In that context, the Omnia sets a high bar for how devices should be built but also how they should be operated. Omnia routers are automatically upgraded on a nightly basis and, by default, do not provide telnet or SSH ports to run arbitrary code. There is the password-less wizard that starts up on install, but it forces the user to chose a password in order to complete the configuration.

Both the hardware and software of the Omnia are free and open. The automatic update's EULA explicitly states that the software provided by CZ.NIC "will be released under a free software licence" (and it has been, as mentioned earlier). This makes the machine much easier to audit by someone looking for possible flaws, say for example a customs official looking to approve the import in the eventual case where IoT devices end up being regulated. But it also makes the device itself more secure. One of the problems with these kinds of devices is "bit rot": they have known vulnerabilities that are not fixed in a timely manner, if at all. While it would be trivial for an attacker to disable the Omnia's auto-update mechanisms, the point is not to counterattack, but to prevent attacks on known vulnerabilities.

The CZ.NIC folks take it a step further and encourage users to actively participate in a monitoring effort to document such attacks. For example, the Omnia can run a honeypot to lure attackers into divulging their presence. The Omnia also runs an elaborate data collection program, where routers report malicious activity to a central server that collects information about traffic flows, blocked packets, bandwidth usage, and activity from a predefined list of malicious addresses. The exact data collected is specified in another EULA that is currently only available to users logged in at the Turris web site. That data can then be turned into tweaked firewall rules to protect the overall network, which the Turris project calls a distributed adaptive firewall. Users need to explicitly opt-in to the monitoring system by registering on a portal using their email address.

Turris devices also feature the Majordomo software (not to be confused with the venerable mailing list software) that can also monitor devices in your home and identify hostile traffic, potentially leading users to take responsibility over the actions of their own devices. This, in turn, could lead users to trickle complaints back up to the manufacturers that could change their behavior. It turns out that some companies do care about their reputations and will issue recalls if their devices have significant enough issues.

It remains to be seen how effective the latter approach will be, however. In the meantime, the Omnia seems to be an excellent all-around server and router for even the most demanding home or small-office environments that is a great example for future competitors.

Note: this article first appeared in the Linux Weekly News.

Enrico Zini: Software quality in 2016

15 November, 2016 - 19:01

Ansible's default output, including the stderr of failed commands, is JSON encoded, which makes reading Jenkins' output hard.

Ansible however has Callback plugins that could be used. In that page it says:

Ansible comes with a number of callback plugins that you can look at for examples. These can be found in lib/ansible/plugins/callback.

That is a link to a git repo with just a pile of Python sources and no, say index to what they do. Hopefully they have some docstring with a short description of what they do? no.

Actually, some do, but just because someone copypasted the default one and didn't even bother removing its docstring.

Keith Packard: AltOS-Lisp

15 November, 2016 - 14:11
A Tiny Lisp for AltOS

I took a bit of a diversion over the last week or so when I wondered how small a lisp interpreter I could write, and whether I could fit that into one of the processors that AltOS runs on. It turns out, you can write a tiny lisp interpreter that fits in about 25kB of ram with a 3kB heap for dynamic data.

I decided to target our ChaosKey boards; they're tiny, and I've got a lot of them. That processor offers 28kB of usable flash space (after the 4kB boot loader) and 6kB of ram with the processor running at a steaming 48MHz.

I'm not at all sure this is useful, but I always enjoy doing language implementations, and this one presented some 'interesting' challenges:

  • Limited RAM. I don't have space to do a classic stop/copy collector.

  • Limited stack. A simple lisp implementation uses the C stack for all recursion in execution and memory collection. I don't have enough ram for that.

Iterative Compacting Allocator

I'm betting someone has built one of these before, but I couldn't find one, so I wrote my own.

The basic strategy is to walk the heap to find a subset of the active objects which are allocated sequentially in memory with only unused storage between them. These objects are then compacted in-place, and then the heap is walked again to update all references to the moved objects. Then, the process is restarted to find another subset and move them.

By looking for these subsets starting at the bottom of the heap, and working upwards towards the top, the whole heap can be compacted into a contiguous chunk at the bottom of memory.

Allocation involves moving a pointer along at the top of active memory; when it gets to the top of the heap, collect and see if there's space now.

As always, the hardest part was to make sure all active memory was tied down. The second hardest part was to make sure that all active pointers were updated after any allocation, in case a collect moved the underlying object. That was just bookkeeping, but did consume much of the development time.

One additional trick was to terminate the recursion during heap walking by flagging active cons cell locations in a global bitmap and then walking that separately, iterating until that bitmap is empty. Nested lambdas form another recursion which should probably get the same approach, but I haven't done that yet.

An unexpected "benefit" of the tiny heap is that the collector gets called a lot, so any referencing bugs will have a good chance of being uncovered in even a short program execution.

ROM-able Lisp

Instead of implementing all of the language in C, I wanted to be able to implement various pieces in Lisp itself. Because of the complex nature of the evaluation process, adding things like 'let' or even 'defun' turn out to be dramatically simpler in Lisp. However, I didn't want to consume bunches of precious RAM to hold these basic functions.

What I did was to create two heaps, one in ROM and the other in RAM. References are be tagged as to which heap they're in.

16-bit Values

Lisp programs use a pile of references. Using a full 32 bits for each one would mean having a lot less effective storage. So, instead, I use an offset from the base of the heap. The top bit of the offset is used to distinguish between the ROM heap and the RAM heap.

I needed a place to store type information, so I settled on using the bottom two bits of the references. This allows for four direct type values. One of these values is used to indicate an indirect type, where the type is stored in the first byte of the object. The direct types are:

ValueType 0Cons cell 114-bit int 2String 3Other

With 2 tag bits, the allocator needs to work in 32-bit units as the references couldn't point to individual bytes. Finally, I wanted 0 to be nil, so I add four to the offsets within the heaps.

The result is that the ROM and RAM heaps can each cover up to 32k - 4 bytes.

Note that ints are not stored in the heap; instead they are immediate values stored in 14 bits, providing a range of -8192 to 8191. One can imagine wanting more range in ints at some point.

Heap-based Evaluator

A simple lisp implementation uses the fact that eval is re-entrant and do the operation on the C stack:

val eval(val exprs) {
    val vals;

    while (exprs) {
        vals = append(vals, eval(car(exprs)));
        exprs = exprs->cdr;
    return execute (car(vals), cdr(vals));

This makes things really simple and provides for a clean framework for implementing various bits of lisp, including control flow and macros. However, it rapidly consumes all of the available memory for a stack, while also requiring separate bookkeeping for the in-use memory in each frame.

I replaced this design with one which keeps the lisp stack on the heap, and then performs eval with a state machine with all state stored in global variables so that the memory manager can reference them directly.

Each eval operation is performed in a separate 'stack' context, which holds the entire eval state except for the current value, which lives in a separate global variable and is used to pass values out of one stack frame and into another. When the last stack context is finished, the evaluation terminates and the value is returned to the caller.

There are nine states in the state machine, each of which is implemented in a separate function, making the state machine a simple matter of pulling the current state from the top of the stack and invoking the associated function:

while (ao_lisp_stack) {
    if (!(*evals[ao_lisp_stack->state])() || ao_lisp_exception) {
        return AO_LISP_NIL;
return ao_lisp_v;

Because there's no C recursion involved, catching exceptions is a simple matter of one test at this level.

Primitives like progn, while, cond and eval all take special magic in the state machine to handle; getting all of that working took several attempts before I found the simple loop shown above.

Lexical Scoping

The last time I did a lisp interpreter, I implemented dynamic scoping. Atoms were all global and had values associated directly with them. Evaluating a lambda started by saving all of the existing global values for the parameter atoms and then binding the new values. When finished, the previous values would be restored. This is almost correct, but provides surprising results for things like:

> (setq baz 1)
> (def foo (lambda (bar) (+ baz bar)))
> (def bletch (lambda (baz) (foo baz)))
> (bletch 2)

The value that foo gets for 'baz' is 2 instead of 1 under dynamic scoping, which most people find surprising. This time, I was determined to use lexical scoping, and it turned out to be surprisingly easy.

The first trick was to separate the atoms from their 'value'; each atom can have a different value in different lexical scopes. So, each lexical scope gets a 'frame' object, those contain the value for each atom defined in that scope. There's a global scope which holds all of the globally defined values (like baz, foo and bletch above). Each frame points to its enclosing scope, so you can search upwards to find the right value.

The second trick was to realize that the lexical scope of a lambda is the scope in which the lambda itself is evaluated, and that the evaluation of a lambda expression results in a 'function' object, which contains the lambda and its enclosing scope:

> (def foo (lambda (bar bletch)
       ((lambda (baz)
          (+ baz bar))
> (foo 2 3)

In this case, the inner lambda in foo can 'see' the value of bar from the enclosing lambda. More subtly, even if the inner lambda were executed multiple times, it would see the same baz, and could even change it. This can be used to implement all kinds of craziness, including generators:

> (defun make-inc (add)
  ((lambda (base)
     (lambda ()
     (setq base (+ base add))

> (setq plus2 (make-inc 2))
> (plus2)
> (plus2)

The current implementation of each frame is a simple array of atom/value pairs, with a reference to the parent frame to form the full scope. There are dramatically faster implementations of this same concept, but the goal here was small and simple.

A Tiny Allocator Optimization

With eval consuming heap space for stacks, frames and argument lists, the interpreter was spending a lot of time in the collector. As a simple optimization, I added some free lists for stack frames and cons cells.

Stack frames are never referenced when they're finished, so they can always go on the free list. Cons cells used to construct argument lists for functions are usually free.

Builtin functions have a bit which indicates whether they might hold on to a reference to the argument list. Interpreted lambdas can't get the list while nlambdas, lexprs and macros do.

Each lambda execution creates a new frame, and while it would be possible to discover if that frame 'escapes' the lambda, I decided to not attempt to cache free ones yet.

Save and Restore

To make the lisp interpreter more useful in tiny computers, I added the ability to save and restore the entire heap to flash. This requires leaving enough space in the flash to preserve the heap, further constraining the amount of flash available for the application.


All of this code is in the 'lisp' branch of my AltOS repository:


The lisp interpreter is independent from the rest of AltOS and could be re-purposed for another embedded operating system. It runs fine on ChaosKey hardware, and also on the STM32F042 Nucleo-32 board

There's also a test framework which runs on Linux, and is how I developed almost all of the code. That's in the src/test directory in the above repository, and is called 'ao_lisp_test'.

Towers of Hanoi

Here's an implementation of the classic recursive Towers of Hanoi game; it shows most of the current features of the language.

; Towers of Hanoi
; Copyright © 2016 Keith Packard <>
; This program is free software; you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation, either version 2 of the License, or
; (at your option) any later version.
; This program is distributed in the hope that it will be useful, but
; WITHOUT ANY WARRANTY; without even the implied warranty of
; General Public License for more details.

; ANSI control sequences

(defun move-to (col row)
  (patom "\033[" row ";" col "H" nil)

(defun clear ()
  (patom "\033[2J" nil)

(defun display-string (x y str)
  (move-to x y)
  (patom str)

; Here's the pieces to display

(setq stack '("*" "**" "***" "****" "*****" "******" "*******"))

(setq top (+ (length stack) 3))

; Here's all of the stacks of pieces
; This is generated when the program is run
(setq stacks nil)

; Display one stack, clearing any
; space above it

(defun display-stack (x y clear stack)
  (cond ((= 0 clear)
     (cond (stack (progn
            (display-string x y (car stack))
            (display-stack x (1+ y) 0 (cdr stack))
    (t (progn
         (display-string x y "          ")
         (display-stack x (1+ y) (1- clear) stack)

; This should probably be included in the rom image...

(defun length (list)
  (cond (list (1+ (length (cdr list))))

; Position of the top of the stack on the screen
; Shorter stacks start further down the screen

(defun stack-pos (y stack)
  (- y (length stack))

; Display all of the stacks, spaced 20 columns apart

(defun display-stacks (x y stacks)
  (cond (stacks (progn
          (display-stack x 0 (stack-pos y (car stacks)) (car stacks))
          (display-stacks (+ x 20) y (cdr stacks)))

; Display all of the stacks, then move the cursor
; out of the way and flush the output

(defun display ()
  (display-stacks 0 top stacks)
  (move-to 1 21)

; Reset stacks to the starting state, with
; all of the pieces in the first stack and the
; other two empty

(defun reset-stacks ()
  (setq stacks (list stack nil nil))
  (length stack)

; more functions which could usefully
; be in the rom image

(defun min (a b)
  (cond ((< a b) a)

(defun nth (list n)
  (cond ((= n 0) (car list))
    ((nth (cdr list) (1- n)))

; Replace a stack in the list of stacks
; with a new value

(defun replace (list pos member)
  (cond ((= pos 0) (cons member (cdr list)))
    ((cons (car list) (replace (cdr list) (1- pos) member)))

; Move a piece from the top of one stack
; to the top of another

(defun move-piece (from to)
  (let ((from-stack (nth stacks from))
    (to-stack (nth stacks to))
    (piece (car from-stack)))
    (setq from-stack (cdr from-stack))
    (setq to-stack (cons piece to-stack))
    (setq stacks (replace stacks from from-stack))
    (setq stacks (replace stacks to to-stack))
    (delay 100)

; The implementation of the game

(defun _hanoi (n from to use)
  (cond ((= 1 n)
      (move-piece from to)
      (_hanoi (1- n) from use to)
      (_hanoi 1 from to use)
      (_hanoi (1- n) use to from)

; A pretty interface which
; resets the state of the game,
; clears the screen and runs
; the program

(defun hanoi ()
  (setq len (reset-stacks))
  (_hanoi len 0 1 2)

Russ Allbery: Review: The Broken Kingdoms

15 November, 2016 - 10:29

Review: The Broken Kingdoms, by N.K. Jemisin

Series: Inheritance #2 Publisher: Orbit Copyright: November 2010 Printing: September 2011 ISBN: 0-316-04395-8 Format: Mass market Pages: 395

The Broken Kingdoms is a fairly direct sequel to The Hundred Thousand Kingdoms and depends heavily on the end of that book. It had been a long time since I'd read the previous book (about five years), and I looked up plot summaries to remind myself what happened. It turned out that I probably didn't have to do that; the explanation does come when it's critical. But this book will definitely spoil the end of The Hundred Thousand Kingdoms.

Oree is an artist who sells her work to tourists in Shadow, the city beneath the World Tree. It's a good enough living, particularly for a blind immigrant from Nimaro, the area settled by the survivors of the destruction of Maro. Oree is not strictly entirely blind, since she can see magic, but that's not particularly helpful in daily life. She's content to keep that quiet, along with her private paintings that carry a strange magic not found in her public trinkets.

One of the many godlings who inhabit Shadow is Oree's former lover, so she has some connection to the powerful of the city. But she prefers her quiet life — until, that is, she finds a man at sunrise in a pile of muck and takes him home to clean him up. A man who she ends up taking care of, despite the fact that he never speaks to her, and despite his total lack of desire or apparent capability to take care of himself or avoid any danger. Not that it seems to matter, since he comes back to life every time he dies.

If you've read The Hundred Thousand Kingdoms, you have a pretty good guess at who the man Oree calls Shiny actually is. But that discovery is not the core plot of this book. Someone is killing the godlings. They're not immortal, although they don't age, but killing them should require immense power or the intervention of the Three, the gods who run the metaphysical universe of this series. Neither of those seem to be happening, and still godlings are being murdered. Nahadoth is not amused: the humans and godlings have one month to find the killer before he does something awful to all of them. Then Shiny somehow kills a bunch of priests of Itempas, and the Order is after both him and Oree. Desperate, she turns to her former boyfriend and the godlings for help, and is pulled into the heart of a dark conspiracy.

The Broken Kingdoms adds a few new elements to Jemisin's world-building, although it never quite builds up to the level of metaphysics of the previous book. But it's mostly a book about Oree: her exasperated care of Shiny, her attempts to navigate her rapidly complicating life, and her determination to do the right thing for her friends. It's the sort of book that pits cosmic power and grand schemes against the determined inner morality of a single person who is more powerful than she thinks she is. That part of the story I liked quite a lot.

Shiny, and Oree's complicated relationship with Shiny, I wasn't as fond of. Oree treats him like a broken and possibly healing person, which is true, but he's also passively abusive in his dark moping. Jemisin tries very hard throughout the book to help the reader try to grasp a bit of what must be going through Shiny's head, and she does succeed at times, but I never much cared for what I found there. And neither Nahadoth nor Yeine, when they finally make their appearance, are very likable. (Yeine in particular I found deeply disappointing and not up to her level of ethics in the first book.) Oree is still quite capable of carrying the story single-handed, and I did like her godling friends. But I felt like the ending required liking Shiny a lot more than I did, or being a lot more sympathetic to Nahadoth and Yeine than I was, and it left a bad taste in my mouth. I enjoyed reading about Oree, but I felt like this story gave her a remarkably depressing ending.

This book is also structured with a long middle section where everything seems to get more and more horrible and the antagonists are doing awful things. It's a common structural way to build tension that I rarely like. Even knowing that there's doubtless an upward arc and protagonist triumph coming, those sections are often unpleasant and difficult to read through, and I had that reaction here.

The Broken Kingdoms is less of a weird romance than The Hundred Thousand Kingdoms (although there is some romance), so you may enjoy it more if you thought that angle was overdone. It does have some interesting world-building, particularly at the godling level, and Lil is one of my favorite characters. I think Oree got a raw deal from the story and would have preferred a different ending, but I'm not sorry I read it.

Followed by The Kingdoms of Gods.

Rating: 7 out of 10

Mike Gabriel: Debian Edu development sprint in Oslo from Nov 25th - Nov 27th 2016

15 November, 2016 - 03:08

For those of you, who already thought about joining us in Oslo for our Debian Edu sprint, here comes your short reminder for signing up on this wiki page and then book your travel.

For those of you, who have learned about our upcoming sprint just now, feel heartily invited to meet and join the Debian Edu team (and friends) in Oslo. Check with your family and friends, if they may let you go. Do that now, put your name onto our wiki page and and book your journey.

Those of you, who cannot travel to Oslo, but feel like being interested in Debian and educational topics around Free Software, put a note into your calendar, so you don't forget to join us on IRC over that weekend (and any other time if you like): #debian-edu on

Looking forward to meeting you at end of November,
Mike (aka sunweaver)

Rapha&#235;l Hertzog: Freexian’s report about Debian Long Term Support, October 2016

15 November, 2016 - 00:15

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In October, about 175 work hours have been dispatched among 14 paid contributors. Their reports are available:

Evolution of the situation

The number of sponsored hours did not change this month. We still need a couple of supplementary sponsors to reach our objective of funding the equivalent of a full time position.

The security tracker currently lists 34 packages with a known CVE and the dla-needed.txt file 29. The situation improved slightly compared to last month.

Thanks to our sponsors

New sponsors are in bold.

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

Ben Hutchings: Debian LTS work, October 2016

15 November, 2016 - 00:03

I was assigned 13.75 hours of work by Freexian's Debian LTS initiative and worked all of them.

I reviewed the fix for CVE-2016-7796 in wheezy's systemd, which needed substantial changes and a few iterations to get right.

I updated linux to the 3.2.82 stable release (and 3.2.82-rt119 for PREEMPT_RT), and added fixes for several security issues including CVE-2016-5195 "Dirty Cow". I uploaded and issued DLA-670-1.

In my role as Linux 3.2 stable maintainer, I made a 3.2.83 release fixing just that issue, and started to prepare a 3.2.84 release with many more fixes.

I cleaned up my work on imagemagick, but didn't go further through the backlog of issues. I put the partly updated package on for another LTS maintatainer to pick up.

Dimitri John Ledkov: /boot less LVM rootfs in Zesty

14 November, 2016 - 22:11

On Ubuntu many of the default boot loaders support booting kernels located on LVM volumes. This includes following platforms

  • i686, x86_64 bios grub2
  • arm64, armhf, i686, x86_64 UEFI grub2
  • PReP partitions on IBM PowerPC
  • zipl on IBM zSystems
For all of the above the d-i has been modified in Zesty to create LVM based installations without a dedicated /boot partition. We shall celebrate this achievement. Hopefully this means one doesn't need to remove kernels as much, or care about sizing /boot volume appropriately any more.
If there are more bootloaders in Ubuntu that support booting off LVM, please do get in touch with me. I'm interested if I can safely enable following platforms as well:
  • armhf with u-boot
  • arm64 with u-boot
  • ppc64el with PReP volume
ps. boots pic is from here

Gregor Herrmann: RC bugs 2016/40-45

14 November, 2016 - 05:23

time for a quick update, I guess. here's the list of release-critical bugs in debian I've worked on during the last couple of weeks.

  • #825608 – libnet-jifty-perl: "libnet-jifty-perl: FTBFS: t/006-uploads.t failure"
    patch test for compatibility with newer Encode, not uploaded in the end because the problem is more likely in the code (pkg-perl)
  • #826192 – libmath-gsl-perl: "libmath-gsl-perl: FTBFS with GSL 2"
    import new upstream release (pkg-perl)
  • #828386 – src:libcrypt-openssl-pkcs12-perl: "libcrypt-openssl-pkcs12-perl: FTBFS with openssl 1.1.0"
    sponsor upload with upstream patch (pkg-perl)
  • #828388 – src:libcrypt-openssl-x509-perl: "libcrypt-openssl-x509-perl: FTBFS with openssl 1.1.0"
    cherry-pick 2 commits from upstream git repo (pkg-perl)
  • #828389 – src:libcrypt-smime-perl: "libcrypt-smime-perl: FTBFS with openssl 1.1.0"
    import new upstream release (pkg-perl)
  • #828408 – src:libpoe-filter-ssl-perl: "libpoe-filter-ssl-perl: FTBFS with openssl 1.1.0"
    use openssl 1.0.2, & downgrade severity (pkg-perl)
  • #830280 – src:libfurl-perl: "libfurl-perl: accesses the internet during build"
    disable DNS queries during build (pkg-perl)
  • #834730 – src:libdist-zilla-plugins-cjm-perl: "libdist-zilla-plugins-cjm-perl: FTBFS: Failed 1/9 test programs. 2/126 subtests failed."
    add patch from CPAN RT (pkg-perl)
  • #839200 – libcpanplus-perl: "libcpanplus-perl: FTBFS: Failed test 'Cwd has correct version in report'"
    add patch from upstream git (pkg-perl)
  • #839505 – src:mongodb: "mongodb: FTBFS: Tests failures"
    propose a possible solution
  • #839580 – src:request-tracker4: "request-tracker4: FTBFS in testing (failed tests)"
    prepare a workaround patch
  • #839987 – libcompress-raw-lzma-perl: "libcompress-raw-lzma-perl: Version Mismatch due to new src:xz-utils"
    patch out version check at runtime (pkg-perl)
  • #839992 – libmath-quaternion-perl: "libmath-quaternion-perl: autopkgtest failure: not ok 48 - rotation_angle works"
    some triaging (pkg-perl)
  • #840479 – src:libdbd-firebird-perl: "libdbd-firebird-perl: FTBFS: not found"
    versioned close (pkg-perl)
  • #840980 – libperinci-sub-normalize-perl: "libperinci-sub-normalize-perl: FTBFS: Can't locate Sah/Schema/rinci/ in @INC"
    add new (build) dependency, after packaging it (pkg-perl)
  • #841545 – src:liborlite-perl: "liborlite-perl: FTBFS: Tests failures"
    fix sqlite commands (pkg-perl)
  • #841562 – src:libvideo-fourcc-info-perl: "libvideo-fourcc-info-perl: FTBFS: dh_auto_build: perl Build returned exit code 255"
    fix sqlite commands (pkg-perl)
  • #841573 – src:libdbix-class-perl: "libdbix-class-perl: FTBFS: Tests failures"
    patch test suite as recommended by upstream (pkg-perl)
  • #842460 – libplack-middleware-csrfblock-perl: "libplack-middleware-csrfblock-perl: FTBFS: missing dependencies on HTML::Parser"
    add missing (build) dependency (pkg-perl)
  • #842462 – libweb-simple-perl: "libweb-simple-perl: FTBFS: Can't locate HTTP/ in @INC"
    add missing (build) dependency (pkg-perl)
  • #842722 – src:kgb-bot: "kgb-bot: FTBFS (failing tests)"
    fix version comparison in test
  • #843704 – libnet-pcap-perl: "libnet-pcap-perl: FTBFS: t/09-error.t fails with newer libpcap"
    add patch from CPAN RT (pkg-perl)

Thorsten Glaser: “I don’t like computers”

14 November, 2016 - 03:28

cnuke@ spotted something on the internet, and shared. Do read this, including the comments. It’s so true. (My car is 30 years old, I use computers mostly for sirc, lynx and ssh, and I especially do not buy any product that needs to be “online” to work.)

Nice parts of the internet, to offset this, though, do exist. IRC as a way of cheap (affordable), mostly reliant, communication that’s easy enough to do with TELNET.EXE if necessary. Fanfiction; easy proliferation of people’s art (literature, in this case). Fast access to documentation and source code; OpenBSD’s AnonCVS was a first, nowadays almost everything (not Tom Dickey’s projects (lynx, ncurses, xterm, cdk, …), nor GNU bash, though) is on a public version control system repository. (Now people need to learn to not rewrite history, just commit whatever shit they do, to record thought process, not produce the perfect-looking patch.) Livestreams too, I guess, but ever since went dead due to a USA law change on 2016-01-02, it got bad.

Dirk Eddelbuettel: pkgKitten 0.1.4: Creating R Packages that purr

14 November, 2016 - 00:09

A new minor release 0.1.4 of pkgKitten just hit on CRAN this morning.

One small change is that the package manual page it creates now makes use of the (still new-ish and under-documented and under-used) Rd macros described at the end of Section 2.13 of Writing R Extensions:

See the system.Rd file in share/Rd/macros for more details and macro definitions, including macros \packageTitle, \packageDescription, \packageAuthor, \packageMaintainer, \packageDESCRIPTION and \packageIndices.

By using these macros, and referencing them from the DESCRIPTION file, we can avoid redundancy, or worse, inconsitency, between both files. Or just be plain lazy and describe things just once in the higher-level file: A good thing!

Otherwise we fixed a URL to the manual thanks to a PR, and just added some of the regular polish to some of the corners which R CMD check --as-cran is looking into:

Changes in version 0.1.4 (2016-11-13)
  • Utilize newer R macros in package-default manual page.

  • Repair a link to Wrting R Extensions (PR #7 by Josh O'Brien)

More details about the package are at the pkgKitten webpage and the pkgKitten GitHub repo.

Courtesy of CRANberries, there is also a diffstat report for this release

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

Andrew Cater: MiniDebconf ARM Cambridge 13/11/16 - Day 4 post 4 - lightning talks

13 November, 2016 - 20:58
Ian Jackson - dgit in two slides with attitude :)

Mike Crowe - Code Club - volunteering to teach programming to school children in after school clubs. Scratch: version 1 is packaged for Debian and Raspberry Pi  CSS HTML Python - all materials provided. Projects for Microbits as well. No slides.

Dimitri Ledkov - SPI board - explaining about SPI. SPI - US non-profit, also registered in Europe. Collects donations, can register trademarks, can hold assets on your project's behalf.  Volunteer project: controlled by member orgs.

Guus Sliepen - ifupdown -  dual protocol, bonding, VPNs, wireless,
- too many slides :)

Andrew Cater: MiniDebconf Cambridge, ARM, 13/11/16 - Day 4 post 3

13 November, 2016 - 18:37
Just about to watch Daniel Silverstone demonstrating his new FPGA board.

Mystorm - open hardware - growing out of Icestorm. Programmable hardware - toolchains - and showing the hardware.

The Debian video team have advised that they are about to start the transcoding process - videos will be available soonish :)

Petter Reinholdtsen: Coz profiler for multi-threaded software is now in Debian

13 November, 2016 - 18:30

The Coz profiler, a nice profiler able to run benchmarking experiments on the instrumented multi-threaded program, finally made it into Debian unstable yesterday. Lluís Vilanova and I have spent many months since I blogged about the coz tool in August working with upstream to make it suitable for Debian. There are still issues with clang compatibility, inline assembly only working x86 and minimized JavaScript libraries.

To test it, install 'coz-profiler' using apt and run it like this:

coz run --- /path/to/binary-with-debug-info

This will produce a profile.coz file in the current working directory with the profiling information. This is then given to a JavaScript application provided in the package and available from a project web page. To start the local copy, invoke it in a browser like this:

sensible-browser /usr/share/coz-profiler/viewer/index.htm

See the project home page and the USENIX ;login: article on Coz for more information on how it is working.

Andrew Cater: Debian MiniConf, ARM Cambridge, 13/11/12 - Day 4 post 2

13 November, 2016 - 18:10
Just watching Lars Wirzenius talking about Qvarn - identity and data protection management on large scale. Compliant with EC data/identity management regulations and concerns.

The room fell silent at 1100 for two minutes - as we did on Friday 11/11/12.
This is remembering the dead, wounded and those  affected by the wars of the 20th and 21st centuries.

Inevitably, it also reminded me of friends and colleagues in Debian that are no longer with us: for Espy and so many others before and since, thanks from me - you are well remembered here.

Daniel Pocock: Are all victims of French terrorism equal?

13 November, 2016 - 17:50

2015 saw a series of distressing terrorist attacks in France. It was also the 30th anniversary of the French Government's bombing of a civilian ship at port in New Zealand, murdering a photographer who was on board at the time. This horrendous crime has been chronicled in various movies including The Rainbow Warrior Conspiracy (1989) and The Rainbow Warrior (1993).

François Hollande and Ségolène Royal. Royal's brother Gérard Royal allegedly planted the bomb in the terrorist mission to New Zealand. It is ironic that Royal is now Minister for Ecology while her brother sank the Greenpeace flagship.

The question has to be asked: if it looks like terrorism, if it smells like terrorism, if the victim of that French Government attrocity is as dead as the victims of Islamic militants littered across the floor of the Bataclan, shouldn't it also be considered an act of terrorism?

If it was not an act of terrorism, then what is it that makes it differ? Why do French officials refer to it as nothing more than "a serious error", the term used by Prime Minister Manuel Valls by a recent visit to New Zealand in 2016? Was it the fact that the French officials involved felt they had Liberté, égalité, fraternité on their side? Or is it just a limitation of the English language that we only have one word for terrorism, while French officials have a different word for such acts carried out by those who serve their flag?

If the French government are sincere in their apology, why have they avoided releasing key facts about the attrocity, like who thought up this plot and who gave the orders? Did the soldiers involved volunteer for a mission with the code name Opération Satanique, or did any other members of their unit quit rather than have such a horrendous crime on their conscience? What does that say about the people who carried out the orders?

If somebody apprehended one of these rogue employees of the French Government today, would they be rewarded with France's highest honour, like those tourists who recently apprehended an Islamic terrorist on a high-speed train?

If terrorism is such an absolute evil, why was it so easy for the officials involved to progress with their careers? Would an ex-member of an Islamic terrorist group be able to subsequently obtain US residence and employment as easily as the French terror squad's commander Louis-Pierre Dillais?

When you consider the comments made by Donald Trump recently, the threats of violence and physical aggression against just about anybody he doesn't agree with, is this the type of diplomacy that the US will practice under his rule commencing in 2017? Are people like this motivated by a genuine concern for peace and security, or are these simply criminal acts of vengence backed by political leaders with the maturity of schoolyard bullies?

Andrew Cater: Debian MiniConf, ARM Cambridge 13/11/16 - Day 4 post 1

13 November, 2016 - 17:23
Just got here, partway into Guus Sliepen's talk about issues with sourceless packages and the DFSG. Lots of problems with, for example, music for games and imagery and also areas where packages autobuild / use generated blobs which are not supplied or are not able to be regenerated.

Checked in by front desk - thanks again to Lisa, to Jo McIntyre and Lucy Wayland who have been very patient waiting for us, very helpful as ever, chasing us at the end of each day to reconcile badges and people and doing all the useful stuff that no one sees.

ARM security folk are still here, obviously, and the building work has stopped for the weekend so we can get in and out of the building more readily.  Thanks once again to the ARM staffers who are also Debian-ites and to the ARM management who have to authorise all of this and allow us to use their facilities, buildings and guest WiFi. It's testament to a whole lot of hard work  behind the scenes that this all seems seamless and (generally) works so well

Hideki Yamane: LTS for PowerPC?

13 November, 2016 - 12:19
Debian9 "Stretch" drops powerpc as release architecture, it means Debian based powerpc box would need more effort to maintain in the future.

If you use Debian for powerpc box in production environment, it maybe better to consider to join LTS funding and ask LTS team to add it to Jessie LTS architecture. I'm not sure they accept it or not, but if it's okay (as they did for armel and armhf), it may be worth to reduce your trouble.

John Goerzen: Morning in the Skies

13 November, 2016 - 02:35

This is morning. Time to fly. Two boys, happy to open the hangar door and get the plane ready.

It’s been a year since I passed the FAA exam and became a pilot. Memories like these are my favorite reminders why I did. It is such fun to see people’s faces light up with the joy of flying a few thousand feet above ground, of the beauty and freedom and peace of the skies.

I’ve flown 14 different passengers in that time; almost every flight I’ve taken has been with people, which I enjoy. I’ve heard “wow” or “beautiful” so many times, and said it myself even more times.

I’ve landed in two state parks, visited any number of wonderful small towns, seen historic sites and placid lakes, ascended magically over forests and plains. I’ve landed at 31 airports in 10 states, flying over 13,000 miles.

Not once have I encountered anyone other than friendly, kind, and outgoing. And why not? After all, we’re working around magic flying carpet machines, right?

(That’s my brother before a flight with me, by the way)

Some weeks it is easy to be glum. This week has been that way for many, myself included. But then, whether you are in the air or on the ground, if you pay attention, you realize we still live in a beautiful world with many wonderful people.

And, in fact, I got a reminder of that this week. Not long after the election, I got in a plane, pushed in the throttle, and started the takeoff roll down a runway in the midst of an Indiana forest. The skies were the best kind of clear blue, and pretty soon I lifted off and could see for miles. Off in the distance, I could see the last cottony remnants of the morning’s fog, lying still in the valleys, surrounding the little farms and houses as if to give them a loving hug. Wow.

Sometimes the flight is bumpy. Sometimes the weather doesn’t cooperate, and it doesn’t happen at all. Sometimes you can fly across four large states and it feels as smooth as glass the whole way.

Whatever happens, at the end of the day, the magic flying carpet machine gets locked up again. We go home, rest our heads on our soft pillows, and if we so choose, remember the beauty we experienced that day.

Really, this post is not about being a pilot. This post is a reminder to pay attention to all that is beautiful in this world. It surrounds us; the smell of pine trees in the forest, the delight in the faces of children, the gentle breeze in our hair, the kind word from a stranger, the very sunrise.

I hope that more of us will pay attention to the moments of clear skies and wind at our back. Even at those moments when we pull the hangar door shut.


Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้