#!/bin/lsh

Static Accessibility and Generative Accessibility

For the first time in a while, I'm setting up bluetooth tethering on a new machine (unlike wifi tethering, I can leave a bluetooth connection up all day long without noticeably affecting my phone's battery life). For reasons outlined here, I do this using short snippets of shell script to bring the bluetooth connection up and down. In the past, this meant calling the pand CLI tool, but that's changed in the latest version of bluez. As found in the Arch Wiki's guide:

$ dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci0/dev_AA_BB_CC_DD_EE_FF org.bluez.Network1.Connect string:'nap'

Compare this to the previous pand invocation:

# pand -E -S -c AA:BB:CC:DD:EE:FF -e bnep0

Now, I don't know what the logic behind changing to a pure-dbus interface between bluez 4 and bluez 5 was. Presumably there was a good reason, but at the same time a few important things have been lost:

  • The only documentation about doing this I could find on the internet was the above mentioned Arch Wiki guide. If that hadn't existed, the only way of discovering how to do this would have been a combination interrogating bluez' dbus interface with dbus debugging tools and reading the source to bluez - and it would have been necessary to somehow find out that bluez now communicates exclusively over dbus, something I only learned by paging back several pages into the news section of the official bluez website. By contrast, there exist multiple tutorials for accomplishing tethering using pand, and additionally it'd be possible to see what utilities get installed with bluez and read their man pages to discover the whole procedure.
  • bluez now hard-depends on dbus.
  • There's no longer a simple way as a user of bluez to have a script or program wait for the connection to succeed or fail. With pand it was possible to just invoke the tool, and examine its exit status afterwards.

It's most likely that the reasoning behind this change is that the dbus interface is better suited for building GUI bluetooth management applets, which make bluetooth functionality accessible to the nontechnical masses. In essence, we're seeing a change from generative accessibility to static accessibility.

Wait, what? Let me 'splain:

Static accessibility is what is typically meant by 'it just works', or the 'appliance' approach. There is a single task and way of performing the task the tool implements. No additional capabilities are possible, but the ones provided are easy to use and foolproof in operation. It's accessible because it's easy to pick up and use without learning anything, and static because it can be used for only one task.

The new dbus interface represents the static approach: it's a low-level interface intended to be hard-wired into a certain type of larger system. It has definite ideas about the kind of use-case (making a bluetooth icon in a system tray able to control bluetooth connections). The main concern is that there is a very specific experience that needs to be provided, and anything not on the critical path to creating that experience is of secondary importance. Hence "static": The tool makes a capability accessible (as in not requiring training or documentation) in a specific way, and only that way.

Generative accessibility is a major component of what's often referred to as 'hackability' or 'the unix way'. The tool provides a certain ability without providing any policy of how to use that ability (e.g. a flathead screwdriver allows applying torque to opposite sides of a slot, a capability that can be used either to turn screws or crack open the case of a malfunctioning appliance), and provides the ability through a combination of documentation and an empirically discoverable interface the ability to be easily used in novel ways in conjunction with other tools. It's accessible because it's easy to learn to use, and generative because it can be used in creative and unexpected ways.

The old pand approach represents the generative approach: rather than providing an internal component for a certain experience, it provides a tool for controlling bluetooth network interfaces (this is a similar idea to the separation of mechanism and policy principle). The tool is designed to make the typical operations of bringing up and taking down an interface for a specific device simple, and is well (or at least basically) documented. This approach is generative because it enables creativity and use cases not forseen by the providers of the tool. In this case, pand could be used to build both GUI bluetooth connection managers, and the small shell script that lets me control tethering on my OpenPandora with a few quick keystrokes, all without having to be a developer on either the bluez project or Gnome/Android/KDE.

(As a sidebar, I'll note that in this specific case, simply documenting the dbus API to bluez properly would change things significantly, restoring much of what was lost by the elimination of the pand tool.)

If the value judgement I'm making here isn't already obvious, let me spell it out: for a project like bluez, Generative Accessibility is superior to Static Accessibility. Static Accessibility can be easily built on top of Generative Accessibility, but not vice versa. It's the easy hackability of tools like pand that has made Linux what it is today, and there's no defensible reason to undo the layered architecture that makes that hackability possible in the myopic pursuit of one particular type of user experience.

PLUG Advanced Topics: Living Desktop Free

Tonight I've given a talk at the Portland Linux User Group's Advanced Topics meeting on using Linux without a desktop environment. Slides for the talk, containing links to all mentioned resources, can be found here.

About LSH

Leander Samuel Harding is a graduate of several challenging technical programs including the Northeastern University College of Computer Science, the Legend of Zelda, and the Marathon series. He has previously worked on everything from experimental command-and-control tools for USCG operations to the #1 (or #2 or #3 depending on who you ask) web mail service in the world. In his spare time he tweaks his Linux installs, studies programming languages, and plays overly baroque German board games. His keyboard weighs more than your whole computer.