Background

For years, I used Bareos, Bacula fork that was basically started for reason of "well, Bacula is too corporate and keeps the features in enterprise versions for years before putting it in community edition.

It was a very convenient system, as list of all backups of all my machines (half a dozen at home, half a thousand at work)

Over the years it came a full circle, with Bareos stopping to even support packages in Debian distribution. Main driving reason for initial install was "I can just install bareos client and get on with backing up my machine", and bareos looked to be the "community chosen" fork, but with time "just install the pacakge" was no longer true and only provided packages were snapshots of dev branch that were often buggy to the point of needing to occasionally restart the daemon when backups stopped working. It's "everything is a tape in disguise" approach was also problematic when trying to do anything but plain hard drive/tape backup

So I started looking for alternatives. There is no really good "enterprise" solution compared to bareos in OSS space, there is BackupPC but managing an Perl app that had last stable release in 4 years didn't looked like something I want to do in my free time. So I started to looking for alternatives

Rejected alternatives

I looked for something that could at least store data on S3 (due to ease of doing it on wider scale, and having cloud options if needed) and typical nice-to-haves of backup software like retention periods and ability to easily exclude files, preferably by means of just putting a file defining a dir/files to exclude

Borg backup

It's entirely fine and fitting. Sparse choice of storage backends removed it from the list

Syncthing

It's a great file synchronization tool; not designed for backups so it have light un-delete functionality; I already use it for sync but not exactly required feature-set for backups

Amanda

Just as with Bareos/Bacula, they are still in denial and pretend everything is tape. I used it some time ago and it was... okay but not something I was looking for. It also "decides for itself" when to make full or incremental based on storage which isn't exactly great when dealing with limited internet bandwidth..

Kopia

Lastly, the one most similar to Restic, Kopia. I test-drove the two for few months and my main take-away is restic is better for scripted backups while Kopia is better at "user UI first" approach. If all you need is to back-up few desktop machines, by all means just use Kopia, it does that excellent.

Why restic was chosen

• veru good cli support
• always-incremental snapshot approach after every backup
• fast enough (within single digit % compared to kopia)
• Supports mounting snapshot as FUSE (few others like kopia or borg support that too, unlike bareos)
• Backup encryption by client (supported by most backup applications above)
• Available in Debian repository (borgbackup and amanda are available, kopia needs external repo)
• Multiple key support - ability to have "master" key that can access every archive and per-host keys that host can use to restore itself

My recently-bought Behringer UMC204HD audio interface, that is advertised as 2 inputs, 4 outputs, presents itself to Linux as one stereo input channel and one 4.0 output channel:

 1pacmd list-sinks |grep -P 'name: \<|channel map' -C 1
 2...
 3    index: 2
 4	name: <alsa_output.pci-0000_00_1b.0.iec958-stereo>
 5	driver: <module-alsa-card.c>
 6--
 7	sample spec: s16le 2ch 44100Hz
 8	channel map: front-left,front-right
 9	             Stereo
10...
11pacmd list-sources |grep -P 'name: \<|channel map' -C 1
12...
13    index: 2
14	name: <alsa_input.usb-BEHRINGER_UMC204HD_192k-00.analog-stereo>
15	driver: <module-alsa-card.c>
16--
17	sample spec: s32le 2ch 44100Hz
18	channel map: front-left,front-right
19	             Stereo
20
21...

I'm guessing the reason is plain "we just use some generic USB ADC/DAC chip and reference implementation comes in that config".

That poses a problem for most voice communication software, usually putting stereo input into it means it will sum both channels up, and summing a channel with signal to channel with zero signal results in volume drop (-6db usually).

Some software is competent enough to auto-gain out of that problem, but most don't even have VU meter, let alone any indication of sound level you're sending to other participants of the conversation so it's easy to be too quiet in out of the box config.

So we need to split one device into two. We might still occasionally want the stereo input so I won't try to replace it with two mono ones.

Why change clock speed

So why you would want to change speed of your I2C interface?

You might just need to probe your sensors more often.

You might also want to get around long standing I2C stretching bug, which caused that by default I2C stretching on rPi I2C controller is disabled.

in this post we will look at how systemd handles dependencies and how they can be used to increase the robustness of the system, and also discuss potential pitfalls.

For the existing services all of the examples should be put in /etc/systemd/system/<service you change>.d/<override>.conf, as this way you will only override the things you change in unit, instead of editing whole unit file in /lib (and having your changes overridden on package upgrade).

Unless mentioned otherwise the dependencies are specified in [Unit] section

Setting up our editor (CLion, VS Code) to debug the STM32 ARM chips.

See Part 1 on how to connect to board and Part 2 on how to setup project and OpenOCD for compile and debug

Setting up project and programming our first piece of Rust code onto microcontroller (Part1)

Preparing build environment

After we finished the hardware setup in Part 1 we should have working openocd connection.

Rest of this series of posts will assume stlink or jlink debugger + Blue Pill board. There is variety of clones like these:

but legality of the software on the clones is at very best dubious. You can also just get a Nucleo board which contains debugger and small eval board all in one

We will also be using template graciously provided by Rust Cortex-M team. Make sure to use at least Rust 1.53 (tutorial is built on that version) and install cross-compile dependencies of rust and binutils-arm-none-eabi:

Setting up tooling and development hardware for Rust on the ARM (STM32 CPUs)

What hardware do we need?

• Dev board. Just about any will do, Blue Pill is pretty popular, other option is one of the STM32 Discovery boards that come with the programmer.
• Programmer/debugger - any of the ST-Link (or clones) will do, here we will be using ST-Link V2 clone. Really, anything supported by openocd is fine, altho some need some tweaking
• Power supply for a dev board - a lot of them just accept micro-USB connector

Most dev boards come with some example code, the barebones often just have LED blinking, but I've seen some that even output on USB.

The more sophisticated ones that have extra peripherals usually come with demo of them so you might want to plug them before doing anything else to have a look.

Git has very convenient feature called filters. What it basically allows to do is to pipe the content of a given file (decided by entry in .gitattributes thru external filter command.

The different hook points are on file checkout (so called "smudge"), check-in, and on diff.

Here are two useful cases for using it:

Formatting files on checkin

If your language have a formatter that just accepts stdin and outputs formatted file on stdout, like Go, it is very straightforward to add it:

1git config --global filter.gofmt.clean "gofmt"
2git config --global filter.gofmt.smudge "gofmt" # or "cat" if you don't want to filter incoming commit

then in either ~/.config/git/attributes or in repository itself under .gitattributes

1*.go filter=gofmt

Do remember that if used on repo where others don't use formatter regularly you might get a bunch of spurious formatting modifications during daily work.Especially with filter on checkout.