In discussions about the infamous goto statement, people frequently point out that it's okay to use goto for error handling. The argument usually goes that without goto, you'd have to repeat your error handling code for each and every error condition that can occur, which would suck more than using goto. Both is wrong.
I'm currently debugging a little server I've written, and I wanted to see what happens if thousands of clients connect to it at once. I've also written a little client app that I can run pretty easily, both in Python. But how do I run it a thousand times in parallel while still keeping control in case they go rogue in some way?
I finally found a nice project that would give all my playing around with Arduino some focus. I've moved from standard boards to breadboard a while ago and I have a whole bunch of 'em, but didn't really know what to do with them. First and foremost, I didn't have an easy way to build a network of Arduinos -- and there's only so much to be done with a single one that can't really communicate to the outside world.
Fortunately, my employer is a company that builds embedded devices connected to a CAN Bus, and I decided to try and build one for myself. Such a network would then allow for a much wider range of interesting things to do. For starters, I'm going to control a Lego train — and I can even use my power supply for that!
So that's the idea. However, the "real" CAN bus seems to require a more complex hardware setup than seemed practical for reproducing across a set of breadboards, so I tried to find a way around that. The result: The Poor Man's CAN bus!
If you're running a VM cluster and regularly deploying new VMs, you'll have noticed that using a base image to build new VMs upon is just a fucking pain in the ass. It is indeed such a huge pain in the ass, that I had to spell this out three times in two sentences, just to clarify how much of a pain in the ass this is. Because you'll build the image, deploy it three times and notice that there's something you fucked up, that you'd like to change, and that gleefully involves just doing the whole thing over without fucking up anything else. Hence, you'll live with the buggy piece of crap because that's still easier than rebuilding the whole thing from scratch and you've got shit to do. At least, that's what I did. Until I got fed up with it and started building vmaker to get rid of the pain.
I finally got around to completing my power supply.
Yesterday evening, I enjoyed a nice game of Dishonored 2. After dealing with the Crown Killer in a non-lethal and somewhat stealthy way, I shut off my PC, went to sleep, and set to continue my endeavour tonight. When I started my PC and fired up Dishonored again, my PC completely froze. I hit the reset button, started Task Manager before starting Dishonored, and I discovered that Steam chose to completely smash my harddrive to pieces. Here's what I saw.
Dear future self, this is a little copy-and-paste tutorial on how to get postgres replication running using repmgr.
If you're working with Ceph, you'll find yourself updating the CRUSH map sooner or later. For that, you regularly need to get the current map, decompile it, edit it, comile it and upload it again. Here's a little script that makes this easier.