Friday, December 30, 2011

XMonad Keybindings and an aside on Piracy

So I've gotten my x220 all set up the way I like. I ended up using XFCE as my desktop environment again, because if nothing else, I sometimes like an external monitor. Really, I expect to spend most of my time in Screen now that I've set up wicd. By the way, in case you're trying to get it to work and failing, you actually need to specify what wireless device it should use to connect to networks. This device is almost always wlan0, but a default isn't set so you need to do Shift+p and type it in manually in the preferences screen.

I'm still debating window managers, and currently have both StumpWM and XMonad installed. I've been using Stump pretty consistently lately, but I have noticed some inconveniences with it related to how window management works. The main things keeping me on it are the home-row mod "key" and the ability to override that "key" in case the program I'm using needs the keystroke. Taking a look at what XMonad config can do these days, here's how I would do the same

import XMonad
import XMonad.Config.Xfce

import qualified XMonad.StackSet as S
import XMonad.Actions.CycleWS
import XMonad.Actions.CycleWindows
import XMonad.Actions.WindowGo
import XMonad.Actions.GridSelect

import XMonad.Util.EZConfig
import XMonad.Util.CustomKeys

import qualified Data.Map as M

main = xmonad $ xfceConfig { modMask = mod4Mask }
       [ ("M-p", dmenu_launch)
       , ("M-<Return>", spawn_term)
       , ("<Print>", spawn "xfce4-screenshooter")
       , ("C-t p", dmenu_launch)
       , ("C-t C-p", dmenu_launch)
       , ("C-t <Return>", spawn_term)
       , ("C-t w", nextScreen)
       , ("C-t e", prevScreen)
       , ("C-t j", windows S.focusDown)
       , ("C-t S-j", windows S.swapDown)
       , ("C-t k", windows S.focusUp)
       , ("C-t S-k", windows S.swapUp)
       , ("C-t g", goToSelected defaultGSConfig)
       , ("C-t <Space>", sendMessage NextLayout)
       , ("C-t h", sendMessage Shrink)
       , ("C-t l", sendMessage Expand)
       , ("C-t t", withFocused $ windows . S.sink)
       , ("C-t C-t", spawn "xdotool key ctrl+t") -- this is a lie
dmenu_launch = spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\""
spawn_term = spawn "xterm"

A couple of those are blatantly ridiculous (specifically the resizing options are less than helpful if you have to do C-t h C-t h C-t h rather than S h h h), and the xdotool command is entirely fictitious, as the comment claims. I'm actually not even sure why that is; the command works fine when I run it from terminal directly, and it also works fine on any keystroke other than C-t, in both Stump and XMonad. I'm beginning to think it may be a bug in xdotool. Incidentally, I realize that in this one specific situation, it may have been simpler to specify my own submap, but I like the emacs-style keys enough to keep them despite a bit of repetition.

Ok, massive gear shift incoming. Don't say I didn't warn you.

There's been a lot of discussion about piracy across the various reddits I frequent lately. Mostly related to the imminent SOPA and PROTECT IP bills set to pass in the US. The thing that's bothered me the entire way through most of the discussions is that there isn't a standard definition of "piracy". Personally, I'd prefer to take the Stallman approach, just outright rejecting the legitimacy of the term, but that ship has sailed[1]. There are political parties[2] using the term as a rallying cry for people in favor of digital freedom and privacy, and most people joining the conversation haven't been exposed to other terms.

You can't help but be biased if that's all the exposure you've had, recent hollywood romanticization of pirates notwithstanding. So, here are some things to keep in mind. I'm not claiming that this is the complete conversation, but this is the 101-level thought that needs to go into a framework for deciding what your opinion of the situation is.

First off, "piracy" in the software sense translates to "unauthorized copying" if you want to be a bit more pedantic about it. If we look at what DMCA, SOPA et al attempt to regulate, piracy includes, but isn't limited to distributing copyrighted works for profit. To start with, here are some examples of piracy in no particular order:

I'm not making a value judgement on which of the above is ok and which isn't, by the way, and you shouldn't either[3] if you hope to build a working understanding of piracy as it applies to copyrighted works. First off, with so many examples, lets try to extract some principles so that we can figure out how the concept is structured. Based on the above, the different examples, all of which are technically piracy, vary along at least 5 axes: commercial/non-commercial, public/private, incidental/central, singular/numerous, direct/transformitive. Note that none of these are binary either/or situations; they're all on a continuum.

Commercial vs. Non-commercial seems fairly straightforward; is the intent behind the copy to make money or not? It's not that cut and dried though. Copying something onto physical media takes money, and so does hosting a web server. So does recouping that cost count as a commercial venture? This is actually a stumbling block that Linux development hit early on; some people wanted to distribute the operating system, but the initial license forbade accepting money in return. Those would-be distributors contacted Linus about this and pointed out that even though they don't want to charge for the OS itself, the CDs they needed to use cost money, and it took time to produce them. Linus switched to the GPL2 as a result, and this sort of semi-commercial sharing (along with fully commercial distribution) is now perfectly legal.

On one end is "no money or goods change hands in compensation for the shared copy" (think exchanging mix-tapes or posting content on Reddit without actually selling anything), on the other is "I'm making more money the more copyrights are infringed" (think the DVD copying organization, or an advertising-supported model of filesharing)

Public vs. Private is more obviously on a continuum based on that example. On one end is something like "copying a CD or DVD you own onto your iPod", on the other is "Put it on the Pirate Bay", and between the two of them are networks of varying privacy ranging from your own family LAN, to a University-only network to a small-esque online community.

Incidental vs. Central; is the entire point of the copy the copyrighted material (as in the example of fan art), or is the point something else entirely and the copyrighted material happens to be there (as in the example of the first steps video)? A decent test for this is: if you strip out any questionably violating material, would the media still be interesting to its target audience?

Singular vs. Numerous is perhaps the most obviously measurable; how many infringements were there? At one end is making one copy of a music CD to put onto your own music device. At the other is making a few hundred thousand copies. Of course, this is made more ambiguous when you consider how digital technology actually works. In the technical sense, a new copy of a YouTube video is produced every time someone views it (even though the original poster only actually produced one copy; the upload from their computer to the YouTube server). Who takes the heat for the additional copies created when the video is viewed? Is a viewer more guilty when they use a service like keepvid to download the video rather than streming it even though the same number of copies are created either way? The technical aspects of the implementation really begin to matter if the law assumes that all copies are equally infringing.

Direct vs. Transformitive is obviously a continuum, but not very easy to measure. If you make a copy of a DVD, that's direct, but how much of a change can actually transform that media into a new work? I'm biased here, having gone through design school and come out the other end, so I'll only point out that merely obstructing pieces strategically changes the audience reaction. By the time you get to fan art/fic, entirely new works merely using existing settings and character names, it seems fair to claim that we should at least reflect on whether Fair Use might apply to the act of piracy in question.

So those are the axes on which piracy is currently defined. I should note that, according to related laws[4], all of these things qualify as piracy (and therefore constitute content that a website might get taken down over), even though only some of them are things which most humans would agree is immoral. There isn't an idea of degree or fair use inherent in the process of a DMCA takedown, or the upcoming SOPA takedowns, and in general the onus is on the accused to fight the accusation rather than on the accuser to prove harm. Is this piracy? [ ] yes [ ] no, and if [x] yes, it's criminal so take it down. Which should at least illustrate why I think it's important for people to understand the terms.

Many of the things we call "piracy" today are things that were considered either free or fair uses as recently as 20 years ago, many didn't exist as recently as 10 years ago, some were illegal then but probably shouldn't be anymore as a result of technological advancements, and finally some were and continue to be both unethical and illegal.

Now I hope you've been paying attention, because here comes the curveball.

Do you support piracy?

Richard Stallman: Attacking ships and killing the entire crew to take the cargo is very bad. Now, if you mean sharing, of course you should share. Sharing is good.

Sony/RIAA/MPAA/et al: No, all pirates should be executed (or at least fined their life savings and prevented from going near a computer ever again.)

You:[your answer here]

I hope you can see how both of the extreme stances are a bit ridiculous, and that a nuanced view needs to prevail if we're going to continue this decade with any semblance of freedom. And if we refer to the thought framework I proposed earlier, it's fairly obvious why each of the extreme views are ridiculous.

It is not ok to take the output of others' creative work without their permission and distribute it for your own profit without sharing any of the proceeds[5]. That sort of activity is not sharing, and probably should be a criminal act. The people who do this are spiritual descendants of the original book pirates; the guys who would set up a press to run off a few thousand Dickens or Twains and sell them to line their own pockets without supporting the original writers. That's one of the few forms of copyright infringements that you can call "theft" without me getting pissed off at you about the implications. There is clear harm being done to the author and legitimate publishers, there is money being made, the work is not transformitive, there are multitudes of copies, those copies are public, and the copyrighted work is central to the exercise. Lock those fuckers up.

It is ok to take copyrighted works that you've purchased and copy them as many times as you like for personal use. You should be able to copy your CDs onto your DVDs and onto your iPods and onto your computers, and you shouldn't have to fear getting arrested and being forced to prove the legitimacy of your copies over that. You should be able to make a backup of your entire hard drive for later restoration, including all copyrighted works present on that hard drive.

You also should be able to post snippets of copyrighted works for educational and critical purposes, and that cuts to the point I touched on earlier about how this page can itself arguably be considered piracy. In order to semi-intelligently discuss pirate sites like The Pirate Bay, YouTube and DeviantArt, I have to link to them. The discussion wouldn't be nearly as enlightening if you had to imagine how these sites worked based on my vague descriptions, but the act of linking connects you to these tools that you can potentially use to pirate media. The linking question is particularly relevant to sites like The Pirate Bay, which indirectly make money off of copyright infringement, but host none of the files. Conceptually, what's happening is that TPB is keeping a list of files on peoples' private computers, and handing you directions to them when you ask. If you torrent something, they're not involved at all after the introductions; the data is moving directly between you and some individuals at the other end.

It's probably this last kind of piracy that's prompting bills like SOPA; peer to peer sharing via torrents can really only be regulated by monitoring all communications on the internet ever, checking whether they contain copyrighted content and stopping them if they do. That sounds like a bad thing to me, but ultimately it'll fall on the public and public officials to decide whether an end to piracy is worth setting up the perfect world-wide surveillance state, criminalizing cryptography again, and giving up the fair use protections that let them discuss piracy intelligently. Hopefully, that'll be a no, but even if it isn't (or you don't think it should be) you should now be equipped to tell me why without resorting to "why do you support stealing?" like a trained parrot.


1 - [back] - No pun intended there. Seriously.

2 - [back] - In Canada too, by the way.

3 - [back] - Yet

4 - [back] - Both ones that are in effect, and ones that are still being discussed.

5 - [back] - This is a matter completely separate from whether it's wise for a creative worker to grant that permission. I'm not getting into that argument today, but most of my code is available under MIT/GPL licenses and all my illustration work is CC-BY-SA, so you can probably infer what side of that argument I'm on.

Monday, December 26, 2011

x220 and (unrelatedly) Portable Keyboards

So I finally got a new machine. A lenovo x220 laptop. It's kind of a lightweight, but even with an i3 and only 4gb of ram, it easily doubles the specs of my netbook (RIP, battery). Speaking of which, I also got a 9-cell battery for the new box. The cost of this unit was much lower than usual because of a promotional code I stumbled upon. I haven't actually had time to take it for a spin, but the battery came about 20% charged and told me that this would be enough for 2:30 hours of operation. That. Is. Awesome.

The drive in it still has Windows on it so I didn't poke around much like I said. My plan is to toss an SSD in there and throw in Debian as usual[1]. That hard drive is going to be a pain in the ass though. It is a standard 2.5 inch SATA drive, but it's very slightly shorter than the OCZ units I have lying around. That leaves me three options

  1. Go buy a new SSD for the laptop (plausible in a little while, but I'm sort of shopped out at the moment)
  2. Mod the laptop to accept slightly taller drives (this kills the warranty, and the laptop is still covered so I don't want to fuck with it)
  3. Mod one of my drives to fit a smaller space (this also kills the warranty, but my drives are long out of their warranty period, so I give precisely zero fucks)

Three is the obvious winner for the short term. I may still go get a new hard drive later; this unit supports SATA3, so I can get an extra little speed boost by shelling out. Sadly, it looks like SATA3 drives don't come smaller than 120GB, which means ~$200 or so. Incidentally, a SATA2 32GB drive is down to the $60 range these days, so if you're a Linux user that still has a 7200RPM, or even a 10k, you may want to pick an SSD up at these prices. The difference is noticeable.

Time Passes...

So that's done

Except that "mod" turned out to be a bit of an overstatement[2]. I literally just removed the case[3], braced it in the laptop drive bracket using some rubber stoppers, and secured the whole thing with some electrical tape. I'm not about to get fancy for an internal component; it just needs to work, and this does.

That's the old install of AMD64 Squeeze I already had on the drive, and it works mostly fine but I'll still need to re-install. The ethernet drivers in Squeeze don't support Intel's 82579LM; it's already been patched in Wheezy. There obviously aren't any plans to push new changes to the stable release, so I guess I'm moving up to testing. I don't anticipate any problems; unetbootin is running as we speak[4].

I have done a little bit of typing on it by this point; my intention was to finish this article with it, but the lack of network connectivity of any kind put a stop to that. I did notice that the keyboard was improperly set; the right side was ok, but the left side was actually vibrating with each keystroke. Undoing the keyboard screws on the back and re-setting it fixed that easily.

Installing Debian is pretty close to a non-event around here in terms of the attention it requires. Really, I've been thinking about prototyping some things. Firstly, the password-logger is proceeding apace, though I still don't have enough done to consider publishing. I'm at the stage where I can have it remember multiple passwords, cycle through them, and output them on a single button-press. Right now I'm playing around with a little 1x11 numeric LED display I picked up so that the unit will be able to display a label for each password, and I still want to put it together in such a way that I can add/change/delete passwords without having to recompile the thing.

In other news, you already know that my plans involved building a prototype of the chordite, but I've also been looking at other layouts and ideas for the same purposes. I'm only about half-way through building a chordite, but here are my preliminary thoughts about all the designs I've taken a look at[5].



  • one-handed (that lets you use the other hand for balance, for example, in a public transit situation)
  • data entry doesn't use fingertips (makes it easy to chord)
  • standard configuration covers 84 keys (the default key mapping reference is in that zip file)
  • simple construction (only 8 switches to wire up, and the rest can be built with a bit of cardboard and some wire coathanger)


  • chords entered in serial (so it doesn't seem like you could easily use Emacs keystrokes of the style C-x C-h, and it seems like this would kneecap your speed since you're doing two or three effective key-presses per keystroke)
  • strapless (which may or may not be comfortable, but it does mean that you thumb needs to support the board rather than being available for its own keystrokes)

joestutes Wearable Keyboard


  • one-handed
  • non-chording (each switch is one key; I'm assuming that this would be more accurate and faster than chording; it also seems like it would make it easier to memorize)
  • provides "mouse" through thumb-operated joystick


  • emulates 40 keys total, so you need a reduced character set; this is not a coding keyboard
  • requires high level of precision control from each finger (I'm actually not even sure if this is a human thing, or just my mutant hands, but I can only reliably do fine-grained independent control with my index and middle finger; the ring and pinky fingers, even on my main hand, can't really move on their own very well and almost certainly wouldn't be able to do the sort of multi-directional movement that this thing seems to need)
  • construction involves wiring 40 separate switches and a joystick. That's not exactly simple.

Ergo Electronics Keyglove


  • tons of keys
  • glove-based (you're not actually holding anything, so you can easily switch between typing and doing something else)
  • one-handed


  • requires high-precision movements with all fingers (it works with some fairly densely packed contacts, and assumes you can hit them, with various levels of hand-contorting movements, with each finger).
  • single keystrokes, so doing Emacs chords seems difficult if not impossible

Carsten Mehring Keyglove (first prototype)


  • tons of keys
  • glove-based
  • Emacs-style chord capability


  • two-handed (even though you can switch between things easily, you need both hands dedicated to typing with this one; not sure if it would work that way in practice)
  • demo video translation is typeset set in Comic Sans (I'm still a designer, dammit)

Carsten Mehring Keyglove (second prototype)


  • glove-based
  • one-handed


  • not entirely sure how the keystrokes are generated, and therefore how many can actually be generated (it looks like it doesn't do Emacs chords either)



  • one-handed
  • strapped (so your thumb is used for modifier keys)
  • provides "mouse" (mini joystick operated by thumb)
  • thumb operates modifier keys (so Emacs-style chords are easy to hit)


  • none that I can see, actually

Like I said, these are very preliminary thoughts. It's possible that actually using some is easier/more comfortable than I imagined based on the demo videos. A priori, it looks like the ideal is a strap-using, portable-joystick-style keyboard, or a two-handed glove model. Granted I've got different problems than the average user. Emacs use means I need to be able to chord multiple keys, and Tiling WM/keyboard reliance means I don't really want a pointing device most of the time.


1 - [back] - The documentation tells me that I'll actually need to set up one piece of non-free software to run my wireless card, which is sad, but I don't really have the time or patience to go hunt down an atheros-based card this week.

2 - [back] - Which is why you don't see pictures.

3 - [back] - Which is not nearly as dangerous for the drive on an SSD as it is on a traditional platter drive.

4 - [back] - Those of you who already have a Debian machine set up can actually just apt-get install unetbootin

5 - [back] - Ideally, I'll actually put together one of each and take them for a test-drive, but I have no idea how long that will actually take me.

Wednesday, December 14, 2011

Teensy Mode

Ok, this isn't one of those bullshit times where I just say "I'm going to bed" and then end up spending three hours explaining various shit at the expense of wakefulness the following day. Seriously, just one thing, I added a very quick, simple teensy-mode module to my emacs-utils project over at github. It turns out that I can't focus to save my life, but it has been damn enjoyable jumping into code so thoroughly after the set of weeks I've just been through.

The relevant bits are really just

(defun teensy-compile-current-file ()
  (shell-command (format "%s %s" teensy-compile-file-command buffer-file-name)))

(defun teensy-compile-project ()
  (shell-command teensy-compile-project-command))

(defun teensy-load-hex-file ()
  (let ((hex-files (directory-files (file-name-directory buffer-file-name) nil "hex$"))
        (command (format "%s -mmcu=%s -wv " teensy-loader-program teensy-processor-type)))
    (cond ((not hex-files) (message "No hex file found"))
          ((= 1 (length hex-files)) (shell-command (concat command (car hex-files))))
          (t (shell-command (concat command (completing-read "Hex File: " hex-files)))))))

(defun teensy-compile-project-load-file ()
  (progn (teensy-compile-project)

the rest of it is various Emacs boilerplate like key and customization declarations. The one interesting thing I've learned from this experience is that the :options keyword does pretty much jack shit. In a hook customization, you can presumably at least see the list, but it still doesn't constrain your choices to what's there. It might be nice to have the option, since the customization I had in mind was the chip-type of your Teensy board (a required option that needs to be correct or it'll hang your chip, so it's sort of critical to get it correct).

I'm also flaking out on actual project compilation, opting to keep the make command involved, which has some seriaah fuck this, I'm going to sleep.

Tuesday, December 13, 2011

Teensy Fucking Passwords

I've been trying to get to as many Toronto Lisp Users' Group meetings as I can since missing one a couple months ago, though I'm not entirely sure it's good for me. The minutes of conversation/interesting thing ratio is approaching zero, to the point that it might be more accurate to start tracking interesting things/minute, which is excellent except that I have this day job thing which keeps me from spending every waking moment on interesting fiction, crazy languages(closed source warning) and crazier architectures. That's without even accounting for the fact that my wife and I have been beating down the Thalmor on a regular basis.

The last link is actually what got me off my ass and seriously interested in coding again in my spare time[1]. The thing is, as soon as I started looking at it, I had to admit that I have no fucking idea how to go about serious embedded programming, let alone how to do it with forth[2].

I also mentioned a little while ago that I tried poking around at the Teensy and found it to actually work on my machine[3]. The other thing I like is that Teensy lets me use Emacs for development, though there isn't a nicely integrated mode for compiling and loading projects/files onto the chip without jumping into an eshell buffer. I might want to sink some time into that...

No! Focus! No new shit right now!

Anyway, poking around is all very well, but I find that I really need a project of some sort to work on otherwise I don't internalize the concepts effectively. I do still eventually want to build myself a chordite (or something similar; relevant bit at the 2:10 mark), but that looks like it'll take a lot more industrial design and wiring than I'm in the mood for. At about the same time I was thinking about all of this, I stumbled upon a writeup about a hardware keylogger and an article entitled fuck passwords.

The second one is all the correct complaints about passwords and authentication that OpenID was supposed to almost solve, and that SSH keys do solve for those of us lucky enough to be using SSH. The problems remaining are

  • Not every system uses OpenID (and even if they did, you still need to authenticate to your OpenID provider, most of whom use passwords :p)
  • The ones that don't use OpenID are the ones you want to be most secure (banks and such), and their password constraints make them the hardest to remember
  • The most secure thing to do is to come up with a separate password for every service and rotate them regularly, but this is hard to memorize

On top of that, there are a few things[4] that can't be solved by OpenID or RSA keys. Just keep that problem in mind.

The other link is called "PHUKD". And a quick glance at that spec page will tell you exactly why. It's a pranking/surveillance tool whose accompanying paper is entitled Plug and Prey: Malicious USB Devices. The way that it works ostensibly this. First, you surreptitiously connect the device to your targets' computer. Then, depending on what you want, you either set the thing to record keyboard/mouse input for later collection, or have it emulate a mouse/keyboard to run random malicious programs[5]. Like I said, the phukd library makes it a fairly explicit goal to screw with people's computers in this way with a separate CommandAtRunBar for each of Windows, GNOME and OS X. That's just ... mean.

Putting it all together, and as usual, I'm almost 100% sure that I'm not even remotely the first person to think this up, but why not just put your passwords onto a hardware key?

It'll be something like the actual teensy keyboard implementation, but bind each button to a sequence of N characters that get typed out whenever it's pushed. Here's what I came up with after a bit of fiddling (pardon the giant code block, C isn't quite as easy for me to express ideas in).

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <string.h>
#include "usb_keyboard.h"

#define LED_CONFIG      (DDRD |= (1<<6))
#define LED_ON          (PORTD &= ~(1<<6))
#define LED_OFF         (PORTD |= (1<<6))
#define CPU_PRESCALE(n) (CLKPR = 0x80, CLKPR = (n))

uint16_t idle_count=0;

int key_from_char(char c){
  if (c >= 'a' && c <= 'z') return c - 93;
  if (c >= 'A' && c <= 'Z') return c - 61;
  if (c >= '1' && c <= '9') return c - 19;
  if (c == '0') return 39; // 0 is low in ASCII, high in the USB key definition
  // there's no easy mapping between the other ASCII characters and 
  // USB keyboard keys, so these are all 
  switch (c) {
  case 32: return KEY_SPACE; break;
  case 33: return KEY_1; break;
  case 34: return KEY_QUOTE; break;
  case 35: return KEY_NUMBER; break;
  case 36: return KEY_4; break;
  case 37: return KEY_5; break;
  case 38: return KEY_7; break;
  case 39: return KEY_QUOTE; break;
  case 40: return KEY_9; break;
  case 41: return KEY_0; break;
  case 42: return KEYPAD_ASTERIX; break;
  case 43: return KEYPAD_PLUS; break;
  case 44: return KEY_COMMA; break;
  case 45: return KEYPAD_MINUS; break;
  case 46: return KEY_PERIOD; break;
  case 47: return KEYPAD_SLASH; break;

  case 58: return KEY_SEMICOLON; break;
  case 59: return KEY_SEMICOLON; break;
  case 60: return KEY_COMMA; break;
  case 61: return KEY_EQUAL; break;
  case 62: return KEY_PERIOD; break;
  case 63: return KEY_SLASH; break;
  case 64: return KEY_2; break;

  case 91: return KEY_LEFT_BRACE; break;
  case 92: return KEY_BACKSLASH; break;
  case 93: return KEY_RIGHT_BRACE; break;
  case 94: return KEY_6; break;
  case 95: return KEY_MINUS; break;
  case 96: return KEY_TILDE; break;

  case 123: return KEY_LEFT_BRACE; break;
  case 124: return KEY_BACKSLASH; break;
  case 125: return KEY_RIGHT_BRACE; break;
  case 126: return KEY_TILDE; break;

  default: return 0;

int modifier_from_char(char c){
  if ((c >= 'A' && c <= 'Z') ||
      c == 33 || c == 34 ||
      (c >= 36 && c <= 38) ||
      c == 40 || c == 41 ||
      c == 58 || c == 60 ||
      (c >= 62 && c <= 64) ||
      c == 94 || c == 95 ||
      (c >= 123 && c <= 126)) return KEY_SHIFT;
  return 0;

int8_t usb_keyboard_print(char *s){
  int s_len = strlen(s);
  int i;

  for(i = 0; i < s_len; i++){
    usb_keyboard_press(key_from_char(s[i]), modifier_from_char(s[i]));

int main(void) {
  uint8_t b, mask, i;
  uint8_t b_previous=0xFF;
  CPU_PRESCALE(0); // set for 16 MHz clock

  DDRB = 0x00;
  PORTB = 0xFF;
  while (!usb_configured()) /* wait */ ;

  while (1) {
    b = PINB;
    mask = 1;

    for (i=0; i<8; i++) {
      if (((b & mask) == 0) && (b_previous & mask) != 0) {
      mask = mask << 1;

    b_previous = b;

It's actually very close to the example code that runs the keyboard, except that I've modified it to take ASCII strings as input and pretend to type them out. I didn't complicate things (yet) by trying to figure out how to hook up an LED or micro SD card. It just keeps passwords in as part of the program source, and outputs one password per button.

I'm going to develop this over the next little while, at least while my interest is focused enough on it, into a unit that stores a bunch of passwords, lets me select which one I want (indexed by what the password belongs to), and output it. Ideally, I'd also get this down to a package small enough that I could just put on a physical keychain. That's a pretty good learning project for the short term.

Anyway, full circle with the fucking of passwords, when I'm done, this will be a little machine that I can plug into any USB-capable computer, push a button or two, and have it output (with much better recall and more accuracy than I could) a password that can be as massive and unique as I damn well please. It's not computer-specific (so I don't need to worry about syncing it, except for backup purposes), and it works anywhere I'd want to plug in an actual keyboard. That should kill the security problems dead. Of course, I'll need to keep some sort of safeguard in case it stops working or falls into the wrong hands, but at least I won't be forced to pick between convenience and security anymore.

It seems like a pretty obvious, elegant solution to the problem, conceptually. I can see why it hasn't caught on yet though; if you want to use something like this, you basically need to build it yourself. If I had to buy one of these dongles rather than build one, there's no chance in hell that I'd do it. I'd have to either really, truly, trust the provider enough to believe that they'd never snoop on my passwords or log unrelated information, OR I'd need to get a blank key and the source code and then put them together myself. There are just too many fragile points to do it any other way.

And that's about it. Oh, actually, I did toss this code up to codereview, in case someone out there is actually a C coder and wants to tear me a new one about something. I'm still chewing through clomments issues, and I've actually done some real work on cl-chan which I'll hopefully be kicking up soon; just as soon as I decide how to treat the image manipulation pieces.


1 - [back] - If you're also interested, but don't want to drop the $500 on a full, two-chip eval board, you can also get a breadboard kit for about $60 total, though you have to buy the individual chip, power supply and breakout board.

2 - [back] - My only experience with it was writing a few toy programs in gforth, which I get the feeling won't be very useful.

3 - [back] - In marked contrast to the more popular Arduino.

4 - [back] - Like the actual, physical computer I use everyday.

5 - [back] - Or just commandeer the browser to take your target to goatse

Friday, December 2, 2011

Clomment Moderation

It's idea-peeling time, so if you're here for insights, go away. I'm just trying to reason things out to myself.

I'm still trying to tackle the moderation system for clomments in some reasonably simple, reasonably performant way.

The questions I've got around my head are all related to the fact that each person won't be hosting their own server. As much as I'd like that to be the case because of how simple it would make things, it probably won't work out that way. This means that there'll be a need for someone other than the clomments server operator to have moderation powers on the server.

The authentication can all be handled using the OpenID protocol[1], but moderation in a system like this adds some complexity.

Primarily, those complications come from the fact that the model here is a large number of servers each handling the comments sections of a small number of sites. That's not necessarily even a design point, just something I'll have to make peace with if I want to release this under AGPL. So it would be a good idea to avoid having to sign up at each clomments server in order to moderate the comments it stores. Establishing ownership of the domain could be handled by the OpenID protocol, but it won't necessarily be doing so; I don't want it to be a requirement that you host your own identity.

So what I'd really want is a way to moderate comments that doesn't involve setting up an account. What I've got in mind is something like

  • allow anyone to "moderate" clomments on a given page
  • moderating doesn't actually delete anything; you can hide or approve a comment
  • as part of calling the clomments server, the user specifies
    1. the moderator account name(s) for this page
    2. how the page treats new comments (hide-until-approved or show-unless-flagged)
  • the clomments server responds with a subset of comments for the given page that fit the specified moderator/behavior

So, what does this get me?

First, a way of moderating clomments without keeping track of anything user-related. If I use OpenID and this kind of soft-moderation as the first step, I don't have to care who owns what domain or who moderates what page. An anonymous 4chan-style comments system means that I don't have to care who posts what comment. The only person has "account information" on the server is ... the person hosting it (their DB user name and password), and that's sort of unavoidable.

Second, likely a bunch of performance headaches. If I'm keeping moderation sets separate from the comment tree, I need a way of merging them for display purposes. I can probably store them in a way that makes it relatively simple to figure out what comments should be shown based on whose approvals/flags need to be taken into consideration.

Third, a bit of added robustness against intrusions. If someone finds out a site owners credentials and "deletes" all comments on a given page, for instance, no real damage has been done. As soon as control of the account is restored, all removed items can be reinstated.

Finally, some potential support for future features. For instance, if I'm letting anyone "moderate", then it would be pretty cool to write a client at some point in the future that lets a viewer apply their own preferences on top of what's been decided by the moderators.

Ok, so I guess I'm definitely doing it this way. The difficult part is really going to be figuring out how to store mod changes in a way that can be queried efficiently along with the comments and then acted upon in the display layer. The simplest way of the top of my head would be something like

(def-view-class moderation ()
  ((id :type integer :accessor id :initarg :id :db-constraints (:not-null :auto-increment) :db-kind :key)
   (user-id :type integer :reader user-id :initarg :user-id)
   (comment-id :type integer :reader comment-id :initarg :comment-id)
   (page-id :type integer :reader page-id :initarg :page-id)

   (stat :type keyword :accessor stat :initarg :stat)))

At which point we'd get the comments, plus mods, out by calling a method that looks something like

(defmethod comments ((page page) &rest moderators)
  (select 'comment 'moderation
          :where [and [null [slot-value 'comment 'parent]]
                      [= [slot-value 'comment 'page-id] (id page)]
                      [= user-id [or moderators]]]))

That wouldn't run, incidentally, it's just pseudo code of what we'd want. Take a page and a list of moderators (in descending order of authority) and get the comment plus the first moderation on the list. And tadaah, what you have is a list of ([comment] [moderation]) pairs that tell you what should be shown. In fact, it may actually be better to have separate methods for "hide-until-approved" and "show-unless-flagged" sites so that the query itself would only return comments that need to be shown.

It's too late for me to get into thinking about that now though. Hopefully, morning me will have some good ideas on how to translate this bullshit into some vaguely runnable code.


1 - [back] - Which, just as a side-note, seems to be much simpler and more flexible than I sort of imagined it being. Check out the wiki page for a breakdown.

Friday, November 11, 2011

False Alarm. Also, Teensy

It turns out that I jumped the gun putting up that dragon emblem[1], so you won't be rid of me as soon as I was expecting. I did end up putting some hours into the PostScript generator port over to Common Lisp (and it looks about as good so far, though I still need to get my head firmly around dictionaries), but I also had to get something to play around with this weekend, in the absence of any Nords.

Actually, now that I think about it, I'm not sure I ever mentioned my dalliance with embedded programming. In an effort to add a capitol C logo to the header there, and to have some fun with low-level electronics, I bought up an Arduino Uno a while ago[2]. This is probably going to incinerate what little programmer cred I have, but I couldn't for the life of me get the damn IDE to actually upload a program to the chip. This was a while too; the board has been sitting there disused, still retaining the default blink program it was shipped with. I've looked at various potential fixes including getting a more recent version from the repos, downloading the official tarballs from the Arduino site, and toying with some command line utilities to program the thing without that fucking annoying little collection of big shiny icons. I officially give up. That removable Atmega328 may get re-purposed at some point, but I'm not sinking another hour into figuring out exactly why the programming tools don't seem to recognize the board.

There's a point to all this, I swear.

I mentioned that I wanted something else to keep me busy through the weekend[3], so I ended up hitting up my local electronics store for a Teensy 2.0. The funny part, to me at least, is that the little packing slip that came with this chip states

Programming Teensy with C provides access to all features. Experience with the C language and reading technical specifications is helpful. For a beginner oriented environment, [the] Arduino may be a better choice.

The reason that's slightly amusing is that, as I mentioned, the Arduino constantly drove me to frustration. By contrast, I got the Teensy up and running in under ten minutes by following the Getting Started tutorial. It boils down to

  • Install the required libraries (apt-get install gcc-avr binutils-avr avr-libc libusb-dev)
  • Download the loader program (either the binary version for your architecture, or the source. Remember to run make if you go with the source version.)
  • Plug in the Teensy
  • Press the pushbutton to activate the HalfKay loader
  • Load your code onto it (either by running the GUI, or by using ./teensy_loader_cli -mmcu=[your processor here] -wv program.hex)

That's that.

I haven't actually started anything yet, but I plan to go through the listings of a few projects to warm up, hopefully culminating in a build of a Chordite and addition of a new logo in a little while.


1 - [back] - Canada Post cheekily celebrates Remembrance Day, so I'll actually have to wait until Tuesday or so to actually get my hands on my RPG fix for the year.

2 - [back] - The old one with the removable Atmega chip, rather than the new one with the tiny but soldered unit.

3 - [back] - As if I didn't already have enough projects in the air.

Thursday, November 10, 2011

PostScript and Temporary Goodbye

So I honestly thought I'd be talking about Erlang and various processing tactics relating to it. I was also potentially planning to do and talk about some more work on clomments, the main off-hours project I've been trying to keep at. As an absolute last resort, I was going to dive into some more Elisp, or maybe finally talk about the shell-ui project. It didn't occur to me that the week would see me dusting off an old implementation of postscript for some new code.

I haven't actually written new code for it, but I have gone over what was there and flipped through the few resources I could find. Postscript, the language, is actually more versatile than I gave it credit for the last time around. To the point that I might actually want to revisit postscript.plt as opposed to just porting what I had over to CL.

Going through the first of the resources I mention above, it actually occurred to me that I could likely accomplish some of my goals by typing .ps directly. I'm going to try that first, but still keep the embedding option in my back pocket to hedge against some issues. First impressions are that the stack is going to annoy the ever-loving fuck out of me. I remember trying out Forth a while ago and not really minding that aspect of it[1], but I honestly can't see how to write a procedure that takes more than two or three parameters without doing some serious head-scratching. If you want the argument order to be at all sensible, it seems like you need to chain exch, dup and pop like a fiend, with an index or two thrown in for good measure. That means functional programming in this language is at least slightly hobbled from the get-go, but it does force you to make the smallest possible procedure to avoid being shot in the foot inadvertently.

The other reason that implementing PostScript in another language would probably be a good idea is, ironically, performance. Not writing performance, obviously, but processing performance at the printer end. If you take a look at that third resource I link to and open it in your editor of choice, you'll notice that the author deliberately chooses one and two letter identifiers for their procedures.

Ordinarily, I'd agree that that's awful, but keep in mind that every extra character in an identifier is one more that the printer will have to parse before outputting. Shortcutting grestore to gr or lineto to li doesn't seem like much, but compounded by the number of invocations per page, pages per document copy and then by copies per hour, I could see that getting scary pretty fast where frequent output is concerned. Now, that's really not much of a reason for me to actually apply this directly; I'd much rather write with human-readable function names and have an intermediate machine compress them down to a more compact format before sitting it in front of the printer. That's basically what I see using the lisp-based generator for; if I plan it out properly, the result will be a much easier language to work in that actually has more efficient output than a hand tuned chunklet of PS.

I was going to promise to post more related content soon, but frankly, as you can see from the new addition to the language bar, you aren't likely to see me for a month or so.


1 - [back] - Maybe it had some syntactic help; I no longer remember, never having done any serious development in it.

Friday, November 4, 2011

Objective Lisp

Stand back! I have dramatic pause an idea!

(defpackage :objective-lisp
    (:nicknames :ol)
    (:use :cl)
  (:shadow #:+ #:- #:* #:/ 
           #:member #:null
           #:= #:string= #:eq #:eql #:equal #:equalp
           #:length #:map #:mapcar #:concatenate)
  (:export #:+ #:- #:* #:/ 
           #:member #:null
           #:= #:string= #:eq #:eql #:equal #:equalp
           #:length #:map #:mapcar #:concatenate))
(in-package :objective-lisp)

;;; not, strictly speaking, relevant to what I want to discuss,
;;; but I figure I've already gone off the deep end just by
;;; writing this, so I may as well make it worth my while

(defun nullp (object) (cl:null object))

;;; or is it...
(defun memberp (item list &key key)
  (cl:member item list :key key :test #'=))

;; imagine other functions here


(defmethod + ((num number) &rest nums)
  (assert (every #'cl:numberp nums))
  (apply cl:+ (cons num nums)))

(defmethod - ((num number) &rest nums)
  (assert (every #'cl:numberp nums))
  (apply cl:- (cons num nums)))

(defmethod * ((num number) &rest nums)
  (assert (every #'cl:numberp nums))
  (apply cl:* (cons num nums)))

(defmethod / ((num number) &rest nums)
  (assert (every #'cl:numberp nums))
  (apply cl:/ (cons num nums)))

(defmethod length (seq) (cl:length seq))

(defmethod map ((fn function) (l list) &rest lists)
  (assert (every #'listp lists))
  (apply #'cl:mapcar fn (cons l lists)))

;; and defined for other types here

(defmethod concatenate ((str string) &rest strings)
  (assert (every #'stringp strings))
  (apply #'cl:concatenate 'string (cons str strings)))

;; and again

(defmethod = (a b) nil)
(defmethod = ((a number) (b number)) (cl:= a b))
(defmethod = ((a string) (b string)) (cl:string= a b))
(defmethod = ((a character) (b character)) (cl:char= a b))
(defmethod = ((a symbol) (b symbol)) (cl:eq a b))
(defmethod = ((a cons) (b cons)) (cl:equalp a b))
(defmethod = ((a array) (b array)) (cl:equalp a b))
(defmethod = ((a structure-object) (b structure-object)) (cl:equalp a b))

;;; really, I should do the same for all the various
;;; comparison functions (>, >=, <=, <), but this is
;;; already longer than I'd like

Now, why would we want to do this terrible thing? Well, we probably wouldn't. I wouldn't ever straight-facedly recommend someone does this in any sort of production environment, but it does sand down some rather annoying corners[1].

What looking at CLOS this way gets you is the easing of a few syntactic binds at the cost of some performance.

  • For starters, we now have a generic = that can be called in pretty-much any situation[2]. That lets us define memberp and other functions without having to pass in a test function (= handles dispatch itself). It also lets us define map/concatenate and similar functions without specifying what the output type is expected to be[3].
  • As I note, it saves us from having a separate =, char= and string= and similar comparison operations.
  • Finally, if we define new types (such as matrix), we are not prevented from giving them a + or * method (and we can specifically define how to go about mapping, concatenateing or lengthing them, if it makes sense, as well as defining the correct new equality test without having to name it matrix=).

You could also do things like override + so that it performs concatenation for strings[4], though I'd shrink from going further and applying it to sequences in general, just because it's somewhat ambiguous.

Because all these calls are handled by the type system, you'd also get compile-time warnings about operations that aren't defined.

Incidentally, I know I'm not even remotely the first person to think of doing something like this on a lark. As usual, I just wanted to get an idea far enough out of my head to take a good look at it.

This has been a completely random thought about Lisp. Thank you for your time.


1 - [back] - In case you care, I stubbed my metaphorical toe on them a little while ago by trying to implement matrix operations in CL as a learning exercise only to find that I couldn't actually give them a + operation. It would have to be something like add or matrix-add. No world-ending obstruction, but slightly less than satisfying. At the time I implemented it as matrix-add.

2 - [back] - leaving aside the identity vs. pointer question that may actually need to be addressed differently in some cases

3 - [back] - Although, to be fair, we do lose the ability to do something like (concatenate 'string "Hello " (list #\t #\h #\e #\r #\e #\!))

4 - [back] - Since that seems to be well accepted in most languages by this point.

Monday, October 24, 2011

John McCarthy

Sunday, October 16, 2011

Ruby vs. Python Briefly

Ok, so I figure it's about time to live up to the title of this blog, since I've spent the vast majority of the language discussion firmly planted in parentheses. Aside from the fact that my company is starting a project in Erlang, I've also been scripting Python and Ruby pretty heavily.

They're actually not very different languages. Neither is perfect from my perspective[1], and neither sucks. If I had to, I could get work done in both (and having gone through the Ruby chapter in 7 Languages in 7 Weeks, I'm more inclined to look at Ruby for my next big project than I used to be). To start with, here's a boiled down, no-nonsense table that represents my perspective. more annoying than...

len([1, 2, 3])
[1, 2, 3].length
"foo " + bar + " baz"
"foo %s bar" % bar
"foo #{bar} baz"
", ".join(["one", "two", "three"])
["one", "two", "three"].join ", "
map(lambda a: a + 1, [4, 3, 2, 1])
## still makes more sense 
## than join or len, though
[4, 3, 2, 1].map {|a| a + 1}
a = [4, 3, 2, 1].sort()
[4, 3, 2, 1].sort[0]
nothing.jpg foo.methods.sort
require 'optparse'
require 'pp'
require 'fileutils'
import optparse, fileutils
## I also prefer the more granular 
## symbol access I get with python
sudo apt-get install ruby-full
python about as annoying as...

def aFunction(foo, bar):
    #do stuff
    return baz
def a_function(foo, bar)
  #do stuff
with tempfile.NamedTempFile() as tmp:
    tmp.write("Test test\n")
    ##more stuff    
    popen(["lp", "-d", "a-printer",]) do |tmp|
   tmp.write("Test test \n")
   ## more stuff
   system("lp", "-d", "a-printer",

So I am slightly biased, but like I said earlier, not enough to actually decry either language. The biggest point in Ruby's favor is its handling of blocks (as seen in that tempfile pseudo-code). I like having an expression that says "Create an entity, do this stuff and then clean up", without having to clean up myself. Python doesn't like that.[2] Gotta admit, I boggled at the join syntax the first time around. Rhetorically, who the hell decided it makes sense that a join operation is something you do to the delimiter, rather than the list? In my opinion, it would even make more sense to make it a standalone function a-la len.

I really like the syntactic whitespace in Python.

def something():
seems like it's cleaner than the Ruby equivalent. Except that when I want to return the result of bar (which I do quite often, given that I much prefer functional programming to OO), I need to do so explicitly. Ruby has me waste an additional line on end, but returns implicitly. While I'm at it, Python libraries seem to be heavily anti-functional programming. They do the standard "OO" thing of exposing functionality via classes, but they also typically have a heavy reliance on side effects, which makes it harder than it ought to be to compose things. A recent example I had to go through involved using pyPDF and reportlab to process existing PDFs. You can do it, but the amount of fiddling involved is nontrivial if you want to decompose the problem properly because you need to do so by setting up multiple instances of PdfFileReader/canvas and making destructive changes to them.

Also, not represented in the table is how much easier it is to install python packages in Debian. While gem frequently errors on something, I've yet to find a package I need that I can't either apt-get or retrieve using python-setuptools. That's worth something (in fact, it's worth enough that I've been procrastinating on a ruby port of get-youtube-series, which used only default components in Python, but requires several installs in Ruby).

The last thing that table doesn't encompass is the version situation. That's a fairly major one from my perspective, but I'm not sure how serious it actually is. Python 3 has been out for quite a while, but it's not uncommon to see "Supports Python 2.7" on various frameworks/utilities. Squeeze still provides 2.6.6, Django still requires 2.[4-7] and Google app-engine is still asking for 2.5 (with 2.7 being supported as an "experimental" feature). That's less than encouraging. By contrast, Ruby 1.9 is fairly widely supported (though the Debian repos are still at 1.8.7). That just doesn't seem to bode well for the next version, regardless of how enthusiastic Rossum is about it.


1 - [back] - Though, to be clear, my opinion is that Ruby gets a damn sight closer than Python.

2 - [back] - Thank you Brendan Miller for pointing me to the with statement (documented here, here and here) which does emulate blocks well enough for my purposes.

Monday, October 10, 2011

Testing googlecl Posting

If it worked, you should be able to read this.

This post was posted via Emacs with help from the googlecl project

ScreenWM Follow-up

So I had enough theorizing last week, and am currently putting the setup through the Compaq Test™.

Preliminary observations are good; now that I've fixed the minor ui annoyances pertaining to screen and blog-mode, this is a very comfortable editing environment. I don't actually have the wireless drivers installed on this machine yet, so I'll have to plug into the router later in order to post this piece, but it's quite snappy considering the hardware I'm actually working with[1].

Hell, slime works pretty well too. Except that paredit[2] seems to have it in for me in various ways. It's nothing I can't work around with some judicious re-binding, but it's extensive enough that I don't want to attempt it today.

I started with a fresh install of Debian Squeeze[3] and basically just ran the following

## Basic dev tools
apt-get install emacs slime git-core mplayer lynx screen openssh-server gnupg
apt-get install sbcl python-setuptools ruby-full erlang

## app configuration
su inaimathi -c "sbcl --load install.lisp"

## I. Fucking. Hate. Caps. Lock.
sed -i 's/XKBOPTIONS=""/XKBOPTIONS="ctrl:nocaps"/g' /etc/default/keyboard
/etc/init.d/console-setup reload

in order to get everything running the way I like. install.lisp contains

(load "quicklisp.lisp")


(ql:quickload :linedit)

(with-open-file (s (merge-pathnames ".sbclrc") :direction :output :if-exists :append :if-does-not-exist :create)
  (format s ";;; Check for --no-linedit command-line option.
(if (member \"--no-linedit\" sb-ext:*posix-argv* :test 'equal)
  (setf sb-ext:*posix-argv* 
        (remove \"--no-linedit\" sb-ext:*posix-argv* :test 'equal))
  (when (interactive-stream-p *terminal-io*)
    (require :sb-aclrepl)
    (ql:quickload \"linedit\")
    (funcall (intern \"INSTALL-REPL\" :linedit)
             :wrap-current t)))"))

(ql:quickload (list :drakma :cl-who :cl-ppcre :cl-fad :hunchentoot :clsql :cl-smtp :cl-base64 :ironclad :trivial-shell))

Which just configures quicklisp and linedit to run whenever I start sbcl. After that , it was just a matter of importing my Emacs settings[4], and .screenrc file. I didn't end up keeping the fancy settings I was thinking about last week, by the way. It currently contains, in its entirety

screen -t emacs emacs -nw

startup_message off

bind S split -v
bind s split
bind R remove
bind ^e screen emacs -nw
bind ^w screen webjump

markkeys "h=^b:l=^f:$=^e"

which is as basic as it could possibly be, except for the line that calls a program named webjump. That's actually a convenience script of my own devising that simulates my conkeror webjumps from the desktop machine. It reads


require 'uri'

print "Webjump: "
input = gets.chomp.split(" ", 2)

def get_url(input)
  jump = input[0]
  query = URI.escape(input[1])
  jumps = {
    "youtube" => "{query}\&aq=f",
    "stockxchange" => "\&txt=#{query}\&w=1\&x=0\&y=0",
    "google" => "{query}\&ie=utf-8\&oe=utf-8\&aq=t",
    "wikipedia" => "{query}\&sourceid=Mozilla-search",
    "gmail" => ""  
  jumps[jumps.keys.find{|k| k =~ /#{jump}/}]

url = get_url(input)
if url
  system("lynx", url)
  puts "Can't find webjump '#{input[0]}'"

which is quite useful when I need to search for something quickly. I'm thinking about changing it such that it just takes a command-line option for which webjump to use so that I could actually keybind google-search as opposed to webjump (I've observed that "go something something" is used far more commonly than any of the others).

Like I said, that's it. It's an extremely minimal system, and it doesn't have any kind of multi-monitor support, but it gives me the important little comforts I've been used to (like tabbing between applications and convenient, keyboard-based browsing) without the need to start up an instance of X[5]. That greatly increases the universe of useable machines for me.

The only things I'm still missing:

  • a klavaro-analogue I still have no way of practicing typing from the command line (which is kind of ironic)
  • more shell-friendly bindings for paredit
  • multi-monitor support which I have no idea where to even start on


1 - [back] - An old Presario R3000 with a 1.4ghz processor and 256MB ram.

2 - [back] - Which I've installed, and actually gotten to like under X, at the recommendation of a friend from the Toronto Lisp User Group. It's actually fantastic, but there are various key that just barf when you try using it from terminal. The default bindings for slurp, barf, forward and back s-exp operations are outright ignored, and it does something funky to my home and end keys so that they insert odd square-bracket escape sequence instead of doing what they say on the key. It's paredit because, all of the above works just fine in other modes.

3 - [back] - Since the Compaq still had a copy of Parabola running from last time.

4 - [back] - Including the steadily-growing blog-mode, which I've added several functions to since I started writing this piece.

5 - [back] - Also, conveniently, lynx doesn't let me waste any time on Reddit, since I can't actually post or upvote from it.