25 January 2014
Robot Odyssey: The Hardest Computer Game of All Time

It would be crazy for me not to link to this. Robot Odyssey occupies a place in my heart as a wonderful, playful, insanely challenging game for my first computer. I played it on a TRS-80, not an Apple, but it was all there. I still have the manual—it follows me everywhere I travel.

Also turns out the robot in my header is named ‘Checkers’. Didn’t remember that.

07 January 2014

The Cloudlet

I’m a cloud citizen. My personal data exists in opaque, centralized systems. Dropbox, Google and Google Apps, iCloud, GitHub. When revelations about our privacy and security online rattled the world, I grew concerned about my reliance on the cloud. I know I’m not alone.

In this article I take a cursory look at two alternatives to the cloud—the private cloud—in open source, and third-party form.

In This Corner

Alex Payne’s sovereign tries to consolidate everything an enterprising, tech-savvy hacker would need to create their personal cloud. It’s a damned good attempt.

Alex provides the philosophical underpinning. He is a previous Google Apps customer who came to the conclusion that Google has, allegedly, “a seriously questionable privacy track record”, “a dwindling commitment to open standards”, and “a lack of long-term commitment to products”.

sovereign is, at its core, a series of Ansible recipes. In this way, a hacker can spin up a Linode instance, execute a playbook, and be off to the races with a personal, secure, cloud.

The community has responded enthusiastically. The project has almost 2,500 stars on GitHub, and about 200 forks. It clearly makes an attempt to be inclusive—providing everything from an RSS reader for disillusioned Google Reader users to an IRC bouncer for nerrrrrds—and its contributors are busily navigating the subtleties of its security implications, configuration, and ease of use.

However, there are some rough edges. Its many pieces introduce complexity. Some components, such as ownCloud, are PHP. Prosody, sovereign’s XMPP server, runs on Lua. Solr, the text search for e-mail, is a Java server. There’s nothing inherently wrong with this, but it requires a user to wear many hats in order to fine-tune its configuration.

In addition, ownCloud seems to be plagued with issues: five-hundred, excluding feature requests, on its GitHub, and a cursory search reveals myriad breakages upgrading from version to version. This latter point is important: while sovereign will ostensibly make it easier to upgrade all the components of one’s personal cloud at once, components which break during version migrations will cause people to hold off, leaving them with insecure, older versions.

The Unexpected Contender

And what if you’re not an enterprising, tech-savvy hacker? What if you can’t be arsed to configure a dozen services of varying complexity? The other attempt I’ve seen—the potential of which might have even escaped its creator—shares much in form with sovereign. It’s a bundle of useful tools designed for administrating the various components one needs from a centralized server. But that’s where the similarity ends. What am I blathering about, you ask?

That’s right. Apple’s unassuming OS X Server.

Well, think about it. You sign up for a Mac Mini colo (no affiliation!), install OS X Server on it, and what are you getting, out of the box, without a second thought? WebDAV, CalDAV, an IMAP server, a wiki, git source control with continuous integration extensibility, Jabber messaging—whose federation you can control with a single setting, checkmate Google—automatic push e-mail for your iThings, and a handful more robust features. Not only that, but you own the hardware as well.

What appeals to me about this solution is the trade-off made. For the cost of a Mac Mini and average hosting costs, you get a robust, easily-configurable UNIX server, mirroring the machines most modern programmers have on their desks. Considering Apple’s vaunted track record with customer support, and developers’ love of their Macs, this is a reasonable proposition. In addition, many pieces of Server are built on open source software: the web hosting on Apache, the Chat Server on jabberd2, the anti-virus on ClamAV, the web interface on Rails, the IMAP server on Cyrus, and so on.

Still, every extension of your life into Apple’s ecosystem comes with the same basic set of rules. Bug reporting and security updates are hidden to the end-user until the eleventh hour. The OS is opinionated, and may fail in opaque ways. I honestly don’t know if being a Server customer makes a difference in the kind of support one gets. Its relative rarity-of-use will make it difficult to find solutions to pressing issues.

On top of the abstract disadvantages, OS X Server also has a few notable issues of its own. Apple’s SMB2 implementation seems to be causing countless headaches. Its VPN server seems to require tricky finagling to get working, and only after Apple patched its implementation after release (and until that point, users had to guess when their VPN connections would be usable).

The Missing Piece

Dropbox is going to be a pain in competitor’s asses for a long time. It is an indispensable part of my arsenal, and one of the few reasons I’m not attempting one of these experiments myself. My 1Password safe is in Dropbox. My research and PDFs are stored in Dropbox. This article is stored in Dropbox. If an iOS application I use doesn’t have Dropbox, that’s a demerit. Its position is unassailable because of the ecosystem that has been wrought around it.

sovereign purports to address this with ownCloud. OmniPresence might fill the gap for OS X Server. Neither of these have the mind-share to make a personal cloud worth the effort yet, in my opinion. My barometer is simple: is there a column for the sync service on iTextEditors? If not, not enough developers are paying attention to it.

Conclusion

The personal cloud is only a small part of the picture. With no way to know where our packets are being routed through, or how secure our encryption really is, or how we may bring mobile application developers onboard to support our offerings, everyone huddling in their own VPS or Mac Mini may not be a comprehensive solution.

I wish I had the time to perform a deep dive into this. This is probably some blue ocean opportunity for enterprising hackers. Either way, it’s something I plan to keep a close eye on.

04 January 2014

cus-edit+ Is the Best Emacs Module You’ve Never Used

I have declared .emacs bankruptcy for 2014. I’ve wanted a simple, extensible Emacs configuration for some time now. On the way to that goal, I discovered a module that’s made it easier, and has changed how I think about Emacs configuration.

Drew Adams is the insanely productive programmer behind Icicles and DoReMi, and countless other Emacs contributions. He is absolutely prolific on the EmacsWiki, tirelessly responding to other users and providing support. In short, he’s a model community member. He’s also the author of cus-edit+.

Its goal is simple: to unify the changes you make both outside and inside Emacs’ Customize system. The results, however, are phenomenal. Huge swaths of my disorganized .emacs.d should have been tracked by Customize.

Here’s a file hidden in my mess of an .emacs.d directory called misc.el:

(setq
    backup-by-copying t
    backup-directory-alist '(("." . "~/.emacs.d/saves"))
    delete-old-versions t
    kept-new-versions 6
    kept-old-versions 2
    version-control t
    ido-enable-prefix nil
    ido-enable-flex-matching t
    ido-create-new-buffer 'always
    ido-use-filename-at-point 'guess
    ido-max-prospects 10)

If you’re like me, this should look familiar. Undocumented detritus with a useless filename, multiple modifications to seemingly unrelated variables.

Here’s what it looks like after using cus-edit+:












Those settings are now in my custom-file. I can M-x customize-saved, and I get their name, their description, their current value, and what group they belong to.

As I go through my old .emacs.d directory:

  1. I find settings that I know I want and execute them.
  2. I use cus-edit+ to update its repertoire of modified custom variables, by M-x customize-update-all-vars.
  3. Then I M-x customize-customized—another cus-edit+ function—to bring all those modified settings into one customize page, so I can review and set them.

It’s basically painless. It doesn’t solve all my problems with Customize (another entry entirely) but it takes huge strides towards finally mopping up the mess that brought me to .emacs bankruptcy in the first place.

Give cus-edit+ a go: It’s available on Melpa, as well as the EmacsWiki. Find all those random setqs cluttering up your Emacs configuration, and get them where they belong.

29 December 2013

Pelicorg: A Pelican Plugin for Emacs Org

Click here to skip the backstory and get to the code.

Back in 2011, this website was published as a set of extensions to Emacs’ popular Org mode. As the years went by, I used Emacs less and less for everything. I started another blog which I deployed using Pelican, which allowed me to quickly dash off posts in Markdown, and publish them without much of a fuss at all. Pelican isn’t perfect—no static site generator is—but for a few manic weeks I was able to almost completely ignore the publishing aspect of things and concentrate on writing.

Still, I had three problems:

  • Org 8 had finally arrived, with a complete rewrite of the publishing backend, and I couldn’t publish my old site with it.
  • I was now maintaining two blogs, with two separate sets of credentials, publishing systems, and authoring tools.
  • I liked both of them: the lightweight structure of Markdown for more prose-centric posts, and the insanely powerful Org mode for more technically focused essays with a lot of code.

I don’t know why it took me so long to cut the Gordian knot, but it finally occurred to me a week or so ago: Why not just… use Pelican to publish the Org files? Then I can give up on my (insanely too janky) Org mode publishing scheme, and have the best of both worlds.

Introducing Pelicorg

How does it work? It’s simple. For every Org file in your content directory, the plugin will launch Emacs on the command line, process the Elisp you give it, and spit out the completed HTML.

Yes, you have to launch Emacs for each file. You can’t run an Emacs server and pass off the requests to it, the behavior of princ is fundamentally broken with emacsclient.

It also requires Org 8. So, keep that in mind.

There are three variables for your pelicanconf.py:

  • ORG_READER_EMACS_LOCATION is a required, absolute path to your Emacs binary. If you use Homebrew, it’s probably /usr/local/Cellar/emacs/<version>/bin/emacs.
  • ORG_READER_EMACS_SETTINGS is an optional, absolute path to an Elisp file you want run on every invocation. This is a good place to (require 'package) and (package-initialize) if that’s where your Org comes from.
  • ORG_READER_BACKEND is an optional string with the name of an alternate backend in it. If you don’t know what this means, simply ignore it.

Well, what are you waiting for? Grab the source on GitHub and use Org to write some awesome technical essays!

Page 1 / 7 next

Copyright MMXIII Matthew Snyder. Made in Munich. RSS. My opinions are not necessarily my employer's. You may be interested in browsing the archives.