The potential solution is the Adam, by Notion Ink. It’s an Android tablet with a Pixel Qi display and (significantly for my quest) both USB and HDMI ports. That means I can carry my library on a portable drive (meaning there’s basically no upper limit to file size: I can store them as ISOs) and plug the thing into a big screen if such is available (our cheapo movie-watching screen at home via an HDMI-to-DVI plug, for instance, unless I mean DVI-to-HDMI).

There are some downsides. The most significant is that Notion Ink reeks of nerdery. Not that I don’t fit the demographic, but my experience with the iLiad by iRex has made me cautious of these bleeding-edge hacker products. The iLiad was a device built on cutting-edge hardware, with open software intended to attract hacking, all put together by a small company. The exact same description fits the Adam. In the case of the iLiad, this led to various problems:

• The cutting-edge hardware quickly got overtaken by new developments (driven by larger companies with larger R&D budgets, one assumes);
• The cutting-edge hardware also required custom software support, which meant that almost no standard software could be easily ported to the device (this will be less of a problem with the Adam, because the display technology is more standard, although not entirely);
• Because of a small but devoted user community of hackers, the company themselves didn’t need to polish their software to gleaming perfection: they made clunky but working solutions, which the users either put up with or hacked around;
• Similarly, the physical design of the device had all sorts of minor issues that a larger company with more time (and money) for design cycles would have eliminated; again the hacker-ish ethos of much of the user base means that there wasn’t any strong pressure to improve on these problems;
• The company went out of business in 2010; you can’t get iLiad components any more, and lots of the connectors (being somewhat prototypy) were decidedly non-standard.

The end result was a product that was at the same time incredibly exciting and incredibly frustrating. You could spend hours messing about with hacked versions of the OS and basic utilities — and I did. (If you were hardcore, of course, you contributed to these projects. I wasn’t hardcore.) At the same time, you had to spend hours installing hacked versions of the utilities if you wanted a usable device; or when you found the latest Cool Thing (“a web browser!”) that would work if you just installed someone’s hacked connection manager, which however didn’t include someone else’s additions to the connection manager so you had to compile a merged version yourself, etc etc. All wonderful fun, but also taking an incredible amount of time.

And now, the battery of my iLiad no longer holds a charge; the AC cable, though, only works if you prop it up at the right angle (said angle being inconsistent with comfortable reading). Since the company went bust, the proprietory cloud-based content management stuff presumably doesn’t work any more, so you need the cable hub which (again) needs careful positioning to make it work. And so on and so on: the first-generation hardware design has meant that the device hasn’t really survived the death of its support company.

Which brings me to Notion Ink. They’re a small independent company, competing with the iPad and the increasing number of increasingly slick Android tablets on the market: going up against giants like Apple and Samsung. They’re writing custom software to make things go, which doesn’t always run smoothly: as long as the company is in business you’ll get support, but if they go under then you’re on your own.

As for my original needs, there’s one sticking point: I’m still not aware of any ISO player for Android. (Daroon Player reportedly plays unconverted DVD folders, which is probably close enough, but I haven’t put it to the test.)

And then there’s one more problem. The Adam is a tablet. I already have an Android tablet (the Samsung Galaxy Tab, ridiculously overpriced and bought in a moment of foolishness: I use it every day, and it doesn’t need replacing). I’m going to buy an iPad (lured by various apps only available on iOS), although possibly secondhand. It’s hard to justify the idea of owning three of these things…

The first tip expands on Mat’s “Vidiian Technique”: using ejecta to push a mote that’s too big to absorb into an even bigger mote, thus cutting it down to size. My addition here is patience: use the bare minimum force necessary to get the thing moving (most likely a single push). When it gets small enough and you plow into it, it will start shrinking from your side; if this happens quickly enough, the shrinkage will make it lose contact with the larger mote that was absorbing it on the other side, so you’re no longer competing with Big Daddy for dinner.

The other tips are about orbital mechanics, and they come from reading science fiction.¹ The good news is, they’re not restricted to Osmos: if you ever find yourself in freefall orbit, they’ll come in handy in real life!²

The first thing you have to get straight is the connection between your orbit and the speed you travel at. Any motes on exactly the same orbit will move with exactly the same speed. That means if your path-projection stays glued to some particular mote, you’ll never catch it. You can catch up on motes “above” you (farther from the “sun”), and ones “below” you will catch up on you (but so long as the orbits stay fairly circular, “catching up” doesn’t mean you’ll touch, just that at some point you’ll have the same angular position).

To understand how your speed depends on the size of your orbit you need to note the difference between angular speed (measured by how long it takes you to make one complete revolution around the “sun”: shorter means faster, in “rounds per second”) and speed simpliciter (measured by how long it takes to cover a fixed distance, e.g. in km/h). A high speed gives you a large orbit, which (counterintuitively) means a lower angular speed (by going faster you make a wider circle, which takes longer to complete one revolution around the “sun”).

So how do you catch up on that juicy mote sitting exactly in your orbit, tantalisingly close ahead of you? Not by jetting yourself towards it: speeding up will move you into a higher orbit, and you’ll see your target creep away from you (although you’re moving faster than you were, your angular speed has decreased so the angle between you and your target is widening).³ Instead, you expel mass towards your target: you jet directly away from it. That drops you into a lower orbit, which lets you close the angular gap; when you’re directly below your target, or perhaps a little ahead, speed up again (in the direction of your orbit) to raise your orbit to meet it.

Likewise, to catch a mote in your orbit but behind you, you speed up (jetting yourself away from it). This pushes you into a higher orbit, which is slower (in angular terms): your target catches up on your angular position, and when the time comes you slow yourself again to drop down on it from above.

The other thing to note about orbital mechanics is that they don’t work in circles but in ellipses. When you slow down you don’t, in fact, drop into a lower circular orbit. Your orbit from any point x will pass again through x (barring interruptions on the way — and only on single-attractor levels!), but if you slow down at x (starting from a circular orbit) then you’ll reach your lowest point directly across from x, on the opposite side of the “sun”. Such cometary orbits (elongated ellipses) are risky if they cut through the (roughly circular) orbits of larger motes (if your orbital periods don’t match, there’s a good chance that after some number of revolutions you’ll collide). Luckily, returning yourself to a roughly circular orbit is easy: when you reach the lowest point of your orbit, slow down again by the same amount you used to first deform your original orbit. Similarly, going to a larger circular orbit requires speeding up twice: first transforming your circle to an ellipse, then at the ellipse’s largest point (opposite your first jet) you speed up again, transforming the ellipse back to a circle. With your orbital prediction path turned on it’s very easy to see whether you’ve got this right or not.

You can use these orbital mechanics to devious effect. If the only remaining mote is bigger than you and close to the sun, you haven’t necessarily lost yet. Use your ejecta to slow it down, and it will fall into lower and lower orbits. (For best effect, time your missiles to catch it at the high point of its orbit: a change in speed has its most extreme effects at the orbital position opposite to where the change occurs, so to make its low end lower you hit it at its high end.) With a bit of care (don’t forget that these missiles change your orbit too!) you can send it to die in the sun, leaving you the winner by default.

In conclusion, as I have argued above, you should play Osmos because it’s educational. If you ever drift away from the station during an EVA, it might even save your life.

Notes:

1. Possibly Neal Stephenson’s Anathem, although I wouldn’t swear to it — they might just be an amalgamation of a infodumps from a whole host of bad sf novels and shorts.
2. Although things are much more complicated in three dimensions: you have to deal not just with speed but with velocity –speed plus direction– since objects orbiting in different planes can quickly spread apart or –catastrophically– come together as their orbital planes diverge and converge.
3. This is like overtaking on a corner: you have more distance to cover, so you have to drive faster just to keep level. Only here the road is all corner, and as you go faster they handicap you by moving you to the outer lanes.

I got a vagrant-packaged CentOS box from a colleague, and starting it up warned me that the VirtualBox Guest Additions were out of date. Fixing things involved these steps:

1. Get VirtualBox to “Install Guest Additions” (from the Devices menu of the running VM). Don’t be fooled: VirtualBox has not, in fact, installed the guest additions at this point.¹
2. What it has done is added the ISO as if it were a cdrom device: you have to mount it and run an install script. This is in the VirtualBox docs, but everything I found assumed the ISO would be on device /dev/cdrom. In my case, though, /dev/cdrom was very handily attached to the cdrom device on my host machine. (Vagrant setup did it? VirtualBox did it by default? Not sure.)
3. Turns out the device you want is /dev/cdrom1 (yeah, obvious in retrospect). Mount that, run the install script, done.

Notes:

1. Yes, this is a rather astonishing failure of UI design. But one that is fairly well-known, googlable, and not the root of the problem here.

The naïve picture of a Turing machine, that I had until this discussion, is that it’s just a state machine with an unlimited memory store attached. Since we’re so familiar with random-access memory these days, it’s natural to picture this as a memory array, indexed by (say) integers. If you’ve simulated a Turing machine, that’s probably how you did it. (At least, it’s how I did it.) The “read/write head” is implemented as an index variable (giving the current position in the “tape” array), and “moving it” means incrementing or decrementing it.

Now of course if you intend this to completely represent a Turing machine, you run into unboundedness problems. Since a TM running a program can require unbounded tape space, there is some program out there that will require your TM to index into the array beyond the limit of the integer representation of whatever language you’re using for your simulation.³ “Of course,” you say at that point, “but it’s not a real Turing machine because our memory is limited.”

My epiphany is that this is not the same problem.

To get there, imagine that we decide to “improve” our TM simulation by allowing it random access to the memory. Instead of the operations shift left/right on the index register, we have simply goto (whichever value the index register currently holds). We should be able to access the same range of tape, without all that tiresome shuttling left and right! Once we work out how to put values into the index register.

Here’s where it falls apart. If those values come purely from the state machine component, then only boundedly many elements of the memory tape can be accessed: the memoryless state machine can only generate boundedly many distinct indices.⁴ This is still true even if you allow the state machine to use the current memory-cell value in generating its index, although that’s slightly trickier.⁵ What does work is to let the index calculation depend on the state machine plus the current index. (It’s easy to implement a shift-left/shift-right function, and then you’re back where you started from.) But that seems to be cheating: now you’ve got two unbounded memory stores, one for the tape and one for the index into the tape.⁶

Now here’s the interesting question: Where is this extra memory hiding in Turing’s formulation of the machine? And the answer: It’s in the position of the read/write head. That gives an arbitrary index into the unbounded memory. The crucial point is that this index is remembered (and can be operated on): it’s an extra kind of memory the machine has. And although the operations are bounded (left-shift/right-shift by only one cell), they are local to the current position (a relative addressing scheme) so given the persistence of the index they can accumulate unboundedly.

PS So how should you simulate your Turing machine to avoid this conceptual trap? Boaz suggested using a block of wood as the “pointer”, which works if you have a reliable supply of paper for the tape⁷ and don’t mind emigrating if the pointer crosses a national border at some point during your computation. If you prefer to stay digital, a two-stack machine does away with the implicit array-index in exactly the right way.

Notes:

1. It started with news of a Turing machine implemented in Django’s templating language. Boaz was unimpressed: “Turing completeness isn’t that hard, Minesweeper is Turing-complete.” That can’t be right, I said, you mean Minesweeper is NP-complete. A game of Minesweeper is a problem to be solved, not a computational system. But I was wrong.
2. Spoiler: what you need is a second unbounded memory for indexing, and bounded operations on that memory to manipulate it. Which is exactly what the read/write head gives you. Clever old Al’.
3. Assuming you’re not using LISP or Python or whatever. Work with me here, I’m trying to make a rhetorical point, all right?
4. Bounded by some calculation based on the number of states of the machine and the size of the alphabet.
5. It seems as if there is potential for recursion: as you index more memory you can use it to store more state, thus allowing to index yet more memory. In fact, though, this isn’t the case. It’s easiest to see if you imagine a separate TM doing the address calculation. Its tape always starts blank: the only way it can vary its computation is based on which state the original machine is in, and what value the original machine is reading at that moment. But there are a fixed number of possibilities, based on the number of states the machine has and the size of the alphabet: that number is how many distinct computations the “address machine” can run on the empty tape, which is then the maximum number of distinct addresses it can generate.
6. To formulate this precisely, imagine as in the previous note that we have an “address machine” that generates an address whenever the “main machine” requests one for a goto. If you spell out carefully how the two machines communicate, the argument of the previous note shows that the tape of the address machine must contain some kind of variable initial information when it is run. The previous address is just the most obvious candidate — you could also imagine the main machine “priming” the tape somehow —given a much more complicated control relationship between the two, since in this simple formulation the address machine runs a computation for every step the main machine takes— but this trivialises quickly into the main machine simply asking the address machine to perform the main machine’s own computation then reading off the result from the address it jumps to!
7. You don’t have to start with an infinite tape, just arrange a contract with a paper factory guaranteeing to supply you with more whenever you need it.

For instance:

• the datetime class lives in the datetime module; careful with your imports, you will want both!
• the datetime module has a time class, but there’s also a time module
• the documentation talks at different places about “time tuples” and also about “time.struct_time” objects; they’re the same thing
• to convert a unix timestamp to a time tuple representing UTC time, you use time.gmtime(); for the reverse conversion, you use calendar.timegm() (this is the only place you’ll use the calendar module)
• to get now you use:
  • time.localtime() if you want a timetuple
  • time.time() if you want a unix timestamp
  • datetime.now() if you want a datetime object
  • time.gmtime() if you want a timetuple representing UTC time
  • datetime.utcnow() if you want a datetime object representing UTC time
  • a crowbar if necessary
• to build a datetime object from a time-tuple, you can set the fields one-by-one… or you can slice the time-tuple and unpack the list: datetime(*a_time_tuple[:6])

In other words, there’s a lot of fiddly detail to remember. So I made a chart.

Click through for (non-blurry) PDF.

It’s formatted for a4 paper and prints nicely. I used the incredible LaTeX drawing system TikZ. (On my screen the arrows have a little glitch at start and finish, but it doesn’t appear in my printout. Possibly a TikZ bug? Not sure.)

Note that it doesn’t show everything you can do; apart from the more egregious omissions (like timezone handling on datetime objects, which actually seems quite straight-forward but didn’t fit nicely into the design), I didn’t include arrows for nonsensical operations. For example you could feed a UTC time-tuple into time.mktime() (which takes a localtime time-tuple to a unix timestamp), but the result would be nonsense: the number of seconds since a date similar to, but probably not quite the same as, the unix epoch.

First the blank screen. From these instructions I added the option nomodeset for the install, and that went swimmingly. But of course on normal startup I had the same problem; I don’t even know what nomodeset means, but should I be setting it as a grub option or something? No, the answer is simpler than that: plug in a second (DVI) monitor.¹ Assuming that doesn’t have any driver problems, you’ll be able to see what you’re doing and can move on to the next hitch…

Wireless. Without a driver, wireless is completely disabled; the network manager applet doesn’t even see it as turned off, it’s simply absent. Solution: plug in a network cable instead. Duh. (It took quite some time for this blindingly obvious insight to hit.)

So at that point I had internet access and could see the screen. But these aren’t “solutions”, they’re temporary workarounds; from a bit of googling, the next step looks like it’s going to be tracking down drivers, uninstalling and reinstalling packages, and tweaking configuration settings ad nauseum.

Nope. System -> Administration -> Hardward Drivers, it found the missing two correctly, they activated without a hitch, and now I’m good to go (the extra monitor and network cable can go back into storage).

Notes:

1. I happen to have one lying around because my previous laptop is a netbook.

Neato, huh?

Pretty funny if the association is familiar. Otherwise, probably pretty incomprehensible. [via]

This, on the other hand, is.

I’ve used GNU screen for ages to keep my working environment set up the way I like it, wherever I am. I have a screen session permanently running on my office linux box, which I ssh to from wherever I happen to be.

That all changed this week, when my branch of our research institute moved to a new building. My linux box was taken offline and loaded into a truck; when it arrived at its new home, due to various cock-ups among the administration, it had no network access. (Word is they’re not going to let us ssh in anyway, sigh.)

So I’ve been playing around trying to set up my eee pc as a useful working environment. Step 1 was just copying all my configs from the desktop over to the netbook, and running everything from there instead. Imagine my surprise when some applications did not work the same way as they used to!

Specifically, screen has gained a purely awesome addition: screen-profiles provides something like the mode bar in emacs, configurable to add all sorts of goodies (battery monitor, wifi strength, lots of bits and pieces).

My other new discovery, which rather overshadows the first, is StumpWM. If screen and emacs had a baby, and brought it up to be a window manager, that would be stumpwm.

It’s a window manager written in lisp, like emacs,¹ and like emacs it’s configurable on-the-fly by lisp hacking.² Also like emacs it’s highly keyboard-driven, but more along the lines of screen: there’s a prefix key that diverts input to the stumpwm keymaps. (Actually I never realised before how similar the emacs and screen models are here; the only real difference is that screen gets away with only one keymap, hence only one prefix command. Stumpwm lets you define more if you need to, naturally.) Like screen, and unlike most window managers, you only see whatever you’re using at the moment (although you can tile windows the same way you can split emacs frames).³

I started messing around with stumpwm because the display of the eee is so tiny, and I was frustrated with the amount of space being wasted on menu bars and panels and whatever.⁴ I didn’t get very far at first, because I was trying to do everything by hand: shut down the Gnome display manager and restart X, pointing it at stumpwm. Of course all sorts of things stopped working, most importantly audio. But then I followed XSteve’s instructions for adding stumpwm as a session type under ubuntu, and magically everything worked.⁵

By “everything”, I mean everything. Audio works (I’m listening to Bettye Lavette in Amarok right now). Two-finger touch-pad scrolling works. I can split a stumpwm screen into two panes, pull firefox into one pane and emacs into the other, mouse-select text in firefox and drag and drop it into emacs. It not only works, it shows the text being dragged (otherwise I never would have tried the experiment). Global shortcut keys defined in Gnome work (so I can control the volume Amarok plays at).

I am a complete convert: stumpwm is fantastic.

I have two complaints.

The first is that I want better ways to switch windows: a list across all groups, that works like ido in emacs: filter the list of possible targets by any sort of match, rather than just prefix-matching and tab-completion.⁶

My second complaint is that both stumpwm and ido are written in (dialects of) lisp. Meaning that it’s conceivable that someone could hack bits of one into the other. Meaning that I’m awfully tempted to give it a try, instead of working on my dissertation. Shame on you, developers, for not protecting me from my instincts.

Notes:

1. Well, stumpwm is written in what emacs would call an inferior brand of lisp…
2. Yes, you can change the source code of your window manager while it’s running. And yes, once you can do this you’ll discover all sorts of reasons why you might want to.
3. And just like screen, now that screen-profiles exists, there’s a configurable mode line.
4. Emacs with no scrollbars and the font set to 8pt fits 80 characters twice, in a two-column split, which is magical for LaTeX. Viewing the pdf in Okular is less pleasant.
5. XSteve is the author of the psvn package (which adds excellent subversion support to emacs), among many other software projects. His config tips are worth checking out too.
6. Ido (‘interactively do things’) is another recent discovery; I’m completely sold on buffer-switching, and the fact that it lets me prefer .tex over .aux when opening files might be enough of a draw card to force me to get used to the way it treats backspace and tab.

(Thanks to Micha — I discovered this while helping him tidy up his texmf tree. And yes, I guess this is less down to (La)TeX and more down to my distribution, details jargon technicalities disclaimer.)