I don't care about unlicensed use. I care about the time spent setting up the photo gallery, uploading photos, adding comments, collecting comments from family, etc, and all that being lost if the album hosting went down.

And yes, I have nightly backups of the photo albums (and all other files on my server) to my home system, something which I cannot do with a hosted photo site like Picasa (or can I? I never researched that option, but I don't know how they would allow you to do a full backup of all aspects of your Picasa albums to your home system (including comments, layout, etc) or in what format the backup would be in if they let you do it).

Also the rollover for the feds comment, and the burying servers in the backyard, etc, is tinfoil hat stuff. I'm practical enough to realize that the only real danger to my data is if the hoster went out of business or if their data center blew up, neither of which is particularly likely, but just likely enough that I don't want to trust my albums to a third party that does not allow me to backup every aspect of the albums like I can do with my own hosted gallery.

This is why I don't want to use PicasaWeb:

Wow that's pretty chilling. Although, I have to wonder if what they're getting at is trying to put a disclaimer up so that they can't be sued for copyright infringement for displaying your photos no matter what form they choose to display them (like, if they change their Picasa web hosting to automatically resize images as a feature or something in a way that changes the size of the images that you uploaded in the past, they don't want you to sue them for altering your copyrighted images).

One could interpret their legalese as essentially protecting them from every kind of frivolous copyright infringement lawsuit that someone hosting copyrighted content on their site could bring, and not as a means to give themselves the ability to 'steal' your content for their own use.

Of course, the effect of the legalese is the same in either case, whatever their intention: they essentially own any content you upload to their site. I guess each individual would have to decide if they are OK with that; and although I am not particularly paranoid, I wouldn't be comfortable with that arrangement.

I want to make clear again that my post, and this thread, is not about bashing Linode as being worse than a micro EC2 instance; I think that probably everyone here on Linode already realizes how incredible this service is. If your content fits in a Linode, then there is no reason to switch to another hoster (aside from some of the more esoteric features of EC2, which wouldn't be applicable to alot of people). I did want to let Linode know that after years of complaining about the cost of disk space, I eventually did put my money where my mouth is and leave because of it; only in the hope that maybe this will make them think about making lower cost disk space available to Linodes so that I can eventually come back.

I personally appreciate you posting this. I'm a Linode client and have ~$400/month in service here across several accounts and its quite frustrating that the disk space offerings are so limited. Its literally my only quibble with Linode.

I appreciate that your post was at the very least constructive, as opposed to, "So long b*tches!!!!1111".

Hope this doesn't go unnoticed. It is a shame you signed up for a year with EC2 though. Best of luck.

Well I'm already experiencing some problems with Amazon EC2 Micro. Basically it turns out that my gallery site occasionally gets hit by spambot networks trying to post comment spam. I haven't figured out yet why they are not succeeding (my gallery installation appears to be a bit borked as I am unable to add comments even legitimately it seems), but whatever the case, the inundation of http requests to some fairly heavyweight PHP pages is bringing my EC2 instance to its knees. It enters a burst-throttle-burst-throttle cycle that makes it nearly unusable.

I turned off commenting on my gallery (which nobody was really using anyway) which will help, but in the end the only way to keep my EC2 instance from blowing up was to run a program called 'cpulimit' to limit my HTTP processes to 20% CPU each (with 3 processes and a maximum 60% CPU utilization).

I tried to ask Amazon if they'd consider a feature request of allowing customers to opt out of the 'burst' feature of micro instances, so that the instance would get a guaranteed constant amount of CPU instead of burst-throttle-burst-throttle, but of course they never even acknowledged my suggestion.

I am not sure why I never noticed the spambots on Linode, either Linode's instances are so fast that I never even noticed the load, or the EC2 IP block is more high profile and more inviting to spambots; or maybe it's just coincidence.

I'm already regretting my move to EC2 micro instance. Of course I need the disk space so I'm kind of stuck between a rock and a hard place now ...

I'm guessing that Amazon will intentionally keep the micro instance throttled to ensure that you aren't getting too much CPU usage for free.

If the micro instance was able to burst to the full capacity of the machine for extended periods then they'd probably get users spawning a bunch of cheaper micro instances instead of the larger instances. You'd get customers with CPU intensive workloads downgrading their existing instances.

S3 or some other storage service along with a Linode probably would've been a better option.

You don't understand. I don't mind the non-bursted, guaranteed CPU capacity that Amazon provides with the Micro instance. It's not blazing fast but it's OK. The problem is that they allow a burst, and unless you have some way of limiting programs from taking as much CPU as is available (i.e. artificially putting 'sleeps' in programs like cpulimit does), the EC2 micro will burst to more than the allocated CPU cycles.

After about 10 seconds of burst, Amazon has some kind of CPU rate limiter in place for its instances that kicks in and throttles the instance *HARD*. Like, to the point of taking away 90+% (feels more like 99%) of CPU. This is the problem that I have. I don't mind the burst, but the throttle is ridiculous. So if I can only have both or neither, I'll gladly take neither. If Amazon wants to slice the CPU up so that my micro instance has a guaranteed "reasonable fraction" of the CPU, then that's fine. But allowing my instance to burst when I don't really want it to, and then throttling my instance to near unusability, is a terrible policy.

After you turned off the comment feature, you're saying you still had to limit the amount of CPU? Unless there's more traffic than I remember you stating, something has to be causing the CPU to rise in the first place. A web site, even with a gallery, sitting there doing little should take up very few resources, including CPU.

bji coming back to Linode in 3, 2, 1...

I also used to whine about the lack of disk space, but nowadays I just buy a cheap VPS or a backup service with lots of disk space (100GB for $14.99, etc.) preferably in the vicinity of a Linode datacenter. I store pictures and other large stuff in the other account, and mount it on my Linode using NFS over an encrypted tunnel or SSHFS. That way, I get a large and relatively low-latency disk attached to my Linode for only a few more dollars a month.

It's much faster and more convenient than S3, especially with existing apps that can't be easily adapted to use S3. The webapp won't even know where the files are actually stored.

That would make a pretty nice HOWTO for the library.

Maybe. But it would be somewhat inappropriate to endorse purchasing services from other VPS companies in a Linode Library article. Also, the reliability of this setup depends entirely on the quality of the "cheap VPS" which, since it's cheap, is unlikely to be up to par with Linode.

Anyway, here's a quick overview:

sshfs username@remote.ip.addr.ess:/remote/directory /local/mountpoint

For a personal or family gallery, a backup/storage account with BQBackup, WebbyCart, etc. is probably all you need. They give you SSH access, so you can add a no-password public key to your account and use SSHFS to mount your backup directory. SSHFS tends to perform badly, but it's OK for small sites. The backup/storage service provider might become unhappy, though, if you move a lot of data all the time.

For more intensive use, you'll probably need a real VPS on the other side. I won't list specific companies here, as they're Linode's competitors. The cost per GB tends to be higher with VPSs than with backup/storage services, so expect to pay more. Whether or not you can use NFS (which is faster than SSHFS) depends on what the VPS host allows. OpenVZ hosts aren't as flexible with kernels as Xen hosts are. Cheap VPS hosts also tend to be somewhat less reliable than backup/storage services, even at similar prices per GB. (Backup/storage services don't need to invest as much in CPU and RAM.)

Whatever service you use, latency is the most important thing to consider. Remote filesystem access generates a lot of back-and-forth traffic, and even a latency of 30-40ms can drastically kill your filesystem performance. Never go for a server more than 10ms away from your Linode. And always remember you're burning up your bandwidth every time you access a remote filesystem.

The best option, of course, would be for Linode to provide cheap extra storage that can be accessed over the private network. Since it seems Linode is not willing to take that route, the second best option would be for someone to launch a storage service in some of the same datacenters that Linode uses. Perhaps they can cut a deal with Linode so that their services can be accessed over the private network.

Thanks for the overview - enough info to figure it out, not enough to get you or Linode in trouble - good work!

In this case, an advantage of S3 and similar services is that they can directly serve the files over HTTP, so you can include the S3 URLs in your web pages instead of proxying it through your Linode, and latency is only an issue for the initial upload.

_________________
Matt Nordhoff (aka Peng on IRC)

That can also be a serious disadvantage, depending on what you're trying to do. If you want to put your files behind a login, payment gateway, or some other form of access control, you'll probably need to proxy all of that stuff through your Linode anyway. You could, of course, use S3 with tokens that expire after a while, but that's probably going to require serious modifications to whatever app you're using. The OP clearly stated that he doesn't want to customize his gallery app.

Also, it's possible to serve your public files directly from any other server, if you follow the two-VPS trick that I described above. There's no difference between S3 and my two-VPS trick in that regard, and sometimes S3 costs more per GB.

Well I'm doing that as we speak. The last thing I'm going to be doing with this crummy EC2 micro instance is taking advantange of its location within the Amazon network to copy all of my gallery images/movies into an S3 bucket. Actually I have the copy operation currently underway and am watching it in a terminal window ...

Look for me pretty shortly to be writing a "Hello again, Linode!" thread as this EC2 micro experiment has ended miserably.