One important point here: In the article the author says that the location of the database is /sdcard/WhatsApp/Databases. That's not entirely correct.
It only gets copied there when you use the build in backup feature (Settings -> Chat Settings). Else, it sits "safely" under /data/data/com.whatsapp/databases like every other Android sqlite database.
But nonetheless, WhatsApp was and is not really known for its safety...
Quick overview: They had a Nagios backdoor, which led to a leak of the customer database of their dedicated server administration console (Hetzner Robot).
They are not sure how it happened right know. External security experts are involved.
The customer passwords are SHA256 hashed (thank god!).
---
This one is really serious. With access to this admin console, you can wipe all dedicated servers with one single click. We advised Hetzer before to add more security (two-way authentication, etc.) to the console, but I think not much happened here...
Pilots now have iPads strapped to their legs. Or, that's what a friend of mine does. It really useful (with a dedicated pilot app, not Google Maps), but they always have a "real" GPS onboard for backup.
German bookstore Lehmanns, known for academic books, is selling Vi, Emacs, Linux, BSD and Latex reference mugs. They even got one with the number Pi and e on it.
Yes. But clients will understand this one better, with different known devices right in front of their eyes. Some of our clients can't map a resized browser window to a smartphone <-> tablet switch.
Definitely CynanogenMod. Probably (I haven't checked them all) the most complete and best testet Rom out there. Available for nearly every major Android hardware.
On the server side, it is ycombinator's decision if they can handle the additional cpu cycles. i believe they can, or else they wouldn't have enabled it.
on the client side, I don't think you can really feel the latency. is measurable, of course, but i don't think you can feel it.
At work, we use a shared Keepass file (Keepass is a password manager). We are only a small team, so this works out quite well. And this leads us to very secure (and different!) passwords for all our client servers and accounts, because getting and setting passwords is just a click away.
Private, I use a simple system where I have a 'master' password, which I augment with letters and numbers based on the domain name of the service. For example (not my system): A domain has 5 letters and a .com TLD, so I add the number 5 to the end and 'moc.' to the beginning of the master password.
You can easily expand this system for your needs. Works really well for me.