I also don’t think you’ve taken into account when happens when one needs to “scale” mysql past the confines of on server. You can add as much memory or CPU to a mysql box as you want but, in an optimal environment, the limitation will almost always disk I/O. An IT, developer, or otherwise thinking they can just “move to RDS” to solve their mysql scalability issues should rethink their situation — Amazon RDS garners little gain in I/O over a dedicated server. Except for small shops, without extended support for replication or other beneficial features, there is simply no benefit to migrate to RDS over simply understanding how to properly configure and deploy mysql within your own environment.

If my code are reusable (now that RDS is there), why won’t I move my apps to cloud and try get rid of my IT overheads (and the headache) ? Didn’t we outsource to India and China and focus on our core operations ? instead of being at the mercy of IT dept in US ? Thinks it as IT function outsourcing, while keeping the IS function in house (same as splitting design and Silicon fabrication functions in 80′s in Chip business)

So from Amazon’s (and all our) viewpoint it makes sense -
1) It lowers the entry barrier to users and developers to get into cloud.
2) It enables faster adoption of cloud, and thereby brings in investment to further stimulate cloud tech development (remember Ford had said -”..they can have any color as they want as long as it is black…” about model T, whose standardization had helped build economy of scale and helped the auto industry)

The argument against RDS would have been stronger if the above analysis had done a comparison on economics and argued from business and strategic angles, rather than speculating that my own backup would be much better than Amazon’s professionally managed data centers.

Sure RDS is relational db thinking, which is not the cutting edge, but it still has its role to play (assuming the RDS is much faster that SimpleDB, else RDS and SimpleDB has to compete with each other) Amazon should be careful against such possible internal conflict and canabalisation, and the RDS engineering team have to keep better latencies in RDS compared to SimpleDB, would be interesting to see how each team does that over next 3 years).
I am sure Amazon’s executive may have thought about such Darwinian strategy to stimulate tech development internally.

Compared to 10.4′s spotlight, 10.5′s a real pain. It’s so inefficient. At least this tip helps a bit!

Even the best cellular networks are multiplexed for voice, not data, and any congestion will result in significantly lowered priority for data. When you combine this, link-layer complexities (whether ATM or not), and that your VoIP Provider is “somewhere on the Internet” and not on the other side of a switched network, the statements in my post apply.

Folks can go back and forth over what’s possible but the fact remains, and I stated very specifically, VoIP over Cellular results in significant overhead and would negatively impact the network (whether it’s just your connection or the tower). Thus, mass adoption is impractical because no matter how hard you try, it’s putting a square peg in a round hole.

Overall, calling out ATT over this is an auspicious act to make something free which while profitable (mobile voice), isn’t free to provide. I’m not saying ATT isn’t a coward, however the suggestion that Voice over Cellular is practical is an implausible dispute for ATT’s network. The real issues are that ILECs are state-regulated monopolies, ATT’s cellular network is really crappy, and POTS is still the status quo for calls. Even if you fix the first and last issue, and even with the permission ATT has recently given app developers to allow VoIP over Cellular, their data network still sucks and so will your VoIP calls.

As far as absolutism – no – and um, who said Never?

As far as I’m concerned, practical includes reliable between two phones when traveling. Good luck with that with VoIP over Cellular.

Cellular data can carry VOIP calls and in such a way that quality doesn’t affect the outcome significantly enough to disrupt call. In the end you pay for what you get. You aren’t going to get the sustained level of quality via the cellular voice or landline networks.

I use the cellular data network all the time to make voIP calls.

Are you basing this on some biased absolutism?

Never say never – celluar data networks have come a long way.

Latency, speed and capacity are no longer the issues they were in cutting edge networks.

You probably drive a car back and forth from work every day, that car keeps you safe from amazing risks, and I bet you’re insured; but, if you weren’t driving a safe vehicle: a) you wouldn’t be insurable, and b) you could die easily. For this reason, automobiles are very safe, people trust them, and manufacturers are mandated to certain levels of safety and security standards. Fortunately, people don’t die when bank security is breached or software programs fail, but at the same time, nobody is liable either because the attitude you have — that just because others fail, nobody should be held to a higher standard. This is why I composed my post, to single out a company — if I had any evidence to single out others, I would. Most of the time though, that evidence is either kept confidential or may even be under gag order which is unfortunate to everyone whose personal data is exposed.

I think it’s good Heartland is doing end-to-end security but that’s really nothing special. Public key infrastructure has been around since before online banking was prevalent and it’s a technology that’s more than a decade old — Heartland has had over a ten years to implement end-to-end data encryption and they’ve waited until after their system was compromised. Sure, you could say such an upgrade prior to now would’ve been expensive, and you would be right — such levels of security should be mandatory and expected.

I also composed this post to support share holders’ actions and because the exploit was via SQL injection. Being vulnerable to SQL Injection is like leaving your car running with the windows rolled down. Moreover, end-to-end encryption doesn’t hinder SQL Injection attacks.

You can google more on “SSL TLS” to find out the history of security and how end-to-end encryption has been done for quite awhile now.

I suppose if Heartland wasn’t so loud with PR about how they’re catching up to 1999, I wouldn’t say anything. All things considered, 1 out of 601 is a start.

While I agree that better precautions need to be taken by all corporations who process data let’s not unfairly single out Heartland Payment Systems.