Jae's Blog

Making Bread

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.

Right now, I got a Point POBM400GS bread machine, but I wonder if I could modify it to add a small webcam and some simple thing that would just return how much time is left before the bread is ready.

Hell, bread machines seem so simple that we could probably even make an Open-Source one.

Watch out for the bread Grafana dashboard.

Using the new GitHub ARM runners

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
Code language: YAML (yaml)

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

For instance, we can add this before the job steps:

    strategy:
      matrix:
        osver: [ubuntu-latest, ubuntu-24.04-arm]
Code language: YAML (yaml)

Then change the runs-on configuration to specify ${{ matrix.osver }} which will create jobs for all the OS versions specified in the matrix.

One issue that might then arise is a name conflict when uploading the job artifacts. For instance, if our old Linux build uses:

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

And the same step is used by the ARM workflow, we will get an error that the artifact matching the name opus-linux already exists for this workflow run.

This is where a small conditional step can be added to set an environment variable with the desired name:

      - name: Set dist name
        run: |
          if ${{ matrix.osver == 'ubuntu-24.04-arm' }}; then
            echo "distname=opus-linux-arm" >> "$GITHUB_ENV"
          else
            echo "distname=opus-linux" >> "$GITHUB_ENV"
          fi
Code language: YAML (yaml)

We can then change our artifact upload step to use these new names:

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: ${{ env.distname }}
          path: ${{ steps.buildoutput.outputs.build-output-dir }}/**/*.so
Code language: YAML (yaml)

As a bit of a sidetrack, you can also use checks like this to conditionally skip (or execute) steps depending on the architecture, using a if statement:

      - name: Mystep
        uses: actions/myaction@v4
        if: ${{ matrix.osver != 'ubuntu-24.04-arm' }}
        steps: |
          echo Hello world
Code language: YAML (yaml)

In the end, it’s good that this GitHub feature finally landed. Before that, you had to use “large” runners which can cost quite a bit in the end.

Building .NET using GitLab CI/CD

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.

Docker

Probably the most straightforward, considering a simple Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
COPY . ./builddir
WORKDIR /builddir/

ARG ARCH=linux-x64

RUN dotnet publish --runtime ${ARCH} --self-contained -o output

FROM mcr.microsoft.com/dotnet/runtime:9.0

WORKDIR /app
COPY --from=build /builddir/output .

RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    && rm -rf /var/lib/apt/lists/*

HEALTHCHECK CMD ["curl", "--insecure", "--fail", "--silent", "--show-error", "http://127.0.0.1:8080"]

ENTRYPOINT ["dotnet", "MyApp.dll"]

Code language: YAML (yaml)

Note: this assumes your app builds to MyApp.dll and has a healtheck endpoint on http://127.0.0.1:8080

Then building the container image itself is really easy:

stages:
  - docker

variables:
  DOCKER_DIND_IMAGE: "docker:24.0.7-dind"

build:docker:
  stage: docker
  services:
    - "$DOCKER_DIND_IMAGE"
  image: "$DOCKER_DIND_IMAGE"
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - docker buildx create --use
    - docker buildx build
      --platform linux/amd64
      --file Dockerfile
      --tag "$CI_REGISTRY_IMAGE:${CI_COMMIT_REF_NAME%+*}"
      --provenance=false
      --push
      .
    - docker buildx rm
  only:
    - branches
    - tags
Code language: YAML (yaml)

This will build, then publish the image to the GitLab container registry of the repo. It’s possible to also specify a different registry, but kinda useless as the default one is already excellent for most cases.

Regular build / NuGet build

This type of build just requires source itself without much additional configuration.

It will build the software, then either upload the resulting files as an artifact or publish it into the GitLab NuGet registry.

For those two, I can recommend setting up a cache policy like:

cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
  paths:
    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json'
    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*'
    - '$NUGET_PACKAGES_DIRECTORY'
  policy: pull-push
Code language: YAML (yaml)

And a small restore snippet:

.restore_nuget:
  before_script:
    - 'dotnet restore --packages $NUGET_PACKAGES_DIRECTORY'
Code language: YAML (yaml)

You can also directly specify the build image that you want to use at the top of the CI definition file with, for instance:

image: mcr.microsoft.com/dotnet/sdk:9.0
Code language: YAML (yaml)

The regular build with artifact upload is also really easy:

build:
  extends: .restore_nuget
  stage: build
  script:
    - 'dotnet publish --no-restore'
  artifacts:
    paths:
      - MyApp/bin/Release/**/MyApp.dll
Code language: YAML (yaml)

In this case, we use ** to avoid having to update the path every time we upgrade the .NET version (for instance, .NET 8 will put the build in the net8.0 directory, .NET 9 in net9.0, etc).

Now, we can also build and publish the solution to the NuGet registry:

deploy:
  stage: deploy
  only: 
    - tags
  script:
    - dotnet pack -c Release
    - dotnet nuget add source "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text
    - dotnet nuget push "MyApp/bin/Release/*.nupkg" --source gitlab
  environment: $DEPLOY_ENVIRONMENT
Code language: YAML (yaml)

As seen in this definition, this publish stage will only run on tag pushes, but it’s also possible to generate a version string with the current commit and pushing this as a nightly release.

As an additional step, but not really related to the build itself, I often activate the Secret, SAST and dependencies scanning as it can prevent really obvious mistakes. Doing so is also really trivial:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
Code language: YAML (yaml)

In the end, building .NET is extremely trivial.

The state of IPv6 in Resonite

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:

The main website:

; <<>> DiG 9.20.4 <<>> AAAA resonite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42354
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;resonite.com.                  IN      AAAA

;; ANSWER SECTION:
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:4001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:2001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:5001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:6001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:1001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:3001
resonite.com.           300     IN      AAAA    2606:4700:3030::6815:7001

;; Query time: 16 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Tue Jan 14 17:44:41 EET 2025
;; MSG SIZE  rcvd: 237Code language: CSS (css)

The assets server:

; <<>> DiG 9.20.4 <<>> AAAA assets.resonite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41689
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;assets.resonite.com.           IN      AAAA

;; ANSWER SECTION:
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:4001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:3001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:7001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:2001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:1001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:5001
assets.resonite.com.    300     IN      AAAA    2606:4700:3030::6815:6001

;; Query time: 16 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Tue Jan 14 17:44:12 EET 2025
;; MSG SIZE  rcvd: 244Code language: CSS (css)

The API:

; <<>> DiG 9.20.4 <<>> AAAA api.resonite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1091
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;api.resonite.com.              IN      AAAA

;; ANSWER SECTION:
api.resonite.com.       91      IN      CNAME   skyfrost-api.azurewebsites.net.
skyfrost-api.azurewebsites.net. 120 IN  CNAME   waws-prod-am2-757.sip-v4andv6.azurewebsites.windows.net.
waws-prod-am2-757.sip-v4andv6.azurewebsites.windows.net. 91 IN AAAA 2603:1020:206:6::24

;; Query time: 26 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Tue Jan 14 17:46:08 EET 2025
;; MSG SIZE  rcvd: 183Code language: CSS (css)

The site status.yellowdogman.com also has out-of-the box IPv6 support.

Some others have to be setup manually (as per GH-3232) via the hosts file or other user-run DNS servers, with:

  • wiki.resonite.com
  • metrics.yellowdogman.com
  • go.resonite.com

To access those domains over IPv6, you will need to amend your /etc/hosts or C:\Windows\System32\drivers\etc\hosts with the following:

[2a01:4f9:2b:2b4a::2] wiki.resonite.com
[2a01:4f9:2b:2b4a::2] metrics.yellowdogman.com
[2a01:4f9:2b:2b4a::2] go.resonite.com
Code language: CSS (css)

Edit: those AAAA records are now added!

Joining any session using a network string like lnl://[<IPv6 address>]:<port>/ is already supported, which only leaves the relays and bridges needing IPv6 support, a mod made by a community member already existing to solve this issue until official support is added.

In the end, I’m very confident that we will see full native IPv6 support land in Resonite this year, if not already in Q1, given this is actively being worked on.

Once those those two issues (relays and bridges + AAAA records missing) are addressed, the only thing missing IPv6 will be… the bug tracker, GitHub, which I already talked about in this article (spoiler, we ain’t seeing IPv6 from them anytime soon).

Also special thanks to ProbablePrime for looking into it!

The making of the Resonite sessions Discord bot

If you are a Resonite player and are in the Discord guild, you might be familiar with the #active-sessions channel, in which a bot displays the 10 most popular sessions on Resonite as well as some stats.

Screenshot of Discord showing game stats as well as an embed for a single session at the bottom.

What you might not know, is that I’m the author of this bot, that I originally started as just a small oneshot project to have some fun.

For some background, when Neos was still a thing (technically still is, but in what state), a bot like this was in the Discord guild, showing sessions and game stats like server metrics and session counts.

When Resonite was released, the channel was there, however, no metrics or posts were ever made, saying that the bot would be revived at some point in the future(TM).

At the time, I was a bit bored and wanted a new project, so I decided to start experimenting with .NET Discord bots and in term set myself the objective to re-create the original bot.

Why .NET? One reason being that I use .NET all the time as it’s fairly easy to use, the other one being that most of the Resonite community also knows .NET due to being used to make mods and whatnot.

The bot itself is fairly simple and divided in multiple parts built around the .NET Hosted Services:

  • Discord client service – handles the connectivity to Discord
  • Interaction service – provides the command handler for the few commands the bot has
  • Startup service – sets up some bot must-haves like the logger and other data
  • Message service – the core functionality of the bot that runs all the logic that makes the magic happen
  • Healthcheck service – this one is optional, but important when hosting the bot in Docker

Let’s go through all of those in detail and see why they were made that way.

I’m gonna group those together as they belong to the same component really: handling Discord-related shenanigans.

The bot has a few commands:

  • /info which shows some info about the bot
  • /setchannel which sets the channel in which you want the notifications
  • /which which shows which channel is set as the notification one
  • /unregister which unsets the notification channel
  • /setting allows you to toggle some settings like if you want thumbnails or not

All of those commands (with the exception of /info) are admin-only.

This part is honestly fairly boring and straightforward, the rest just passes a Discord bot token, connects to the chat service and tries to log in.

        await _client.LoginAsync(TokenType.Bot, token);
        await _client.StartAsync();
Code language: C# (cs)

The message service

Now this is the juicy stuff.

This part handles:

  • Retrieving the info from the Resonite API
  • Formats it neatly into a message
  • Generates embeds from the session info
  • Storing which messages were sent where in a DB
  • Checking if messages can be updated
  • Updating said messages with the new data

First off, the bot uses a relatively simple SQLite DB to avoid everything being hardcoded. The first versions were using direct channel IDs, but this is far from ideal if you want something modular without having to host multiple copies.

The DB basically stores the guild ID, channel ID and settings for the bot to send the updates in the right place, containing what we want.

Speaking of settings, there is only one so far: show the session thumbnails or not. The reason for this is a difference between the Discord & Resonite ToS. While nipples aren’t considered sexual on Resonite, they are on Discord, meaning having a session thumbnail showing nipples on Discord without gating the channel to 18+ users would be violating the ToS of the platform.

One thing I am quite proud of is how stable the bot it, nowadays it rarely, if ever, crashes alone, which it used to do quite often.

The bot is made to handle errors gracefully and never shut down or crash the program unless something really, really warrants it. When running this bot, all the errors that would normally crash it are instead logged with an error message and stacktrace to make it easy to debug.

Another thing to note is that the database schema hasn’t been updated since the bot basically released and touching it is considered a very last resort thing. Having the DB break during an upgrade would be disastrous, requiring all admins to re-set the notifications channel. As they say, if it ain’t broken, don’t fix it.

Out of all the variables in the mix, Discord is the most unstable one, having lots of outages, sometimes lasting hours at a time, just being slow for no reason whatsoever or thinking existing things (such as channels or messages) don’t exist even though they do.

This is why the whole checking logic exists, it will first check if the channel exists, if it does will check if the message exists, and if it does, try to update it. If it fails at any point, it will try again for a while then delete the message, try to re-send it, and ultimately, if this fails, delete the channel from the DB and the admin will have to re-set the notification channel again.

The re-try was implemented after some issues raised from Discord:

  • The bot would forget about the message (because Discord said it didn’t exist anymore) and would send a second one in the same channel or over and over until restarted
  • Sometimes the checks would fail on first try and delete everything gracefully without notifying anybody
  • Bot would crash because everything “ceased” to exist

On the Resonite side, if an error happens while contacting the API, the bot will just skip this cycle and try updating the next time (one minute by default). This used to crash the bot (whoops) in the early days.

The latest addition made was the Docker healthcheck, given recently the bot crashed in the main Resonite guild (GH-3521) and no monitoring was triggered.

Now the bot has a small HTTP server running, simply returning the date that a curl instance will check every 30 seconds.

The CI/CD

It’s no secret that I love GitLab as a software. I also work daily on and with it in my day-to-day job.

The CI/CD used in this project is extensive, but classic:

  • Secret detection
  • SAST scan
  • Dependency scanning
  • NuGet build
  • NuGet deployment
  • ARM64 and x86 Docker builds
  • Release publishing

The first three are kinda explicit, and will warn if any secrets have been pushed, if any unsafe codepaths are detected or if any dependencies needs updating.

Now the most important thing to highlight are the separated Docker builds for the two architectures. I originally tried combining the builds into a single one as you would do by specifying multiple architectures in buildx, however this did not work.

An error when building ARM on x86 (with virtualization) and vice versa would always arise, though the same command would work for other projects.

To avoid errors when doing things manually, the release process is also automated, triggering when a tag is detected. It will basically build as usual with the version tag and then publish the release following a markdown template. It will also automatically fill-in some details like image tags, etc from the changelog.


Fun fact, the bot is Open-Source under the MIT license, meaning you are welcome to host your own version.

Some stats about the project so far:

  • 47 pull requests merged
  • 97 commits (PRs are squashed)
  • 16 releases
  • 6+ months of existence
  • 10k (roughly) of users served in the Resonite Discord alone
  • Way too many hours sunk into overengineering this

What’s to come? Nothing much really, this bot has basically achieved its goal of having the active session list published somewhere.

The project is basically in maintenance mode, housed under the Crystalline Shard development group which I am one of the founders.

Now for the self-criticism: if I had to restart the project from scratch, I would probably opt into an even less complex design. Some services are really huge files that only increased in complexity with time.

Currently nothing too bad, but I think a refactor would be warranted to decrease complexity and make it more maintainable.

I wouldn’t touch the language though, since the bot’s footprint is really small, only about 30Mb to 50Mb of RAM used total during normal runtime.

In the end, this bot is a really fun project to make and maintain, and I’m extremely happy that it got canonized and used in an official manner.

For a quick roadmap:

  • GL-33 have someone completely review the codebase
  • GL-39 disable unneeded intents for the bot (on hold for evaluation)
  • GL-48 solve a mystery crash that randomly happens… sometimes

Let’s see in about 6 more months to see how everything evolved with even more bugs being squashed.

Deploying Hugo using GitLab pages

It is 2025 and it’s still super easy to deploy a blog using Hugo and GitLab pages.

In fact, the post you are reading right now is exactly that, deployed on my self-managed instance.

But Jae, weren’t you on another host beginning from last year?

Yes, last year I switched to Mataroa for the ease of mind the platform has.

The interface is very clean, has no bullshit whatsoever and is made and hosted in small web fashion.

Sadly, it has one caveat that was underlined once again by @miyuru@ipv6.social on the Fediverse (ironically under my post about GitHub and its lack of IPv6): no IPv6.

This is why today I moved back my blog on something I used to have a long time ago, a GitLab pages site generated by Hugo.

Actually implementing it was as easy as I remembered:

  1. Create a new Hugo project
  2. Add the CI config file
  3. Move my domain’s CNAME
  4. Wait for Let’s Encrypt to do its work (funnily enough this was the longest part)
  5. Tada, all done

The Hugo setup itself is fairly easy, so is the CI file:

default:
  image: ghcr.io/hugomods/hugo:ci-non-root

variables:
  GIT_SUBMODULE_STRATEGY: recursive

test:
  script:
    - hugo
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH

deploy-pages:
  script:
    - hugo
  pages: true
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production
Code language: YAML (yaml)

The main difference from years ago is that now, we have fully-featured (and maintained) Docker images for Hugo, the one being selected in this instance being ghcr.io/hugomods/hugo, maintained by HugoMods.

So now, enjoy all the posts over IPv6 \o/

GitHub and IPv6 in 2025

In this year 2025, the main GitHub domain still doesn’t serve over IPv6.

Some subdomains do have IPv6 though, just… not what you would expect.

For instance, avatars.githubusercontent.com:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> AAAA avatars.githubusercontent.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18015
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;avatars.githubusercontent.com. IN      AAAA

;; ANSWER SECTION:
avatars.githubusercontent.com. 159 IN   AAAA    2606:50c0:8002::154
avatars.githubusercontent.com. 159 IN   AAAA    2606:50c0:8001::154
avatars.githubusercontent.com. 159 IN   AAAA    2606:50c0:8003::154
avatars.githubusercontent.com. 159 IN   AAAA    2606:50c0:8000::154

;; Query time: 32 msec
;; SERVER: 2a09::#53(2a09::) (UDP)
;; WHEN: Wed Jan 08 04:55:56 UTC 2025
;; MSG SIZE  rcvd: 170Code language: CSS (css)

Whereas none of the other domains accessed when accessing github.com (named github.com, github.githubassets.com and alive.github.com) has IPv6.

The package registry ghcr.io as well doesn’t support IPv6:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> AAAA ghcr.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 967
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 29: (Result from negative cache)
;; QUESTION SECTION:
;ghcr.io.                       IN      AAAA

;; AUTHORITY SECTION:
ghcr.io.                547     IN      SOA     ns-773.awsdns-32.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 32 msec
;; SERVER: 2a09::#53(2a09::) (UDP)
;; WHEN: Wed Jan 08 04:57:35 UTC 2025
;; MSG SIZE  rcvd: 152Code language: CSS (css)

And so does gist:

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> AAAA gist.github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52139
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gist.github.com.               IN      AAAA

;; ANSWER SECTION:
gist.github.com.        1019    IN      CNAME   github.com.

;; AUTHORITY SECTION:
github.com.             182     IN      SOA     dns1.p08.nsone.net. hostmaster.nsone.net. 1656468023 43200 7200 1209600 3600

;; Query time: 32 msec
;; SERVER: 2a09::#53(2a09::) (UDP)
;; WHEN: Wed Jan 08 04:58:11 UTC 2025
;; MSG SIZE  rcvd: 123Code language: CSS (css)

So yeah, years later, always the same excuse, and no support at all.

I played Star Citizen so you don’t have to

Star Citizen is a game that has been in development since around 2013.
It claims to be a space simulator, MMORPG, FPS and a bunch of other things.

More than 10 years later, 750 million USD invested, what have we got?

The good

The game looks visually good, even if overly generic “space stuff”.

Nothing much else to say on that point, the ships have real thought put in their design, starting environment seem to be somewhat consistent and hand built (tho I noticed there are really a lot of food shops everywhere for some reason).

There is also a good already existing selection of ships, all having their own stats and benefits, which you can also upgrade.

The bad

Not a single of my sessions was what I would call a good experience.

From server crashes, game crashes, contracts items magically disappearing during loading, contracts themselves disappearing after a game crash, ships going through the floor, getting kicked out of your ship for no reason at all and having a fine, the list just goes on.

As of now, the game feels like any Unreal Engine asset flip of a “space stuff” game.

The game is mostly empty, contracts get repetitive really quickly, you can barely talk to any NPC and despite having those, you have to shop using touchscreens (which barely work if the server is a tad laggy).

Nothing in the game is really explained, it feels like there is feature creep even though no single feature is actually finished and in a working state.

The performance is also a huge issue, never going above 45fps, even when no players are around (and it goes without saying my computer specs blows the minimal ones out of the water).

The ugly

The game itself requires putting on the table at least 50€ to get into, the more expensive starter pack being at more than 1300€ as of time of writing.

In normal times, I wouldn’t have an issue having a store where you can buy things to support the development of a game, however, we’re talking about one that is possibly one of the most expensive game of all time, where in the end, there barely is a game.

The fact that if you lose in-game something you bought with real money for 250€, you lose it permanently, is also the cherry on top.

They also use the “we are in development” as a shield to deflect any criticism of the game, which honestly cannot be done when talking about a game having this much money poured into it and already that much development time.


So, conclusion: don’t waste your money.

Star Citizen is a game that will continue with its unscoped development and probably will never release in a stable or playable form anytime soon, if ever.

It’s an already seen tale of a game too ambitious to be done in one go, with developers trying to do it anyway.

I’ve seen Bethesda games with fewer bugs.

Happy new year, btw.

Jae 2012-2025, CC BY-SA 4.0 unless stated otherwise.