Sure, there are enough of third-party binaries around, but if you are like me and you would like to avoid running binaries provided by random strangers on the internet, the best strategy is always to build from source.

And Signal Desktop is easy to build! You can even create an AppImage that contains everything you need to run Signal on your favorite flavor of Linux.

1. git clone https://github.com/signalapp/Signal-Desktop && cd Signal-Desktop
2. Checkout the release you want to build, e.g., git checkout v6.1.0
3. Edit package.json and add --linux AppImage to the end of the build:electron target
4. Run git lfs install
5. Make sure you have the correct nodejs version (requires nvm to be installed): nvm use
6. Make sure you have yarn: npm install --global yarn
7. yarn install --frozen-lockfile
8. yarn generate
9. yarn build
10. Copy the executable ./release/Signal-x.y.z.AppImage to wherever you want
11. Start with --use-tray-icon to have a nice tray indicator

Make sure to regularly check for new releases and rebuild your AppImage to stay up to date and secure.

Mozilla VPN is a VPN client developed by Mozilla. It is open source and uses WireGuard. It is available for Linux, Windows, Mac, Android, and iOS. To use it, you need to buy a subscription from Mozilla.

Building from source

As usual, Linux binaries are only provided for Debian-based systems. If you want to run Mozilla’s VPN client on e.g., Gentoo, you might want to build from source.

So cloning the repository is the first step:

git clone https://github.com/mozilla-mobile/mozilla-vpn-client

It uses git submodules, so we have to do

git submodule init
git submodule update

The project uses cmake, so it should be easy enough. In theory!

If you do not have rust installed yet, that is the time! Get the toolchain installer and run rustup default stable to get everything set up. Also, you need wireguard and its wireguard-tools installed.

Surprisingly, Gentoo’s Qt is currently too old (Qt6 is required by the vpn client) and even with the qt overlay and after unmasking a bunch of hard-masked stuff I was not able to produce a successful build.

So I figured that I had to compile Qt6 from source first. I was delighted when I found out that in the repository of the vpn client a script is provided for that exact purpose!

Building Qt6

How nice! So downloading and unpacking the qt6 sources and running

scripts/utils/qt6_compile.sh path/to/qt-everywhere-src-6.2.4 path/to/destination

should be all that is needed for that.

However, I learned that my cmake was not built with zstd support and I did not find a quick way to resolve that in Gentoo. So, I added the line

set(QT_AVOID_CMAKE_ARCHIVING_API ON)

in CMakeLists.txt of the qt6 sources and then everything was fine.

Update 2023-11

It seems that in some cases, qt6.6 has issues building and you might need to add

-skip qtspeech \

to scripts/utils/qt6_compile.sh

Building Mozilla VPN Client

First, we need to install the python dependencies:

pip install -r requirements.txt --user

Now we can use the compiled qt6 to configure the project:

mkdir build && cmake -S . -B build -DCMAKE_PREFIX_PATH=path/to/qt6/lib/cmake

If everything went well, we compile the vpn client:

cmake --build build -j$(nproc)

Finally,

sudo cmake --install build

installs everything to /usr/local including a .desktop file in /usr/local/share/applications, so you can start the tool conveniently.

Trickle

Trickle is a userland bandwith shaper that can be used to manage the bandwith usage of any userspace process (unless it is statically linked or setuid):

trickle -d 300 -u 300 firefox

starts firefox and limits it to 300 KB/s downstream and upstream.

Libvirt Virtual Machines

To limit the bandwidth usage of a whole virtual machine, we can use Libvirt’s QoS capabilities:

<bandwidth>
  <inbound average="300" peak="800"/>
  <outbound average="300" peak="800"/>
</bandwidth>

inside of the <interface> block of a virtual machine aims for an average bandwith usage of 300 KB/s with a maximum peak of 800 KB/s, each up- and downstream.

I mostly use this to upgrade one or more virtual machines in the background without disturbing other applications or video calls too much.

Two inconvenient solutions for this are:

1. Use interactive staging for each commit and make sure that this particular change doesn’t end up in the commit.
   Until I accidentally stage it at some point in time and discover that it made it into the upstream branch. Which, at least for me, is really just a matter of time.
2. Commit the fix to a dedicated branch, make the contributions on top of it and when ready, cherry-pick them into the target branch. Variations of this are working with an integration branch. This solution is a lot of juggling branches and commits around and will in the end break my running latexmk build.

Turns out this can be done elegantly with the filter functionality from git-attributes. With git filter you can automatically run two scripts: a smudge script when a file is checked out, and clean script when a file is checked in.

So in my case, I can define in .git/config what I want to happen:

[filter "fix-texlive2019"]
 smudge = sed '/^\\\\usepackage{amssymb}.*/d'
 clean = sed '/^\\\\usepackage{booktabs}/i \\\\\\usepackage{amssymb}'

While the escaping-hell looks a bit odd, these sed commands achieve exactly what I need: In my workspace, the \includepackage{amssymb} line will be removed (because it created a definition conflict with another package in my texlive version), whereas during a check-in, the line will be inserted right before the \usepackage{booktabs} line, which is the place where it was before.

Now we just have to assign the filter to tex files, which is done in .git/info/attributes:

*.tex filter=fix-texlive2019

Using this approach allows me to magically have my necessary changes, being able to compile the document at all times, without having to worry about accidentally committing the required local fix.

So an obvious solution is killing the process and running it in a newly created tmux session — but what if the process ran for a while and I don’t want to kill it because I either lose progress or end up in a mess? Instead of killing and re-running a process, it would be much smoother to just move it into a tmux session. This involves changing the parent of a process, which is not exactly trivial, but thankfully @nelhage made a tool for that: reptyr. If you’re interested in how reptyr actually achieves its goal, check out his blog posts[^1]¹!

As for usage, it is very easy:

1. Suspend the respective process with Ctrl-Z
2. Send the job to background using bg
3. Take away the ownership from the shell using disown
4. Start or enter your tmux/screen session
5. Run reptyr PID to attach the process to the current shell

It also has some additional useful features, such as TTY-stealing, which is documented in the man page.

Before compiling reptyr, make sure to check whether it is in your distributions repository. At the time of writing, this was at least the case for Gentoo, Fedora, and Debian.

Update (2023-01-05): ptrace scoping
A fellow Gentoo enthusiast noticed that on recent systems, the following error occurs when invoking reptyr as regular user:

Unable to attach to pid 1348999: Operation not permitted
The kernel denied permission while attaching. If your uid matches
the target's, check the value of /proc/sys/kernel/yama/ptrace_scope.
For more information, see /etc/sysctl.d/10-ptrace.conf

And this is how I learned about ptrace scoping, a feature that was added to the Linux kernel in version 3.4.

The problem:
In order to attach to a process, reptyr uses the ptrace system call, which is used to debug processes. In order to prevent unprivileged users from attaching to processes, the kernel has a feature called “ptrace scoping” which allows you to restrict which users and processes can attach to which processes. The value of /proc/sys/kernel/yama/ptrace_scope determines the scope of ptrace:

• 0: No restrictions, anything can be attached as long as the uids match.
• 1: Only the process owner and root can attach to a process. Also, some kind of relationship is required between the processes.
• 2: Only root can attach to a process.
• 3: No one can attach to a process.

On my Gentoo, it was set to 1 by default, which seems reasonable. As there is no relationship between the process I want to move and the reptyr process, reptyr is denied the permission to attach via ptrace.

So what can we do about this? I assumed that I could use the prctl system call to set PR_SET_PTRACER to PR_SET_PTRACER_ANY for the process I want to move. However, it seems that I can only set a tracer for the calling process, not for an arbitrary one, which I find rather annoying.

If somebody finds out how to do this, I would be glad to include it here instead of the following “dirty” workaround.

The workaround:
The only remaining option I found so far is temporarily setting ptrace_scope to 0 before invoking reptyr, which can be done by running sysctl -w kernel.yama.ptrace_scope=0. Note that this creates a security problem, as now all processes can be attached. For security reasons, I prefer to reset it to 1 right after the process has been re-attached.

I started by extracting the tar and generating checksums for each relevant file:
tar -xJf jdime-src.tar.xz && cd jdime-src
find src/ -type f -name \*.java -exec sha1sum {} \; > /tmp/sha1sums

/tmp/sha1sums now looked like this:

015bd1948789546e977266196fbea427b2eb64d1  src/de/fosd/jdime/merge/package-info.java
c8cdccd30d215fb955a9b0011a442d6a792cf91f  src/de/fosd/jdime/merge/MergeInterface.java
28722ec3fd2e280519cc4d9bdc97496f4ae57505  src/de/fosd/jdime/merge/UnorderedMerge.java
5c1b1082417790b853c9bb971cf22667ecc25274  src/de/fosd/jdime/merge/OrderedMerge.java
bc18227a8c63100bb5d97e9d5923e76df3d9eb46  src/de/fosd/jdime/merge/Merge.java
...

Next, I needed a way to look for the files in my git repository and find the right commit for each file (i.e., if there is one that matches the checksum).

I found this gist on github by mloberg, that I rewrote a little bit for my needs.
The result was this (also available as gist):

#!/bin/sh
# find-by-hash.sh

usage() {
 echo "Usage: $0 [-m] [-s] hash file"
 echo "\t-m use md5 for hashing"
 echo "\t-s use sha1 for hashing (this is the default)"
 exit 1
}

HASHCMD="sha1sum"

while getopts ":m:s" opt; do
 case $opt in
  m)
   HASHCMD="md5sum"
   shift
   ;;
  s)
   HASHCMD="sha1sum"
   shift
   ;;
 esac
done

CHECKSUM=$1
FILE=$2

if [ -z "$CHECKSUM" -o -z "$FILE" ]; then
 usage
fi

# Check if valid git repo
ROOT=$(git rev-parse --show-toplevel)

if [ $? -ne 0 ]; then
 echo "Not a valid git repo."
 exit 1
fi

cd $ROOT

# git revision for file
REVS=$(git rev-list --all -- $FILE)

# temp file
file_to_check=$(mktemp)

# check each revision for checksum
FOUND=""
for rev in $REVS; do
 git show $rev:$FILE > $file_to_check 2>/dev/null
 if $HASHCMD $file_to_check | grep -q $CHECKSUM; then
  FOUND="$rev"
  # intentionally no break to see if we find an older revision
  # insert a break if you want the most recent commit instead of the oldest
 fi
done

# cleanup
rm $file_to_check

# output
if [ -n "$FOUND" ]; then
 echo "$FOUND"
 exit 0
else
 echo "Not found: $CHECKSUM $FILE"
 exit 1
fi

The rest was easy: Executing the script for each line in /tmp/sha1sums reveals whether there is a matching commit in the repository in the format commit checksum filename:

> while read -r line; do echo "$(./find-by-hash.sh $line) $line"; done < /tmp/sha1sums | tee /tmp/results
6b14e2bf8eeaba3176c4e310c055cd4480e06ebd 8f2ebe7afe4b540516388763688675d8  src/de/fosd/jdime/merge/package-info.java
6b14e2bf8eeaba3176c4e310c055cd4480e06ebd bb5d89779398697f956d7f6d5e7d16b6  src/de/fosd/jdime/merge/MergeInterface.java
...

Let’s see how many different commits we’re dealing with:

> awk '{print $1}' /tmp/results | sort | uniq -c
     50 6b14e2bf8eeaba3176c4e310c055cd4480e06ebd
      1 a0ba24e5c0237d6cb1c394cbfadb9d9df895a410
      2 de655106866164efccd060b36064c8c6db87cb7a
      1 f2f5265f1dd666948962cdeb63e90d08c1cf322c

Great, this means each file was found in the exact version that it is in the tar! They’re just spread over 4 different commits, but that’s no big problem. What I wanted to do next was to create a commit that resembles the state of the tar, so I can put a tag on it and find it easily in the future.

The majority of files (50) is already in a single commit (6b14e2bf), so I used that as a base for the branch:
git checkout -b old-evaluation 6b14e2bf8eeaba3176c4e310c055cd4480e06ebd

So what about the 4 remaining files that are from different commits? Let’s just put them on top of our new branch:

for rev in $(awk '{print $1}' /tmp/results | sort | uniq -c | tail -n+2 | awk '{print $2}'); do
 file=$(grep $rev /tmp/results | awk '{print $3}')
 git checkout $rev -- $file && git add $file
done

All there was left to do was committing these changes and tagging the revision:
git commit -m ... && git tag -a ...

Therefore, I was surprised that update-alternatives --config python resulted in an error message:
update-alternatives: error: no alternatives for python

However, this is easily fixed by manually installing alternative entries: update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
update-alternatives --install /usr/bin/python python /usr/bin/python3.5 2

A higher number specifies a higher priority, which in this case results in python3 being the default from now on.

Sometimes I want to include a pdf or an image, e.g., a plot or a screenshot in a gist.
While this is not possible using the web interface, it can easily be done by operating on the gist directly with git (gists are git repositories):

git clone git@gist.github.com:HASH.git /tmp/mygist
cd /tmp/mygist
cp /path/to/plot.pdf . && git add plot.pdf && git commit -m "Add plot"
git push

Done :)

In my case, I had to limit the network usage of a zfs send/recv that was running over ssh, because the traffic was disturbing other processes who needed the bandwidth as well.

Turns out it’s easy with pv:
zfs send ... | pv -L 5M | ssh remote zfs recv ...
limits the pipe to 5M/s.

As an example, I show how I backup my ~/.mail (which is fetched by mbsync in maildir format).

Initialization

Before we can store our data, we have to initialize a restic repository:
restic -r sftp:user@remotehost:/path/to/storage/mail init
Restic will now let you set the encryption passphrase.

Backup

Now we can start our first backup operation:
restic -r sftp:user@remotehost:/path/to/storage/mail backup ~/.mail --exclude=".notmuch/" --exclude="*.mbsyncstate"
The exclude arguments in this example are used to avoid copying the state files of mbsync and the index created by notmuch.

Subsequent backups are issued the same way and are performed in an incremental way.
Each backup is represented by a snapshot in the restic repository.

List

List all snapshots:
restic -r sftp:user@remotehost:/path/to/storage/mail snapshots

Restore

If we want to restore a snapshot, we just retrieve the hash with the above command and issue a restore:
restic -r sftp:user@remotehost:/path/to/storage/mail restore HASH --target /tmp/restore-mail

Another convenient way to access the backups is the ability to use fuse mounts:
restic -r sftp:user@remotehost:/path/to/storage/mail mount /mnt/restic-mail

Read password from gpg-encrypted file

I usually don’t want to remember/type/paste my encryption passphrase, so let’s store it in a file encrypted with our gpg key.
Using bash process substitution (not /bin/sh compatible), we can then operate on our repository like this:
restic -p <(gpg -dq ~/.restic-password.gpg) -r ...
Now we just have to decrypt the password file using our gpg passphrase (or query a running gpg-agent process).
Note that with this approach, the encryption passphrase appears in the process list - so maybe don’t do this in multi user environments.

Scripting

If you want to trigger your backups with cron or systemd-timers, you might be looking for a way to automatically provide the encryption passphrase.
This can be done by storing the passphrase in the RESTIC_PASSWORD shell variable, but please make sure that’s really what you want to do.