I'm also using both vendors with a couple VPSes at each.
I've had one outage with Slicehost when they needed to replace a drive in one of my servers. I wasn't even aware that there was a problem prior which shows how proactive they were. The outage was short and on schedule and everything came back up, as expected.
I've had excellent experiences with tech support in both organizations. Both are very responsive.
Both have pretty strong user communities with Slicehost having a bit of an edge on documentation, if you aren't already comfortable with your own admin. Both have active IRC channels.
Honestly, for me they're almost a coin flip. When I get ready to acquire a new VPS I see what each is offering at the time and go with the biggest bang for my buck. The article is helpful, even if unscientific, at determining the efficiency of the bang.
It doesn't make sense to base your production system on a hack of your provider's platform. 64bit OS was the reason I ditched Slicehost too, although I knew about this hack.
A hack? To the best of my knowledge, both providers allow users to install arbitrary Linux distributions. It's not against any rules, so I wouldn't consider this a hack.
Go through all that when Linode (or others) lets me click a button to get the same thing? No thanks - it looks like a 'hack' to me. Sure, I don't mind running my own system, but imagine doing that every time I decide to provision a new one - yuck!
I'm curious to see what the 64-bit memory-tax is for various languages/runtimes.
I took a quick glance at the Language Shootout to see if I could find any patterns, but at least for the few I checked, it's all over the place. For example, on the "n-body" problem, both Ruby and SBCL grow 31% on x86-64. But Ruby on "pidigits" grows only 2%, while SBCL on that problem adds a whopping 111%. On "spectral-norm", Ruby grows 61%, while SBCL grows 31%.
So this appears to be a place where moving to 64-bit is completely unknown, and you have to test for your specific application. It might double your memory usage with no change in speed, or (if you're running pidigits.rb) it might double your speed with almost no change in memory usage.
The SBCL thing makes me wonder if there are any modern lisps that can be restricted to a 4GB (32-bit) address space, while still using 64-bit values and registers...
Then, cons cells would take up only one machine word.
If everything you point to is aligned on an eight-byte boundary, and if you don't use type tags, then a 32-bit pointer can point to anything in a 35-bit address space. So you can get up to 32 GB.
I've been using linode for the last 8 months and so far it has been a wonderful low cost, high performance solution. My only complaint is that they don't appear to offer any backup solutions. I an under the assumption that I'll be rebuilding my linode disk image from scratch if the physical server is involved in a fire, corrupts my disk image, etc. It would be nice if I could do the equivalent of take a snapshot, encrypt it, and upload it to s3.
With Slicehost now being owned by Rackspace, they are more likely to stick around for a while which is nice if you're into that sort of thing. But they are both fantastic, can't go wrong.
Linode has been around a pretty long time now- I've been a customer for least a couple years. I think they're well past the point where we need to be worried if they're still going to be around next year.
Or rackspace could just one day decide the VPS market isn't for them and declare slicehost a mistake, and then shut it down. Not entirely impossible...
Or they could lower prices hoping to attract more people. Or they could deploy the Slicehost guys to work on their own offerings, which don't interest me. Or ... lots of things.
I can't speak for slicehost, but I have used linode for a little while now and it's been completely painless. I haven't had any disasters (perhaps that alone is telling) so I can't speak about riding the river either.
Linode has help on IRC for anything that isn't straight-forward too. Easy.
I don't use them any more as I've moved to Slicehost, but Rimuhosting have servers in London and their pricing and service are very good, if a little pricier than Slicehost/Linode
That is interesting; I asked about increasing it on my personal slice and Slicehost refused. I decided to move to Linode as a result.
The company I work for also has several slices at Slicehost and, from what I understand, Slicehost wouldn't increase the limit on that account either.(I am not the point of contact so I can't say definitively in this case)
* Their 90-day money back guarantee only applies if they have failed to meet industry standards for performance and reliability. So, if you just don't like the service, you're out of luck.
* Their 90-day money back guarantee actually doesn't give you your money back! They give you a pro-rated refund of your charges for that month. So, even if you can argue to them that they are slow and unreliable, you'll still only get a refund of your unused portion.
Maybe they are really good, but their public presentation leaves a little to be desired. I'm ok if someone doesn't want to offer a money-back guarantee. However, why word something so poorly? A pro-rated refund is not a money-back guarantee.
Going into their order system, they're definitely cheap - they divided their costs by 100! So, that $53 level becomes $0.53! It just seems like they don't have their act together. It could just be that they put all their effort into the product itself and didn't pay attention to the other details, but it isn't a great way to run a business.
The price isn't a mistake: "CURRENT SPECIAL: 99% off the first month on Virtual Private Server and Dynamic Dedicated Server VPS accounts! Discount automatically applied at checkout. The next 80 orders will receive this discount."
I have used both. Gor my usage pattern (low) they have both proved to be excellent.
However, I would a ++ for Linode because they seem to offer more RAM/$ on paper. And their online control panel is a bit more sophisticated than Slicehost's.
I've been using Linode for a while and I've been generally happy with it. There were some glitches when they started doing xen hosting, where one of my filesystems would suddenly drop into read-only mode and only a reboot would fix it, but that hasn't happened in months.
I used to use OpenHosting (openvps.com), and I have no complaints about their pricing or service, but (a) they use CentOS exclusively, and (b) they use Linux-VServer rather than Xen or another better-known virtualization system. If you can work within those constraints I would recommend looking into them.
If he was running ruby enterprise and passenger for these comparison's then the results may be skewed. My understanding is that you get about a 30% memory usage reduction with ruby enterprise, but that's only on 32bit images... so he wouldn't get that benefit on a the stock 64bit slicehost install.
I went through this comparission recently and didn't find much between them. I ended up going with Slicehost due to their excellent collection of articles (the last time I setup up a prod linux server from scratch was about 6 years ago, so I was a bit rusty and the articles proved invalulable).
huh. both use xen... you'd think you'd be able to put a 32-bit image on there (unless they are using some ancient version of Xen) 32 on 64 seems to work pretty well on Xen 3.3.
this reminds me, I need to start providing some 32-bit images.
I've had one outage with Slicehost when they needed to replace a drive in one of my servers. I wasn't even aware that there was a problem prior which shows how proactive they were. The outage was short and on schedule and everything came back up, as expected.
I've had excellent experiences with tech support in both organizations. Both are very responsive.
Both have pretty strong user communities with Slicehost having a bit of an edge on documentation, if you aren't already comfortable with your own admin. Both have active IRC channels.
Honestly, for me they're almost a coin flip. When I get ready to acquire a new VPS I see what each is offering at the time and go with the biggest bang for my buck. The article is helpful, even if unscientific, at determining the efficiency of the bang.