A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.
Here are some exciting news from the BitBucket Pipelines blog: Bitbucket Pipelines now supports building Docker images, and service containers for database testing.
We developed Pipelines to enable teams to test and deploy software faster, using Docker containers to manage their build environment. Now we’re adding advanced Docker support – building Docker images, and Service containers for database testing.
Vidar Hokstad explains what systemd units are and how to write them. Very useful for that day when I will stop hating systemd and will try to embrace it.
Systemd has become the defacto new standard init for Linux-based systems. While not everyone has made the switch yet, pretty much all the major distros have made the decision to switch.
For most people this has not meant all that much yet, other than a lot of controversy. Systemd has built in SysV init system compatibility, and so it’s possible to avoid dealing with it quite well.
But there is much to be gained from picking up some basics. Systemd is very poweful.
I’m not going to deal with the basics of interacting with systemd as that’s well covered elsewhere. You can find a number of basic tips and tricks here.
Instead I want to talk about how to write systemd units.
CSV, or comma-separated values, is a very common format for managing all kinds of configurations, as well data manipulation. As the linked Wikipedia page mentions, there are a few RFCs that try to standardize the format. However, I thought, there is still a lack of schema-type standard that would allow one to define a format for particular file.
Today I came across an effort that attempts to do just that – CSV Schema Language v1.1 – an unofficial draft of the language for defining and validating CSV data. This is work in progress by the Digital Preservation team at The National Archives.
Apart from the unofficial draft of the language, there is also an Open Source CSV Validator v1.1 application, written in Scala.
“Living Without Atomic Clocks” is an interesting article that covers some design bits of distributed systems and CockroachDB (what a name!), especially those related to time precision. This part in particular is the one I’m sure I’ll came back to at some point:
How does TrueTime provide linearizability?
OK, back to Spanner and TrueTime. It’s important to keep in mind that TrueTime does not guarantee perfectly synchronized clocks. Rather, TrueTime gives an upper bound for clock offsets between nodes in a cluster. Synchronization hardware helps minimize the upper bound. In Spanner’s case, Google mentions an upper bound of 7ms. That’s pretty tight; by contrast, using NTP for clock synchronization is likely to give somewhere between 100ms and 250ms.
So how does Spanner use TrueTime to provide linearizability given that there are still inaccuracies between clocks? It’s actually surprisingly simple. It waits. Before a node is allowed to report that a transaction has committed, it must wait 7ms. Because all clocks in the system are within 7ms of each other, waiting 7ms means that no subsequent transaction may commit at an earlier timestamp, even if the earlier transaction was committed on a node with a clock which was fast by the maximum 7ms. Pretty clever.
Here are a couple of useful Bash resources that came upon my radar recently.
First one is Julia Evans’ blog post “Bash scripting quirks & safety tips“. It’s quite introductory, but is has a few useful tips. The one in particular I either didn’t know about or completely forgot mentioned recently is on how to make Bash scripts safer by using “set -e“, “set -u“, and “set -o pipefail“. These go well with another post of mine not so long ago.
The second is Sam Rowe’s blog post “Advancing in the Bash Shell“, which I found useful for all kinds of navigation and variable expansion in Bash command line. Especially the bits on searching and reusing the history.