On Complacency

I encountered the wonderful neologism “consumer-lifestyle anxiety” the other day. It manages to describe so much of what my digital life has turned into.

Recently I was trying to find software to annotate a maps for a travel itinerary. I wanted to go make a list of interesting things in London, and put them all on a “walking-around” map of sorts. That way, I could have a loose itinerary, and wherever I was, I could pull up this walking-around map, and see what was nearby.

I guess that’s not how people do this, because Google Maps on iOS doesn’t support maps made with this Maps Engine, or My Places, or whatever it’s called. And Google Earth for iOS hasn’t been updated since before iOS 7. It has two menu options for custom maps or My Places, and one of them says the operation can’t be completed, and the other one says “No Maps Found”. So, fine. Maps Engine exports to KML, and Galileo imports KML. Except now the little map icons I set, so that I can tell if something is a museum or a restaurant, are all the same icon. Because KML is a standard, but apparently the place marker icons aren’t standardized.

So I wrote a Python script to import the KML from Google Maps, and then process it and replace the icons with the ones from Galileo. And something occurred to me while I shaved this yak: I’m no longer motivated in solving the problems that became my career.

It feels like a curve. When I was very young, the only way I knew how to fix something in Linux, was just to re-install the whole thing and start over. And there was a time in the middle, during college, where I was capable of fixing things: compiling kernels, compiling wireless network card kernel modules, getting sound to work, writing my first web applications, and all the little systems I tinkered with in college.

Around 2008, I slowly stopped caring about solving these deep, interesting—or at least relevant to my discipline—problems, and started just wanting perfection. Refusing to use an old app for iOS. Refusing to use any apps except the absolute best, the ones with the highest reviews, the most attention. I can’t count the amount of time I’ve spent rearranging icons on my iPhone. This weird sort of fidgety digital pruning; constantly wanting to be on the bleeding edge as a consumer, and no longer as a tinkerer.

That dovetails with my minimalism a ton. Tinkering requires clutter. It requires the corpses of old desktop computers, hard drives, wires, tools, projects constantly half done scattered all over one’s living space, terrible code lying around, undocumented projects, the natural entropy of the creative act.

So either my ecosystem, or my personal laziness, or some other aspect of my life, has made it more difficult for me to really want to solve problems in the way I’ve been trained to. The sheer frustration of dealing with terrible software has definitely worn on me. But even for someone who has the power to change it, it’s getting harder to rationalize.

It’s my hope that writing more here will help stimulate my desire to perform creative acts, to engage with the software community, and fix things. So here’s to 2015.

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.

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.

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.

Page 1 / 7 next