The Rust programming language features a versatile type system. It gives memory safety by distinguishing between raw pointers, pointers to valid data and pointers to data that may be written to. It helps with concurrency by marking types that may be moved between threads. And it helps keep API users on the right track with typestate programming.

With some features of current nightly builds, this concept can be extended to statically check that a function will succeed. Let's explore that road!

fn build_response<W: WritableMessage>(&self, request_data: ..., response: W) -> Result<(), W::Error> {
    let chunk = self.data.view(request_data.block);
    match chunk {
        Ok((payload, option)) => {
            message.set_code(code::Content);
            message.add_opaque_option(option::ETag, &self.etag)?;
            message.add_block_option(option::Block2, option);
            message.add_payload(payload)?;
        }
        Err(_) => {
            message.set_code(code::BadRequest);
        }
    };
    Ok(())
}

fn build_response<W: WritableMessage<520>>(&self, request_data: ..., response: W) -> impl WritableMessage<0> {
    let chunk = self.data.view(request_data.block);
    match chunk {
        Ok((payload, option)) => {
            message
                .set_code(code::Content)
                .add_opaque_option(option::ETag, &self.etag)
                .add_block_option(option::Block2, option)
                .add_payload(payload)
        }
        Err(_) => {
            message
                .set_code(code::BadRequest)
                .into()

        }
    }
}

    Checking myserver v0.1.0
error[E0277]: the trait bound `impl WritableMessage<520>: WritableMessage<522_usize>` is not satisfied
  --> src/main.rs:9:10
   |
1  | fn build_response(&self, request_data: ..., response: W) -> impl WritableMessage<0> {
...
9  |     .add_payload(payload)
   |          ^^^ the trait `WritableMessage<522_usize>` is not implemented for `impl WritableMessage<520>`
   |
help: consider further restricting this bound
   |
1  | fn build_response<W: WritableMessage<522_usize>>(...) {

error: aborting due to previous error

This morning two unfortunate things coincided:

• My /boot had recently run out of disk space, I did my usual workaround of removing all initrd images, and forgot to do the second step of rebuilding them. (Or I just reconfigured grub instead of initramfs-tools).
• My battery went out and the machine went to hibernation.

Consequently, the machine failed to come up at all, showing a kernel panic about being unable to find the root device.

As I have way more volatile state in a running session than I'd like, I made every effort to resume the session, which (spoilers!) eventually worked. Note that this is not a tutorial, just a report that roughly these steps worked for me.

It's worth pointing out that it's likely one only gets one shot at this. Had I gotten it half-right to the point where the init system could open the encrypted root partition but got the resume partition wrong, it would come up and invalidate any hibernation image there was. (An issue I had run into several years ago where the system would try to resume from there on a subsequent boot and wreck everything has been resolved already as far as I understood).

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

echo 'Loading Linux 5.6.1-1-amd64'
linux /vmlinuz-5.6.0-1-amd64 root=-/dev/mapper/hephaistos--vg-root ro quiet
echo 'Manually added initrd'
initrd (hd0)/initrd.img-5.6.0-0.bpo.2-amd64

# blkid /dev/nvme0n1p3
/dev/nvme0n1p3: UUID="b47fac73-66d5-42c6-a370-f9f1dce497d1" TYPE="crypto_LUKS" PARTUUID="76773950-442c-4b81-bf70-9b9da41ec5bf"
# cryltsetup luksOpen /dev/nvme0n1p3 decrypted
[...]
# blkid /dev/mapper/hephaistos--vg-swap_1
/dev/mapper/hephaistos--vg-swap_1: UUID="3c7f3271-f54f-41f0-8ec5-aee20977418e" TYPE="swap"

echo 'Loading Linux 5.6.1-1-amd64'
linux (hd0)/vmlinuz-5.6.0-0.bpo.2-amd64 root=-/dev/mapper/hephaistos--vg-root ro quiet resume=UUID=3c7f3271-f54f-41f0-8ec5-aee20977418e
echo 'Manually added initrd'
initrd (hd0)/initrd.img-5.6.0-0.bpo.2-amd64

Back in the day, the machines I used to maintain either had public IP addresses or were local to my home network; that has changed. I still want to regularly log in to devices "on the road" by means of SSH.

The approaches I considered were:

• "Use the (modern) internet": Only consider IPv6 connections where there is no NAT any more, have the devices announce themselves via some kind of dyndns (TSIG'd AXFRs seem to be the way to go)), and tell their firewalls to let SSH traffic pass (UPNP might be the way to go there).

  I did not follow thisapproach because there are still backwards internet providers that don't provide IPv6, and because especially mobile providers have a tendency not to implement port opening protocols.

• "Use a VPN": Set up a VPN server, assign addresses based on host certificates.

  Would have worked, but I dreaded the configuration effort and running an own central server.

• "Use TOR hidden services": Run TOR on all boxes and announce a hidden service that runs SSH.

  A helper script and custom DNS data allow using this without any per-server configuration on the clients.

  That's the approach I'm describing here.

Host myhost.example.com
    ProxyCommand nc -X 5 -x localhost:9050 abc1234567890.onion 22

_ssh._onion.myhost.example.com IN TXT abc1234567890.onion

Host *
    ProxyCommand ~/.config/maybe-tunnel %h %p

#!/bin/sh
set -e

if getent hosts $1 >/dev/null
then
        exec nc $1 $2
else
        torhost="`dig +short TXT _ssh._onion."$1" | grep \\.onion | sed 's/"//g'`"

        if [ x = x"$torhost" ]
        then
                echo "Host $1 could not be resolved, and has no _ssh._onion TXT record either." >&2
                exit 1
        fi
        exec nc -X 5 -x localhost:9050 "$torhost" $2
fi

I've toyed around with a Beaglebone Black for some days, evaluating its usefulness as a living room box. (Long story short: It's unusable for that, because it can drive only up to 720p due to pixel clock limits, lack of hardware video decoding support and lack of practical [1] 3D acceleration).

(Long-term note: This describes the state of things around 2016-06-28. In some months, this is hopefully only historically relevant, and might be shortened.)

Nevertheless, I've learned some things:

• Serial Debugging is easy to connect once you have a 3.3V USB UART -- the USB UART's GND goes to J1, RX goes to J5 and TX goes to J4, where J1..6 is the pin header next to the socket bar between USB host and 5V, and only J1 is labelled.

  Except for debugging, it is not really required, though; for most of what is described on the rest of this page, one can do without.

• The beaglebone by default executes the U-Boot loader stored on the internal flash memory (eMMC); pressing the boot select button S2 during powerup (reset doesn't count) alters the boot sequence to skip that. This first stage of the booting process is goverened by a program in ROM that I haven't seen anyone try to manipulate yet. (Also, why should one -- it behaves sanely and not touching it makes the device unbrickable for all I can tell).

  • When trying to boot from an MMC device (either the builtin eMMC called mmc0 or the microSD card called mmc1; eMMC and SD cards are rather exchangable as far as the CPU is concerned), the startup code (SPL/MLO (see later), U-Boot, U-Boot config) may either reside on the first and FAT formated partition, or at some fixed offsets between the partition table and the first partition. (So if you wind up with arguments in the kernel cmdline you fail to find in the mounted image, have a look at the intermediate space with a hex editor).
  • Failing that (eg. because no microSD card is inserted and S2 was pressed), the ROM fires up an Ethernet interface via the USB gadget side (ie. when the mini-USB port is connected to a PC, a new USB network card appears there) and asks for the SPL/MLO via bootp.

  The Alexander Holler's boot explaination image visualises this well.

  Both the MMC and the USB networking boot flow take an intermediate step (the secondary program loader, SPL; file name MLO) before loading full U-Boot (file name u-boot.img or similar). The SPL is actually a U-Boot itself, just stripped down to run from on-board RAM; it then initializes the rest of the RAM and loads the fully configured U-Boot (with debug prompt and device support for everything else) to continue.

• It is possible to do the entire flashing without possession of a microSD card, but it's not a widespread way of operation and thus you might encounter some bugs.

  The following workflow shows how to flash the provided Debian image right into eMMC.

  • Obtain a copy of the compressed image file from the latest-images page.

  • Get a copy of the spl, uboot and fit files from the BBBlfs bin/ directory. (There's a copy inside the image at partition 1 in /opt/source/BBBlfs, that should work as well and can be extracted using kpartx and loop mounting). Rename fit to itb because that's the file name needed later.

  • Prepare a DHCP server for the incoming USB connections. I generally find it practical to have a device independent Ethernet setting which I call "I am a WiFi adapter" in NetworkManager, which is configured to have IPv4 "Shared to other computers" -- setting that to "automatically connect to this network when it is available" for the time of playing around is one of the easiest ways to get a DHCP server running.

  • Tell the server to ship the required images by creating a /etc/NetworkManager/dnsmasq-shared.d/spl-uboot-fit.conf file, which modern NetworkManager versions include to every started DHCP server, or include the sniplet into your dnsmasq config if you start it manually:

    bootp-dynamic
    enable-tftp
    tftp-root=/where/you/stored/last/steps/files
    dhcp-vendorclass=set:want-spl,AM335x ROM
    dhcp-vendorclass=set:want-uboot,AM335x U-Boot SPL
    dhcp-boot=tag:want-spl,/spl
    dhcp-boot=tag:want-uboot,/uboot
    

    This will serve the right file at the right time.

  • Wire up the BeagleBone's mini-USB to your workstation and keep S2 pressed while plugging in. You should see NetworkManager take the interface up and set it to "I am a WiFi adapter" (or manually do that if you didn't configure autoconnect).

    If the connection fails to come up / disappears, check your NetworkManager log files (eg. at /var/log/daemon.log); chances are that dnsmasq does not come up because it can't access the TFTP root path. If it does come up, it should disappear again soon afterwards, and you should see a line like

    dnsmasq-tftp[...]: sent /some/path/bin/spl to 10.42.0.x
    

    which indikates that the first stage loader asked as expected and got its response. Following that, a new USB network interface should appear, and you should see the same line just with uboot instead of spl. (Without autoconnect, you'd have to nudge NetworkManager again).

  • Due to what I consider a bug in BBBlfs, we need to take a detour (see bug details on the why, this is just the how of the workaround):

    sudo /etc/init.d/network-manager stop
    sudo ip address add dev enp0s20u1c2 192.168.1.9/24
    sudo dnsmasq --no-daemon --port=0 --conf-dir=/etc/NetworkManager/dnsmasq-shared.d
    

    Once that too shows a "sent" line, end dnsmasq with Ctrl-C; you can start NetworkManager again. (There's a timeout of guesstimated one minute in this step, after which the cycle starts from the beginning. If you don't get a "sent" line from the dnsmasq, check whether you properly renamed the fit file.)

  • You should now see a new block device (/dev/sdc for me) appear, which represents the eMMC flash memory on the BeagleBone. If you have a serial console attached, you are dropped in a linux root shell on the BeagleBone. (What is running there is actually "just" a linux kernel with a g_ether module configured to expose /dev/mmcblk0).

    With that, you can flash images onto eMMC (follow the steps further) or mount and modify existing installations (eg. change the root password you were sure not to forget and have no clue about a year later).

  • You can now flash the image using sudo dd if=bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img of=/dev/sdX -- and double-check whether you're writing to the correct sd-whatever device, dd is short for "disk destroyer".

  • The current images have a (uboot config?) bug that results in the wrong root= argument being passed to the kernel. This can be circumvented by telling U-Boot to use disk UUIDs instead of device names [2]:

    Mount /dev/sdc1 (current bone Debian images have exactly one partition) and edit its /boot/uEnv.txt. There should be a commented-out line uuid=; remove the comment mark (#) and append the UUID of the partition obtained by the blkid /dev/sdc1 command.

    Unmount the disk, wait until the LEDs on the bone only flicker regularly, and then power-cycle it. The device should now boot into a full Debian that can be used from an HDMI attached monitor and USB mouse / keyboard.

I have just switched my terminal from urxvt to xfce4-terminal.

Some considerations that led to the decision:

• urxvt's annoying Ctrl-Shift behavior: Just because I want Unicode displayed, I don't necessarily want to use all the input methods, which get in one's way and are hard to disable. 393847 is a workaround, but not much help for 256 color users. (That was what pushed me over the switching inertia.) If I want to input 🂭, I use gucharmap.
• Switching font sizes is easy with Xfce terminal.
• Standard desktop software: As much as I like my custom desktop, I try to stick to non-exotic components where practical; Xfce is available on most desktops around me.
• I don't need terminal features like scrollback or tabs, because I use tmux both locally and remote for scrollback and multiple shells in a single window.
• Both feel equally snappy, provide support running a single process for many windows, support 256 colors, can be configured not to show anything but the text, and behave well with respect to re-wrapping text (at least when used with tmux).

…with the following changes since 0.1.4 (the intermediate releases were not important enough to get own release announcements):

• Merged parts of the cglita branch
  • solves ValueError / "1080p" issue (Debian bug #507521)
• Fix the 'primary' issue
  • ignores the primary keyword
  • makes ARandR compatible with xrandr 1.4.0
• Show the entire output submenu as disabled instead of the "Active" checkbox
• New unxrandr tool
• New translations:
  • Bosnian (by Semsudin Abdic)
  • Breton (by Belvar)
  • Dutch (by wimfeijen)
  • Galician (by Miguel Anxo Bouzada)
  • Greek (by Dimitris Giouroukis)
  • Hungarian (by Tamás Nagy)
  • Japanese (by o-157)
  • Korean (by ParkJS)
  • Lithunian (by Algimantas Margevičius)
  • Persian (by Alireza Savand)
  • Romanian (by sjb and Себастьян Gli ţa Κατινα)
  • Slovak (by Slavko)
  • Swedish (by Ingemar Karlsson)
  • Ukrainian (by Rax Garfield)
• Updated translations:
  • French (by Bruno Patri)
  • Lithuanian (by Mantas Kriaučiūnas)
  • Persian (by Alireza Savand)
  • Spanish (by Miguel Anxo Bouzada)
• Other small bugfixes

Sticking to what seems to be my two-year window manager changing schedule, I switched again and ended up with i3. Xmonad was ok, performance- and feature-wise, but I didn't find the time to learn Haskell to be really able to configure it properly.

i3 has some properties I particularly like:

• The way it handles multi-monitor setups: Every workspace gets assigned to an output; switching to a workspace on another output opens the workspace there and warps the focus to that output.
• Layouting is so much more flexible, though I still somewhat miss my Super+Return "swap the current window with the big one" of Xmonad.
• The scratchpad: a place to send a window where it can easily be recalled as a popup to the desktop. To be fair, it should be possible to implement the same thing with Xmonad or awesome, but here, it's usable without learning a whole language.

I use the scratchpad as a more powerful replacement for dmenu_run, which under high IO load can take long time to fire up: I keep a terminal with tmux ready at the scratchpad, which is configured to hide itself again as soon as a command is executed, and to spawn another tmux window to be ready for the next input.

Usability-wise, it's like running dmenu or gmrun (which I used some time ago): You press Super-p, a window shows up, you enter your command, press Return, the window vanishes and the command gets executed. In addition, it offers

• a real shell, with all its tab completion powers, aliases etc., and
• a way to recover started processes' stdout/err data, even if they crash (the windows are kept around for some minutes).

The code for that is pretty short, and most of it is to cover corner cases. This file is ~/.config/i3/scratchpad/perpetual_terminal.sh and is best executed from i3 under a flock guard:

(download)

#!/bin/sh

run_inside="'ZDOTDIR=${HOME}/.config/i3/scratchpad zsh'"

while true; do
    # not using urxvtc here, as we're relying on the process to run
    # until either
    #
    # * it gets detached (eg by ^Ad)
    # * it terminates (because someone killed all windows)
    #
    # in any case, we try to reattach to the session, or, if that fails,
    # create a new one.
    urxvt -name scratchpad -e sh -c "tmux attach -t scratchpad || tmux new-session -s scratchpad $run_inside ';' set-option -t scratchpad default-command $run_inside"
done

And this file, ~/.config/i3/scratchpad/.zshrc, configures the shell that gets executed:

(download)

source ~/.zshrc

# reset again what was set outside
export ZDOTDIR=${HOME}

PS1="(scratchpad)$PS1"

preexec() {
    i3-msg '[instance="^scratchpad$"]' move scratchpad
    tmux new-window

    precmd() {
            echo "=============================="
            echo "exited with $?"
            exec sleep 10m
    }
}

zshexit() {
    # user pressed ^D or window got killed, will not be executed when the
    # shell gets "killed" by the final exec in the regular workflow
    i3-msg '[instance="^scratchpad$"]' move scratchpad
    tmux new-window
}

TRAPHUP() {
    # when the window gets killed, just die
    zshexit() {}
}

To activate this from i3, the following lines are placed in the i3 config:

bindsym $mod+p [instance="^scratchpad$"] scratchpad show
exec_always flock -w1 ~/.config/i3/scratchpad/lockfile ~/.config/i3/scratchpad/perpetual_terminal.sh
for_window [instance="^scratchpad$"] move scratchpad

All of the above requires zsh, tmux and urxvt to be installed, zsh to be configure as login shell and possibly other things I might have forgotten (please let me know if you have trouble reproducing this setup).

Other i3 features that look good and I plan to discover:

• Easy to use modes -- maybe I'll revive my key combos of old (Super+Space, g, P for "games / pioneers server", Super+Space, Print, u for "take a screenshot, upload it to my server and put the URL into my clipboard" etc.
• VIM-like marks

An issue I yet have to find a solution for is the status bar: I want nice graphs of CPU usage etc, so the tiling window manager typical solutions like dzen2 or i3's i3status/i3bar won't do the trick. I'm using conky for the moment, but I still need i3bar because it has a realtime display of the active workspace and of urgency notifications. Ideally, I'd want i3bar to provide an X window to conky where it can draw, but for the moment, I'm keeping a single statusline worth of visual information in two distinct panels.

This is a bugfix / translation update release with the following changes since 0.1.3:

• Fix for "unknown connection" bug
• New translations:
  • Russian (by HsH)
  • French (by Clément Démoulins)
  • Polish (by RooTer)
  • Arabic (by Mohammad Alhargan)
  • Turkish (by Mehmet Gülmen)
  • Spanish (by Ricardo A. Hermosilla Carrillo)
  • Catalan (by el_libre)
  • Chinese (by Carezero)
• Translation updates:
  • Danish
  • Brazilian
  • Arabic (by aboodilankaboot)

I am sorry to disappoint those that wait for the "next big" release (with enhanced parsing to fix #507521 and support for xrandr 1.3 features like --primary) – while those issues are as important as the bug fixed here, this was a "low hanging fruit" and a welcome occasion to do a release with all the new translations. Big thanks to all translators!

After having used awesome for more than two years, I just switched to xmonad. Main reasons for the change were the configuration mess (which rendered my carefully crafted CPU and memory indicators useless in one of the last major upgrades) and the way awesome handles multi-monitor setups (boils down to reloading after adding or removing an output).

The packages I use are:

xmonad
   suckless-tools # provides dmenu-run configured on Win-P
   gmrun # confiured on Win-Shift-P
   dzen2 # menu bar
   # needed for custom configuration:
   libghc6-xmonad-dev
   libghc6-xmonad-contrib-dev

My xmonad configuration looks like this:

(download)

import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ManageDocks
import XMonad.Util.Run(spawnPipe)
import XMonad.Util.EZConfig(additionalKeys)
import System.IO
import qualified Data.Map as M
import XMonad.Actions.CycleWS
import XMonad.Actions.CycleRecentWS
import XMonad.Hooks.DynamicLog   (PP(..), dynamicLogWithPP, wrap, defaultPP)
import XMonad.Hooks.UrgencyHook

-- keybindings: similar to the awesome default config i got used to
-- ---------------------------------------------------------------------------

myKeys conf@(XConfig {XMonad.modMask = modm}) = [
    ((modm, xK_Down), nextScreen),
    ((modm .|. shiftMask, xK_Down), shiftNextScreen),
    ((modm, xK_Up), prevScreen),
    ((modm .|. shiftMask, xK_Up), shiftPrevScreen),

    ((modm, xK_Left), prevWS),
    ((modm .|. shiftMask, xK_Left), shiftToPrev),
    ((modm, xK_Right), nextWS),
    ((modm .|. shiftMask, xK_Right), shiftToNext),

    ((modm, xK_Escape), toggleWS),

    ((modm .|. shiftMask, xK_b), spawn "epiphany -p")
    ]
newKeys x  = M.union (keys defaultConfig x) (M.fromList (myKeys x))

-- main program
-- ---------------------------------------------------------------------------

main = do
    statusBarPipe <- spawnPipe statusBarCmd
    xmonad $ withUrgencyHook dzenUrgencyHook { args = ["-bg", "darkgreen", "-xs", "1"] }
            $ defaultConfig {
            modMask = mod4Mask, -- windows key
            terminal = "uxterm",
            manageHook = manageDocks <+> manageHook defaultConfig, -- autodetection for gnome panel and similar
            layoutHook = avoidStruts  $  layoutHook defaultConfig, -- adds gaps for panels
            keys = newKeys,
            logHook = dynamicLogWithPP $ myPP statusBarPipe
    }

-- status bar on top
-- ---------------------------------------------------------------------------

statusBarCmd= "dzen2 -p -h 16 -ta l -bg '" ++ myNormalBGColor ++ "' -fg '" ++ myNormalFGColor ++ "'"

-- helper function (my first haskell function *g*)
--
-- as ppUrgent is applied after ppHidden, the dzen markup has to be removed and new stuff added

dzenStripWrap :: String -> String -> String -> String
dzenStripWrap _ _ "" = ""
dzenStripWrap l r m = l ++ dzenStrip m ++ r

-- status bar design
--
-- based on http://www.haskell.org/haskellwiki/Xmonad/Config_archive/Xilon's_xmonad.hs

myNormalBGColor     = "#2e3436"
myNormalFGColor     = "#babdb6"
myEmptyBGColor      = myNormalBGColor
myEmptyFGColor      = "#7478f6" -- (myNormalBGColor + myNormalFGColor) / 2

myFocusedBGColor    = "#414141"
myFocusedFGColor    = "#73d216"
myOtherscreenBGColor= myFocusedBGColor
myOtherscreenFGColor= myNormalFGColor
mySeperatorColor    = "#000000"
myUrgentBGColor     = "#0000ff"
myUrgentFGColor     = "#f57900"


-- pretty printer

myPP handle = defaultPP {
        ppCurrent                   = wrap ("^fg(" ++ myFocusedFGColor ++ ")^bg(" ++ myFocusedBGColor ++ ")^p(4)") "^p(4)^fg()^bg()",
        ppUrgent                = dzenStripWrap ("^fg(" ++ myUrgentFGColor  ++ ")^bg(" ++ myUrgentBGColor  ++ ")^p(4)") ("^fg(" ++ myUrgentFGColor  ++ ")^bg(" ++ myUrgentBGColor  ++ ")^p(4)^fg()^bg()"),
        ppVisible               = wrap ("^fg(" ++ myOtherscreenFGColor  ++ ")^bg(" ++ myOtherscreenBGColor  ++ ")^p(4)") "^p(4)^fg()^bg()",
        ppHidden                = wrap ("^fg(" ++ myNormalFGColor  ++ ")^bg(" ++ myNormalBGColor  ++ ")^p(4)") "^p(4)^fg()^bg()",
        ppHiddenNoWindows       = wrap ("^fg(" ++ myEmptyFGColor  ++ ")^bg(" ++ myEmptyBGColor  ++ ")^p(4)") "^p(4)^fg()^bg()",
        ppWsSep     = "", -- explicit ^p(4) above provide coloured border
        ppSep     = "^fg(" ++ mySeperatorColor ++ ") * ^fg()",
        ppLayout = (\x -> ""), -- i usually see which layout is used and don't need an extra display
        ppTitle   = wrap ("^fg(" ++ myFocusedFGColor ++ ")") "^fg()" ,
        ppOutput  = hPutStrLn handle
}

All together, the transition was quite painless. I still miss my window list from awesome (the window list from gnome-panel seems not to work with xmonad) – any ideas how to get one easily?

… with the following changes since 0.1.2:

• Prevent too large window size requests
• New translations:
  • Italian (by Quizzlo)
  • Brasilian (by Phantom X)
  • Danish (by Joe Hansen)
  • Kannada (by gundachandru)
• Better translation infrastructure
  • Translations now hosted on https://transifex.net/projects/p/arandr/
• man page enhancements
  • man page generation now depends on docutils (>=0.6)
• New source code repository at http://gitorious.org/arandr/arandr