Cheap Computers, Know your tools, Python, Databases, testing, CBCrypt, SSH best practices

Post date: Apr 26, 2016 2:58:52 PM

• Quickly checked list of cheap hardware computers. But cloud is so cheap that running hardware systems just doesn't make sense, unless it's a hobby.
• Wow, once again. It's extremely important to know your tools in every detail. Almost committed a massive fail into one project. There was a bad bug, which I fixed with even worse one. Never read documentation and implement something based on it alone. First you have to write experimental code and verify how things ACTUALLY work, because most of documentation doesn't cover all possible edge cases. It's very important to know, what happens with certain special cases which aren't fully covered by documentation. I've just in a few months fixed tons of stuff like that. Which could well pass and get into production, unless there's extensive testing. Yet, this is one of the reasons why this kind of fails are just so common in software. Also because many of these fails are connected to locking and complex transactions, it's well possible that all normal unit tests pass with flying colors. Problems only arise, when transactions start to take a long time, due to excess load on system etc.
• Nice article, Python is the new BASIC (2008). Yep, that's just why I like it.
• Excellent presentation: - Torturing Databases for Fun and Profit | USENIX - Highly recommended reading if you're into databases. - Don't trust your database(s), those are broken. Yes. You just haven't noticed it yet. ACID? Yeah, so they claim, but that's not the truth. - Transaction isolation violation, durability and transaction recovery failures, ordering failures, etc. It's nice that they optimized the error spotting based on predictions instead of doing exhaustive search. Transaction is partially committed, great? What's the point of transactions then?
• Previous also applies to pretty much the rule I've found out. If you claim it's working, it's probably due to because you haven't tested it. If you start testing things properly, you'll be finding so staggering amount of issues that you might not want to do it after all. So, don't test, and you can honestly claim that it's working and there's no proof of things being otherwise. - Traditional testing methodology may not be enough for today's complex storage systems. Thorough testing requires purpose-built workloads and intelligent fault injection techniques. Well well. This applies directly to the second bullet point of this post. Everyone assumed that the code was working, and it almost was. But it could still overwrite already committed transactions with old data. Of course this only comes up very rarely, and can be hard to spot in most of cases.
• CBCrypt - Encrypt password on client side. There's no point to send clear text passwords to the server. Works also for authentication secrets and encryption keys. Yet CBCrypt 2.0 isn't anything special. It just uses PBKDF2 with Salt and SHA-256. It's basically what anyone should do anyway. It's just standardized way of doing it.
• SSH best practices - Nice post. Nothing new.