diff --git a/2017/flatpak_and_debian.mdwn b/2017/flatpak_and_debian.mdwn
index 55c03a3..12bdef2 100644
--- a/2017/flatpak_and_debian.mdwn
+++ b/2017/flatpak_and_debian.mdwn
@@ -8,7 +8,7 @@
 alt="Decorative photo of the indoor garden"
 caption="The indoor garden at Collège de Maisonneuve, the DebConf 17 venue"]]
 
-I'm currently at DebConf 17 in Montreal, back at DebConf for the first
+I'm currently at DebConf 17 in Montréal, back at DebConf for the first
 time in 10 years (last time was DebConf 7 in Edinburgh). It's great to
 put names to faces and meet more of my co-developers in person!
 

diff --git a/2017/flatpak_and_debian.mdwn b/2017/flatpak_and_debian.mdwn
index e2fc4ca..55c03a3 100644
--- a/2017/flatpak_and_debian.mdwn
+++ b/2017/flatpak_and_debian.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="DebConf 17: Flatpak and Debian"]]
 [[!meta date="2017-08-09 13:06:00 -04:00"]]
-[[!meta updated="2017-08-09 13:06:00 -04:00"]]
+[[!meta updated="2017-08-16 21:50:00 +01:00"]]
 [[!meta copyright="Copyright © 2017 Simon McVittie"]]
 [[!tag debian flatpak]]
 
@@ -12,17 +12,20 @@ I'm currently at DebConf 17 in Montreal, back at DebConf for the first
 time in 10 years (last time was DebConf 7 in Edinburgh). It's great to
 put names to faces and meet more of my co-developers in person!
 
-On Monday I gave a talk entitled “A Debian maintainer's guide to
-Flatpak”, aiming to introduce Debian developers to Flatpak, and show
+On Monday I gave a talk entitled “[A Debian maintainer's guide to
+Flatpak](https://debconf17.debconf.org/talks/59/)”, aiming to introduce
+Debian developers to Flatpak, and show
 how Flatpak and Debian (and Debian derivatives like SteamOS) can help
 each other. It seems to have been quite well received, with people
 generally positive about the idea of using Flatpak to deliver backports
 and faster-moving leaf packages (games!) onto the stable base platform
 that Debian is so good at providing.
 
-I've now put up my slides in the DebConf `git-annex` repository, with
+[A video of the talk](http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/a-debian-maintainer-s-guide-to-flatpak.vp8.webm) is available from the Debian
+Meetings Archive.
+I've also put up my slides in the DebConf `git-annex` repository, with
 some small edits to link to more source code:
-[A Debian maintainer's guide to Flatpak](https://annex.debconf.org/debconf-share/debconf17/slides/debconf17_smcv_flatpak.html).
+[A Debian maintainer's guide to Flatpak](https://annex.debconf.org/debconf-share/debconf17/slides/59-debian-maintainers-guide-to-flatpak.html).
 [Source code for the slides](https://git.collabora.com/cgit/user/smcv/dc17.git/)
 is also available from Collabora's git server.
 
@@ -47,4 +50,7 @@ derivatives, with a lot of flexibility during development but very limited
 state on deployed systems, and Endless' approach seems a perfect fit for
 those situations.
 
+\[Edited 2017-08-16 to fix the link for the slides, and add links for the
+video\]
+
 [[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]

diff --git a/2017/flatpak_and_debian.mdwn b/2017/flatpak_and_debian.mdwn
new file mode 100644
index 0000000..e2fc4ca
--- /dev/null
+++ b/2017/flatpak_and_debian.mdwn
@@ -0,0 +1,50 @@
+[[!meta title="DebConf 17: Flatpak and Debian"]]
+[[!meta date="2017-08-09 13:06:00 -04:00"]]
+[[!meta updated="2017-08-09 13:06:00 -04:00"]]
+[[!meta copyright="Copyright © 2017 Simon McVittie"]]
+[[!tag debian flatpak]]
+
+[[!img indoor-garden.jpg align=right
+alt="Decorative photo of the indoor garden"
+caption="The indoor garden at Collège de Maisonneuve, the DebConf 17 venue"]]
+
+I'm currently at DebConf 17 in Montreal, back at DebConf for the first
+time in 10 years (last time was DebConf 7 in Edinburgh). It's great to
+put names to faces and meet more of my co-developers in person!
+
+On Monday I gave a talk entitled “A Debian maintainer's guide to
+Flatpak”, aiming to introduce Debian developers to Flatpak, and show
+how Flatpak and Debian (and Debian derivatives like SteamOS) can help
+each other. It seems to have been quite well received, with people
+generally positive about the idea of using Flatpak to deliver backports
+and faster-moving leaf packages (games!) onto the stable base platform
+that Debian is so good at providing.
+
+I've now put up my slides in the DebConf `git-annex` repository, with
+some small edits to link to more source code:
+[A Debian maintainer's guide to Flatpak](https://annex.debconf.org/debconf-share/debconf17/slides/debconf17_smcv_flatpak.html).
+[Source code for the slides](https://git.collabora.com/cgit/user/smcv/dc17.git/)
+is also available from Collabora's git server.
+
+The next step is to take my proof-of-concept for building
+Flatpak runtimes and apps from Debian and SteamOS packages,
+[flatdeb](https://git.collabora.com/cgit/user/smcv/flatdeb.git/), get it
+a bit more production-ready, and perhaps start publishing some sample
+runtimes from a cron job on a Debian or Collabora server. (By the way,
+if you downloaded that source right after my talk, please update - I've
+now pushed some late changes that were necessary to fix the 3D drivers
+for my OpenArena demo.)
+
+I don't think Debian will be going quite as far as
+[Endless](https://endlessos.com/) any time soon: as
+Cosimo outlined in the talk right before mine, they
+deploy their Debian derivative as an immutable base OS with
+[libOSTree](https://ostree.readthedocs.io/en/latest/), with all the
+user-installable modules above that coming from Flatpak. That model is
+certainly an interesting thing to think about for Debian derivatives,
+though: at Collabora we work on a lot of appliance-like embedded Debian
+derivatives, with a lot of flexibility during development but very limited
+state on deployed systems, and Endless' approach seems a perfect fit for
+those situations.
+
+[[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]
diff --git a/2017/flatpak_and_debian/indoor-garden.jpg b/2017/flatpak_and_debian/indoor-garden.jpg
new file mode 100644
index 0000000..aaf9bdf
Binary files /dev/null and b/2017/flatpak_and_debian/indoor-garden.jpg differ

diff --git a/2017/dbus_and_containers.mdwn b/2017/dbus_and_containers.mdwn
new file mode 100644
index 0000000..16195fd
--- /dev/null
+++ b/2017/dbus_and_containers.mdwn
@@ -0,0 +1,360 @@
+[[!meta title="GTK hackfest 2017: D-Bus communication with containers"]]
+[[!meta date="2017-03-23 18:07 +0000"]]
+[[!meta updated="2017-03-23 18:07 +0000"]]
+[[!meta copyright="Copyright © 2017 Simon McVittie"]]
+[[!tag debian gtk flatpak d-bus]]
+
+At the [GTK hackfest][] in London (which accidentally became mostly a
+Flatpak hackfest) I've mainly been looking into how to make D-Bus
+work better for app container technologies like [Flatpak][] and [Snap][].
+
+The initial motivating use cases are:
+
+* [Portals][]: Portal authors need to be able to identify whether the
+  container is being contacted by an uncontained process (running with
+  the user's full privileges), or whether it is being contacted by a
+  contained process (in a container created by Flatpak or Snap).
+
+* [dconf][]: Currently, a contained app either has full read/write access
+  to dconf, or no access. It should have read/write access to its own
+  subtree of dconf configuration space, and no access to the rest.
+
+At the moment, Flatpak runs a D-Bus proxy for each app instance that has
+access to D-Bus, connects to the appropriate bus on the app's behalf,
+and passes messages through. That proxy is in a container similar to the
+actual app instance, but not actually the same container; it is trusted
+to not pass messages through that it shouldn't pass through.
+The app-identification mechanism works in practice, but is Flatpak-specific,
+and has a known race condition due to process ID reuse and limitations
+in the metadata that the Linux kernel maintains for `AF_UNIX` sockets.
+In practice the use of X11 rather than Wayland in current systems is a much
+larger loophole in the container than this race condition, but we want to
+do better in future.
+
+Meanwhile, Snap does its sandboxing with AppArmor, on kernels where it
+is enabled both at compile-time (Ubuntu, openSUSE, Debian, Debian derivatives
+like Tails) and at runtime (Ubuntu, openSUSE and Tails, but not Debian by
+default). Ubuntu's kernel has extra AppArmor features that haven't yet
+gone upstream, some of which provide reliable app identification via
+LSM labels, which `dbus-daemon` can learn by querying its `AF_UNIX` socket.
+However, other kernels like the ones in openSUSE and Debian don't have
+those. The access-control (AppArmor *mediation*) is implemented in upstream
+dbus-daemon, but again doesn't work portably, and is not sufficiently
+fine-grained or flexible to do some of the things we'll likely want to do,
+particularly in dconf.
+
+After a lot of discussion with dconf maintainer [Allison Lortie][] and
+Flatpak maintainer [Alexander Larsson][], I think I have a plan for fixing
+this.
+
+This is all subject to change: see [fd.o #100344][] for the latest ideas.
+
+## Identity model
+
+Each user (uid) has some *uncontained* processes, plus 0 or more
+*containers*.
+
+The uncontained processes include dbus-daemon itself, desktop environment
+components such as gnome-session and gnome-shell, the container managers
+like Flatpak and Snap, and so on. They have the user's full privileges,
+and in particular they are allowed to do privileged things on the user's
+session bus (like running `dbus-monitor`), and act with the user's full
+privileges on the system bus. In generic information security jargon, they
+are the trusted computing base; in AppArmor jargon, they are unconfined.
+
+The containers are Flatpak apps, or Snap apps, or other app-container
+technologies like Firejail and AppImage (if they adopt this mechanism,
+which I hope they will), or even a mixture (different
+app-container technologies can coexist on a single system).
+They are containers (or container instances) and not "apps", because in
+principle, you could install `com.example.MyApp` 1.0, run it, and while
+it's still running, upgrade to `com.example.MyApp` 2.0 and run that; you'd
+have two containers for the same app, perhaps with different permissions.
+
+Each container has an *container type*, which is a reversed DNS
+name like `org.flatpak` or `io.snapcraft` representing the
+container technology, and an *app identifier*, an arbitrary non-empty
+string whose meaning is defined by the container technology. For Flatpak,
+that string would be another reversed DNS name like `com.example.MyGreatApp`;
+for Snap, as far as I can tell it would look like `example-my-great-app`.
+
+The container technology can also put arbitrary metadata on the D-Bus
+representation of a container, again defined and namespaced by the
+container technology. For instance, Flatpak would use some serialization
+of the same fields that go in the [Flatpak metadata][] file at the moment.
+
+Finally, the container has an opaque *container identifier* identifying
+a particular container instance. For example, launching `com.example.MyApp`
+twice (maybe different versions or with different command-line options
+to `flatpak run`) might result in two containers with different
+privileges, so they need to have different container identifiers.
+
+## Contained server sockets
+
+App-container managers like Flatpak and Snap would create an `AF_UNIX`
+socket inside the container, `bind()` it to an address that will be made
+available to the contained processes, and `listen()`, but not `accept()`
+any new connections. Instead, they would fd-pass the new socket to the
+dbus-daemon by calling a new method, and the dbus-daemon would proceed
+to `accept()` connections after the app-container manager has signalled
+that it has called both `bind()` and `listen()`. (See [fd.o #100344][]
+for full details.)
+
+Processes inside the container must not be allowed to contact the
+`AF_UNIX` socket used by the wider, uncontained system - if they could,
+the dbus-daemon wouldn't be able to distinguish between them and uncontained
+processes and we'd be back where we started. Instead, they should have the
+new socket bind-mounted into their container's `XDG_RUNTIME_DIR` and
+connect to that, or have the new socket set as their
+`DBUS_SESSION_BUS_ADDRESS` and be prevented from connecting to the
+uncontained socket in some other way.
+Those familiar with the [kdbus][] proposals a while ago might recognise
+this as being quite similar to kdbus' concept of *endpoints*, and I'm
+considering reusing that name.
+
+Along with the socket, the container manager would pass in the container's
+identity and metadata, and the method would return a unique, opaque
+identifier for this particular container instance. The basic fields
+(container technology, technology-specific app ID, container ID) should
+probably be added to the result of `GetConnectionCredentials()`, and
+there should be a new API call to get all of those plus the
+arbitrary technology-specific metadata.
+
+When a process from a container connects to the contained
+server socket, every message that it sends should also have the
+container instance ID in a new header field. This is OK even though
+[dbus-daemon does not (in general) forbid sender-specified future header
+fields][fd.o #100317], because any dbus-daemon that supported this new feature
+would guarantee to set that header field correctly, the existing
+Flatpak D-Bus proxy already filters out unknown header fields, and
+adding this header field is only ever a reduction in privilege.
+
+The reasoning for using the sender's container instance ID (as opposed to
+the sender's unique name) is for services like dconf to be able to treat
+multiple unique bus names as belonging to the same equivalence class of
+contained processes: instead of having to look up the container metadata
+once per unique name, dconf can look it up once per container instance
+the first time it sees a new identifier in a header field. For the second
+and subsequent unique names in the container, dconf can know that the
+container metadata and permissions are identical to the one it already saw.
+
+## Access control
+
+In principle, we could have the new identification feature without adding
+any new access control, by keeping Flatpak's proxies. However, in the
+short term that would mean we'd be adding new API to set up a socket for
+a container without any access control, and having to keep the proxies
+*anyway*, which doesn't seem great; in the longer term, I think we'd
+find ourselves adding a second new API to set up a socket for a container
+*with* new access control. So we might as well bite the bullet and go for
+the version with access control immediately.
+
+In principle, we could also avoid the need for new access control by
+ensuring that each service that will serve contained clients does its own.
+However, that makes it really hard to send broadcasts and not have them
+unintentionally leak information to contained clients - we would need to
+do something more like kdbus' approach to multicast, where services know
+who has subscribed to their multicast signals, and that is just not how
+dbus-daemon works at the moment. If we're going to have access control
+for broadcasts, it might as well also cover unicast.
+
+The plan is that messages from containers to the outside world will be mediated
+by a new access control mechanism, in parallel with dbus-daemon's current
+support for firewall-style rules in the XML bus configuration, AppArmor
+mediation, and SELinux mediation. A message would only be allowed through
+if the XML configuration, the new container access control mechanism,
+and the LSM (if any) all agree it should be allowed.
+
+By default, processes in a container can send broadcast signals,
+and send method calls and unicast signals to other processes in the same
+container. They can also receive method calls from outside the
+container (so that interfaces like `org.freedesktop.Application` can work),
+and send exactly one reply to each of those method calls. They cannot own
+bus names, communicate with other containers, or send file descriptors
+(which reduces the scope for denial of service).
+
+Obviously, that's not going to be enough for a lot of contained apps,
+so we need a way to add more access. I'm intending this to be purely
+additive (start by denying everything except what is always allowed,
+then add new rules), not a mixture of adding and removing access like
+the current XML policy language.
+
+There are two ways we've identified for rules to be added:
+
+* The container manager can pass a list of rules into the dbus-daemon
+  at the time it attaches the contained server socket, and they'll be
+  allowed. The obvious example is that an `org.freedesktop.Application`
+  needs to be allowed to own its own bus name. Flatpak apps'
+  implicit permission to talk to [portals][], and [Flatpak metadata][]
+  like `org.gnome.SessionManager=talk`, could also be added this way.
+
+* System or session services that are specifically designed to be used by
+  untrusted clients, like the version of `dconf` that Allison is working
+  on, could opt-in to having contained apps allowed to talk to them
+  (effectively making them a generalization of Flatpak portals).

(Diff truncated)

diff --git a/2016/gtk-hackfest.mdwn b/2016/gtk-hackfest.mdwn
index 81df24f..2773d10 100644
--- a/2016/gtk-hackfest.mdwn
+++ b/2016/gtk-hackfest.mdwn
@@ -102,7 +102,7 @@ Other planned portals include:
 * notifications, probably based on freedesktop.org Notifications
 * video streaming (perhaps using Pinot, analogous to PulseAudio but for video)
 
-## Environment variables
+## <a id="environment-variables">Environment variables</a>
 
 GNOME on Wayland currently has a problem with environment variables:
 there are some traditional ways to set environment variables for X11

diff --git a/2016/gtk-hackfest.mdwn b/2016/gtk-hackfest.mdwn
index 239614a..81df24f 100644
--- a/2016/gtk-hackfest.mdwn
+++ b/2016/gtk-hackfest.mdwn
@@ -203,7 +203,7 @@ being able to publish a walkthrough for
 
 ## GTK life-cycle and versioning
 
-The [life-cycle of GTK releases](gtk-versioning) has already been
+The [[life-cycle of GTK releases|gtk-versioning]] has already been
 mentioned here and elsewhere, and there are some interesting responses
 in the comments on my earlier blog post.
 

diff --git a/2016/gtk-hackfest.mdwn b/2016/gtk-hackfest.mdwn
new file mode 100644
index 0000000..239614a
--- /dev/null
+++ b/2016/gtk-hackfest.mdwn
@@ -0,0 +1,235 @@
+[[!meta title="GTK Hackfest 2016"]]
+[[!meta date="2016-06-20 19:37 +0100"]]
+[[!meta updated="2016-06-20 19:37 +0100"]]
+[[!meta copyright="Copyright © 2016 Simon McVittie"]]
+[[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]
+[[!tag debian gtk flatpak ostree]]
+
+I'm back from the GTK hackfest in Toronto, Canada and mostly recovered from
+jetlag, so it's time to write up my notes on what we discussed there.
+
+Despite the hackfest's title, I was mainly there to talk about non-GUI
+parts of the stack, and technologies that fit more closely in what could
+be seen as the freedesktop.org platform than they do in GNOME. In particular,
+I'm interested in Flatpak as a way to deploy self-contained "apps" in a
+freedesktop-based, sandboxed runtime environment layered over
+[the Universal Operating System](https://www.debian.org/) and
+[its many derivatives](https://wiki.debian.org/Derivatives/Census),
+with both binary and source compatibility with other GNU/Linux distributions.
+
+I'm mainly only writing about discussions I was directly involved in:
+lots of what sounded like good discussion about the actual graphics toolkit
+went over my head completely :-)
+[More notes](https://wiki.gnome.org/Hackfests/GTK2016), mostly from Matthias
+Clasen, are available on the GNOME wiki.
+
+In no particular order:
+
+## Thinking with portals
+
+We spent some time discussing Flatpak's *portals*, mostly on Tuesday.
+These are the components that expose a subset of desktop functionality
+as D-Bus services that can be used by contained applications: they are
+part of the security boundary between a contained app and the rest of the
+desktop session. Android's *intents* are a similar concept seen elsewhere.
+While the portals are primarily designed for Flatpak, there's no real
+reason why they couldn't be used by other app-containment solutions
+such as Canonical's Snap.
+
+One major topic of discussion was their overall design and layout. Most
+portals will consist of a UX-independent part in Flatpak itself, together
+with a UX-specific implementation of any user interaction the portal
+needs. For example, the portal for file selection has a D-Bus service
+in Flatpak, which interacts with some UX-specific service that will
+pop up a standard UX-specific "Open" dialog — for GNOME and probably
+other GTK environments, that dialog is in (a branch of) GTK.
+
+A design principle that was reiterated in this discussion is that
+the UX-independent part should do as much as possible, with the
+UX-specific part only carrying out the user interactions that need
+to comply with a particular UX design (in the GTK case, GNOME's design).
+This minimizes the amount of work that needs to be redone for other
+desktop or embedded environments, while still ensuring that the other
+environments can have their chosen UX design. In particular, it's
+important that, as much as possible, the security- and performance-sensitive
+work (such as data transport and authentication) is shared between all
+environments.
+
+The aim is for portals to get the user's permission to carry out actions,
+while keeping it as implicit as possible, avoiding an "are you sure?" step
+where feasible. For example, if an application asks to open a file,
+the user's permission is implicitly given by them selecting the file
+in the file-chooser dialog and pressing OK: if they do not want this
+application to open a file at all, they can deny permission by cancelling.
+Similarly, if an application asks to stream webcam data, the UX we expect
+is for GNOME's Cheese app (or a similar non-GNOME app) to appear, open
+the webcam to provide a preview window so they can see what they are about
+to send, but not actually start sending the
+stream to the requesting app until the user has pressed a "Start" button.
+When defining the API "contracts" to be provided by applications in that
+situation, we will need to be clear about whether the provider is expected
+to obtain confirmation like this: in most cases I would anticipate that
+it is.
+
+One security trade-off here is that we have to have a small amount of
+trust in the providing app. For example, continuing the example of Cheese
+as a webcam provider, Cheese could (and perhaps should) be a contained
+app itself, whether via something like Flatpak, an LSM like AppArmor
+or both. If Cheese is compromised somehow, then whenever it is running, it
+would be technically possible for it to open the webcam, stream video and
+send it to a hostile third-party application. We concluded that this is an
+acceptable trade-off: each application needs to be trusted with the privileges
+that it needs to do its job, and we should not put up barriers that are easy
+to circumvent or otherwise serve no purpose.
+
+The main (only?) portal so far is the file chooser, in which the contained
+application asks the wider system to show an "Open..." dialog, and if the user
+selects a file, it is returned to the contained application through a FUSE
+filesystem, the *document portal*. The reference implementation of the UX for
+this is in GTK, and is basically a `GtkFileChooserDialog`. The intention is
+that other environments such as KDE will substitute their own equivalent.
+
+Other planned portals include:
+
+* image capture (scanner/camera)
+* opening a specified URI
+  - this needs design feedback on how it should work for non-http(s)
+* sharing content, for example on social networks (like Android's Sharing menu)
+* proxying joystick/gamepad input (perhaps via Wayland or FUSE, or perhaps
+  by modifying libraries like SDL with a new input source)
+* network proxies (`GProxyResolver`) and availability (`GNetworkMonitor`)
+* contacts/address book, probably vCard-based
+* notifications, probably based on freedesktop.org Notifications
+* video streaming (perhaps using Pinot, analogous to PulseAudio but for video)
+
+## Environment variables
+
+GNOME on Wayland currently has a problem with environment variables:
+there are some traditional ways to set environment variables for X11
+sessions or login shells using shell script fragments (`/etc/X11/Xsession.d`,
+`/etc/X11/xinit/xinitrc.d`, `/etc/profile.d`), but these do not apply to
+Wayland, or to noninteractive login environments like `cron` and
+`systemd --user`. We are also keen to avoid requiring a Turing-complete shell
+language during session startup, because it's difficult to reason about
+and potentially rather inefficient.
+
+Some uses of environment variables can be dismissed as unnecessary or even
+unwanted, similar to the statement in Debian Policy §9.9: "A program must not
+depend on environment variables to get reasonable defaults." However,
+there are two common situations where environment variables can be necessary
+for proper OS integration: search-paths like `$PATH`, `$XDG_DATA_DIRS` and
+`$PYTHONPATH` (particularly necessary for things like Flatpak), and
+optionally-loaded modules like `$GTK_MODULES` and `$QT_ACCESSIBILITY`
+where a package influences the configuration of another package.
+
+There is a stopgap solution in GNOME's gdm display manager,
+`/usr/share/gdm/env.d`, but this is gdm-specific and
+insufficiently expressive to provide the functionality needed by
+Flatpak: "set `XDG_DATA_DIRS` to its specified default value if unset,
+then add a couple of extra paths".
+
+`pam_env` comes closer — PAM is run at every transition from "no user logged
+in" to "user can execute arbitrary code as themselves" — but it doesn't
+support `.d` fragments, which are required if we want distribution packages
+to be able to extend search paths. `pam_env` also turns off per-user
+configuration by default, citing security concerns.
+
+I'll write more about this when I have a concrete proposal for how to solve it.
+I think the best solution is probably a PAM module similar to `pam_env` but
+supporting `.d` directories, either by modifying `pam_env` directly or
+out-of-tree, combined with clarifying what the security concerns for
+per-user configuration are and how they can be avoided.
+
+## Relocatable binary packages
+
+On Windows and OS X, various GLib APIs automatically discover where the
+application binary is located and use search paths relative to that;
+for example, if `C:\myprefix\bin\app.exe` is running, GLib might put
+`C:\myprefix\share` into the result of `g_get_system_data_dirs()`,
+so that the application can ask to load `app/data.xml` from the data
+directories and get `C:\myprefix\share\app\data.xml`. We would like
+to be able to do the same on Linux, for example so that the apps in a
+Flatpak or Snap package can be constructed from RPM or dpkg packages without
+needing to be recompiled for a different `--prefix`, and so that other
+third-party software packages like the games on Steam and gog.com can
+easily locate their own resources.
+
+Relatedly, there are currently no well-defined semantics for what happens
+when a `.desktop` file or a D-Bus `.service` file has `Exec=./bin/foo`.
+The meaning of `Exec=foo` is well-defined (it searches `$PATH`) and the
+meaning of `Exec=/opt/whatever/bin/foo` is obvious. When this came up in
+D-Bus previously, my assertion was that the meaning should be the same as
+in `.desktop` files, whatever that is.
+
+We agreed to propose that the meaning of a non-absolute path in a `.desktop`
+or `.service` file should be interpreted relative to the directory
+where the `.desktop` or `.service` file was found: for example, if
+`/opt/whatever/share/applications/foo.desktop` says `Exec=../../bin/foo`,
+then `/opt/whatever/bin/foo` would be the right thing to execute.
+While preparing a mail to the freedesktop and D-Bus mailing lists proposing
+this, I found that I had
+[proposed the same thing](https://lists.freedesktop.org/archives/xdg/2014-September/013339.html)
+[almost 2 years ago](https://lists.freedesktop.org/archives/dbus/2014-September/016330.html)...
+this time I hope I can actually make it happen!
+
+## Flatpak and OSTree bug fixing
+
+On the way to the hackfest, and while the discussion moved to topics that I
+didn't have useful input on, I spent some time fixing up the Debian packaging
+for Flatpak and its dependencies. In particular, I did my first upload
+as a co-maintainer of [bubblewrap](https://tracker.debian.org/news/776053),
+uploaded ostree to unstable (with the known limitation that [the grub, dracut
+and systemd integration is missing for now](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824650)
+since I haven't been able to test it yet), got
+most of the way through packaging Flatpak 0.6.5 (which I'll upload soon),
+cherry-picked the right patches to make ostree compile on Debian 8 in an effort
+to make backports trivial, and spent some time disentangling
+[a flatpak test failure](https://github.com/flatpak/flatpak/commit/1d185f7dd6c4537726a86629b9ddcb516767fcb7)
+which was breaking the Debian package's installed-tests.
+I'm still looking into
+[ostree test failures on little-endian MIPS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827473),
+which I was able to reproduce on a Debian porterbox just before the end of the
+hackfest.
+
+## OSTree + Debian

(Diff truncated)

diff --git a/2016/gtk-versioning/comment_5_40b982666c386cf75df37b221eb2ed60._comment b/2016/gtk-versioning/comment_5_40b982666c386cf75df37b221eb2ed60._comment
new file mode 100644
index 0000000..a301ba4
--- /dev/null
+++ b/2016/gtk-versioning/comment_5_40b982666c386cf75df37b221eb2ed60._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/c0f354dae99f5d9eb0474518bc507905"
+ subject="themes"
+ date="2016-06-20T12:11:01Z"
+ content="""
+> *3.20 was supposed to be the last big break, and after this the theme API was supposed to be stable - Matthias blogged about this. Now, with continual breaks, it seems that this promise is basically out of the window. As a theme author I again need to track the breaking releases of GTK and potentially port my theme each time.*
+
+That's a valid concern, and I don't know what the policy will be regarding themes.
+
+I suspect that in practice theming is always going to be \"interesting times\"
+territory, because a theme potentially needs to know about every widget,
+and it's easy for a relatively minor bug to make a particular application
+unusable (through a combination of factors accidentally producing
+white-on-white text or whatever).
+
+I'm assuming that GTK will break API/ABI where it's necessary to enable future work,
+but will not break API/ABI just for the sake of it. I don't know what that means for
+themes: perhaps the fact that they touch every widget means they're likely to be
+affected by at least one breakage, but perhaps that's balanced out by the move
+from unique GTK'isms to something very close to standard W3C CSS.
+
+One interesting side effect of being more willing to break API/ABI is that the
+GTK maintainers would be more free to expose APIs they aren't 100% sure about
+being able to retain for multiple years of development, such as the CSS
+\"gadget\" APIs that Matthias mentioned in his blog post - if I'm understanding
+it correctly, that would make  it much easier for custom widgets outside GTK
+to be \"first class citizens\" with the same level of CSS support as the widgets
+in GTK. If an API turns out to have been a bad idea, it can be dropped
+immediately (during the SONAME-breaking development period), and won't
+show up in the next 2ish-year major release.
+"""]]

diff --git a/2016/gtk-versioning/comment_4_e32139aa9478cda4fc065043bc483869._comment b/2016/gtk-versioning/comment_4_e32139aa9478cda4fc065043bc483869._comment
new file mode 100644
index 0000000..cfbef95
--- /dev/null
+++ b/2016/gtk-versioning/comment_4_e32139aa9478cda4fc065043bc483869._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/c0f354dae99f5d9eb0474518bc507905"
+ subject="comment 4"
+ date="2016-06-20T11:56:52Z"
+ content="""
+> *There will definitely be unstable-using applications (maybe a third party developer needed a feature in GTK 4.2 but is now busy for a short while and its API broke in 4.4) that either stop being developed completely, or whose maintainer (either in GNOME or out of it - even within GNOME inactive maintainers will mean things get broken from time to time until the build fixers show up, unless a policy like 'no GTK release until all modules build with it').*
+
+We did touch on this during discussions at the hackfest. Someone (sorry, I
+forget who) made the point that within GNOME, if a module becomes
+unmaintained-in-practice, it's considered valid for anyone else in GNOME to
+land fixes. That hopefully mitigates the problem within GNOME.
+
+Outside GNOME, I think the recommendation would likely be that maintainers
+shouldn't get on the unstable train unless they are willing to ride it all
+the way to the next station :-) With semi-frequent stable releases, sticking
+to a stable release puts you much less far behind than in GTK's historical
+schedule.
+
+> *To get around this, it seems to me that distribution maintainers will have
+> to adopt a 'remove first' policy so that they don't become burned out.
+> This is where we have to hope that people don't use the unstable GTK+.*
+
+To some extent, Debian already has that policy via autoremovals. If
+dependent packages don't want to be autoremoved, it is up to the maintainer
+of the dependent package to fix it - this sort of thing is why we call
+ourselves Debian maintainers, not Debian packagers.
+
+> *Let's say that Debian release X freezes when GTK 5.2 (unstable) and its
+> corresponding GNOME is current. Would you expect the GNOME maintainers
+> to avoid packaging 5.2? To avoid updating GNOME to this release but still
+> package GTK? Or to package all of it?*
+
+This would be a decision for the GTK and GNOME maintainers based on how much
+work it is and how much time is available, but if it was up to me, I'd expect
+that we'd package both GTK 4.0 and GTK 5.2, together with the version of
+GNOME that corresponds to 5.2.
+
+> *If the latter, what is the maintenance commitment of the GTK+ team to this
+> unstable-but-stable-in-the-GNOME-sense branch? Can we expect bugfixes to be
+> cherry-picked for a few months, as normal, even if the API has moved on in
+> master*
+
+I would hope so. Note that the stable branches already largely exist for
+distribution maintainers' benefit, and as far as I can see, what goes into
+those branches is often already driven by what distribution maintainers
+want those branches to look like.
+
+It's possible that the \"LTS\" branches might become even more conservative in
+what they will accept, taking only changes with a particularly good ratio
+of severity of bugs fixed / (probability × severity) of regressions expected,
+a lot like a Debian stable release.
+"""]]

diff --git a/2016/gtk-versioning/comment_3_3d8c92c0acf0b8c28677b9b527c87ca4._comment b/2016/gtk-versioning/comment_3_3d8c92c0acf0b8c28677b9b527c87ca4._comment
new file mode 100644
index 0000000..71568eb
--- /dev/null
+++ b/2016/gtk-versioning/comment_3_3d8c92c0acf0b8c28677b9b527c87ca4._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="smcv"
+ avatar="http://cdn.libravatar.org/avatar/c0f354dae99f5d9eb0474518bc507905"
+ subject="comment 3"
+ date="2016-06-20T11:37:46Z"
+ content="""
+> *for the sake of clarity I think it's good to mention that Qt doesn't breaks API+ABI in their major versions, normally ~10 years apart from each other*
+
+But you/they did break API+ABI between Qt 3 and Qt 4, and then again between Qt 4
+and Qt 5, right? That's the parallel I was trying to draw.
+
+This proposal does have more frequent major versions than Qt, which is a
+trade-off: it means there are potentially more versions \"in the wild\" at
+any given time, but it hopefully also reduces the need for projects that don't
+closely track GTK and GNOME to depend on the version that is the current focus of
+development, reducing the probability of a change breaking those projects.
+
+If GTK contributors want to support a particular branch for 10 years, they
+are of course welcome to do so - GTK 2 is still maintained, although it's
+really showing its age by now.
+
+> *although we actually needed some ugly hacks in between*
+
+This touches on the reason that I think it's necessary to be willing to break ABI
+sometimes, and not necessarily a bad thing as long as you're honest about it (by
+bumping the SONAME). It is always *possible* to avoid breaking ABI, but taking
+that too far can easily make new features or bug-fixes prohibitively expensive,
+either in paid contributors' time (direct financial cost) or
+volunteers' time (not a direct financial cost, but also a finite resource).
+
+I used to work on Telepathy, which tried very hard not to break ABI, and suffered
+for it: paid developers adding new features found it hard to be cost-effective,
+while volunteer community members were put off by the amount of time and effort
+that it took to get anything from idea to merge. Telepathy 1.0 (the first version
+to do a \"hard\" ABI break since the very early days of the project) was started
+but never finished, partly as a result of this high cost.
+"""]]

diff --git a/2016/gtk-versioning/comment_1_c71a48836bb8b10c9129728fffd7e6af._comment b/2016/gtk-versioning/comment_1_c71a48836bb8b10c9129728fffd7e6af._comment
new file mode 100644
index 0000000..1aedc8d
--- /dev/null
+++ b/2016/gtk-versioning/comment_1_c71a48836bb8b10c9129728fffd7e6af._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://perezmeyer.blogspot.co.uk/"
+ subject="Maybe not so similar to Qt"
+ date="2016-06-14T14:22:06Z"
+ content="""
+Hi Simon! I think you gave the right example with respect to parallel installations with Qt (although we actually needed some ugly hacks in between). But for the sake of clarity I think it's good to mention that Qt doesn't breaks API+ABI in their major versions, normally ~10 years apart from each other.
+
+If you build an app with Qt 4.0.0 it would still be able to run with Qt 4.8, the latest in the series which happened ~10 years later. Same goes for Qt5. The only thing that we don't warrant with Qt is downgrading the Qt version: if you build an app with Qt 5.4 you will surely not be able to run it against Qt 5.0.
+
+Hope that makes thing clearer :)
+"""]]
diff --git a/2016/gtk-versioning/comment_2_8f58ec79c059dd8a061c8f8c1b2ab10f._comment b/2016/gtk-versioning/comment_2_8f58ec79c059dd8a061c8f8c1b2ab10f._comment
new file mode 100644
index 0000000..545542c
--- /dev/null
+++ b/2016/gtk-versioning/comment_2_8f58ec79c059dd8a061c8f8c1b2ab10f._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~laney"
+ nickname="laney"
+ avatar="http://cdn.libravatar.org/avatar/0278f207f1ee700c7d640a496c55d17fc308be0bbdd7e35b3ee26d22b9952416"
+ subject="Downstream concerns"
+ date="2016-06-15T09:12:16Z"
+ content="""
+Thanks to you all for thinking about these things, they are important issues. Sorry that this gets a bit rambly.
+
+I already mentioned some of my concerns in a conversation on IRC, but I want to write them down here - and maybe you want to respond.
+
+It feels like the plan makes sense as far as there is a stable target and an unstable one which application developers can choose between depending on what they are willing to sign up for. It's probably not controversial to say that things are unlikely to end up being that neat in reality. There will definitely be unstable-using applications (maybe a third party developer needed a feature in GTK 4.2 but is now busy for a short while and its API broke in 4.4) that either stop being developed completely, or whose maintainer (either in GNOME or out of it - even within GNOME inactive maintainers will mean things get broken from time to time until the build fixers show up, unless a policy like 'no GTK release until all modules build with it').
+
+When a new GNOME release which depends on an unstable GTK+ happens, and distributors want to ship this, the new policy says this is a transition every time. Fine, we know how to deal with those in distributions - but, at least for Debian and Ubuntu, it means that *every* reverse dependency needs to be ported or removed. Each of the (temporarily or not) unmaintained ones are going to be a drag on this, and a burden on GTK+'s distribution maintainer - they will analyse the breakages and either try to fix or remove the package. That's a drag in both mental effort and time, and one that this scheme will give distributors every 6 months if they want to ship current GNOME. To get around this, it seems to me that distribution maintainers will have to adopt a 'remove first' policy so that they don't become burned out. This is where we have to hope that people don't use the unstable GTK+.
+
+Should LTS and stable Debian ship the GTK and GNOME that correspond to the current-stable release at the time? Let's say that Debian release X freezes when GTK 5.2 (unstable) and its corresponding GNOME is current. Would you expect the GNOME maintainers to avoid packaging 5.2? To avoid updating GNOME to this release but still package GTK? Or to package all of it? If the latter, what is the maintenance commitment of the GTK+ team to this unstable-but-stable-in-the-GNOME-sense branch? Can we expect bugfixes to be cherry-picked for a few months, as normal, even if the API has moved on in master and is shipping such an intermediate (\"non-LTS\" in your analogy\" version in an LTS/stable advisable?
+
+Finally, themes. GTK 3 below 3.20 never promised stability in the theme API, and theme authors certainly have had to catch up with GTK's changes every cycle. Because of this, maintaining a theme was an onerous ongoing commitment. 3.20 was supposed to be the last big break, and after this the theme API was supposed to be stable - [Matthias blogged about this](https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/). Now, with continual breaks, it seems that this promise is basically out of the window. As a theme author I *again* need to track the breaking releases of GTK and potentially port my theme each time. It feels like we had *just* managed to get there - the next stable release after the promise isn't even out yet - and now the rug is being pulled away again. Having more parallel-installable releases out there actually makes the situation a little bit worse since theme authors will have to maintain branches for each stable release until its obsolescence. You might think \"well, having to rewrite your theme once every 2 years instead of every 6 months is an improvement\", but that ignores the promise as previously mentioned - and it's not right to say that it is every 2 years. If you want your theme to be usable on current GNOME, based on unstable GTK, you need to be developing your theme for that. So the commitment is still an ongoing one.
+
+I hope these comments are helpful at outlining some concerns of a downstream person. Happy hackfest. :)
+
+"""]]

diff --git a/2016/gtk-versioning.mdwn b/2016/gtk-versioning.mdwn
new file mode 100644
index 0000000..61ad02a
--- /dev/null
+++ b/2016/gtk-versioning.mdwn
@@ -0,0 +1,102 @@
+[[!meta title="GTK versioning and distributions"]]
+[[!meta date="2016-06-13T21:56:00-0400"]]
+[[!meta updated="2016-06-13T21:56:00-0400"]]
+[[!meta copyright="Copyright © 2016 Simon McVittie"]]
+[[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]
+[[!tag debian gtk]]
+
+Allison Lortie has provoked a lot of comment with her blog post on
+[a new proposal for how GTK is versioned](https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/).
+Here's some more context from the discussion at the GTK hackfest that
+prompted that proposal: there's actually quite a close analogy in
+how new Debian versions are developed.
+
+The problem we're trying to address here is the two sides of a trade-off:
+
+* Without new development, a library (or an OS) can't go anywhere new
+* New development sometimes breaks existing applications
+
+Historically, GTK has aimed to keep compatible within a major version,
+where major versions are rather far apart (GTK 1 in 1998, GTK 2 in
+2002, GTK 3 in 2011, GTK 4 somewhere in the future). Meanwhile, fixing
+bugs, improving performance and introducing new features sometimes
+results in major changes behind the scenes. In an ideal world, these
+behind-the-scenes changes would never break applications; however, the
+world isn't ideal. (The Debian analogy here is that as much as we
+aspire to having the upgrade from one stable release to the next not break
+anything at all, I don't think we've ever achieved that in practice -
+we still ask users to read the release notes, even though ideally
+that wouldn't be necessary.)
+
+In particular, the perceived cost of doing a proper ABI break (a fully
+parallel-installable GTK 4) means there's a strong temptation to make
+changes that don't actually remove or change C symbols, but are clearly
+an ABI break, in the sense that an application that previously worked
+and was considered correct no longer works. A prominent recent example is
+the theming changes in GTK 3.20: the ABI in terms of functions available
+didn't change, but what happens when you call those functions changed in
+an incompatible way. This makes GTK hard to rely on for applications
+outside the GNOME release cycle, which is a problem that needs to
+be fixed (without stopping development from continuing).
+
+The goal of
+[the plan we discussed today](https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/)
+is to decouple the latest branch of development, which moves fast and
+sometimes breaks API, from the API-stable branches, which only get bug
+fixes. This model should look quite familiar to Debian contributors,
+because it's a lot like the way we release Debian and Ubuntu.
+
+In Debian, at any given time we have a development branch
+(testing/unstable) - currently "stretch", the future Debian 9. We
+also have some stable branches, of which the most recent are Debian
+8 "jessie" and Debian 7 "wheezy". Different users of Debian have
+different trade-offs that lead them to choose one or the other of
+these. Users who value stability and want to avoid unexpected changes,
+even at a cost in terms of features and fixes for non-critical bugs,
+choose to use a stable release, preferably the most recent; they only
+need to change what they run on top of Debian for OS API changes (for
+instance webapps, local scripts, or the way they interact with the GUI)
+approximately every 2 years, or perhaps less often than that with the
+Debian-LTS project supporting non-current stable releases. Meanwhile,
+users who value the latest versions and are willing to work with a
+"moving target" as a result choose to use testing/unstable.
+
+The GTK analogy here is really quite close. In the new versioning model,
+library users who value stability over new things would prefer to use
+a stable-branch, ideally the latest; library users who want the latest
+features, the latest bug-fixes and the latest new bugs would use the
+branch that's the current focus of development. In practice we expect
+that the latter would be mostly GNOME projects. There's been some
+discussion at the hackfest about how often we'd have a new
+stable-branch: the fastest rate that's been considered is a stable-branch
+every 2 years, similar to Ubuntu LTS and Debian, but there's no consensus
+yet on whether they will be that frequent in practice.
+
+How many stable versions of GTK would end up shipped in Debian depends
+on how rapidly projects move from "old-stable" to "new-stable" upstream,
+how much those projects' Debian maintainers are willing to patch them
+to move between branches, and how many versions the release team will
+tolerate. Once we reach a steady state, I'd hope that we might have
+1 or 2 stable-branched versions active at a time, packaged as separate
+parallel-installable source packages (a lot like how we handle Qt).
+GTK 2 might well stay around as an additional active version just
+from historical inertia. The stable versions are intended to be
+fully parallel-installable, just like the situation with GTK 1.2,
+GTK 2 and GTK 3 or with the major versions of Qt.
+
+For the "current development" version, I'd anticipate that we'd probably
+only ship one source package, and do ABI transitions for one version
+active at a time, a lot like how we deal with libgnome-desktop and the
+evolution-data-server family of libraries. Those versions would have
+parallel-installable runtime libraries but non-parallel-installable
+development files, again similar to libgnome-desktop.
+
+At the risk of stretching the Debian/Ubuntu analogy too far, the
+intermediate "current development" GTK releases that would accompany
+a GNOME release are like Ubuntu's non-LTS suites: they're more up to
+date than the fully stable releases (Ubuntu LTS, which has a release
+schedule similar to Debian stable), but less stable and not supported
+for as long.
+
+Hopefully this plan can meet both of its goals: minimize breakage for
+applications, while not holding back the development of new APIs.

diff --git a/2016/flatpak.mdwn b/2016/flatpak.mdwn
new file mode 100644
index 0000000..6bb88ab
--- /dev/null
+++ b/2016/flatpak.mdwn
@@ -0,0 +1,72 @@
+[[!meta title="Flatpak in Debian"]]
+[[!meta date="2016-06-05T12:24:00+0100"]]
+[[!meta updated="2016-06-05T12:24:00+0100"]]
+[[!meta copyright="Copyright © 2016 Simon McVittie"]]
+[[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]
+[[!tag debian xdg-app flatpak]]
+
+Quite a lot has happened in xdg-app since
+[[last time I blogged about it|xdg-app]]. Most noticeably, it isn't called
+xdg-app any more, having been renamed to [Flatpak](http://flatpak.org/).
+It is now available in Debian experimental under that name, and the
+xdg-app package that was briefly there has been removed. I'm currently
+in the process of updating Flatpak to the latest version 0.6.4.
+
+The privileged part has also spun off into a separate project,
+[Bubblewrap](https://github.com/projectatomic/bubblewrap), which recently
+had its first release (0.1.0). This is intended as a common component
+with which unprivileged users can start a container in a way that
+won't let them escalate privileges, like a more flexible version of
+[linux-user-chroot](https://git.gnome.org/browse/linux-user-chroot/).
+
+Bubblewrap has also been made available in Debian, maintained by Laszlo
+Boszormenyi (also maintainer of linux-user-chroot). Yesterday I sent a patch
+to [update Laszlo's packaging for 0.1.0](https://bugs.debian.org/826358).
+I'm hoping to become a co-maintainer to upload that myself, since I suspect
+Flatpak and Bubblewrap might need to track each other quite closely.
+For the moment, Flatpak still uses its own internal copy of Bubblewrap,
+but [I consider that to be a bug](https://bugs.debian.org/824647) and
+I'd like to be able to fix it soon.
+
+At some point I also want to experiment with using Bubblewrap to
+sandbox some of the game engines that are packaged in Debian: networked
+games are a large attack surface, and typically consist of the sort
+of speed-optimized C or C++ code that is an ideal home for security
+vulnerabilities. I've already made some progress on jailing game engines
+with AppArmor, but making sensitive files completely invisible to the
+game engine seems even better than preventing them from being opened.
+
+Next weekend I'm going to be heading to Toronto for the
+[GTK Hackfest](https://wiki.gnome.org/Hackfests/GTK2016), primarily to to
+talk to GNOME and Flatpak developers about their plans for sandboxing,
+portals and Flatpak. Hopefully we can make some good progress there: the more I
+know about the state of software security, the less happy I am with random
+applications all being equally privileged. Newer display technologies like
+Wayland and Mir represent an opportunity to plug [one of the largest
+holes in typical application containerization](https://mjg59.dreamwidth.org/42320.html),
+which is a major step in bringing sandboxes like Flatpak and Snap from
+proof-of-concept to a practical improvement in security.
+
+Other next steps for Flatpak in Debian:
+
+* To get into the next stable release (Debian 9), Flatpak needs to move
+  from `experimental` into `unstable` and `testing`. I've taken the
+  first step towards that by uploading `libgsystem` to unstable.
+  Before Flatpak can follow, OSTree also needs to move.
+* Now that it's in Debian, please [report bugs in the usual Debian
+  way](https://www.debian.org/Bugs/Reporting) or send patches to fix
+  bugs: [Flatpak](http://bugs.debian.org/src:flatpak),
+  [OSTree](http://bugs.debian.org/src:ostree),
+  [libgsystem](http://bugs.debian.org/src:libgsystem).
+* In particular, there are some OSTree bugs tagged `help`. I'd
+  appreciate contributions to the OSTree packaging from people
+  who are interested in using it to deploy `dpkg`-based operating systems -
+  I'm primarily looking at it from the Flatpak perspective, so the boot/OS
+  side of it isn't so well tested. Red Hat have `rpm-ostree`,
+  and I believe [Endless](https://endlessm.com/) do something analogous
+  to build OS images with `dpkg`, but I haven't had a chance to look into
+  that in detail yet.
+* Co-maintainers for [Flatpak](https://tracker.debian.org/pkg/flatpak),
+  [OSTree](https://tracker.debian.org/pkg/ostree),
+  [libgsystem](https://tracker.debian.org/pkg/libgsystem) would also
+  be very welcome.

diff --git a/2016/xdg-app.mdwn b/2016/xdg-app.mdwn
index 9820b25..0b6c32b 100644
--- a/2016/xdg-app.mdwn
+++ b/2016/xdg-app.mdwn
@@ -447,11 +447,14 @@ in having such a simplistic demo to go alongside the various GNOMEish apps.
 
 Acknowledgements:
 
-* [Betacowork Coworking Brussels](http://www.betacowork.com/),
-  [ICAB Business & Technology Incubator](http://www.icabrussel.be/) and
-  [Collabora](https://www.collabora.com/) and
-  [the GNOME Foundation](https://www.gnome.org/foundation/) sponsored the
+* [Betacowork Coworking Brussels](http://www.betacowork.com/) and
+  [ICAB Business & Technology Incubator](http://www.icabrussel.be/)
+  hosted the hackfest, with [Collabora](https://www.collabora.com/)
+  providing snacks, and
+  [the GNOME Foundation](https://www.gnome.org/foundation/) supporting the
   hackfest in general;
 * Collabora also sponsored my travel, accommodation and time;
 * my colleague [Philip Withnall](https://tecnocode.co.uk/) organised the
-  hackfest
+  hackfest.
+
+Thanks to all those!

diff --git a/2016/xdg-app.mdwn b/2016/xdg-app.mdwn
index 6c35ac3..9820b25 100644
--- a/2016/xdg-app.mdwn
+++ b/2016/xdg-app.mdwn
@@ -28,7 +28,7 @@ that space:
   tend to test on a vaguely recent Ubuntu LTS and leave it at that.
 
 * There's no widely-supported mechanism for installing third-party
-  applications as an ordinary user. [gog.com](http://www.gog.com/)
+  applications as an ordinary user. [gog.com](https://www.gog.com/)
   used to distribute Ubuntu- and Debian-compatible `.deb` files,
   but installing a `.deb` involves running arbitrary vendor-supplied
   scripts as root, which should worry anyone who wants any sort of
@@ -98,7 +98,7 @@ Source code:
 
 Binaries (no trust path, so only use these if you have a test VM):
 
-* `deb http://people.debian.org/~smcv/xdg-app xdg-app main`
+* `deb https://people.debian.org/~smcv/xdg-app xdg-app main`
 
 ## The "Hello, World" of xdg-apps
 

diff --git a/2016.mdwn b/2016.mdwn
new file mode 100644
index 0000000..2a95548
--- /dev/null
+++ b/2016.mdwn
@@ -0,0 +1 @@
+[[!map pages="2016/* and copyright(*)" show=title]]
diff --git a/2016/xdg-app.mdwn b/2016/xdg-app.mdwn
new file mode 100644
index 0000000..6c35ac3
--- /dev/null
+++ b/2016/xdg-app.mdwn
@@ -0,0 +1,457 @@
+[[!meta title="GNOME Developer Experience hackfest: xdg-app + Debian"]]
+[[!meta date="2016-01-30T19:07:45+0100"]]
+[[!meta updated="2016-01-30T19:07:45+0100"]]
+[[!meta copyright="Copyright © 2016 Collabora Ltd."]]
+[[!meta license="[CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/)"]]
+[[!tag debian xdg-app]]
+
+Over the last few days I've been at the GNOME Developer Experience hackfest
+in Brussels, looking into
+[xdg-app](https://wiki.freedesktop.org/www/Software/xdg-app/)
+and how best to use it in Debian and Debian derivatives.
+
+xdg-app is basically a way to run "non-core" software on Linux distributions,
+analogous to apps on Android and iOS. It doesn't replace distributions
+like Debian or packaging systems, but it adds a layer above them. It's
+mostly aimed towards third-party apps obtained from somewhere that isn't
+your distribution vendor, aiming to address a few long-standing problems in
+that space:
+
+* There's no single ABI that can be called "a standard Linux system" in
+  the same way there would be for Windows or OS X or Android or whatever,
+  apart from LSB which is rather limited. Testing that a third-party app
+  "works on Linux", or even "works on stable Linux releases from 2015",
+  involves a combinatorial explosion of different distributions, desktop
+  environments and local configurations. Steam uses
+  [the Steam Runtime](https://github.com/ValveSoftware/steam-runtime),
+  a chroot environment closely resembling Ubuntu 12.04 LTS; other vendors
+  tend to test on a vaguely recent Ubuntu LTS and leave it at that.
+
+* There's no widely-supported mechanism for installing third-party
+  applications as an ordinary user. [gog.com](http://www.gog.com/)
+  used to distribute Ubuntu- and Debian-compatible `.deb` files,
+  but installing a `.deb` involves running arbitrary vendor-supplied
+  scripts as root, which should worry anyone who wants any sort of
+  privilege-separation. (They have now switched to executable self-extracting
+  installers, which involve running arbitrary vendor-supplied scripts
+  as an ordinary user... better, but not perfect.)
+
+* Relatedly, the third-party application itself runs with the user's
+  full privileges: a malicious or security-buggy third-party application
+  [can do more or less anything](https://xkcd.com/1200/), unless you
+  either switch to a different uid to run third-party apps, or
+  use a carefully-written, app-specific AppArmor profile or equivalent.
+
+To address the first point, each application uses a specified "runtime",
+which is available as /usr inside its sandbox. This can be used to run
+application bundles with multiple, potentially incompatible sets of
+dependencies within the same desktop environment. A runtime can be
+updated within its branch - for instance, if an application uses the
+"GNOME 3.18" runtime (consisting of a basic Linux system, the GNOME 3.18
+libraries, other related libraries like Mesa, and their recursive dependencies
+like libjpeg), it can expect to see minor-version updates from GNOME 3.18.x
+(including any security updates that might be necessary for the bundled
+libraries), but not a jump to GNOME 3.20.
+
+To address the second issue, the plan is for application bundles
+to be available as a single file, containing metadata (such as
+the runtime to use), the app itself, and any dependencies that
+are not available in the runtime (which the app vendor is responsible for
+updating if necessary). However, the primary way to distribute
+and upgrade runtimes and applications is to package them as
+[OSTree](https://wiki.gnome.org/Projects/OSTree) repositories, which
+provide a git-like content-addressed filesystem, with efficient updates
+using binary deltas. The resulting files are hard-linked into place.
+
+To address the last point, application bundles run partially isolated
+from the wider system, using containerization techniques such as namespaces
+to prevent direct access to system resources. Resources from outside the
+sandbox can be accessed via "portal" services, which are responsible for
+access control; for example, the Documents portal (the only one, so far)
+displays an "Open" dialog outside the sandbox, then allows the application to
+access only the selected file.
+
+## xdg-app for Debian
+
+One thing I've been doing at this hackfest is improving the existing
+[Debian/Ubuntu packaging](https://launchpad.net/~alexlarsson/+archive/ubuntu/xdg-app)
+for xdg-app (and its dependencies ostree and libgsystem), aiming to get it
+into a state where I can upload it to Debian experimental. Because xdg-app
+aims to be a general freedesktop project, I'm currently intending to make
+it part of the "Utopia" packaging team alongside projects like D-Bus
+and polkit, but I'm open to suggestions if people want to co-maintain
+it elsewhere.
+
+In the process of updating xdg-app, I sent various patches to Alex,
+mostly fixing build and test issues, which are in the new 0.4.8 release.
+
+I'd appreciate co-maintainers and further testing for this stuff,
+particularly ostree: ostree is primarily a whole-OS deployment technology,
+which isn't a use-case that I've tested, and in particular ostree-grub2
+probably doesn't work yet.
+
+Source code:
+
+* <https://anonscm.debian.org/cgit/users/smcv/libgsystem.git>
+* <https://anonscm.debian.org/cgit/users/smcv/ostree.git>
+* <https://anonscm.debian.org/cgit/users/smcv/xdg-app.git>
+
+Binaries (no trust path, so only use these if you have a test VM):
+
+* `deb http://people.debian.org/~smcv/xdg-app xdg-app main`
+
+## The "Hello, World" of xdg-apps
+
+Another thing I set out to do here was to make a runtime and an app
+out of Debian packages. Most of the test applications in and around GNOME
+use the "freedesktop" or "GNOME" runtimes, which consist of a Yocto base
+system and lots of RPMs, are rebuilt from first principles on-demand,
+and are extensive and capable enough that they make it somewhat non-obvious
+what's in an app or a runtime.
+
+So, here's a step-by-step route through xdg-app, first using typical
+GNOME instructions, but then using the simplest GUI
+app I could find - xvt, a small xterm clone. I'm using a Debian testing
+(stretch) x86\_64 virtual machine for all this. xdg-app currently requires
+systemd-logind to put users and apps in cgroups, either with systemd as
+pid 1 (systemd-sysv) or systemd-shim and cgmanager; I used the default
+systemd-sysv. In principle it could work with plain cgmanager, but nobody
+has contributed that support yet.
+
+### Demonstrating an existing xdg-app
+
+Debian's kernel is currently patched to be able to allow unprivileged users to
+create user namespaces, but make it runtime-configurable, because there have
+been various security issues in that feature, making it a security risk for a
+typical machine (and particularly a server). Hopefully unprivileged user
+namespaces will soon be secure enough that we can enable them by default,
+but for now, we have to do one of three things to let xdg-app use them:
+
+* enable unprivileged user namespaces via sysctl:
+
+      sudo sysctl kernel.unprivileged_userns_clone=1
+
+* make xdg-app root-privileged (it will keep `CAP_SYS_ADMIN` and drop the rest):
+
+      sudo dpkg-statoverride --update --add root root 04755 /usr/bin/xdg-app-helper
+
+* make xdg-app slightly less privileged:
+
+      sudo setcap cap_sys_admin+ep /usr/bin/xdg-app-helper
+
+First, we'll need a runtime. The standard xdg-app tutorial would tell you to
+download the "GNOME Platform" version 3.18. To do that, you'd add a *remote*,
+which is a bit like a git remote, and a bit like an apt repository:
+
+    $ wget http://sdk.gnome.org/keys/gnome-sdk.gpg
+    $ xdg-app remote-add --user --gpg-import=gnome-sdk.gpg gnome \
+        http://sdk.gnome.org/repo/
+
+(I'm ignoring considerations like trust paths and security here, for
+brevity; in real life, you'd want to obtain the signing key via https
+and/or have a trust path to it, just like you would for a secure-apt signing
+key.)
+
+You can list what's available in a remote:
+
+    $ xdg-app remote-ls --user gnome
+    ...
+    org.freedesktop.Platform
+    ...
+    org.freedesktop.Platform.Locale.cy
+    ...
+    org.freedesktop.Sdk
+    ...
+    org.gnome.Platform
+    ...
+
+The Platform runtimes are what we want here: they are collections of
+runtime libraries with which you can run an application. The Sdk runtimes
+add development tools, header files, etc. to be able to compile apps that
+will be compatible with the Platform.
+
+For now, all we want is the GNOME 3.18 platform:
+
+    $ xdg-app install --user gnome org.gnome.Platform 3.18
+
+Next, we can install an app that uses it, from Alex Larsson's nightly
+builds of a subset of GNOME. The server they're on doesn't have a great deal
+of bandwidth, so be nice :-)
+
+    $ wget http://209.132.179.2/keys/nightly.gpg
+    $ xdg-app remote-add --user --gpg-import=nightly.gpg nightly \
+        http://209.132.179.2/repo/
+    $ xdg-app install --user nightly org.mypaint.MypaintDevel
+
+We now have one app, and the runtime it needs:
+

(Diff truncated)

diff --git a/2015/why_polkit/comment_2_5737545284e3755fe1e923c0bb946c82._comment b/2015/why_polkit/comment_2_5737545284e3755fe1e923c0bb946c82._comment
new file mode 100644
index 0000000..4739a08
--- /dev/null
+++ b/2015/why_polkit/comment_2_5737545284e3755fe1e923c0bb946c82._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="June@fec140941ae43fa8df8c3cfb0ddcf561a27fac76"
+ nickname="June"
+ avatar="http://cdn.libravatar.org/avatar/45d480a40970c748094226fa3174eac3"
+ subject="Great!"
+ date="2015-06-18T14:23:45Z"
+ content="""
+Glad to finally see some info written about this. Any chance this will be put into a man page or a texinfo doc or something similar? The #1 objection I have about almost every single free desktop.org project is their utter lack of documentation of how things work. The #2 objection is not religious as you assume, but technical, but I won't tilt against that windmill here.
+"""]]

diff --git a/2015/discworldnoir-boxes.jpg b/2015/discworldnoir-boxes.jpg
new file mode 100644
index 0000000..35a6214
Binary files /dev/null and b/2015/discworldnoir-boxes.jpg differ
diff --git a/2015/discworldnoir.mdwn b/2015/discworldnoir.mdwn
new file mode 100644
index 0000000..132e632
--- /dev/null
+++ b/2015/discworldnoir.mdwn
@@ -0,0 +1,191 @@
+[[!meta title="Discworld Noir in a Windows 98 virtual machine on Linux"]]
+[[!meta date="2015-11-15T17:19:00+0000"]]
+[[!meta updated="2015-11-15T17:19:00+0000"]]
+[[!meta copyright="Copyright © 2015 Simon McVittie"]]
+[[!tag debian qemu games]]
+
+[Discworld Noir](https://en.wikipedia.org/wiki/Discworld_Noir) was a
+superb adventure game, but is also notoriously unreliable, even in
+Windows on real hardware;
+[using Wine is just not going to work](https://appdb.winehq.org/objectManager.php?sClass=version&iId=2254).
+After many attempts at bringing it back into working order, I've settled
+on an approach that seems to work: now that qemu and libvirt
+have made virtualization and emulation easy, I can run it in a version
+of Windows that was current at the time of its release. Unfortunately,
+Windows 98 doesn't virtualize particularly well either, so this
+still became a relatively extensive
+[yak-shaving](http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.html)
+exercise.
+
+[[discworldnoir-boxes.jpg]]
+
+These instructions assume that `/srv/virt` is a suitable place to put
+disk images, but you can use anywhere you want.
+
+The emulated PC
+---------------
+
+After some trial and error, it seems to work if I configure
+qemu to emulate the following:
+
+- Fully emulated hardware instead of virtualization (`qemu-system-i386 -no-kvm`)
+- Intel Pentium III
+- Intel i440fx-based motherboard with ACPI
+- Real-time clock in local time
+- No HPET
+- 256 MiB RAM
+- IDE primary master: IDE hard disk (I used 30 GiB, which is massively
+  overkill for this game; qemu can use sparse files so it actually ends
+  up less than 2 GiB on the host system)
+- IDE primary slave, secondary master, secondary slave: three CD-ROM drives
+- PS/2 keyboard and mouse
+- Realtek AC97 sound card
+- Cirrus video card with 16 MiB video RAM
+
+A modern laptop CPU is an order of magnitude faster than what Discworld Noir
+needs, so full emulation isn't a problem, despite being inefficient.
+
+There is deliberately no networking, because Discworld Noir doesn't need it,
+and a 17 year old operating system with no privilege separation is
+very much not safe to use on the modern Internet!
+
+Software needed
+---------------
+
+- Windows 98 installation CD-ROM as a `.iso` file
+  (`cp /dev/cdrom windows98.iso`) - in theory you could also use a
+  real optical drive, but my laptop doesn't usually have one of those.
+  I used the OEM disc, version 4.10.1998 (that's the original Windows 98,
+  not the Second Edition), which came with a long-dead PC, and didn't
+  bother to apply any patches.
+- A Windows 98 license key. Again, I used an OEM key from a past PC.
+- A complete set of Discworld Noir (English) CD-ROMs as `.iso` files.
+  I used the UK "Sold Out Software" budget release, on 3 CDs.
+- [A multi-platform Realtek AC97 audio driver](http://drivers.softpedia.com/get/SOUND-CARD/REALTEK/Realtek-AC97-Audio-Driver-A400.shtml).
+
+Windows 98 installation
+-----------------------
+
+It seems to be easiest to do this bit by running qemu-system-i386 manually:
+
+    qemu-img create -f qcow2 /srv/virt/discworldnoir.qcow2 30G
+    qemu-system-i386 -hda /srv/virt/discworldnoir.qcow2 \
+        -drive media=cdrom,format=raw,file=/srv/virt/windows98.iso \
+        -no-kvm -vga cirrus -m 256 -cpu pentium3 -localtime
+
+Don't start the installation immediately. Instead, boot the installation
+CD to a DOS prompt with CD-ROM support. From here, run
+
+    fdisk
+
+and create a single partition filling the emulated hard disk. When
+finished, hard-reboot the virtual machine (press Ctrl+C on the
+`qemu-system-i386` process and run it again).
+
+The DOS `FORMAT.COM` utility is on the Windows CD-ROM but not in the root
+directory or the default `%PATH%`, so you'll have to run:
+
+    d:\win98\format c:
+
+to create the FAT filesystem. You might have to reboot again at this point.
+
+The reason for doing this the hard way is that the Windows 98 installer
+doesn't detect qemu as supporting ACPI. You want ACPI support, so that
+Windows will issue `IDLE` instructions from its idle loop, instead of
+occupying a CPU core with a busy-loop. To get that, boot to a DOS
+prompt again, and use:
+
+    setup /p j /iv
+
+`/p j` forces ACPI support
+(Thanks to ["Richard S" on the Virtualbox forums](https://forums.virtualbox.org/viewtopic.php?f=6&t=32989)
+for this tip.)
+`/iv` is unimportant, but it disables the annoying "billboards" during
+installation, which advertised once-exciting features like support for
+dial-up modems and JPEG wallpaper.
+
+I used a "Typical" installation; there didn't seem to be much point in
+tweaking the installed package set when everything is so small by
+modern standards.
+
+Windows 98 has built-in support for the Cirrus VGA card that we're
+emulating, so after a few reboots, it should be able to run in a
+semi-modern resolution and colour depth. Discworld Noir
+apparently prefers a 640 × 480 × 16-bit video mode, so right-click
+on the desktop background, choose Properties and set that up.
+
+Audio drivers
+-------------
+
+This is the part that took me the longest to get working. Of the sound
+cards that qemu can emulate, Windows 98 only supports the SoundBlaster 16
+out of the box. Unfortunately, [the Soundblaster 16 emulation in qemu is
+incomplete](https://bugs.launchpad.net/qemu/+bug/1295587),
+and in particular version 2.1 (as shipped in Debian 8) has a tendency to
+make Windows lock up during boot.
+
+I've seen advice in various places to emulate an Eqsonic ES1370
+(SoundBlaster AWE 64), but that didn't work for me: one of the drivers I
+tried caused Windows to lock up at a black screen during boot, and the other
+didn't detect the emulated hardware.
+
+The next-oldest sound card that qemu can emulate is a Realtek AC97,
+which was often found integrated into motherboards in the late 1990s.
+This one seems to work, with the "A400" driver bundle linked above.
+For Windows 98 first edition, you need a driver bundle that includes
+the old "VXD" drivers, not just the "WDM" drivers supported by
+Second Edition and newer.
+
+The easiest way to get that into qemu seems to be to turn it into a CD image:
+
+    genisoimage -o /srv/virt/discworldnoir-drivers.iso WDM_A400.exe
+    qemu-system-i386 -hda /srv/virt/discworldnoir.qcow2 \
+        -drive media=cdrom,format=raw,file=/srv/virt/windows98.iso \
+        -drive media=cdrom,format=raw,file=/srv/virt/discworldnoir-drivers.iso \
+        -no-kvm -vga cirrus -m 256 -cpu pentium3 -localtime -soundhw ac97
+
+Run the installer from E:, then reboot with the Windows 98 CD inserted, and
+Windows should install the driver.
+
+Installing Discworld Noir
+-------------------------
+
+Boot up the virtual machine with CD 1 in the emulated drive:
+
+    qemu-system-i386 -hda /srv/virt/discworldnoir.qcow2 \
+        -drive media=cdrom,format=raw,file=/srv/virt/DWN_ENG_1.iso \
+        -no-kvm -vga cirrus -m 256 -cpu pentium3 -localtime -soundhw ac97
+
+You might be thinking "... why not insert all three CDs into D:, E: and F:?"
+but the installer expects subsequent disks to appear in the same drive
+where CD 1 was initially, so that won't work. Instead, when prompted for
+a new CD, switch to the qemu monitor with Ctrl+Alt+2 (note that this
+is 2, _not_ F2). At the `(qemu)` prompt,
+use `info block` to see a list of emulated drives, then issue a
+command like
+
+    change ide0-cd1 /srv/virt/DWN_ENG_2.iso
+
+to swap the CD. Then switch back to Windows' console with Ctrl+Alt+1
+and continue installation. I used a Full installation of Discworld Noir.
+
+Transferring the virtual machine to GNOME Boxes
+-----------------------------------------------
+
+Having finished the "control freak" phase of installation, I wanted a
+slightly more user-friendly way to _run_ this game, so I transferred
+the virtual machine to be used by libvirtd, which is the backend for
+both GNOME Boxes and virt-manager:
+
+    virsh create discworldnoir.xml
+
+[[Here is the configuration I used|discworldnoir.xml]]. It's a mixture
+of automatic configuration from virt-manager, and hand-edited configuration
+to make it match the qemu-system-i386 command-line.
+
+Running the game
+----------------
+
+If all goes well, you should now see a `discworldnoir` virtual machine
+in GNOME Boxes, in which you can boot Windows 98 and play the game.

(Diff truncated)

diff --git a/2015/why_polkit/comment_1_26e6fab68b3e762d135e35311fd2df19._comment b/2015/why_polkit/comment_1_26e6fab68b3e762d135e35311fd2df19._comment
new file mode 100644
index 0000000..9be186a
--- /dev/null
+++ b/2015/why_polkit/comment_1_26e6fab68b3e762d135e35311fd2df19._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://albertodebian.wordpress.com/"
+ nickname="albertodebian"
+ avatar="http://cdn.libravatar.org/avatar/13ffc7c31e719eb6b1ba6b91cb6eff6a"
+ subject="very informative"
+ date="2015-06-05T19:35:18Z"
+ content="""
+thanks! more posts like this one!!
+
+usually the people who better understand it is the people who less need have for documentation and so dont bother... but this was great!
+
+next one on how to debug it! 
+"""]]

diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
index c2c6c40..b3f304a 100644
--- a/2015/why_polkit.mdwn
+++ b/2015/why_polkit.mdwn
@@ -214,8 +214,7 @@ a particular disk is in. So `udisks2` can make a more informed decision.
 So, a naive approach might be to write a function in `udisks2` that looks
 something like this pseudocode:
 
-[!format txt """
-may_i_mount_this_disk (user, disk, mount options) → boolean
+[[!format txt """may_i_mount_this_disk (user, disk, mount options) → boolean
 {
     if (user is root || user is root-equivalent)
         return true;
@@ -238,8 +237,7 @@ may_i_mount_this_disk (user, disk, mount options) → boolean
        return false;
 
     return true;
-}
-"""]]
+}"""]]
 
 ## Delegating the security policy to something central
 

diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
index ae6eb83..c2c6c40 100644
--- a/2015/why_polkit.mdwn
+++ b/2015/why_polkit.mdwn
@@ -214,7 +214,8 @@ a particular disk is in. So `udisks2` can make a more informed decision.
 So, a naive approach might be to write a function in `udisks2` that looks
 something like this pseudocode:
 
-[!format txt """may_i_mount_this_disk (user, disk, mount options) → boolean
+[!format txt """
+may_i_mount_this_disk (user, disk, mount options) → boolean
 {
     if (user is root || user is root-equivalent)
         return true;

diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
index 87188d9..ae6eb83 100644
--- a/2015/why_polkit.mdwn
+++ b/2015/why_polkit.mdwn
@@ -214,8 +214,7 @@ a particular disk is in. So `udisks2` can make a more informed decision.
 So, a naive approach might be to write a function in `udisks2` that looks
 something like this pseudocode:
 
-<pre><code>[[!format txt """
-may_i_mount_this_disk (user, disk, mount options) -> boolean
+[!format txt """may_i_mount_this_disk (user, disk, mount options) → boolean
 {
     if (user is root || user is root-equivalent)
         return true;
@@ -239,7 +238,7 @@ may_i_mount_this_disk (user, disk, mount options) -> boolean
 
     return true;
 }
-"""]]</code></pre>
+"""]]
 
 ## Delegating the security policy to something central
 

diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
index f403839..87188d9 100644
--- a/2015/why_polkit.mdwn
+++ b/2015/why_polkit.mdwn
@@ -214,30 +214,32 @@ a particular disk is in. So `udisks2` can make a more informed decision.
 So, a naive approach might be to write a function in `udisks2` that looks
 something like this pseudocode:
 
-    may_i_mount_this_disk (user, disk, mount options) -> boolean
-    {
-        if (user is root || user is root-equivalent)
-            return true;
+<pre><code>[[!format txt """
+may_i_mount_this_disk (user, disk, mount options) -> boolean
+{
+    if (user is root || user is root-equivalent)
+        return true;
 
-        if (disk is not removable)
-           return false;
+    if (disk is not removable)
+       return false;
 
-        if (mount options are scary)
-           return false;
+    if (mount options are scary)
+       return false;
 
-        if (user is in “manipulate non-local disks” group)
-            return true;
+    if (user is in “manipulate non-local disks” group)
+        return true;
 
-        if (user is not logged-in locally)
-           return false;
+    if (user is not logged-in locally)
+       return false;
 
-        # [[https://en.wikipedia.org/wiki/Multiseat_configuration]]
-        if (user is not logged-in on the same seat where the disk is
-                plugged in)
-           return false;
+    # [[https://en.wikipedia.org/wiki/Multiseat_configuration]]
+    if (user is not logged-in on the same seat where the disk is
+            plugged in)
+       return false;
 
-        return true;
-    }
+    return true;
+}
+"""]]</code></pre>
 
 ## Delegating the security policy to something central
 

diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
index 08974e4..f403839 100644
--- a/2015/why_polkit.mdwn
+++ b/2015/why_polkit.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2015-06-05T17:32:30+0100"]]
 [[!meta updated="2015-06-05T17:32:30+0100"]]
 [[!meta copyright="Copyright © 2015 Collabora Ltd."]]
-[[!tag debian]]
+[[!tag debian polkit d-bus udisks]]
 
 I've recently found myself explaining `polkit` (formerly PolicyKit) to one of
 [Collabora](https://www.collabora.com/)'s clients, and thought that

diff --git a/2014/still_universal.mdwn b/2014/still_universal.mdwn
index e4f0a90..835ba2b 100644
--- a/2014/still_universal.mdwn
+++ b/2014/still_universal.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="still aiming to be the universal operating system"]]
-[[!meta date="2014-11-19"]]
-[[!meta updated="2014-11-19"]]
+[[!meta date="2014-11-19T23:59+0000"]]
+[[!meta updated="2014-11-19T23:59+0000"]]
 [[!meta copyright="Copyright © 2014 Simon McVittie"]]
 [[!tag debian]]
 
diff --git a/2015.mdwn b/2015.mdwn
new file mode 100644
index 0000000..c419b5d
--- /dev/null
+++ b/2015.mdwn
@@ -0,0 +1 @@
+[[!map pages="2015/* and copyright(*)" show=title]]
diff --git a/2015/why_polkit.mdwn b/2015/why_polkit.mdwn
new file mode 100644
index 0000000..08974e4
--- /dev/null
+++ b/2015/why_polkit.mdwn
@@ -0,0 +1,345 @@
+[[!meta title="Why polkit (or, how to mount a disk on modern Linux)"]]
+[[!meta date="2015-06-05T17:32:30+0100"]]
+[[!meta updated="2015-06-05T17:32:30+0100"]]
+[[!meta copyright="Copyright © 2015 Collabora Ltd."]]
+[[!tag debian]]
+
+I've recently found myself explaining `polkit` (formerly PolicyKit) to one of
+[Collabora](https://www.collabora.com/)'s clients, and thought that
+blogging about the same topic might be useful for
+[other people who are confused by it](http://changelog.complete.org/archives/9299-has-modern-linux-lost-its-way-some-thoughts-on-jessie);
+so, here is why `udisks2` and `polkit` are the way they are.
+
+As always, opinions in this blog are my own, not Collabora's.
+
+## Privileged actions
+
+Broadly, there are two ways a process can do something: it can do it
+directly (i.e. ask the kernel directly), or it can use inter-process
+communication to ask a service to do that operation on its behalf.
+If it does it directly, the components that say whether it can succeed
+are the Linux kernel's normal permissions checks
+([DAC](https://en.wikipedia.org/wiki/Discretionary_access_control)),
+and if configured, AppArmor, SELinux or a similar
+[MAC](https://en.wikipedia.org/wiki/Mandatory_access_control) layer.
+All very simple so far.
+
+Unfortunately, the kernel's relatively coarse-grained checks are not sufficient
+to express the sorts of policies that exist on a desktop/laptop/mobile
+system. My favourite example for this sort of thing is mounting filesystems.
+If I plug in a USB stick with a FAT filesystem, it's reasonable to expect
+my chosen user interface to either mount it automatically, or
+let me press a button to mount it. Similarly, to avoid data loss, I
+should be able to unmount it when I'm finished with it.
+However, mounting and unmounting a USB stick is fundamentally the same
+system call as mounting and unmounting any other filesystem - and if
+ordinary users can do arbitrary mount system calls, they can cause all
+sorts of chaos, for instance by mounting a filesystem that contains setuid
+executables (privilege escalation), or umounting a critical OS filesystem
+like `/usr` (denial of service). Something needs to arbitrate: “you can mount
+filesystems, but only under certain conditions”.
+
+The kernel developer motto for this sort of thing is “mechanism, not policy”:
+they are very keen to avoid encoding particular environments' policies
+(the sort of thing you could think of as “business rules”) in the kernel,
+because that makes it non-generic and hard to maintain. As a result,
+direct mount/unmount actions are only allowed by privileged processes,
+and it's up to user-space processes to arrange for a privileged process
+to make the desired mount syscall.
+
+Here are some other privileged actions which laptop/desktop users can
+reasonably expect to “just work”, with or without requiring a sysadmin-like
+(root-equivalent) user:
+
+* reconfiguring networking (privileged because, in the general case, it's an
+  availability and potentially integrity issue)
+* installing, upgrading or removing packages (privileged because, in the
+  general case, it can result in arbitrary root code execution)
+* suspending or shutting down the system (privileged because you wouldn't
+  want random people doing this on your server, but should normally be
+  allowed on e.g. laptops for people with physical access, because they could
+  just disconnect the power anyway)
+
+In environments that use a MAC framework like AppArmor, actions that
+would normally be allowed can become privileged: for instance, in a
+framework for sandboxed applications, most apps shouldn't be allowed to
+record audio. This prevents carrying out these actions directly,
+again resulting in the only way to achieve them being to ask a service
+to carry out the action.
+
+## Ask a system service to do it
+
+On to the next design, then: I can submit a request to a privileged process,
+which does some checks to make sure I'm not trying to break the system
+(or alternatively, that I have enough sysadmin rights that I'm allowed
+to break the system if I want to), and then does the privileged
+action for me.
+
+You might think I'm about to start discussing D-Bus and daemons, but
+actually, a prominent earlier implementation of this was mount(8), which
+is normally setuid root:
+
+    % ls -l /bin/mount
+    -rwsr-xr-x 1 root root 40000 May 22 11:37 /bin/mount
+
+If you look at it from an odd angle, this is inter-process communication
+across a privilege boundary: I run the setuid executable, creating a
+process. Because the executable has the setuid bit set, the kernel makes
+the process highly privileged: its effective uid is root, and it has
+all the necessary capabilities to mount filesystems. I submit the request
+by passing it in the command-line arguments. mount does some checks -
+specifically, it looks in `/etc/fstab` to see whether the filesystem I'm
+trying to mount has the “`user`” or “`users`” flag - then carries out the
+mount system call.
+
+There are a few obvious problems with this:
+
+* When machines had
+  [a static set of hardware devices](https://www.redhat.com/archives/redhat-install-list/2003-July/msg00199.html)
+  (and a sysadmin who knew how to configure them), it might have
+  made sense to list them all in /etc/fstab; but this is not a useful
+  solution if you can plug in any number of USB drives, or if you are
+  a non-expert user with Linux on your laptop. The decision
+  ought to be based on general attributes of devices, such as “is removable?”,
+  and on the role of the machine.
+* Setuid executables are
+  [alarmingly easy to get wrong](http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/environment-variables.html)
+  so it is [not](https://security-tracker.debian.org/tracker/CVE-2013-0157)
+  [necessarily](https://security-tracker.debian.org/tracker/CVE-2007-5191)
+  [wise](https://security-tracker.debian.org/tracker/CVE-2005-2876)
+  to assume that mount(8) is safe to be setuid.
+* One fact that a reasonable security policy might include is “users who
+  are logged in remotely should have less control over physically present
+  devices than those who are physically present” - but that sort of thing
+  can't be checked by mount(8) without specifically teaching the
+  mount binary about it.
+
+### Ask a system service to do it, via D-Bus or other IPC
+
+To avoid the issues of setuid, we could use inter-process communication in
+the traditional sense: run a privileged daemon (on boot or on-demand),
+make it listen for requests, and use the IPC channel as our privilege boundary.
+
+`udisks2` is one such privileged daemon, which uses D-Bus as its IPC channel.
+D-Bus is a commonly-used inter-process system; one of its
+intended/designed uses is to let user processes and system services
+communicate, especially this sort of communication between a privileged
+daemon and its less-privileged clients.
+
+People sometimes criticize D-Bus as not doing anything you couldn't do yourself
+with some `AF_UNIX` sockets. Well, no, of course it doesn't - the important
+bit of the reference implementation and the various interoperable
+reimplementations consists of a daemon and some `AF_UNIX` sockets, and the
+rest is
+[a simple matter of programming](https://en.wikipedia.org/wiki/Small_matter_of_programming).
+However, it's sufficient for most uses in its problem space, and is usually better than inventing your
+own.
+
+The advantage of D-Bus over doing your own thing is precisely that you
+are not doing your own thing: good IPC design is hard, and D-Bus makes
+some structural decisions so that fewer application
+authors have to think about them. For instance, it has a central “hub” daemon
+(the `dbus-daemon`, or “message bus”) so that <i>n</i> communicating applications
+don't need O(<i>n</i>²) sockets; it uses the `dbus-daemon` to provide a
+[total message ordering](https://en.wikipedia.org/wiki/Total_order)
+so you don't have to think about message reordering; it has a distributed
+naming model (which can also be used as a distributed mutex) so you don't
+have to design that; it has a serialization format and a type system so you
+don't have to design one of those; it has a framework for “activating"
+run-on-demand daemons so they don't have to use resources initially,
+implemented using a setuid helper and/or systemd; and so on.
+
+If you have religious objections to D-Bus, you can mentally replace
+“D-Bus” with “`AF_UNIX` or something” and most of this article will
+still be true.
+
+## Is this OK?
+
+In either case - `exec`'ing a privileged helper, or submitting a request to a
+privileged daemon via IPC - the privileged process has two questions that
+it needs to answer before it does its work:
+
+* what am I being asked to do?
+* should I do it?
+
+It needs to make some sort of decision on the latter based on the
+information available to it. However, before we even get there, there is
+another layer:
+
+* did the request get there at all?
+
+In the setuid model, there is a simple security check that you can
+apply: you can make `/bin/mount` only executable by a particular group,
+or only executable by certain AppArmor profiles, or similar. That works
+up to a point, but cannot distinguish between physically-present and

(Diff truncated)

diff --git a/2014.mdwn b/2014.mdwn
new file mode 100644
index 0000000..10512f2
--- /dev/null
+++ b/2014.mdwn
@@ -0,0 +1 @@
+[[!map pages="2014/* and copyright(*)" show=title]]
diff --git a/2014/still_universal.mdwn b/2014/still_universal.mdwn
new file mode 100644
index 0000000..e4f0a90
--- /dev/null
+++ b/2014/still_universal.mdwn
@@ -0,0 +1,70 @@
+[[!meta title="still aiming to be the universal operating system"]]
+[[!meta date="2014-11-19"]]
+[[!meta updated="2014-11-19"]]
+[[!meta copyright="Copyright © 2014 Simon McVittie"]]
+[[!tag debian]]
+
+Debian's latest round of angry mailing list threads have been about some
+combination of init systems, future direction and project governance.
+The details aren't particularly important here, and pretty much everything
+worthwhile in favour of or against each position has already been said several
+times, but I think this bit is important enough that it bears repeating:
+the reason I voted "we didn't need this General Resolution" ahead
+of the other options is that I hope we can continue to use our normal
+technical and decision-making processes to make Debian 8 the best possible
+OS distribution for everyone. That includes people who like systemd,
+people who dislike systemd, people who don't care either way and just
+want the OS to work, and everyone in between those extremes.
+
+I think that works best when we do things, and least well when a lot
+of time and energy get diverted into talking about doing things.
+I've been trying to do my small part of the former by
+[fixing some release-critical bugs](https://udd.debian.org/bugs.cgi) so we
+can release Debian 8. Please join in, and remember to
+[write](http://www.jwiltshire.org.uk/content/2014/11/16/getting-things-into-jessie-1/)
+[good](http://www.jwiltshire.org.uk/content/2014/11/17/getting-things-into-jessie-2/)
+[unblock](http://www.jwiltshire.org.uk/content/2014/11/18/getting-things-into-jessie-3/)
+[requests](http://www.jwiltshire.org.uk/content/2014/11/19/getting-things-into-jessie-4/)
+so our hard-working release team can get through them in a finite time.
+I realise not everyone will agree with my idea of which bugs, which
+features and which combinations of packages are
+highest-priority; that's fine, there are plenty of bugs to go round!
+
+Regarding init systems specifically, Debian 'jessie' currently works with
+at least systemd-sysv or sysvinit-core as pid 1 (probably also Upstart, but
+I haven't tried that) and I'm confident that Debian developers won't let
+either of those regress before it's released as Debian 8.
+
+I expect the freeze for Debian 'stretch' (presumably Debian 9) to be a
+couple of years away, so it seems premature to say anything about what
+will or won't be supported there; that depends on what upstream developers
+do, and what Debian developers do, between now and then. What I can predict is
+that the components that get
+[useful bug reports](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html),
+active maintenance, thorough testing, careful review,
+and similar help from contributors will work better than the things
+that don't; so if you like a component and want it to be supported in
+Debian, you can help by, well, supporting it.
+
+----
+
+PS. If you want the Debian 8 installer to leave you running sysvinit
+as pid 1 after the first reboot, here's a suitable incantation to add to
+the kernel command-line in the installer's bootloader. This one certainly
+worked when [KiBi](http://mraw.org/blog/) asked for testing a few days ago:
+
+    preseed/late_command="in-target apt-get install -y sysvinit-core"
+
+I think that corresponds to this line in a preseeding file, if you use those:
+
+    d-i preseed/late_command string in-target apt-get install -y sysvinit-core
+
+A similar apt-get command, without the in-target prefix, should work on an
+installed system that already has systemd-sysv. Depending on other installed
+software, you might need to add systemd-shim to the command line too,
+but when I tried it, apt-get was able to work that out for itself.
+
+If you use aptitude instead of apt-get, double-check what it will do
+before saying "yes" to this particular switchover: its heuristic for
+resolving conflicts seems to be rather more trigger-happy about removing
+packages than the one in apt-get.

diff --git a/local.css b/local.css
index e57e876..c31f65b 100644
--- a/local.css
+++ b/local.css
@@ -1,2 +1 @@
 @import url("/style/pcu.css");
-@import url("/style/trail.css");
diff --git a/templates/page.tmpl b/templates/page.tmpl
deleted file mode 100644
index 770ac23..0000000
--- a/templates/page.tmpl
+++ /dev/null
@@ -1,207 +0,0 @@
-<TMPL_IF HTML5><!DOCTYPE html>
-<html>
-<TMPL_ELSE><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-</TMPL_IF>
-<head>
-<TMPL_IF DYNAMIC>
-<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
-<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>
-</TMPL_IF>
-</TMPL_IF>
-<TMPL_IF HTML5><meta charset="utf-8" /><TMPL_ELSE><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></TMPL_IF>
-<title><TMPL_VAR TITLE></title>
-<TMPL_IF FAVICON>
-<link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" />
-</TMPL_IF>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL>style.css" type="text/css" />
-<TMPL_IF LOCAL_CSS>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" />
-<TMPL_ELSE>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" />
-</TMPL_IF>
-<TMPL_IF EDITURL>
-<link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" />
-</TMPL_IF>
-<TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF>
-<TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF>
-<TMPL_IF META><TMPL_VAR META></TMPL_IF>
-<TMPL_LOOP TRAILLOOP>
-<TMPL_IF PREVPAGE>
-<link rel="prev" href="<TMPL_VAR PREVURL>" title="<TMPL_VAR PREVTITLE>" />
-</TMPL_IF>
-<link rel="up" href="<TMPL_VAR TRAILURL>" title="<TMPL_VAR TRAILTITLE>" />
-<TMPL_IF NEXTPAGE>
-<link rel="next" href="<TMPL_VAR NEXTURL>" title="<TMPL_VAR NEXTTITLE>" />
-</TMPL_IF>
-</TMPL_LOOP>
-</head>
-<body>
-
-<TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
-
-<TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
-<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF>
-<span>
-<span class="parentlinks">
-<TMPL_LOOP PARENTLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ 
-</TMPL_LOOP>
-</span>
-<span class="title">
-<TMPL_VAR TITLE>
-<TMPL_IF ISTRANSLATION>
-&nbsp;(<TMPL_VAR PERCENTTRANSLATED>%)
-</TMPL_IF>
-</span>
-</span>
-<TMPL_IF SEARCHFORM>
-<TMPL_VAR SEARCHFORM>
-</TMPL_IF>
-<TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_IF HAVE_ACTIONS>
-<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF>
-<ul>
-<TMPL_IF EDITURL>
-<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>
-</TMPL_IF>
-<TMPL_IF RECENTCHANGESURL>
-<li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
-</TMPL_IF>
-<TMPL_IF HISTORYURL>
-<li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
-</TMPL_IF>
-<TMPL_IF GETSOURCEURL>
-<li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li>
-</TMPL_IF>
-<TMPL_IF PREFSURL>
-<li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li>
-</TMPL_IF>
-<TMPL_IF ACTIONS>
-<TMPL_LOOP ACTIONS>
-<li><TMPL_VAR ACTION></li>
-</TMPL_LOOP>
-</TMPL_IF>
-<TMPL_IF COMMENTSLINK>
-<li><TMPL_VAR COMMENTSLINK></li>
-<TMPL_ELSE>
-<TMPL_IF DISCUSSIONLINK>
-<li><TMPL_VAR DISCUSSIONLINK></li>
-</TMPL_IF>
-</TMPL_IF>
-</ul>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF OTHERLANGUAGES>
-<TMPL_IF HTML5><nav id="otherlanguages"><TMPL_ELSE><div id="otherlanguages"></TMPL_IF>
-<ul>
-<TMPL_LOOP OTHERLANGUAGES>
-<li>
-<a href="<TMPL_VAR URL>"><TMPL_VAR LANGUAGE></a>
-<TMPL_IF MASTER>
-(master)
-<TMPL_ELSE>
-&nbsp;(<TMPL_VAR PERCENT>%)
-</TMPL_IF>
-</li>
-</TMPL_LOOP>
-</ul>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_VAR TRAILS>
-
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_IF SIDEBAR>
-<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
-<TMPL_VAR SIDEBAR>
-<TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<div id="pagebody">
-
-<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
-<TMPL_VAR CONTENT>
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_UNLESS DYNAMIC>
-<TMPL_IF COMMENTS>
-<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
-<TMPL_VAR COMMENTS>
-<TMPL_IF ADDCOMMENTURL>
-<div class="addcomment">
-<a href="<TMPL_VAR ADDCOMMENTURL>">Add a comment</a>
-</div>
-<TMPL_ELSE>
-<div class="addcomment">Comments on this page are closed.</div>
-</TMPL_IF>
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-</TMPL_UNLESS>
-
-</div>
-
-<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
-<TMPL_UNLESS DYNAMIC>
-<TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
-
-<TMPL_IF TAGS>
-<TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><div class="tags"></TMPL_IF>
-Tags:
-<TMPL_LOOP TAGS>
-<TMPL_VAR LINK>
-</TMPL_LOOP>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF BACKLINKS>
-<TMPL_IF HTML5><nav id="backlinks"><TMPL_ELSE><div id="backlinks"></TMPL_IF>
-Links:
-<TMPL_LOOP BACKLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
-</TMPL_LOOP>
-<TMPL_IF MORE_BACKLINKS>
-<span class="popup">...
-<span class="balloon">
-<TMPL_LOOP MORE_BACKLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
-</TMPL_LOOP>
-</span>
-</span>
-</TMPL_IF>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF COPYRIGHT>
-<div class="pagecopyright">
-<a name="pagecopyright"></a>
-<TMPL_VAR COPYRIGHT>
-</div>
-</TMPL_IF>
-
-<TMPL_IF LICENSE>
-<div class="pagelicense">

(Diff truncated)

diff --git a/2008/08/collaboratively/comment_1_a84b93620c75ccd319d40db3369491d8._comment b/2008/08/collaboratively/comment_1_a84b93620c75ccd319d40db3369491d8._comment
new file mode 100644
index 0000000..b6a4d56
--- /dev/null
+++ b/2008/08/collaboratively/comment_1_a84b93620c75ccd319d40db3369491d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joel.rosdahl.net/"
+ nickname="jrosdahl"
+ subject="A better way"
+ date="2011-12-11T20:17:39Z"
+ content="""
+A both easier and more robust way of doing it is this:
+
+    export CCACHE_PREFIX=icecc
+
+See <http://ccache.samba.org/manual.html#_using_ccache_with_other_compiler_wrappers>.
+"""]]

diff --git a/index.mdwn b/index.mdwn
index 99f30ab..95debaf 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -10,8 +10,8 @@
 This is Simon McVittie's software development blog. Main site:
   [pseudorandom.co.uk](http://www.pseudorandom.co.uk/)
 
-[[!trailinline pages="20*/* and copyright(*) and !*/Discussion"
-  show="5" actions="yes" sort="age"
+[[!inline pages="20*/* and copyright(*) and !*/Discussion"
+  show="5" actions="yes" sort="age" trail="yes"
   atom="yes" guid="urn:uuid:0955f57e-4c2c-4614-b791-cf0bfb70f00e"
   description="Simon McVittie's software development blog"]]
 

diff --git a/style/trail.css b/style/trail.css
index 1bd1862..0fdc145 100644
--- a/style/trail.css
+++ b/style/trail.css
@@ -1,40 +1 @@
-/* from IkiWiki branch */
-
-.trail {
-	display: block;
-	clear: both;
-	position: relative;
-}
-
-.trailprev {
-	display: block;
-	text-align: left;
-	position: absolute;
-	top: 0%;
-	left: 3%;
-	width: 30%;
-}
-
-.trailup {
-	display: block;
-	text-align: center;
-	margin-left: 35%;
-	margin-right: 35%;
-}
-
-.trailnext {
-	display: block;
-	text-align: right;
-	position: absolute;
-	top: 0%;
-	width: 30%;
-	right: 3%;
-}
-
-.trailsep {
-	display: none;
-}
-
-/* pseudorandom-specific */
-
 .trails, .actions { margin-top: 0.5em; margin-bottom: 0.5em; }

diff --git a/style/trail.css b/style/trail.css
index e6a08ed..1bd1862 100644
--- a/style/trail.css
+++ b/style/trail.css
@@ -37,4 +37,4 @@
 
 /* pseudorandom-specific */
 
-.trails, .actions { margin-top: 0.2em; margin-bottom: 0.2em; }
+.trails, .actions { margin-top: 0.5em; margin-bottom: 0.5em; }

diff --git a/style/trail.css b/style/trail.css
index 6b26540..e6a08ed 100644
--- a/style/trail.css
+++ b/style/trail.css
@@ -34,3 +34,7 @@
 .trailsep {
 	display: none;
 }
+
+/* pseudorandom-specific */
+
+.trails, .actions { margin-top: 0.2em; margin-bottom: 0.2em; }

diff --git a/style/trail.css b/style/trail.css
index 6b26540..1bd1862 100644
--- a/style/trail.css
+++ b/style/trail.css
@@ -34,3 +34,7 @@
 .trailsep {
 	display: none;
 }
+
+/* pseudorandom-specific */
+
+.trails, .actions { margin-top: 0.5em; margin-bottom: 0.5em; }

diff --git a/style/trail.css b/style/trail.css
index 35a1331..6b26540 100644
--- a/style/trail.css
+++ b/style/trail.css
@@ -1,506 +1,4 @@
-/* ikiwiki style sheet */
-
-/* Note that instead of modifying this style sheet, you can instead edit
- * local.css and use it to override or change settings in this one.
- */
-
-/* html5 compat */
-article,
-header,
-footer,
-nav {
-	display: block;
-}
-
-.header {
-	margin: 0;
-	font-size: 140%;
-	font-weight: bold;
-	line-height: 1em;
-	display: block;
-}
-
-.inlineheader .author {
-	margin: 0;
-	font-size: 112%;
-	font-weight: bold;
-	display: block;
-}
-
-.actions ul {
-	margin: 0;
-	padding: 6px .4em;
-	height: 1em;
-	list-style-type: none;
-}
-.actions li {
-	display: inline;
-	padding: .2em;
-}
-.pageheader .actions ul {
-	border-bottom: 1px solid #000;
-}
-
-.inlinepage .actions ul {
-	border-bottom: 0;
-}
-
-#otherlanguages ul {
-	margin: 0;
-	padding: 6px;
-	list-style-type: none;
-}
-#otherlanguages li {
-	display: inline;
-	padding: .2em .4em;
-}
-.pageheader #otherlanguages {
-	border-bottom: 1px solid #000;
-}
-
-.inlinecontent {
-	margin-top: .4em;
-}
-
-.pagefooter,
-.inlinefooter,
-.comments {
-	clear: both;
-}
-
-#pageinfo {
-	margin: 1em 0;
-	border-top: 1px solid #000;
-}
-
-.tags {
-	margin-top: 1em;
-}
-
-.inlinepage .tags {
-        display: inline;
-}
-
-.mapparent {
-	text-decoration: none;
-}
-
-.img caption {
-	font-size: 80%;
-	caption-side: bottom;
-	text-align: center;
-}
-
-img.img {
-	margin: 0.5ex;
-}
-
-.align-left {
-	float:left;
-}
-
-.align-right {
-	float:right;
-}
-
-#backlinks {
-	margin-top: 1em;
-}
-
-#searchform {
-	display: inline;
-	float: right;
-}
-
-#editcontent {
-	width: 98%;
-}
-
-.editcontentdiv {
-	width: auto;
-	overflow: auto;
-}
-
-img {
-	border-style: none;
-}
-
-pre {
-	overflow: auto;
-}
-
-div.recentchanges {
-	border-style: solid;
-	border-width: 1px;
-	overflow: auto;
-	width: auto;
-	clear: none;
-	background: #eee;
-	color: black !important;
-}
-.recentchanges .metadata {
-	padding: 0px 0.5em;
-}
-.recentchanges .changelog {
-	font-style: italic;
-	clear: both;
-	display: block;
-	padding: 1px 2px;
-	background: white !important;
-	color: black !important;
-}
-.recentchanges .desc {
-	display: none;
-}
-.recentchanges .diff {
-	display: none;
-}
-.recentchanges .committer {
-	float: left;
-	margin: 0;
-	width: 40%;
-}
-.recentchanges .committype {
-	float: left;
-	margin: 0;
-	width: 5%;
-	font-size: small;
-}
-.recentchanges .changedate {
-	float: left;
-	margin: 0;
-	width: 35%;
-	font-size: small;
-}
-.recentchanges .pagelinks,
-.recentchanges .revert {
-	float: right;
-	margin: 0;
-	width: 60%;
-}
-
-.blogform, #blogform {
-	padding: 10px 10px;
-	border: 1px solid #aaa;
-	background: #eee;
-	color: black !important;
-	width: auto;
-	overflow: auto;
-}
-
-.inlinepage {
-	padding: 10px 10px;
-	border: 1px solid #aaa;
-	overflow: auto;
-}

(Diff truncated)

diff --git a/index.mdwn b/index.mdwn
index cf48691..99f30ab 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -11,7 +11,7 @@ This is Simon McVittie's software development blog. Main site:
   [pseudorandom.co.uk](http://www.pseudorandom.co.uk/)
 
 [[!trailinline pages="20*/* and copyright(*) and !*/Discussion"
-  show="5" actions="yes" sort="-age"
+  show="5" actions="yes" sort="age"
   atom="yes" guid="urn:uuid:0955f57e-4c2c-4614-b791-cf0bfb70f00e"
   description="Simon McVittie's software development blog"]]
 

diff --git a/index.mdwn b/index.mdwn
index c6157e5..cf48691 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -11,7 +11,7 @@ This is Simon McVittie's software development blog. Main site:
   [pseudorandom.co.uk](http://www.pseudorandom.co.uk/)
 
 [[!trailinline pages="20*/* and copyright(*) and !*/Discussion"
-  show="5" actions="yes"
+  show="5" actions="yes" sort="-age"
   atom="yes" guid="urn:uuid:0955f57e-4c2c-4614-b791-cf0bfb70f00e"
   description="Simon McVittie's software development blog"]]
 

diff --git a/index.mdwn b/index.mdwn
index 24fc35c..99f30ab 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -10,8 +10,8 @@
 This is Simon McVittie's software development blog. Main site:
   [pseudorandom.co.uk](http://www.pseudorandom.co.uk/)
 
-[[!inline pages="20*/* and copyright(*) and !*/Discussion"
-  show="5" actions="yes"
+[[!trailinline pages="20*/* and copyright(*) and !*/Discussion"
+  show="5" actions="yes" sort="age"
   atom="yes" guid="urn:uuid:0955f57e-4c2c-4614-b791-cf0bfb70f00e"
   description="Simon McVittie's software development blog"]]
 

diff --git a/index.mdwn b/index.mdwn
index 24fc35c..c6157e5 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -10,7 +10,7 @@
 This is Simon McVittie's software development blog. Main site:
   [pseudorandom.co.uk](http://www.pseudorandom.co.uk/)
 
-[[!inline pages="20*/* and copyright(*) and !*/Discussion"
+[[!trailinline pages="20*/* and copyright(*) and !*/Discussion"
   show="5" actions="yes"
   atom="yes" guid="urn:uuid:0955f57e-4c2c-4614-b791-cf0bfb70f00e"
   description="Simon McVittie's software development blog"]]

diff --git a/local.css b/local.css
new file mode 100644
index 0000000..e57e876
--- /dev/null
+++ b/local.css
@@ -0,0 +1,2 @@
+@import url("/style/pcu.css");
+@import url("/style/trail.css");
diff --git a/style/trail.css b/style/trail.css
new file mode 100644
index 0000000..35a1331
--- /dev/null
+++ b/style/trail.css
@@ -0,0 +1,538 @@
+/* ikiwiki style sheet */
+
+/* Note that instead of modifying this style sheet, you can instead edit
+ * local.css and use it to override or change settings in this one.
+ */
+
+/* html5 compat */
+article,
+header,
+footer,
+nav {
+	display: block;
+}
+
+.header {
+	margin: 0;
+	font-size: 140%;
+	font-weight: bold;
+	line-height: 1em;
+	display: block;
+}
+
+.inlineheader .author {
+	margin: 0;
+	font-size: 112%;
+	font-weight: bold;
+	display: block;
+}
+
+.actions ul {
+	margin: 0;
+	padding: 6px .4em;
+	height: 1em;
+	list-style-type: none;
+}
+.actions li {
+	display: inline;
+	padding: .2em;
+}
+.pageheader .actions ul {
+	border-bottom: 1px solid #000;
+}
+
+.inlinepage .actions ul {
+	border-bottom: 0;
+}
+
+#otherlanguages ul {
+	margin: 0;
+	padding: 6px;
+	list-style-type: none;
+}
+#otherlanguages li {
+	display: inline;
+	padding: .2em .4em;
+}
+.pageheader #otherlanguages {
+	border-bottom: 1px solid #000;
+}
+
+.inlinecontent {
+	margin-top: .4em;
+}
+
+.pagefooter,
+.inlinefooter,
+.comments {
+	clear: both;
+}
+
+#pageinfo {
+	margin: 1em 0;
+	border-top: 1px solid #000;
+}
+
+.tags {
+	margin-top: 1em;
+}
+
+.inlinepage .tags {
+        display: inline;
+}
+
+.mapparent {
+	text-decoration: none;
+}
+
+.img caption {
+	font-size: 80%;
+	caption-side: bottom;
+	text-align: center;
+}
+
+img.img {
+	margin: 0.5ex;
+}
+
+.align-left {
+	float:left;
+}
+
+.align-right {
+	float:right;
+}
+
+#backlinks {
+	margin-top: 1em;
+}
+
+#searchform {
+	display: inline;
+	float: right;
+}
+
+#editcontent {
+	width: 98%;
+}
+
+.editcontentdiv {
+	width: auto;
+	overflow: auto;
+}
+
+img {
+	border-style: none;
+}
+
+pre {
+	overflow: auto;
+}
+
+div.recentchanges {
+	border-style: solid;
+	border-width: 1px;
+	overflow: auto;
+	width: auto;
+	clear: none;
+	background: #eee;
+	color: black !important;
+}
+.recentchanges .metadata {
+	padding: 0px 0.5em;
+}
+.recentchanges .changelog {
+	font-style: italic;
+	clear: both;
+	display: block;
+	padding: 1px 2px;
+	background: white !important;
+	color: black !important;
+}
+.recentchanges .desc {
+	display: none;
+}
+.recentchanges .diff {
+	display: none;
+}
+.recentchanges .committer {
+	float: left;
+	margin: 0;
+	width: 40%;
+}
+.recentchanges .committype {
+	float: left;
+	margin: 0;
+	width: 5%;
+	font-size: small;
+}
+.recentchanges .changedate {
+	float: left;
+	margin: 0;
+	width: 35%;
+	font-size: small;
+}
+.recentchanges .pagelinks,
+.recentchanges .revert {
+	float: right;
+	margin: 0;
+	width: 60%;
+}
+
+.blogform, #blogform {
+	padding: 10px 10px;
+	border: 1px solid #aaa;
+	background: #eee;
+	color: black !important;

(Diff truncated)

diff --git a/local.css b/local.css
new file mode 100644
index 0000000..e57e876
--- /dev/null
+++ b/local.css
@@ -0,0 +1,2 @@
+@import url("/style/pcu.css");
+@import url("/style/trail.css");
diff --git a/style/trail.css b/style/trail.css
new file mode 100644
index 0000000..6b26540
--- /dev/null
+++ b/style/trail.css
@@ -0,0 +1,36 @@
+/* from IkiWiki branch */
+
+.trail {
+	display: block;
+	clear: both;
+	position: relative;
+}
+
+.trailprev {
+	display: block;
+	text-align: left;
+	position: absolute;
+	top: 0%;
+	left: 3%;
+	width: 30%;
+}
+
+.trailup {
+	display: block;
+	text-align: center;
+	margin-left: 35%;
+	margin-right: 35%;
+}
+
+.trailnext {
+	display: block;
+	text-align: right;
+	position: absolute;
+	top: 0%;
+	width: 30%;
+	right: 3%;
+}
+
+.trailsep {
+	display: none;
+}
diff --git a/templates/page.tmpl b/templates/page.tmpl
new file mode 100644
index 0000000..770ac23
--- /dev/null
+++ b/templates/page.tmpl
@@ -0,0 +1,207 @@
+<TMPL_IF HTML5><!DOCTYPE html>
+<html>
+<TMPL_ELSE><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+</TMPL_IF>
+<head>
+<TMPL_IF DYNAMIC>
+<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
+<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>
+</TMPL_IF>
+</TMPL_IF>
+<TMPL_IF HTML5><meta charset="utf-8" /><TMPL_ELSE><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></TMPL_IF>
+<title><TMPL_VAR TITLE></title>
+<TMPL_IF FAVICON>
+<link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" />
+</TMPL_IF>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL>style.css" type="text/css" />
+<TMPL_IF LOCAL_CSS>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" />
+<TMPL_ELSE>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" />
+</TMPL_IF>
+<TMPL_IF EDITURL>
+<link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" />
+</TMPL_IF>
+<TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF>
+<TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF>
+<TMPL_IF META><TMPL_VAR META></TMPL_IF>
+<TMPL_LOOP TRAILLOOP>
+<TMPL_IF PREVPAGE>
+<link rel="prev" href="<TMPL_VAR PREVURL>" title="<TMPL_VAR PREVTITLE>" />
+</TMPL_IF>
+<link rel="up" href="<TMPL_VAR TRAILURL>" title="<TMPL_VAR TRAILTITLE>" />
+<TMPL_IF NEXTPAGE>
+<link rel="next" href="<TMPL_VAR NEXTURL>" title="<TMPL_VAR NEXTTITLE>" />
+</TMPL_IF>
+</TMPL_LOOP>
+</head>
+<body>
+
+<TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
+
+<TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
+<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF>
+<span>
+<span class="parentlinks">
+<TMPL_LOOP PARENTLINKS>
+<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ 
+</TMPL_LOOP>
+</span>
+<span class="title">
+<TMPL_VAR TITLE>
+<TMPL_IF ISTRANSLATION>
+&nbsp;(<TMPL_VAR PERCENTTRANSLATED>%)
+</TMPL_IF>
+</span>
+</span>
+<TMPL_IF SEARCHFORM>
+<TMPL_VAR SEARCHFORM>
+</TMPL_IF>
+<TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_IF HAVE_ACTIONS>
+<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF>
+<ul>
+<TMPL_IF EDITURL>
+<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>
+</TMPL_IF>
+<TMPL_IF RECENTCHANGESURL>
+<li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
+</TMPL_IF>
+<TMPL_IF HISTORYURL>
+<li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
+</TMPL_IF>
+<TMPL_IF GETSOURCEURL>
+<li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li>
+</TMPL_IF>
+<TMPL_IF PREFSURL>
+<li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li>
+</TMPL_IF>
+<TMPL_IF ACTIONS>
+<TMPL_LOOP ACTIONS>
+<li><TMPL_VAR ACTION></li>
+</TMPL_LOOP>
+</TMPL_IF>
+<TMPL_IF COMMENTSLINK>
+<li><TMPL_VAR COMMENTSLINK></li>
+<TMPL_ELSE>
+<TMPL_IF DISCUSSIONLINK>
+<li><TMPL_VAR DISCUSSIONLINK></li>
+</TMPL_IF>
+</TMPL_IF>
+</ul>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_IF OTHERLANGUAGES>
+<TMPL_IF HTML5><nav id="otherlanguages"><TMPL_ELSE><div id="otherlanguages"></TMPL_IF>
+<ul>
+<TMPL_LOOP OTHERLANGUAGES>
+<li>
+<a href="<TMPL_VAR URL>"><TMPL_VAR LANGUAGE></a>
+<TMPL_IF MASTER>
+(master)
+<TMPL_ELSE>
+&nbsp;(<TMPL_VAR PERCENT>%)
+</TMPL_IF>
+</li>
+</TMPL_LOOP>
+</ul>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_VAR TRAILS>
+
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_IF SIDEBAR>
+<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
+<TMPL_VAR SIDEBAR>
+<TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<div id="pagebody">
+
+<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
+<TMPL_VAR CONTENT>
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_UNLESS DYNAMIC>
+<TMPL_IF COMMENTS>
+<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
+<TMPL_VAR COMMENTS>
+<TMPL_IF ADDCOMMENTURL>
+<div class="addcomment">
+<a href="<TMPL_VAR ADDCOMMENTURL>">Add a comment</a>
+</div>
+<TMPL_ELSE>
+<div class="addcomment">Comments on this page are closed.</div>
+</TMPL_IF>
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+</TMPL_UNLESS>

(Diff truncated)