I’m writing most of my own tools in go. Sometime ago I found a tool called goreleaser which automates the release process of software written in go. goreleaser is pretty well documented, therefore this is just a quick overview how I use it. It will do the following things for you: Generate a changelog with the latest commit since the last release. Build artifacts for different architectures (Linux/Mac/Windows). Create a GitHub/GitLab release and attach changelog and artifacts....

I recently got active noise-cancelling headphones (Sony WH-1000MX4). They work just fine with my Android phone but on my Linux notebook I had a bit of a fight to get them working. I am running Arch Linux on most of my machines, so this post is written with Arch specific commands, but most of them (and the general idea) should also work on Ubuntu or Debian based distros. Keep in mind that older versions of PulseAudio and/or PipeWire may not have the features described here!...

I am subscribed to a lot of blog feeds, but (sadly) I don’t have enough time to read all of them. This is especially the case for rather long (but often interesting) posts. Therefore it would be perfect to save these posts and read them in the near future. There are already existing solutions for this like Mozilla Pocket. But as always I want to host this service on my own server (I have to justify the server somehow)....

As stated earlier I use a combination of technologies to run this blog. This blog is created with hugo (a static site generator) and uses the papermod theme. Additional technologies that are used: GitLab as git remote GitLab CI to build container images (development and production) Docker to run the images (development on my home server and production on a machine on the public internet) Watchtower to check for new images every ~5 minutes Caddy to handle TLS certificates (only for production) A VM on Hetzner Cloud used as a host for multiple containers GitLab At first the development and production hosts need access to the container registry....

I manage a few servers with some friends. We mostly rely on Terraform to update/change DNS records or create new VMs. Terraform use a state to store the last applied configuration of the managed infrastructure. The default location for this state is your local filesystem, but if you manage your infrastructure with multiple persons it must be shared. This can be problematic as it also contains secrets, like api tokens, so it should not be accessible for everyone....