[mdasen]

There are several.

Slicehost has been doing Xen hosting longer. Linode is older, but they were using User Mode Linux (not nearly as good as Xen) for a long time. Slicehost got the mindshare by getting to Xen hosting first.

Slicehost is local to all their data centers. Whether in St Louis or Dallas/Ft Worth, their employees actually work there. Linode's employees all work in South Jersey, 2 hours from their Newark data center and inaccessible to their other data centers. Kinda indicates that they have other people setting up a lot of their stuff.

Linode is often out of stock or having limited stock. This might just be that Slicehost doesn't tell us how the sausage is made and Linode does.

Linode tops out at 2880MB. Slicehost offers instances going up to 15.5GB. That's a major difference if you want to try scaling up easily and there is a huge difference between trying to get your site to handle traffic on a 3GB server and a 15GB server.

Backups are a nice touch.

The Rackspace name lends a "they're the big game in town" to their service.

They aren't that much more expensive. Linode charges a constant $0.0555. . . per MB of RAM. At the 2GB level, Slicehost is charging $0.634 per MB of RAM. That means that if you were to get 2GB servers from each, the Slicehost would cost you $130 and the Linode would cost you $114. It is cheaper, but it isn't so significantly cheaper.

Slicehost can more easily upgrade your plan. Linode has to switch your box should you want to move plans. Often Slicehost can move plans while keeping you on the same box.

--

Now, none of that may matter to you. It doesn't to me and that's why I'm a Linode customer. However, for many these are considerations. If you're running a business, having instances top out at 3GB is a concern. Would you pay a 13% premium for Slicehost just for the knowledge that you can upgrade beyond 3GB of RAM should the need arise? If I had a person project where downtime for migration would be embarrassing, I would.

Likewise, some might care that the Slicehost people actually work in the area rather than colo-ing boxes with places like The Planet.

I'm very happy with Linode, but I can see why many would choose Slicehost.

[axod]

>> "They aren't that much more expensive"

Bandwidth overage on slicehost is .30/GB. On Linode it's .10/GB. That's a fairly massive difference.

[patio11]

For some businesses, the economic value of a marginal gigabyte is, say, (does math) $50.

Santa, for Christmas this year:

1) I'd like to use all of my 500 GB quota, every month.

2) I'd like to start paying overage charges. REALLY BIG OVERAGE CHARGES.

[jbr]

> Slicehost can more easily upgrade your plan. Linode has to switch your box should you want to move plans. Often Slicehost can move plans while keeping you on the same box.

I'm on slicehost, and when I upgraded ("resized") a slice, it was not a "live" operation. I don't know whether it's physically the same machine, but the old slice had to be shutdown, file system copied, and a new slice booted.

From the "Resize your slice" page:

Step 3: Current slice is shut down and migrated You will experience a downtime varying in proportion to fullness of the filesystem.

[axod]

It's pretty similar on SH and LN. I prefer LN, because you get to decide when it happens. You just get a message in your manager to say you have a migrate pending, and you can shutdown when you like.

When I moved from 1400 to 2800 it was a very speedy operation.

[jpwagner]

http://journal.dedasys.com/2008/11/24/slicehost-vs-linode

[davidw]

Exactly (thanks for linking to it:-) you can't compare the RAM prices directly. You have to figure in the 64 bit tax on Slicehost first, then compare. It turns out that Linode is significantly cheaper.

[zepolen]

> trying to get your site to handle traffic on a 3GB server and a 15GB server.

I find that I always hit cpu limits way before memory becomes an issue.

[diN0bot]

same here. i've been profiling this past week trying to see if i can trim cpu cycles or whether that's just how the game is played.

[zepolen]

The problem is template rendering, string handling is a (relatively) expensive process. I found utf8'ing my entire workflow (instead of decoding to unicode then reencoding to utf8) drastically affected performance (using python).

[lsc]

if you want more than 15GiB... use hardware. For less than half what a 16GiB slice sets you back, I'd be happy to rent you your own 8 core server with 32GiB ram.