Accepting a bad route from a peer and accepting a cryptographically signed bad route from a peer are the same thing.

How is this a fix again? How is security the issue here? It's not like someone snuck onto the internets and did something malicious, a provider with BGP peering agreements sent out bad routes that their peers didn't filter.

The problem is not something that additionally encrypting/signing messages will fix, it's a problem of network operators blindly trusting routes from their providers and passing them along.

The only fix here is for operators to properly filter routes from people they peer with. Period.

Great, just what we need. More corn subsidies.

I don't know the last time I looked at everything in stdio.h for problems so it's tough to say...

Things to avoid tend to be better indicators than things to go for. I'd avoid:

* Companies that aren't open about issues. If there isn't a public forum, status RSS feed, status twitter account, etc. BAD NEWS
* Companies that offer unlimited anything. By definition, unlimited means that they are overselling and while things may be great now, they'll suffer in the long run
* Linux hosts that don't give you SSH access. CPanel/Fantastico/Whatever do plenty of things, but there is no substitute for having shell access
* Anything at all that makes you feel funny. There are _plenty_ of options out there and if something doesn't feel right, you're better off going somewhere else.
* Companies that won't respond to you personally for pre-sales questions. When I was looking for colo space, this turned out to be the most important factor. The better they communicate with you before they have any of your money, the better off things will be in the long run.
* Anything that seems to be too good to be true. i.e. If you have a need for a lot of disk/bandwidth/cpu, and "unlimited" is $5/month, BAD NEWS

I run ithought dot org and host a reasonable number of sites, and try to adhere to all of the above. One thing you won't be able to find out easily with hosts is something I do: I won't accept customers that seem like they aren't a fit for the hardware I have. Shared hosting is what it is and if a customer is going to drive up the load on servers such that it affects other customers, but doesn't want to pay for dedicated hardware or a VM, their actions shouldn't hurt other shared hosting customers that are only using a very small amount of resources.

Most of the cloud stuff is plenty nice if you want to manage it (S3, SliceHost, etc) but don't underestimate what is involved with keeping server OSs up to date, tuned, and monitored. If you're core competency isn't tweaking server software you should let someone else worry about that for you until it makes sense for you to hire an Operations person/team.

I do have a job and I have used OpenVZ in a production environment :) Scrapped 2 machines running VMware ESX, put OpenVZ on them, and we can handle over 3x the number of Virtual Machines ("containers" in OpenVZ land) on the same hardware without paying the cost of VMware licenses. Highly recommended.

A +1 to ZenOSS from me. Quality product and commercial support is great.

Bunches of Linux servers (200+) running CentoOS, RHEL, CentOS, Gentoo, and a few others, all with recent versions of NTP, and all said something like:

Dec 31 18:59:59 aurora Clock: inserting leap second 23:59:60 UTC

when GMT rolled over.