Last night I installed the OS X 10.8.3 update on my laptop (updating from 10.8.2). This morning, upon plugging my laptop into the external Thunderbolt display as I always do, and it didn’t wake up when I opened the lid, nor when I started tapping on the external keyboard.

As I noted before, a retina MBP (or MacBook Air) that doesn’t immediately wake when you open the lid is annoying not only because it slows you down, but because Apple’s removed all the battery indicator buttons, and there’s absolutely no sign of life from a powered off (or hibernating) machine until you press the power button.

So I woke it up with the power button on the builtin keyboard, and watched it boot to the preboot login screen associated with an encrypted boot drive¹, and was further annoyed that at this screen it was still ignoring the external keyboard plugged into the Thunderbolt display. Having to use the builtin keyboard for a docked laptop is suboptimal. Anyway.

When it finished booting, I fired up pmset to ask it what’s going on, first on AC power:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

magi@duality ~> pmset -g
Active Profiles:
Battery Power     -1
AC Power          -1*
Currently in use:
 standbydelay         4200
 standby              0
 womp                 1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 darkwakes            0
 gpuswitch            2
 networkoversleep     0
 disksleep            10
 sleep                0
 autopoweroffdelay    14400
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         10
 acwake               0
 lidwake              1

And then again² on battery:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

magi@duality ~> pmset -g
Active Profiles:
Battery Power     -1*
AC Power          -1
Currently in use:
 standbydelay         4200
 standby              1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 darkwakes            0
 gpuswitch            2
 disksleep            10
 sleep                10
 autopoweroffdelay    14400
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         2
 acwake               0
 lidwake              1

As posted before, I’d previously changed standbydelay to 43200 seconds on battery power, and disabled standby entirely on AC power. Apparently the 10.8.3 upgrade reverted the former change to Apple’s new default of 4200 seconds, though it left the latter change alone.

Note that’s not quite consistent with my observation that my rMBP (bought in 2012 and shipped with OS X 10.8) had standby enabled by default, while my previous MBP (bought in 2010 and shipped with OS X 10.6 and subsequently upgraded to 10.7 and then 10.8) never had standby enabled at all.

Once I got Jekyll and Octopress to import my blog from Tumblr and generate it in its new format, almost everything was formatted correctly, with the marked exception of footnotes. Like a certain furious Canadian¹, I’ve become a fan of footnotes for adding detail without littering my posts with parenthetical expressions. In the migrated posts, the footnotes were there at the bottom, but the links to them were all wrong — full-sized unlinked numbers, instead of superscripted hyperlinks.

It took me a while to figure out what was wrong because there were actually 3 distinct problems. And as background, while it wasn’t a direct problem here, you should understand that footnotes are not a feature of the original Markdown syntax, but were added later by other dialects, mostly converging around PHP Markdown Extra, which is what Tumblr uses.

First: The post content generated in Markdown format from tumblr.rb, in its trip through nokogiri and html2text and maybe elsewhere, didn’t actually preserve the footnote declarations I’d originally given Tumblr. Even though I had written these posts in Markdown format, and the Markdown form of my posts is presumably preserved somewhere at Tumblr², tumblr.rb instead downloads HTML and then reverse-converts it back to Markdown format. This conversion doesn’t preserve footnotes as Markdown footnotes; instead it leaves them as static HTML, and it renders the footnote bodies reasonably but the footnote links unreasonably.

So I had to go edit all the posts in which I used footnotes, and manually redo the footnote links using PHP Markdown Extra syntax.

Second: Having done that and told Jekyll to regenerate the blog, I found myself looking at a bunch of raw unconverted PHP Markdown Extra footnote tags. That’s because Jekyll’s markdown processing is done by RDiscount, and the version of RDiscount specified by Octopress’s Gemfile (1.6.8) does not support footnotes at all; footnotes using PHP Markdown Extra syntax were added as a feature of RDiscount 2.0.7, as an optional extension named footnotes.

So I had to edit the Gemfile to specify RDiscount 2.0.7, and edit _config.yml to enable the footnotes extension. These changes look like:

Gemfile:

1
2

-  gem 'rdiscount', '~> 1.6.8'
+  gem 'rdiscount', '~> 2.0.7'

_config.yml:

1
2
3

 markdown: rdiscount
+rdiscount:
+  extensions: [ footnotes ]

Third: Having done that and told Jekyll to regenerate the blog, some posts looked fine, but others had chunks of footnote definition content floating near the end of the post body but before the footnotes, and completely out of order. Some trial and error led me to deduce that RDiscount 2.0.7 does not actually honor the documented PHP Markdown Extra syntax, which allows you to hard-wrap the footnotes or even place the definition offset from the footnote number³; RDiscount is happy only if the footnote number and entire body are on one logical line with no hard line breaks. Since I’m doing all this posting from a colocated Linux VM on which I don’t run X, and thus use text editors in old-school terminal windows, I tend to hard-break my posts (and in fact, the posts I imported from Tumblr tended to be hard-wrapped at 76 columns by something somewhere along the write/post/import pipeline). RDiscount doesn’t play well with these hard breaks.

So I had to edit all the footnoted posts again to comply with RDiscount’s actual behavior.

Summary: you can get nice footnotes from Octopress/Jekyll if you

• Update to RDiscount 2.0.7
• Enable RDiscount’s footnotes extension
• Use the footnote syntax that RDiscount actually supports, which is like PHP Markdown Extra except each footnote definition must stay on one line without hard line breaks
• If importing your blog from a previous home using a script like tumblr.rb, verify that the conversion actually generates footnote markup

There’s still one more bug with footnotes on the index page, which is that Jekyll generates each page independently through RDiscount, which generates in-page links between the footnotes and their bodies, using the footnote number: for the first footnote, the forward link is #fn:1 and the backward link is #fnref:1. This works fine on individual pages, but on the index page the footnote numbers get reused and collide, so the in-page links don’t work there. Syeong Gan has a post with a deeper description of this problem, and a possible workaround.

Having decided to move this blog from Tumblr to Octopress, there remained the matter of migrating it¹.

Octopress is basically a convenience framework around Jekyll, adding a nice-by-default theme and some convenience wrappers for starting new posts, invoking Jekyll to generate the site, and deploying the site. You could probably use Octopress quite happily without touching Jekyll directly, unless you want to import an existing blog; then you end up at Jekyll’s Blog Migrations tool, which has options for a number of popular blog engines, including Tumblr.

The instructions for setting up Octopress are pretty simple and well documented:

• git and ruby (and probably rvm or rbenv) are prerequisites
• obtain octopress itself via “git clone”
• install dependencies via “gem install bundler; bundle install”
• install the default Octopress theme (which also generates the skeleton site layout) via “rake install”

At this point, you’ve got a working Octopress installation and you could use its rake task-based interface to write and publish posts. However, if you want to migrate an existing blog, you have more setup steps which are also well documented:

• assuming you want to keep your raw posts in markdown format instead of raw HTML, Jekyll’s Tumblr migrator needs nokogiri: gem install nokogiri
• invoke the Tumblr migrator:ruby -rubygems -e 'require "jekyll/migrators/tumblr"; Jekyll::Tumblr.process("http://www.your_blog_url.com", "md")' Note that this doesn’t require any account information or credentials, because the Tumblr API will provide enough information to do this anonymously. Heck, if you’re evil, you could convert someone else’s blog (don’t do that). On the topic of Tumblr reliability, I ran this step a few dozen times while I was figuring out how it works and fixing some bugs in tumblr.rb, and ~90% of the time, it downloaded my ~165 posts almost instantly, but palpably often, it would get stuck halfway as the Tumblr API stopped sending it network traffic. Oh well. Ctrl-C and restart if this happens to you.

What neither the Jekyll nor Octopress documentation tells you is what happens next. Assuming you run all the above commands from the octopress directory: Octopress setup (the rake install step) created a directory called “source”, under which the (initially empty) “_posts” directory is where Jekyll will look for posts. Meanwhile, Jekyll’s tumblr.rb will create and populate a “_posts/tumblr” directory with your posts, and a “posts” directory with redirects from the old Tumblr-style post URLs to new Octopress-style URLs²,³. Neither the “_posts” nor “posts” directory spit out by tumblr.rb are under “source” where Jekyll will look for them. What this means is that without additional effort on your part, Jekyll as invoked by Octopress won’t see the files you just imported.

Again: your blog posts go in “octopress/source/_posts”. The Tumblr migrator will create “octopress/posts” and “octopress/_posts”. Just move these two directories under “octopress/source” once you’ve verified they look OK. (NB: the migrator actually dumped all its files under “octopress/_posts/tumblr”; it’s fine to leave them there, so they end up in “octopress/source/_posts/tumblr”; Octopress doesn’t seem to care about the organization of your files inside the source/_posts directory.)

Now, you can tell Octopress to generate the site: “rake generate”.

If you’re reading this at the right point of relative stability, lucky you; you win. I ran into several more issues, due to the fact that Jekyll and Octopress are prerelease open source software intended for an audience of hackers; some assembly definitely required:

• At the point I was performing this migration (January 2013), Jekyll was at version 0.12 and the tumblr.rb migrator script was broken in a couple respects which I submitted patches for.
• After my patches were merged upstream, I tried running with Jekyll’s head version in mid-February, to find that tumblr.rb had been deleted from the Jekyll repository entirely, and moved to a separate jekyll-import project, which at the time had no documentation and appeared to have little chance of running.
• Meanwhile, using any version of Jekyll newer than 0.12 broke Octopress in a trivial way; the :generate rule in Octopress’s Rakefile finishes by invoking Jekyll as system 'jekyll', with no arguments, and newer versions of Jekyll expect a build argument. Octopress will fix this when Jekyll actually releases a new version (which may have already happened between me finding this and posting this); it makes no sense to fix it sooner.

This last list of foibles is probably all related to Jekyll being in the throes of the 1.0 release process and will probably be a historical footnote afterwards.

When I first started this blog, I set it up at Tumblr so I wouldn’t have to think about hosting it and could concentrate on writing.

I’ve since realized that Tumblr is a bad match. Among things that I prioritize higher than Tumblr evidently does, reliability ranks high on the list¹, as do control over site structure and appearance. Tumblr themes allow some control over appearance — and there are some very nice ones — but not the structure².

Among things that they care about that I do not are their web posting interface, iOS native clients, a plethora of post types designed to be slightly quicker if you want to post audio/picture/video/quote content³, and a follower system⁴.

So. On to Octopress. I get a lot more control over site structure, a more usable form of control over visual layout, and I can host it somewhere reliable (github for now, myself if I want to, and I can move hosting providers without having to do any deeper conversion).

Here’s a bonus on top of a bonus: OS X 10.8 (Mountain Lion) adds a really useful “Wi-Fi” scan feature, buried inside a utility I didn’t know existed.

I wanted a Wi-Fi scan tool to show me a list of nearby wireless networks and strengths, so I could avoid interference from existing networks when placing and choosing a channel for a new access point, and verify the new access point is operating properly. A few years ago I did this with KisMAC, MacStumbler or iStumbler, but these utilities seem to have stopped working over time, either as a result of newer hardware or newer OSes.

Googling for new alternatives to these utilities, I found that Mountain Lion actually has this functionality built in. There’s a “Wi-Fi Diagnostics” app buried in /System/Library/CoreServices (where, annoyingly, Spotlight can’t find it and the Finder by default won’t show it); at launch it presents a very limited-looking wizard interface, but in the menubar the File:New command and command-N keyboard shortcut have been replaced by an unassuming “Network Utilities” command.

This brings up a “Network Utilities” window, not to be confused with /Applications/Utilities/Network Utility.app, with a bunch of really useful utilities (which look like a strict superset of the old Network Utility, have a more modern UI and additional functionality, and except for the “Wi-Fi Scan” tab, have no reason to be restricted to Wi-Fi networks).

I only wish this thing were easier to find; it should probably replace the old Network Utility app. I don’t remember seeing it mentioned in most what’s-new-and-why-to-upgrade articles about Mountain Lion. For me, it’s a pretty nice bonus to having upgraded and deserves wider mention.

In this announcement of a new Sony tablet for Android, the following bit stood out to me:

The company claims the tablet is not only the “world’s thinnest 10.1-inch tablet” at 6.9 millimeters, but it’s apparently waterproof in up to three feet of water for 30 minutes.

The water resistance is a lot more notable to me than the thinness, in an industry obsessed with thin fragile things, given how many phones I’ve seen destroyed by water, and given how I put this on my wishlist for the iPhone 5 last fall. But phones see a lot more exposure to dangerous circumstances than tablets do, I wager, so I’d still like to see this feature make its way over to phones.

My initial reason for switching from Windows laptops to Mac laptops 7 years ago — which has remained a primary benefit across those 7 years — was better power management. The details are many but the result is simple: a laptop that sleeps and wakes consistently and quickly, which never crashes on wakeup, never drops the Wi-Fi connection on wakeup, and is on the network and ready for me to type almost as soon as I open the lid. Almost like what we expect from a tablet or smartphone.

That’s the dream, anyway. I’ve never owned or used a Windows laptop (or Linux laptop, for that matter) that pulled that off, and not for lack of trying. It was much truer of Apple laptops running Mac OS X, ever since their introduction in 2001. It remained one of my favorite things about more recent Macbooks, but I’ve found it getting less true over time, culminating in my 2012 “Macbook Pro with Retina Display” (henceforth rMBP), which seems to take like 30 seconds to wake from sleep, then sometimes crashes immediately as the crowning touch.

After getting frustrated enough by the slow wakeup time to get to the bottom of it, I think there are 3 pieces to the puzzle.

1. The rMBP (like Macbook Air models) has no external status lights. No charge level indicator on the battery like older models with removable batteries, no charge level indicator on the side of the unit like previous unibody Macbook Pro models, no power light that winks while asleep and glows while awake like all previous Macbook models. So when you open the lid, if it wakes up and is ready for use, great, but if not, you don’t know whether it’s powered off, has a dead battery, or is already trying to wake up and just taking its sweet time.

2. The default power-management plan is “Safe Sleep”, which means that when you close the lid the computer writes a suspend image to disk, then suspends to RAM¹. Then wakeup is normally fast because RAM contents are still present, but if power is lost for any reason (battery dies, battery is removed on models where that’s possible, or the computer decides to power itself off to stop expending battery power to support the RAM), it can still resume from where you left it, just more slowly, by reading from disk. This last bit about deciding to power itself off is crucial; it’s controlled by a parameter known as standbydelay, and on this computer at least (rMBP running OS X 10.8) the default value of standbydelay was 4200 seconds, or 70 minutes, just over an hour. This means if you suspend the computer and wake it up again within 70 minutes, it will resume from RAM, but if you leave it asleep for more than 70 minutes, it will have powered off entirely, and will resume from disk. On my previous laptop (a 13” Macbook Pro from 2010, also now running OS X 10.8), standbydelay was not set at all, which I assume means it will try to keep RAM supplied with power until the battery dies. I don’t know the reason for the different defaults.

3. This rMBP has 16 gigabytes of RAM, more than any laptop I’ve owned in the past. Now, it also has a fast SSD, so I wouldn’t have thought it would take that much longer to resume from disk vs RAM (and in actual usage it shouldn’t have to save and restore all of it anyway) but it’s likely a factor: if it had to transfer the entire 16GB, even at 500 MB/sec that would be 32 seconds. It actually only needs to save/restore the active pages; say on average that’s 60% of memory and add a few seconds to get the hardware devices from cold boot to powered on, and you’re in the 20 second ballpark that is long enough to annoy me.

So boiled down: this machine feels slower to resume than previous ones because it’s suspending to disk, has a lot of memory to restore from disk, and doesn’t show any visible signs of progress while restoring from disk.

I changed the standbydelay value to 12 hours on battery (sudo pmset -b standbydelay 43200) and disabled it entirely on AC power (sudo pmset -c standby 0) and things seem much better now².

Oh. And sleep reliability³? That’s even more important. When I first got the rMBP, it would kernel panic and show “Your computer must be restarted” when resuming from sleep once in a while, roughly once a month. That was intolerable; at a guess I disabled PowerNap; I don’t know whether it was the actual problem but I haven’t had reliability problems since.

So these are my current recommendations for power management on a rMBP or Macbook Air:

• Increase standbydelay value enough that you don’t notice the computer resuming from disk in normal use
• Disable PowerNap

On a recent trip to Mexico, we stayed in a hotel that charged a significant extra fee for fairly slow Internet access. After paying for an access code, we could associate one device at a time to the Wi-Fi network; we could use multiple devices only by paying for multiple codes (which we didn’t want to do because for the speed, even paying once was a poor value) or by disconnecting the previous device.

Of course, I went looking for ways around this. We had at our disposal a Mac laptop, two iPads and two iPhones. Mac OS X has built-in Internet connection sharing, but it operates only between separate network adapters: you can share an Ethernet-connected Internet connection over Wi-Fi, or vice versa, but you can’t share Wi-Fi over Wi-Fi¹. There’s some reason to hope that this would be possible — it’s “just” a software problem²; Windows and Linux generally support multiple virtual Wi-Fi interfaces from the same physical device, as used by Connectify Hotspot for Windows or the multi-SSID feature in many Linux-based Wi-Fi access points — but this software feature doesn’t exist for Mac OS X.

So, no sharing Wi-Fi over Wi-Fi with my Mac laptop, unfortunately. But there’s another option that works without additional hardware; this is where the learning comes in. First new fact: you can share an Internet connection over Bluetooth. I’d thought this was only for sharing a cellular data connection from a phone to a computer (under the oxymoronic misnomer of “wireless tethering”), but it turns out to work in the other direction (known as “reverse tethering”). If you pair an iPhone or iPad with a Mac over Bluetooth, your Mac will grow a new network adapter called “Bluetooth PAN” (for Personal Area Network); you can then use the normal Sharing preference panel to enable Internet Sharing from Wi-Fi to Bluetooth PAN. Bingo.

(I can claim only partial success here, but it was good enough for me at the time. This technique works fine for iPads, but not iPhones. I don’t know why; nobody else seems to know why either.)

That got us past our trip, and I was happy to have a new tool for my cheap-connectivity-while-traveling toolbox. However, when we returned home, I had an unpleasant surprise, though it took me a while to connect the dots. My Mac laptop was getting really hot when I left it plugged in overnight to charge. I eventually realized this was because it wasn’t asleep, even with the lid closed (and with the lid closed, it generates more heat than it can comfortably dissipate, even at idle). This was frustrating because there are so many things that can keep a Mac from sleeping; this is where more learning comes in. Googling for ways to identify causes of Mac insomnia, I learned of the pmset -g log command, which I now highly recommend. It pointed me right at the culprit. Second new fact: Internet connection sharing prevents the Mac from sleeping while plugged in. (This is actually incredibly obvious in retrospect; it says so right in the Sharing panel: “Computers connected to AC power won’t sleep while Internet Sharing is turned on.” I hadn’t read that while enabling Internet Sharing because I thought I already knew how to use it; by the time it was causing problems, the problems were too disconnected from the cause.)

In summary: Internet connection sharing is useful, and the Bluetooth PAN variant is further useful, but don’t leave it on when you’re not using it.

Here’s a useful nugget if you’re inclined to poke at computers to see how they work: pmset -g log.

I had a problem where my rMBP would sleep just fine on battery power but not when plugged into its charger. Even with the lid closed, and even if I explicitly poked the Sleep button first. This meant my chair got really warm if I left the computer sitting there plugged in to charge overnight. (NB: I did have the slider in energy saver preferences set to sleep:never for AC, but that should only affect sleep-after-idle, not lid-close or explicit sleep request.)

The command pmset -g log helped me learn that this state, where the computer is awake with the lid closed and no external display or keyboard is attached, is called DarkWake and that InternetSharing was the entity requesting that over sleep.

Now that I know about DarkWake, I’m curious what the relationship is between it and PowerNap. On this same rMBP, I disabled PowerNap because it would occasionally kernel panic when waking from sleep; I forget how I decided that was PowerNap but it hasn’t happened since disabling.

Google Accounts allow you to stay signed into multiple accounts at once, which is hugely helpful for those of us who have multiple account, but there’s one thing that’s been frustrating me here.

I use the browser address bar (relying heavily on its autocomplete feature) to do most of my navigation directly from the keyboard. If I want my document files in Google Docs, I open a new browser tab from the keyboard shortcut, then type “docs” and by that time, autocomplete has already filled in docs.google.com¹,².

However, I have 3 different Google Accounts that I’m usually signed into: one standard personal account (ending in @gmail.com), one GAFYD³ account for my personal email⁴, and one GAFYD account for work. If I navigate to docs.google.com, Google automatically chooses one of the accounts to redirect to, and at different times on different computers I end up with a different (seemingly arbitrary) account selected, and if it wasn’t the right one, it’s 3 extra clicks in the account switcher to get to the right account.

What’s controlling its choice? It turns out it’s the order you sign into the accounts. If you look closely at the URLs, either by mousing over the links in the account switcher or by looking at the URL you end up at for gmail but not for docs⁵, you’ll see an “authuser” or “u” parameter which is a low-valued integer. It starts at 0 for the first account you sign into, and counts up from there as you sign into additional accounts.

If you navigate directly to docs.google.com (or mail.google.com, etc), you’ll get the account currently associated as authuser 0, which is the first account you signed into.

For the GAFYD case, Google lets you set up convenient forwarding addresses for domains you control, and I’ve used this to map mail.mydomain.foo and docs.mydomain.foo to redirect automatically to mail.google.com/a/mydomain.foo and docs.google.com/a/mydomain.foo. This means that for the two GAFYD domains, if I want the mail or docs view associated with that account, I go to docs.mydomain.foo, which in turn means that if I navigate to docs.google.com, I always want my personal account selected by default.

For me, the solution to get the behavior I wanted boils down to:

• Sign out (which signs you out of all acocunts)
• Sign into the primary account which I want as default (the one ending in gmail.com) first, then sign into the others.
• Always use this same signin order in the future.

Thanks go to Ramesh for helping me figure this out.