It’s been a while. A very, very long while. So much for “writing regularly” like I told myself I would. But lo and behold, we are putting that behind us! (Or so I am telling myself, again.) I’ve decided that I need an outlet boring my definitively non-technical friends with ramblings of how I did this or that at some ungodly hour of the morning. And so, here we are.

What’s changed?

Well, how I run the site has been completely overhauled. I fell in love with Tumblr, as seemingly everyone else did, but getting email notifications that the site is bouncing up and down like a ping-pong ball makes me wonder if the platform has any long-term viability. But that’s a topic for far more knowledgable beings to tackle. Me? I just switched to using Jekyll.

The initial issue when I considering switching to Jekyll is that I use MarsEdit to write up most my content. I just like the feel of a desktop application. Since Jekyll posts are all just text files, I could just launch TextMate and go to town. That doesn’t really suit me though. MarsEdit has this lovely live-preview window that I’ve pretty much come to rely on when proof-reading on the go. At first, it seemed as though there was no possible way to hook MarsEdit into a file-based blogging system. After a helpful hint from Daniel Jalkut on Twitter though, I realized there was indeed a file-based blogging option and I eventually came up with a way to use this feature and leverage the power of Jekyll.

In short, all I did was customize Alex Payne’s newpost script for my devious needs. What I ended up with was a new conversion script that takes my text file posts from MarsEdit and spits them back out in nice Jekyll posts with the appropriate YAML data.

The longer version

In MarsEdit, you can create a Blosxom blog. This tells MarsEdit to “post” your content to text files in a directory of your choosing and optionally execute a script when you publish a new post. So, I added a _blosxom folder to my Jekyll directory and execute the aforementioned conversion script when I write a new post. Walla! MarsEdit with Jekyll. But, I couldn’t stop there.

I love the microblog layout of Tumblr. The idea of having smaller, better formatted posts for the type of content you want to share underscores the point of a blog. To share something. For many people though, that something isn’t always a wall of text. So, despite the fact that I only ever use the text and link options, I needed this.

Jekyll has a wonderful template system utilizing Liquid. It renders your pages based on which layout you specify in the post metadata. So specifying a post as “link” layout allows you to specify a different template for that content. The hitch I ran into was with MarsEdit’s file format. The Blosxom functionality is very bare-bones, as it was intended to be. It simply puts the title of the post on the first line, and your content follows. Expanding the conversion script and changing how I title my posts was the solution.

I now prefix all my post titles with the layout I want to use in MarsEdit. E.g. “Text: Is This Thing On?” and “Link: Amazing awesome link from twitter!” Any relevant URLs I simply include in a line at the top of the post before the actual content. When the script opens the files, it checks the post title to see if it is text or not and will additionally insert the relevant metadata and remove it from the post. Really simple, works well.

What’s so special?

Nothing, really. I’m just smitten that I can still use MarsEdit and have my site look and feel very Tumblr-esque (in fact, I copied my Tumblr theme over almost identically) and have the power of Jekyll underneath. And of course, being a Jekyll blog I am hosting it via GitHub’s awesome Pages feature.

Shoutouts and Thank Yous

Giving credit where credit is due, I want to tip my hat to the people’s work I built upon.

  • Jekyll is maintained by Tom Preston-Werner, Nick Quaranto, “and many awesome contributors!”
  • Alex Payne, for his newpost.rb script that got me wondering and for having his own personal blog open to the public on GitHub. Having a baseline to create my own was extremely helpful.
  • Daniel Jalkut (Red Sweater Software), for his awesome MarsEdit application.
  • GitHub, for being… well, GitHub. I host this blog there via Pages and, of course, host the repository there as well. They are all amazing.

While I unfortunately can’t remember who linked this on Twitter, (Sorry! Twitter doesn’t allow searching just the people I follow.) I was pointed to this evaluation by BrowserMob of Google’s new DNS service compared to OpenDNS and the run-of-the-mill ISP. The results were surprising, and I suggest you take a gander at what they found.

Pause while you read up…
Alright! Welcome back.

At the end of their post, they provide a downloadable Java application that they built to perform the test. It queries for the DNS for the top 1000 Alexa sites worldwide via Google’s DNS, OpenDNS, and whatever local DNS you specify. It runs the test three times.

Here are my results from just outside New York City using Optimum Online:

Test 1: Google
45164 ms for 1000 records
Test 2: Google
40363 ms for 1000 records
Test 3: Google
35965 ms for 1000 records
Test 1: OpenDNS
98885 ms for 1000 records
Test 2: OpenDNS
26778 ms for 1000 records
Test 3: OpenDNS
17898 ms for 1000 records
Test 1: Your DNS
79021 ms for 1000 records
Test 2: Your DNS
71502 ms for 1000 records
Test 3: Your DNS
58576 ms for 1000 records

Now right off the bat, I see the Google isn’t at impressive as I thought it would be. That said, my Google results are still about twice as fast as BrowserMob’s. OpenDNS once again had the slowest response of all with their first test, but quickly made a comeback. In fact, in terms of the fastest results OpenDNS takes the cake. Looking on, I think the most important piece of information lies in the Optimum Online results. They were slower than Google every time, and much slower than OpenDNS with the rather obvious exception.

BrowserMob came to the conclusion that while OpenDNS provides nice features, and Google claims to be cutting down on DNS query times, their local ISP was still the best option. This was true in their case, but very wrong in mine. Logically, it takes less network hops to get to my own ISP’s servers than either Google or OpenDNS. So why so slow? I really couldn’t tell you, but looking over the comments on BrowserMob’s blog there’s a good mix of results like theirs and results similar to my own.

I think that when choosing which DNS service to use (something that most computer users will never even think about) a test like this proves beneficial. You can’t just make a broad statement that Google is better due to their web presence or that OpenDNS is better due to their experience in the field (though they do have nice features that Google doesn’t yet). Some will find that their tried-and-true provider’s DNS may be best. For me, I don’t know which I’ll stick with yet. I don’t use very many of OpenDNS’ features but their horrific first test and Google’s slower average leaves some food for thought.

Eivind Uggedal —

Aside from cost, performance was the most important criteria for me when selecting a provider for was it up?. 5 different benchmarks were carried out every 3 hours over a week, leading to 56 runs each. The slowest system used up to 3 hours to complete all 5 benchmarks. Weeklong benchmarking was used to account for variance in host load during the day/night and week. I speculated that the host systems could be more utilizied on weekdays when people in the US were awake (all providers under test were US based). At the end of this article you’ll find a table summarizing the averages and standard deviations of the 5 benchmarks on all providers.

In the end, Linode won out with both their 32-bit and 64-bit platforms. Much more in-depth performance reports that nicely support my previous VPS comparison.

Updated 2009/09/22.

A while back on the macsb mailing list there was some discussion about hosting and which VPS provider was the best for a developer’s typical needs. The two competitors that rose out of the discussion were Linode and Slicehost. I’ve used both and decided it would be good of me to post a more comprehensive guide, this is the result.

In essence, the difference between these two companies is their feel.

If you like to tinker, Linode gives you everything you need. If you rather a defined, slick experience, Slicehost is for you.


Server location doesn’t matter as much as it used to, at least when you’re discussing US-based traffic. So while this is a largely unnecessary area of their services, it does matter to some and for that reason I’ve included it.

Slicehost Linode
Dallas, TX Dallas, TX
St. Louis, MO
Atlanta, GA
Newark, NJ
Fremont, CA

From what I saw, Slicehost provides no way to choose where your Slice (that is, the VPS) is provisioned. Linode, on the other hand, let’s you choose when first setting up the Node (that’s what Linode calls them). Linode also lists their current availability on their website.

Both companies will move your VPS via a support request.


Almost all VPS hosts provide a variety of Linux distributions to choose from, it’s just a matter of selection.

Distribution Slicehost Linode
Arch Linux 2009.02 Yes Yes
CentOS 5.3 Yes Yes
CentOS 5.2 Yes Yes
Debian 5.0 Yes Yes
Debian 4.0 Yes
Fedora 11 Yes Yes
Fedora 10 Yes
Fedora 9 Yes
Gentoo 2008.0 Yes Yes
Gentoo 2007.0 Yes
OpenSUSE 11.0 Yes
Slackware 12.2 Yes
Ubuntu 9.04 Yes Yes
Ubuntu 8.10 Yes Yes
Ubuntu 8.04.2 LTS Yes Yes

Slicehost now offers RedHat EL (currently 5.3) for a monthly charge. This is a huge step-up over Linode for users who require RH Enterprise Support.

Linode also allows you to (somewhat) easily install any custom system, that is really powerful.

[Addendum] – Something I forgot to put in here, but I noticed when Slicehost announced it. Both providers offer kernel select from within their respective managers.

32 or 64-bit? Does it matter?

On the same track as distributions, I should point out that Linode offers both i386 (32-bit) and x86_64 (64-bit) versions of their distributions while Slicehost only offers the latter. This doesn’t make much of a difference, but on a smaller VPS setup (with less RAM), it could be an issue. For the fully skinny on how this might affect you, check out this awesome article by David Welton.

Bandwidth, IP addresses, and High-Availability

Bandwidth obviously varies by pricing plan, which will be looked at later. But generally speaking, when comparing Slicehost and Linode plans side-by-side, Linode offers more bandwidth of Slicehost at equivalent pricing tiers.

Both Linode and Slicehost give 1 dedicated IP address for each VPS, with more purchasable. (You must provide proper justification when applicable.)

Both parties offer private IP addresses for unmetered bandwidth (in the same data-center). Linode offers this immediately upon setting up your Node, Slicehost will accommodate you receiving a support request.

Both companies offer in-depth guides to achieving high-availability / IP-failover.

Want to grow?

Growth typically leads to one of two desires when dealing with a VPS. Either make more of them or make it bigger.

Both providers offer a service where you just “click a button” and their systems will take your VPS down, make a larger one, and copy it over in the same exact state. You simply have to pay the higher price.

Both services providers allow you to “clone” existing systems to create additional copies.

Mission Control

Linode has a rather advanced control panel compared to Slicehost’s SliceManager. It just comes down to how fine-tuned you want your setup to be.

With Slicehost, you are given a premade box with a swap, a disk (based on plan), and the OS installed and setup.

Linode takes a more technical approach. While they do provide a wizard that will automate the deployment process, you actually can make multiple boot profiles, and cut up and setup your disk space into however many images you like. This can be quite powerful and even allows you to install a custom OS if you want to get your hands dirty.


Linode also offers another method on control.

Lish is a shell that you can SSH into that gives you complete control over your server. It’s primary tool is to give you console access to your node (rather than an Ajax page)… but you can do much, much more. It can essentially give you all the essential tools that you normally have to go to the web panel for, in one concise tool.

To really realize how handy this is, you should just view the documentation.

Rescue 911!

We’ve all reached that point where we realize we shouldn’t have entered that command, or changed that network configuration, or done whatever it was that crashed your box. The point is, it happens. Being able to recover from such a situation is what matters.

Linode has this nice little shutdown “watchdog” named Lassie (Linode Autonomous System Shutdown Intelligent rEbooter) who will automatically reboot your server if it died unexpectedly (that is, you don’t set a proper shutdown via Lish or the control panel). This could make or break your day (or night) while you’re away from your computer.

Both companies offer recovery consoles to allow you to control the server directly in case of emergency.

Price point

For some people, it really comes down to this… a pricing comparison. I should point out that Linode has many more pricing tiers, but Slicehost has larger options.

VPS Price (Mo) RAM Disk Space Bandwidth
Linode 360 $19.95 360MB 16GB 200GB
256 Slice $20.00 256MB 10GB 100GB
Linode 540 $29.95 540MB 24GB 300GB
512 Slice $38.00 512MB 20GB 200GB
Linode 720 $39.95 720MB 32GB 400GB
Linode 1080 $59.95 1080MB 48GB 600GB
1GB Slice $70.00 1024MB 40GB 400GB
Linode 1440 $79.95 1440 MB 64GB 800GB
2GB Slice $130.00 2048MB 80GB 800GB
Linode 2880 $159.95 2880MB 128GB 1600GB
4GB Slice $250.00 4096MB 160GB 1600GB
8GB Slice $450.00 8192MB 320GB 2000GB
15.5GB Slice $800.00 15872MB 620GB 2000GB

As you can see, Linode typically gives you more for your money - though I am unable to gain concrete information regarding their private “high-end” dealings.

And finally…

The Community.

Both companies having thriving communities surrounding them, though Linode is generally less mainstream and therefore less known.

Slicehost has a nice-sized IRC channel as well as a Campfire chat room. You can hear people discussing Slicehost on Twitter often enough and many well known services run off Slicehost.

Linode is more tight-knit in my experience. They have an IRC channel hosted on OFTC which is lively throughout the day. There are a lot of regulars there that will help anyone who has a problem, or just geek out with you.

In Summary

It all comes back to the feel. Linode can offer you more if you like to pull the levers and push the buttons, but Slicehost will offer you a more controlled experience, which is quite enjoyable. In the end, I’d say it’s mostly a matter of preference.

The one-line summary: push into a remote repository that has a detached work tree, and a post-receive hook that runs git checkout -f.

Great how-to for putting a website under the control of git and avoiding some of the issues that can pop up when using git pull from your server is not an option.