Since I had used alpine images, linking against libmusl was a reasonable choice, but that meant this hack would be limited to libmusl-based images.

I have since found a way to generalise this to work with any flavor of libc:

// getrandom_shim.c  — no libc dependency
#include <sys/syscall.h>
#include <stddef.h>

static long sys(long n, long a, long b, long c) {
    long r;
#if defined(__x86_64__)
    register long r10 asm("r10"); // unused here
    asm volatile("syscall" : "=a"(r) : "a"(n),"D"(a),"S"(b),"d"(c)
                 : "rcx","r11","memory");
#elif defined(__aarch64__)
    register long x8 asm("x8")=n, x0 asm("x0")=a, x1 asm("x1")=b, x2 asm("x2")=c;
    asm volatile("svc 0" : "+r"(x0) : "r"(x8),"r"(x1),"r"(x2) : "memory");
    r = x0;
#endif
    return r;
}

long getrandom(void *buf, size_t len, unsigned int flags) {
    (void)flags;
    long fd = sys(SYS_open, (long)"/dev/urandom", 0 /*O_RDONLY*/, 0);
    if (fd < 0) return -1;
    long n = sys(SYS_read, fd, (long)buf, (long)len);
    sys(SYS_close, fd, 0, 0);
    return n;
}

We now have to add -nostdlib to the compilation command, but musl-dev is still needed for the syscall headers:

docker run --rm -v "$PWD":/src -w /src alpine:3.19 sh -c \
  "apk add --no-cache gcc musl-dev && gcc -shared -fPIC -nostdlib -O2 -o getrandom_shim.so getrandom_shim.c"
chmod 644 getrandom_shim.so

And now we can use the getrandom_shim.so for any images, regardless of what style of libc they use.

On that note, this follow-up post answers whether this hack is still in place.

After half a decade the zipper on my trusty backpack has failed. No surprise there, I had been travelling for 10s of thousands of KMs with the thing by Airplane, Train, Buses, Car, Motorcycles and on Foot and have used (and abused) it to hell and back.

The options were having it repaired, but that would have either involved sending the thing halfway across the globe (and getting a replacement v2 variant in the end) or repairing it here locally, I had even started to look into possible replacement parts and their specs. But that would have set me back more than half of the cost of a brand-new backpack.

Instead I then took this as an opportunity to upgrade to the Peak Design 45L Travel Backpack, which solves several issues I had with the old one, like the straps, the luggage pass-through and the small volume. On the other hand this also means I now have to optimise my gear and packing procedure again from scratch (which isn’t necessarily a bad thing, but additional effort)

Motorcycle CarPlay Display

After two seasons of riding with the cheap CarPlay display from China (that was supposed to be weather-proof) the pixels in the display got stuck. This was fine but sometimes the backlight cut out, making it impossible to read directions.

By recommendation of a friend of mine, I replaced it with an Elebest C650, which is solves several of the issues I had with the first device:

• The screen is high-res enough that you can’t make out any pixels by eye and way brighter

• Media Playback does only resume on connect if there is an app actively in memory and has an open media session

• The display is mounted in a cradle and can be removed

  This one is also supposed to be weather-proof, but instead of verifying this I can remove the display over the winter.

Gloves

During the Wiesbaden Trip I got cold and bought warm Reusch Driftice gloves, I’ll keep my Rukka Viriums but then for warmer weather.

Officially Coolify supports Azure, BitBucket, GitLab and Google OAuth providers. While not explicitly mentioned in the docs, it supports a few more (Authentik, Clerk, Discord, Infomaniak and Citadel).

But mine (PocketID) unfortunately isn’t on the list and all the providers differ in their implementations in minute details, like data structures or URL schemas.

Fake Clerk Proxy

An hour of back and forth with Claude later, Clerk was made out to be the closest match to PocketID. All that is needed is a small proxy that rewrites a few urls:

:80 {
    log {
        output file /var/log/caddy/access.log
        format json
    }

    @authorize path /oauth/authorize
    handle @authorize {
        uri query scope openid+email+profile
        redir {$POCKETID_URL}/authorize?{query} 302
    }

    rewrite /oauth/token    /api/oidc/token
    rewrite /oauth/userinfo /api/oidc/userinfo

    reverse_proxy {$POCKETID_URL}
}

Combined with a small Dockerfile:

FROM caddy:2-alpine
ENV POCKETID_URL=""
COPY Caddyfile /etc/caddy/Caddyfile
EXPOSE 80
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -q --spider http://localhost/ || exit 1

Custom Claims

Coolify expects additional Claims from “Clerk” that PocketID does not provide by default, using a custom User Group that injects these hardcoded values we can fake it.

email_verified = true
user_id = pocketid-user

The actual values don’t matter, Coolify merely expects them to be set and then ignores it. Users are matched by their email address.

Configure Coolify OAuth

Once deployed and running, the “Clerk” OAuth can be configured as usual and the Base URL/Authentication Endpoint pointing to the “Clerk” Proxy.

PocketID being Passkeys-only is considered safe, but the old Username/Password login is vulnerable to brute-force attacks. To prevent this we add a redirect in the Server Configuration -> Proxy -> Dynamic Configurations we add a file called login-redirect.yaml (Don’t forget to replace {coolify-host} with your domain):

http:
  middlewares:
    redirect-to-clerk:
      redirectRegex:
        regex: "^https://{coolify-host}/login$"
        replacement: "https://{coolify-host}/auth/clerk/redirect"
        permanent: false

  routers:
    coolify-login-redirect:
      rule: "Host(`{coolify-host}`) && Path(`/login`)"
      middlewares:
        - redirect-to-clerk@file
      service: coolify
      entryPoints:
        - https
      tls:
        certresolver: letsencrypt

Coolify’s Traefik should automatically pick up dynamic configs and the next login should immediately redirect you to your OAuth Endpoint.

Further considerations

This will break authentication if the “Clerk” Proxy container or PocketID is ever not up and reachable.

Should either one of those go down we can place this shell script on the host as an easy way to gain emergency access:

#!/bin/sh

FILE="/data/coolify/proxy/dynamic/login-redirect.yaml"

if [ -f "$FILE" ]; then
    rm "$FILE"
    echo "Login redirect disabled — password login restored"
else
    cat > "$FILE" << 'EOF'
http:
  middlewares:
    redirect-to-clerk:
      redirectRegex:
        regex: "^https://{coolify-host}/login$"
        replacement: "https://{coolify-host}/auth/clerk/redirect"
        permanent: false

  routers:
    coolify-login-redirect:
      rule: "Host(`{coolify-host}`) && Path(`/login`)"
      middlewares:
        - redirect-to-clerk@file
      service: coolify
      entryPoints:
        - https
      tls:
        certresolver: letsencrypt
EOF
    echo "Login redirect enabled — passkey login enforced"
fi

Git push to my Gitea failed with the following message:

remote: error: unable to get random bytes for temporary file: Function not implemented
remote: error: unable to create temporary file: Function not implemented

Instead of generating random bits from /dev/urandom, modern Git now calls the getrandom syscall via libc, which has been available from Kernel 3.17 and up. Unfortunately for me Synology does not update to newer Kernel versions, instead they backport patches to the old version that came with the device, which is good for stability, but bad if you need to run a more modern Git version.

LD_PRELOAD shim

Claude suggested to replace the NAS, second best option was to build this small shim as SO file against libmusl and mount it into Gitea’s container:

// file: getrandom_shim.c
#define _GNU_SOURCE
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>

ssize_t getrandom(void *buf, size_t buflen, unsigned int flags) {
    (void)flags;
    int fd = open("/dev/urandom", O_RDONLY);
    if (fd < 0) { errno = EIO; return -1; }
    ssize_t n = read(fd, buf, buflen);
    close(fd);
    return n;
}

We take this small shim that redirects the syscall to the old /dev/urandom device and compile it against alpine, which uses musl:

/volume1/docker/shim# docker run --rm -v "$PWD":/src -w /src alpine:3.19 sh -c \
  "apk add --no-cache gcc musl-dev && gcc -shared -fPIC -O2 -o getrandom_shim.so getrandom_shim.c"
/volume1/docker/shim# chmod 644 getrandom_shim.so

Once the shim is built, we can now add these two lines the Gitea docker-compose.yaml to inject it into the dynamic linker before all the other symbols are resolved and redeploy:

environment:
      - LD_PRELOAD=/usr/local/lib/getrandom_shim.so
…
volumes:
      - /volume1/docker/shim/getrandom_shim.so:/usr/local/lib/getrandom_shim.so:ro

Git is now working properly again. This post is put under the playground category deliberately, because I don’t know yet whether I want to keep it like this or not.

Day 1: Baden

Started trip in light drizzle and 12 degrees C.

As the tour went on the rain stopped but I started to feel cold and replaced my light gloves with warmer ones I picked up along the way in Pforzheim.

With a small delay we made it to Heidelberg where (at least in the old town area) publicly accessible chargers were sparse. A friendly parking garage manager did help me by blocking a free spot that had just opened up.

After a quick bite (including a quick dessert to go from Zeit für Brot) we went on to Mainz way delayed.

To not have additional delays we decided to use the faster route via the Autobahn, but were held up majorly when a construction site merged three lanes into one and traffic stopped to a crawl.

We made it to Mainz right after the sun went down. But the charger near our hotel I had previously planned on using was in a parking garage with license plate recognition and they refused to let me in to charge.

I then found one in the old town area that showed as free, but when I arrived one was blocked by an electric car that had the cable in but wasn’t even charging and the other one by a rundown combustion Opel, so I had to drive up onto the sidewalk next to the charger.

I first tried the EnBW app and it appeared to unlock it but wouldn’t start charging. Two attempts via their website didn’t work. I then proceeded to download their app, where you had to unlock the charger first and then plug the vehicle in after it prompts you, it worked. Left the 80% charge target in because we wanted to spend time in Wiesbaden the next day.

Day 2: Franken

We stayed at the Ibis city, rooms and hotel bar were nice but when I woke up I was greeted by bed bugs.

During checkout the front desk wasn’t occupied, but since we stayed only for the one night I didn’t bother waiting around to complain.

We went on to meet up for breakfast with friends. Naturally, the public charger on the map was on fenced off company grounds and the gate guard didn’t even know about a charger for electric vehicles existing.

I then found one nearby that wasn’t on any map by ESWE unfortunately neither the Roaming, nor their app worked.

Weather was nice and sunny, lots of other motorcycle riders out.

We continued on to Aschaffenburg. Found a charger next to some industrial zone. Plugged it in, and due to the learnings of the days prior, went straight to the AppStore and downloaded the app. While charging we went to a nearby Biergarten for some coffee and cake.

The journey onwards to Würzburg was uneventful and nice. We switched to lighter clothes for the day.

After checking into the hotel at the border of the city we went looking for a charger nearby. All the ones we found, either didn’t work or had the wrong plugs. Finally when we wanted to go grab some lunch, we came by a company parking lot with lots of free chargers and a poster saying for public use, naturally not showing up on the map.

Day 3: Hohenlohe

The next day I grabbed a quick coffee double espresso from the hotel before getting my bike back from the charger, then got back and ate real breakfast.

The weather already didn’t look promising with light rain.

We drove on to Schwäbisch Hall, where after a long, time reach anxiety kicked in again. Perhaps it was a combo of using the rain mode (which reduces the power recovered from braking), being soaking wet and cold and wanting to escape to a bakery with a warm coffee and watching the battery gauge slowly go down: Plugged in for 15 mins, couldn’t find an open bakery and drove on for the final (about 35) KMs. Didn’t need the 15 mins of charging in the end.

Wind, overcast sky and pouring rain for hours make for a terrible riding experience.

In Schwäbisch Hall we found the parking lot of the DMV that had chargers. There was a sign for no motorcycle parking, which I conveniently ignored and pulled a ticket. The chargers are activated using your entry ticket and you pay for both charging and parking before leaving.

We went to a restaurant at the top of the Einkorn and met up with friends and family there for lunch. Pealed off several layers of soaked clothing in the hopes of it drying at least somewhat.

Picked up the bike on the way back and was surprised that on Sundays parking (and charging) is free!

It was still raining and we were cold all the way to Esslingen where we went into a gas station to top up and warm up for a few minutes.

Slight navigational mishap lead us onto the A8 for a short stint. After that we rode the B27 back home with the option to stop in Tübingen if we get colder or the range gets any lower.

In the end we made it right before the sun went down. Freezing cold and shaking. I plugged the bike back in at home with 17 KMs of battery left.

Summary

In good conditions the bike has way more reach than what our backs can endure on those seats.

Riding for hundreds of kilometers in wind and rain is miserable. I am now considering what adjustments I’m going to make to my gear for future trips.

I now have three more charging apps on my phone. Price-wise (the free charging not included) it averages about 60 cents/kWh. The best experiences were with chargers that somebody put there, but weren’t on any map. I’ll add them to Chargemap once I’m done writing this.

This post describes my setup step by step in case you (or I) need to recreate it.

Prerequisites

• a working Gitea instance
• with its User Accounts set up
• at least one user with a Public Key set up
• your Synology has its SSH service properly configured, secured, exposed through the firewall

SSH fundamentals

But first a few things to understand, which I fully grasped way too late into the process:

• There will be just one SSH server running (on the host)

• During authentication the SSH protocol only allows authentication. And exactly once.

  That means you cannot during the authentication forward the connection to another server, only after authentication. But any authentication required by the second server would fail because your (git) client thinks auth has already completed (which in a way it has)

• Agent-Forwarding might work in theory, but we want regular ssh clones without any host config modifications required, that matters doubly on CI builds.

The setup

Gitea comes batteries-included with little helpers for that. But the tricky part is getting this to work reliably and securely. We’ll mount the git’s .ssh dir read-write into the Gitea container and Gitea will then keep it updated with all its valid users public keys and an additional tagged command that lets Gitea to detect the user and allows further processing.

Setting up the git user

We need a system user that all git clones then are funnelled through (The git@ part in git@$domain.tld).

Synology’s Web Interface will block the creation of a git user for security reasons. Terminal it then is:

sudo synouser --add git '' "" 0 "" 0

Then set an invalid password for the git user to prevent password authentication:

sudo synouser --setpw git '*'

While you’re at it, go to the Web Interface and tick the “Prevent user from changing password” checkbox.

Setting up the git user’s SSH directory

sudo mkdir -p /var/services/homes/git/.ssh
sudo touch /var/services/homes/git/.ssh/authorized_keys
sudo chown -R 1000 /var/services/homes/git/.ssh
sudo chmod 700 /var/services/homes/git/.ssh
sudo chmod 600 /var/services/homes/git/.ssh/authorized_keys
sudo chmod 755 /var/services/homes/git

Next we remove Synology’s extended ACLs from the git’s home directory, as sshd’s StrictModes rejects directories with ACL entries:

sudo /usr/syno/bin/synoacltool -del /var/services/homes/git

Preparing the git user account settings

The user in my Gitea Docker container has the user id 1000 and because SSH PubKey auth is set to be picky when it comes to file permissions of its key files, I had to match the uid on the host.

First let’s check if the user id 1000 is free:

id 1000

In my case it said “no such user”, which is exactly what we need.

Open the passwd file and change the git user id entry to 1000.

Please take utmost care when editing this file, as it potentially could break your Synology install and lock you out of it!

sudo vi /etc/passwd

Find the git line and change it to:

git:x:1000:100::/var/services/homes/git:/bin/sh

This a changes the git user id to 1000 and the login shell to a valid value.

Now is a good time to restart the ssh service using

sudo synoservicectl --restart sshd

Forwarding to Gitea

This is the tricky part I didn’t understand at first: An entry in the authorized_keys file can have additional parameters, like restricting the user to certain commands after auth.

We’ll create our own wrapper to forward to Gitea and restrict the git user to only be able to execute this one command that connects through to Gitea as /usr/local/bin/gitea-serv:

sudo vi /usr/local/bin/gitea-serv

And put the following content there:

#!/bin/sh
exec /volume1/@appstore/ContainerManager/usr/bin/docker exec -i -u git -e SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea /app/gitea/gitea serv "$@" --config /data/gitea/conf/app.ini

Make it executable:

sudo chmod 755 /usr/local/bin/gitea-serv

Allow gitea-serv in sudoers

By default no user can access Gitea (or any other Docker container for that matter). We could add the git user to the docker group, but that would give it full access to any Container. We don’t want that. But we can give it sudo access without password check to the gitea-serv command:

sudo sh -c 'cat > /etc/sudoers.d/git-gitea << EOF
git ALL=(root) NOPASSWD: /usr/local/bin/gitea-serv
Defaults>root env_keep+=SSH_ORIGINAL_COMMAND
EOF'

Verify it works by switching to the git user and testing:

sudo su -s /bin/sh git -c 'sudo /usr/local/bin/gitea-serv serv key-1'

If it works the expected output should be something like Hi there, <username>! You've successfully authenticated.... The actual name doesn’t matter, as key-1 is just the first key that Gitea has stored.

If it didn’t work yet, it’ll probably sort itself out with the next step.

Mount the git users’ .ssh directory into the Gitea container

I use docker-compose for the Gitea install, so I had to add this in the volumes section:

volumes:
  - other volumes
  - /var/services/homes/git/.ssh:/data/git/.ssh:rw

But if you use plain old Docker, just add the directory in there.

Please note: You have to mount the entire .ssh dir, as with file-based mounts Gitea has issues writing the keys.

Update Gitea’s configuration

As already mentioned earlier, we have to tell Gitea to write the correct command (our gitea-serv) to the authorized_keys file, and we have to disable the built-in ssh server.

In my case I updated the docker-compose.yaml again:

environment:
  - SSH_DOMAIN=${ssh domain}
  - SSH_PORT=22 # change this to whatever your Synology SSH daemon listens to
  - START_SSH_SERVER=false # Gitea's own SSH server not needed

The first two env variables do not have any effect other than to show up in the UI as clone URL. The second disables the built-in SSH server.

The other part of the Gitea config lives in the app.ini file:

[server]
SSH_CREATE_AUTHORIZED_KEYS_FILE = true
SSH_AUTHORIZED_KEYS_COMMAND_TEMPLATE = sudo /usr/local/bin/gitea-serv key-{{.Key.ID}}

Now it is time to restart (or in case of docker-compose redeploy) Gitea:

cd {location of your docker-compose.yaml} && docker compose restart

Populate authorized_keys

Whenever a key is removed or added in the Gitea webinterface the authorized_keys will be regenerated. But the regeneration can also be invoked from the CLI:

docker exec -u git gitea /app/gitea/gitea admin regenerate keys --config /data/gitea/conf/app.ini

Verify the file was written correctly:

docker exec gitea cat /data/git/.ssh/authorized_keys | head -3

Expected format should be:

# gitea public key
command="sudo /usr/local/bin/gitea-serv key-1",no-port-forwarding,...,restrict ssh-ed25519 AAAA... user-1

Test the connection

ssh -T git@${your-server}

Expected output:

Hi there, jan! You've successfully authenticated with the key named ${your-key-name},
but Gitea does not provide shell access.

And your regular users should also still be able to connect:

ssh {non-git-user}@{your-server}

I am so happy works! I now can ssh into the machine using any other user and the HTTPS/SSH clone URLs finally work as expected. Didn’t have to do weird redirects, the git user and the sudo part is restricted to this one functionality. And Gitea is now also part of Synology’s fail2ban mechanism.

Troubleshooting

These are the steps I took to troubleshoot issues with the setup.

Permission denied on connect

Check what the sshd logs say:

sudo journalctl -u sshd.service --since "5 minutes ago"

bad ACL permission

Try removing the Extended ACLs again: synoacltool -del /var/services/homes/git

Could not open authorized keys”

Check ownership: sudo chown -R 1000 /var/services/homes/git/.ssh

Key not found

Regenerate keys: docker exec -u git gitea /app/gitea/gitea admin regenerate keys --config /data/gitea/conf/app.ini

Git push/pull shows Gitea welcome message instead of working

SSH_ORIGINAL_COMMAND is not being passed. Verify sudoers contains:

Defaults>root env_keep+=SSH_ORIGINAL_COMMAND

Setup broken after DSM update

Re-do the steps in Preparing the git user account settings

Wrapper script: docker not found

Verify the Docker binary path:

readlink -f /usr/local/bin/docker

Update the path in /usr/local/bin/gitea-serv accordingly. On Synology with Container Manager it is typically:

/volume1/@appstore/ContainerManager/usr/bin/docker

Wasabi used to have a nice offer 4$/TB/month, S3 interface and a few years ago they even started to offer their services in European data centers. And because Synology HyperBackup natively supports S3 with custom endpoints it was a breeze to set up.

But over the years they have increased their prices, while at the same time their service got worse year over year.

When I got my second Synology, the plan was to allocate a small portion of storage on each machine and receive the backups of the other. And since both Synologys are hundreds of kilometers apart, it would even count as proper off-site backup.

Reddit is full of both reports that it works reliably, and that it always refuses connect from one machine to the other. However all agree that for it to work ports 5001 (HTTPS Webinterface) and 6281 (HyperBackup Vault) have to be reachable.

In my case, the port 5001 isn’t reachable from the internet, but a reverse proxy terminates the traffic on a subdomain using SNI.

Eventually I gave up, since Wasabi did mostly work, and a working but increasingly expensive backup is better than a free one that isn’t reliable. But then the E-Mails about failing backup jobs slowly started to pile up, until I was fed up and had another go.

Tailnet

I had Tailscale installed on both machines. Normally used as Exit Node when using unencrypted WiFis or when I’m abroad and need an IP that is located in Germany. But due to the way Synology has set up the networking on their devices, I could connect from the Tailnet into the NAS but not from the NAS out to the Tailnet.

The Tailscale Docs describe a workaround which involves creating the needed tun device on each boot. Now that they can see each other, we can use the Tailnet link-local IPv6 to set up the backup. Since the SSL cert for the login frame (and in my case even worse: PassKey auth) is broken, you’ll have to use the “Password Login” option.

The power went out during my lunch break. One of the rare occasions where I noticed it before the UPS informed me.

For simplicity sake my default way of publishing was with static sites on either GitLab Pages or GitHub Pages. But for deploying web apps I just didn’t have a nice way.

There were unsuccessful attempts with serverless Cloud providers, that charge by the CPU second, but that means I don’t get to have any application state, because the instances are short-lived. And the deployment itself was always fiddly and couldn’t be relied on.

I had stumbled on Coolify earlier before and had wanted to give it a try. But when I found out you can have Hetzner pre-install one when configuring a shared server with them, there was just no reason not to try.

Setup took a few minutes, and now all I have to do is to add a tiny Dockerfile to a Kotlin repo, the usual: pull temurin, build the app, run the jar, expose port 8080 and set up a new App in Coolify. Add a domain name and optionally a Webhook that triggers a rebuild when the code changes, and off we go.

Coolify makes this feel outright casual and effortless. Need a database side-car along with it? Coolify has you covered. Custom config for the reverse proxy? Easily done.

Static Site Hosting

After having migrated from Neocities to GitLab Pages, I had (somewhat jokingly) mused on self-hosting again. And since it worked so well with the custom web apps, I had to try it with a static site.

And with some help from Claude this now runs on my own host. The SSL score is atrocious¹ and I am not fully happy with the setup, but at least it is mine. Instead of using the static site deploy type, I built a bespoke Docker container with nginx.

The convoluted GitLab Pipeline process with multiple containers and interwoven includes is now handled by a small multi-step Dockerfile that contains a total of 19 lines of code for building, deploying and running everything!

Batteries-included Apps

It even comes with pre-configured apps. You can spin up a complete PocketID instance in a few seconds, ready to go.

I always wanted to try AppWrite or Supabase for small personal projects. Now I can deploy one with a few clicks, play around and tear it down with as few clicks again.

Downsides

Coolify is written in PHP. I’d much prefer something written in a more robust language, but it works.

It does work with arbitrary Git Servers, like Gitea, but takes some coercion and finagling to get it working, while it is clearly designed to be used with the GitHub integration that comes with it.

Note: Gitea doesn’t (yet) have a dedicated Coolify target for WebHooks but will work when selecting “Gitea” as target.

ALL the different http apps are in use. Coolify uses Caddy as frontend, Traefik as backend and the Docker Images usually have their own Webserver or Reverse Proxy in it. It works but that is more moving pieces than I would have liked my setup to have. If any one of those has a security vulnerability the entire stack is open to attack.

Today everything serendipitously fell into place: yesterday was warm enough, no frost over night, nice weather on a lazy Saturday afternoon and a buddy of mine was also planning on a short ride.

Started the ride at 80% battery, and rode 55 kilometers in total, down to about 50%. We took it slowly on backroads and gradually increased the riding difficulty. We had all kinds of terrain, flat portions and up and down the hills, easy curves, turnpikes. By the end the sun was about to set and the temperatures started to drop from the 17 degrees we had set out at, down to 13 degrees.

Compared to my (also electric) winter car, it is noticeable how much better the motor and the BMC performs. Not only in output power but in estimating, recouping and saving power.

It was fun every minute of the ride and I’m looking forward to the warmer months, when the conditions are even better and the sun is up for longer.