A few months ago, I started using Signal again. The messenger evolved quite a lot since I last used it, for instance, usernames weren’t even a thing back then, and this is mainly what drove me out of the platform.

But now that we have them, I feel a bit safer using it, knowing people don’t need my direct phone number to add me anymore. As a bonus, it’s now possible to import extended chat history when linking a desktop app, which is quite nice.

I recently got myself a bread maker. While I used to make the bread myself, the bread maker makes it even easier given I can just throw the ingredients in and forget about it. Since I got it, that poor thing has been running at least once a day (yes, I eat a lot of bread).

My go-to recipe is generally:

1. Add 236mL of water in the pot
2. Add 1.5 teaspoons of salt
3. Add 2 tablespoons of sugar
4. Add 2 tablespoons of oil
5. Add 405g of flour
6. Add 2 teaspoons of yeast
7. Set the program on “sandwich bread” (should be a 3h one)
8. There ya go

Pretty easy, right? The machine will knead, let it raise, then bake the bread all by itself, just don’t forget to let it cool for around an hour after it’s finished.

Just yesterday at the time of writing, GitHub (finally) released their public ARM runners for Open-Source projects.

This means you can now build ARM programs natively on Linux without having to fiddle with weird cross-compilation.

One way to achieve that is through a Matrix. Considering the following workflow to build, then upload an artifact (taken from the YDMS Opus workflow I wrote):

on: [push]

jobs:
  Build-Linux:
    name: Builds Opus for Linux
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Download models
        run: ./autogen.sh

      - name: Create build directory
        run: mkdir build

      - name: Create build out variable
        id: buildoutput
        run: echo "build-output-dir=${{ github.workspace }}/build" >> "$GITHUB_OUTPUT"

      - name: Configure CMake
        working-directory: ${{ steps.buildoutput.outputs.build-output-dir }}
        run: cmake .. -DBUILD_SHARED_LIBS=ON

      - name: Build Opus for Linux
        working-directory: ${{ steps.buildoutput.outputs.build-output-dir }}
        run: cmake --build . --config Release --target package

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: opus-linux
          path: ${{ steps.buildoutput.outputs.build-output-dir }}/**/*.so

We can now easily make it build for ARM by using a matrix referencing the new ubuntu-24.04-arm runner label.

As I often mention, I use .NET a lot in general, as it’s fairly easy to use, has a huge ecosystem, and has evolved really positively in the past years (long gone are the days of Mono :D).

Another component of this is that .NET projects are incredibly easy to build and publish using GitLab CI/CD.
Today, we’re gonna explore some ways of building and publishing a .NET project using just that.

Given sessions in Resonite are hosted by the players themselves, IPv6 is very useful in this context as there are no needs to battle with CGNAT or other network shenanigans and restrictions ISPs might put in place to save up on IP space.

As full native IPv6 support is currently being worked on (see GH-143 for a more in-depth status), some parts already do support it.

This is the case for: