My Profile Photo

Sheogorath's Blog


Depending on the time of the day a friend, a colleague, a wise guy. The beauty of the world is its sense of humor to show humans their way by letting them search their own.


  1. Timeshift and its limits

    Today I learned that the backup tool Timeshift, which basically allows you to automatically take and manage snapshots of your filesystem, given you run BTRFS or LVM underneath, and provide an easy-to-use backup solution, is rather limited in its usefulness. It currently only supports the Ubuntu layout on BTRFS, which uses subvolume names called @ for / and @home for /home, which is not like distros like Fedora work. While this is not something Timeshift does wrong, it’s unfortunate for me as a Fedora user. …


  2. A/B-Upgrades are not enough

    Today I learned that A/B-Upgrades are not enough to make sure your setup is resilient from upgrade errors. What you actually need are A/B/C-Upgrades. A/B-Upgrades leave one possible error-case in the box, that is hard to counter: A broken Updater. While there are potential mitigations, such as checking the you can do a update dry-run on boot, to make sure you can in theory upgrade, if your upgrade process breaks in the last step (e.g. when writing your last bits to slot B) and you want to make sure you run all upgrades unsupervised, you can end up in a dead situation, where you can no longer rollback, since your update slot B is already overwritten, but unfinished. And you can’t write a new update due to the inability to finish the write process completely. One of the most straight-forward way to mitigate this problem is to provide an additional update slot, to create an A/B/C-Upgrade. Allowing your device at all time, to be able to update to a new version or rolling back to a version where upgrades have already successfully worked. An alternative would be of course to do a lot more excessive testing, and accepting the remaining risk. …


  3. FRITZ!Box link local fallback

    Today I learned that FRITZ!Boxes have an IPv4 link-local fallback address, in case a device doesn’t catch any DHCP configuration. According to the documentation a FRITZ!Box is also always reachable through 169.254.1.1. So if you device is ever configured using auto-IP and assigns itself an IP address from the IP range 169.254.0.0/16, you can easily reach your FRITZ!Box and enable DHCP, without the need to configure a static IP address. …


  4. Systemd and OOM

    Today I learned that Systemd will execute the equivalent of systemctl stop <service> when a process of your service runs OOM by default. This will mean that you might experience a downtime, when a OOM situation occurs even though your service might can handle it, when one of the processes is killed completely gracefully. You can adjust the behaviour by setting OOMPolicy in your service definition. …


  5. git blame ignore refs

    Today I learned that since git version 2.23 you can add a file to your repository to exclude large commits for e.g. format changes from your git blame. With the --ignore-rev as additional parameter, you can hide single commits for this specific blame call. More useful is the use of a --ignore-revs-file which can specify a file, that has a list of commits, similar to how .gitignore has a list a files to ignore. The standard name for this file appears to be .git-blame-ignore-revs. …


  6. Kubernetes default scheduler vs HPC

    Today I learned that the default Kubernetes scheduler is unsuitable for High-Performance-Computing (HPC) applications. HPC schedulers provide a variety of features, that easily become a rather complex constructs, including the ability to reclaim resources, reserve and backfill jobs, etc., compared to the simple scheduling algorithm that the Kubernetes scheduler provides. So given you want to deploy your HPC workload on Kubernetes it might be worth to look for a more advanced scheduler for your workload. …


  7. Mirroring to help license enforcement

    Today I learned that mirroring git repositories can help license enforcement. In legal cases a mirrored repository that the original authors have no access to, can help to proof that their git history is unchanged and can be used as evidence in the case, since the mirrored repository attests the authenticity of the original/upstream one. …


  8. Yarn and merge conflicts

    Today I learned that yarn can resolve merge-conflicts on its own. If your yarn.lock has a conflict during a local merge, just run yarn and the package manager will resolve the conflict in the lock-file for you. …


  9. Schroedinger's publish

    Today I learned that GitLab silently drops published NPM packages due to a wrong package prefix, while yarn publish thinks it successfully published a package to GitLab’s integrated NPM package repository. The key to solve it, is to prefix your package with the exact value of $CI_PROJECT_ROOT_NAMESPACE. For example, when your package is hosted under https://git.shivering-isles.com/sheogorath/node-markdown-spellcheck, your package has to use @sheogorath as package prefix, otherwise GitLab will silently drop it. …


  10. Nail violin

    Today I learned one can build a violin with nails instead of strings. The idea is as simple as genius. You take a block of wood, your violin bow, a few nails and a hammer. You take the nails and depending on how deep you drive it in, it’ll make a different sound, when you bow it. If you take a bunch of nails and a lot of time, you can make a well sounding violin which is fully playable. …