SudoAlex

The one problem they have is that the majority of their instances include local storage, which would make migration impossible. So the best they can offer is a reboot so the server ends up on another host.

They could potentially do this on their second generation (M3) instances, as well as micro instances if they wanted to. However I'd guess that these instances are just a small percentage of the overall servers used.

Beware of using DateTimeField for anything which uses DateMixin - https://docs.djangoproject.com/en/1.5/ref/class-based-views/...

You can end up in a weird situation with 404s due to timezone settings. Our timezone is set to Europe/London, the get_absolute_url method for any objects between midnight and 1am BST returns the result for the wrong day. The object will still be visible, just not at the expected URL.

If you're using dates for URLs, add an additional DateField, set it to editable=False, add something in save() which sets the date based on the datetime, and use the date field for your get_absolute_url method.

These days, I ensure any personal servers that I rent can be scripted as much as possible with ansible so I can do this myself - not just work servers.

If a new provider comes up with a great offer, I can place an order, run ansible, rsync the remaining data, change IPs, proxy any remaining services I need for a little bit and off I go!

Show no loyalty, get the best deal you can.

The original title should be kept somewhere on the comments page if possible, to show that the title was edited.

Example:

Vulnerability in ICMPv6 could allow Denial of Service (was: Ping of Death Reloaded)

Of all the alternatives I've tried today after The Old Reader's announcement (I've tried about 5 others, and quickly deleted my account from most of them) - this certainly feels like the best reader for me.

It's fast, blazing fast compared to the alternatives. The UI isn't perfect, but the speed certainly makes up for it.

I think the simple answer to this one is that it's a universal deployment tool. Like it or not, anyone who uses git can use it.

If I'm working on a Python project, I could possibly create a Fabric file to help automate the deployment. Anyone working on the same project would have to install Fabric, and figure out any quirks it has.

The same then applies to every other language. They tend to recreate deployment tools in their own language to solve the exact same problem. Capistrano for Ruby, etc. Everyone has to learn the deployment process for each different project.

Using git as a deployment tool means that the only person who has to worry about the deployment process is the one who creates the server side commit hook/push scripts. All the complexity is taken away, they just have to say "push to git@example.org" and all the magic behind it is taken care of.

It's universal between all projects. If I'm running a PaaS, all I have to tell my users is to put files in a specific place, add a config file, push to our servers. Without this, users of every language might need specific deployment tools, or be forced to use a generic one which might not suit their needs.

CoDeL is solution which has come out from all of this: http://www.bufferbloat.net/projects/codel/wiki - it can operate without any tuning, as it starts dropping packets when they start spending too much time in the queue.

Really wish the pricing was more reasonable, the costs are just too high.

£40/month for 80/20 FTTC, an additional £20/month to increase the data transfer cap to 250GB (could possibly get away with £10/month for 150GB, but I wouldn't want to risk it).

£60/month is just too much. I'd be willing to pay a small premium - but not that much of one.

This is one of the things which annoys me about AWS, and certain other providers which do a per GB cost on outgoing bandwidth.

We get around 50TB of data transfer per month from Linode, from having around $500/month worth of servers. The cost of using this much data with EC2 - around $5400 a month. It's not even close to being competitive.

I'm surprised this isn't mentioned more often.

If you've spent the hours learning to code, and even more time learning how to host your brand new app on a server... just spend that little bit of extra time to get those backups up and running - don't launch without it.

Your business could potentially be dead overnight without backups.

This doesn't just apply to the operations of your site, this also applies to every bit of data related to your business. Do you have backups of everything on your local machine? Do you also have backups in a remote location incase your local backup gets destroyed/stolen? If not then stop everything until you've put a plan in action.

Who needs backups anyway? Everyone does, unless you don't care about your data.

Use a queue processor - but that's probably going too far for simple email validation.

The simple work around - don't do it. This code is susceptible to Denial of Service problems similar to the URLField verify_exists option https://www.djangoproject.com/weblog/2011/sep/09/security-re... - a malicious SMTP server could tarpit all your SMTP connections from Django leaving your site with no workers to process other requests.

The email validation from an EmailField is designed to ensure that it could be a valid email address, not that it's a valid mailbox. Live with the limitation instead of trying to be too smart.

It feels like Nominet have tried to find a bunch of premium features which they can sell as premium for new domains, but which don't actually cost that much to maintain.

There's no real need for it.