April 22, 2026

Heads up: this is a long post. Feel free to skip to the end for the technical part.

Titan is back! Who is “Titan”? It's none other than my 1999 PC! But first, a bit of history so you can catch up with the rolling stock. After its first appearance on this blog, Titan kept going strong for a good while. Then a few years ago, Windows 98 decided to kick the bucket after I installed the chipset drivers. My mistake for trying to fix something that wasn't broken. Well, 98 is not known for its robustness anyway, so I just reinstalled it (for the thousandth time :D). It worked fine for a while, then some day, Titan wouldn't boot. Just a black screen that left me completely clueless about the issue. I tried shuffling RAM sticks around, a different GPU, reseating the CPU cartridge… No dice. Had I plugged in a speaker, maybe I would have gotten some clue… But I didn't. So I put Titan aside and in its place came a Socket 7 system I had recently refurbished.

It stayed that way for a while until recently, when I decided time had come to attempt to breath some life into him again. Of course, cardiopulmonary resuscitation had not been maintained during the months Titan spent on the sideways. Thus, hopes were slim. But this time around I was equipped with a speaker and a PCI debug card, strongly determined to fatten them a bit. After laying the motherboard bare on a salvaged piece of cardboard, right next to another PC, I effectively created a FrankenTitan by hooking the motherboard up to the other's PC PSU. Having a spare PSU would surely lack taste ;-) I started simple: CPU, GPU, a known good CR2032 battery and one RAM stick. The speaker pierced my ears with one long beep. Then nothing. Apparently, for this BIOS, one long beep means “RAM issue”. After finding an unofficial manual for this motherboard on the retro web, I was intrigued by the fact that if using a single RAM stick, it recommended to put it in slot 1. On my end, it was in slot 3, the farthest from the CPU, as that's what’s recommended for modern machines. Titan is different. After moving my RAM stick to slot 1, Titan finally agreed to grant me the sacrosanct short beep. POST successful!

Just like that, Titan was back. A few days were all it took me to bring it back to its full glory: a dedicated case and PSU, 2 sticks of RAM, its faithful ISA sound card, a mechanical hard drive loaded with a brand new Windows 98 SE install, and a DVD drive that will play an interesting role a bit later. And with that, I could finally solve a mystery that bogged me ever since I had discovered months ago that a VOGONS user was able to decode a 480p Xvid video on the very same CPU that makes Titan tick. My previous attempts were limited to 360p MPEG2. What gives? How could someone shove more pixels with a more advanced codec down this CPU's throat? The first thing that came to my mind was the wide gap in software stack: I was using Windows 98 and VLC media player, while they were using Windows 2000 with PowerDVD 4.0. I didn't feel like wiping my brand new 98 install, so a switch to 2000 was out of the question. But PowerDVD, I could try. I had a gut feeling that if I wanted to play back higher quality video than what I had previously achieved, I would either need a highly optimized CPU-only decoder, or a GPU-assisted one. If GPU-assisted video decode was ever a thing last century.

I was wrong to be skeptical about GPU-assisted video decode on such an old setup. It is not as new a thing as I thought it to be: PowerDVD 2.55, as far back as the late 1990s, already did it! I preferred this one over 4.0, as the latter seems to belong more to the 2000s. I want to play HQ videos, 1990s style! So 2.55 it is. Turns out that it supports a select few GPUs for hardware-accelerated motion compensation, and Titan's GPU, the mighty S3 Savage4, is among the chosen ones! Upon reading this in the README, the hype immediately grew to unbearable levels. Then quickly took a nose dive when PowerDVD refused to play back all the files I thew at it. All. Of. Them. Heck, even the file playback feature was hidden behind a small button of its UI! When I finally saw the light and realized that PowerDVD was first and foremost conceived to play back… DVDs… (who would’ve guessed?), I shoved one in the DVD drive, and voilà, PowerDVD finally agreed to display some moving pictures. And boy did they look crisp! It was the best video play back I had ever seen from Titan. I'd say the picture quality is very good on a 15”, 1024×768 screen. And perfectly fluid at that, with some CPU cycles to spare even, as the mighty Pentium 3 was chugging along effortlessly, averaging around 50% usage. Having witnessed that, I made it a priority to find out how to produce my own video file(s) that PowerDVD would accept.

Given that PowerDVD 2.55 is very DVD-focused, I took a peek at the DVD specification as summarized by Wikipedia. The highest resolution of the spec is either 720×480 at 30fps (PAL) or 720×576 at 23.97fps (NTSC). The video codec to use is MPEG2 with a bit rate averaging around 6000Kb/s, with a total (audio+video+subtitles) ceiling of 9800Kb/s. Not too shabby! Although PowerDVD seems to take a few shortcuts that do affect image quality a bit compared to a modern player, I have to give my hats off to the engineers that worked magic so that last century's toasters could handle such high quality. On the audio front, the spec mentions several codecs. I chose AC-3 as it should be available for NTSC and PAL players both. It took me a while to find the right FFMPEG setup to produce files close enough to the spec that PowerDVD would accept them. It boils down to a few parameters:

1. You have to use a DVD container (that's -f dvd)
2. PowerDVD seems quite picky about audio bit rate. A 5.1 channels stream decodes just fine at 448Kb/s, but a stereo one cannot go above 160Kb/s without producing annoying crackling during playback. My attempts to go below 128Kb/s were also unsuccessful, but the audio quality is less than desirable at such low bit rates anyway.
3. Most content nowadays is presented with an aspect ratio of 16:9 or even 2.35:1. That's a bit tricky because the DVD spec does not offer a 16:9 resolution. The trick is to set a display aspect ratio (DAR) that stretches the pixels horizontally. If encoding at 720x576, the pixels have to be stretched during playback to 1024x576, which is 16:9. For 2.35:1, you basically encode at 16:9 with black borders. There's no other choice because that aspect ratio is not standard in the DVD spec.
4. Every time I've tried changing the refresh rate of a video, I get stutters in the resulting encode. So I don't change it and just target a resolution that's compatible with the original material refresh rate according to the DVD spec. That's also the reason why I don't use the target presets of FFMPEG, as those will mess with refresh rate. For 23.97 or 25fps, I go for 720x576, effectively targeting NTSC. For 29.97 or 30fps, I go for 720x480, effectively targeting PAL.

To maximize quality, I chose a 2-pass encode. Here are the 2 commands that I use, one for each pass. Please note that the commands below assume a target resolution of 720x576 with 16:9 aspect ratio, and adds black borders if necessary. When targeting 720x480, in the -vf part of the commands, you should replace the "576" with "480" (obviously), but also the "1024" with "853". That's to keep the target 16:9 aspect ratio.

$ ffmpeg -i in.mp4 -c:v mpeg2video -b:v 6000k -vf "scale=720:1024*ih/iw,pad=720:576:(ow-iw)/2:(oh-ih)/2,setdar=16/9" -bufsize 1835k -maxrate 9800k -pass 1 -an -sn -f null NUL
$ ffmpeg -i in.mp4 -c:a ac3 -b:a 160k -c:v mpeg2video -b:v 6000k -vf "scale=720:1024*ih/iw,pad=720:576:(ow-iw)/2:(oh-ih)/2,setdar=16/9" -bufsize 1835k -maxrate 9800k -f dvd -pass 2 out.mpg

I've encoded a few files with these commands, and I'm pleased to report that they play back fine with PowerDVD 2.55. Now going further, I could try to create real DVDs that play on commercial players. That would also allow me to add subtitles, which are not supported with my current workflow. I know that the dvdauthor tools should allow to do that, and more (menus anyone?). I've yet to try it though, might be for another time.

PS: You might be wondering where the "Titan" name comes from. It's pretty simple: when I got it, Titan was setup in a very (very) tall case. Think of a standard ATX case with power supply at the top, but with lots of spare room above the 5.25" bays and the power supply. So when Windows asked me to name it during its first install… A quick glance at the case and inspiration struck me :-)

June 9, 2025

I'm a big fan of suckless tools. My laptop has been running dwm for years now. One of their tool has fascinated me ever since I discovered it: sent.

Its purpose is to create presentations. Being a suckless tool, it only needs a plain text file with each paragraph corresponding to a slide. Pictures can be displayed on a slide, but not with text on the same slide. You then launch sent on the file and the presentation starts in a plain X11 window.

It is diabolically efficient, and I like that. No need for a bloated WYSIWYG tool or elaborate markup language. Just write what you want to present, and it's done. With the file being plain text, you can even open it with any viewer or editor and just read it that way.

Some may find that the resulting presentation is a little too bland for their taste. In my opinion, that's a feature. I think many slides are way too bloated in the presentations I see. Having a few simple sentences or just one picture per slide is enough. It lets the viewer quickly read it and then listen to what is being said about it. The slide should support the talk, and not the opposite.

To test drive sent, I've created a simple "Maven primer" presentation. Don't take it too seriously, I've not checked everything I've written. You can find the presentation source file here. The sent home page is quite clear that exporting the presentation to other formats is not supported, but suggests automating a PNG export of each slide. That's exactly what I've done with a quick and dirty bash script:

#!/bin/bash

echo "Please focus sent window"

for i in {3..1}
do
    echo "$i..."
    sleep 1
done

xdotool getactivewindow windowsize $1 $2

for i in {01..19}
do
    import -screen -window 'sent' $i.png
    xdotool getactivewindow key n
done

Just launch it with your desired output resolution and then you have 3 seconds to focus the sent presentation to export:

$ ./sent-export.sh 800 600

March 24, 2025

But why?

Recently I needed to setup a proxy for three websites. The proxy and the sites are distributed among two servers. One of the servers hosts the proxy itself as well as two of the sites. The other server hosts the remaining site. The two machines are connected through the internet so the forwarded traffic to the remote server needs to be encrypted. A picture is worth a thousand words as they say:

Both servers are running OpenBSD, so we're going to rely on relayd(8) as the proxy and httpd(8) as the web server.

relayd setup

In the relayd(8) configuration file /etc/relayd.conf we must first define two tables, one for the local server running relayd(8) and another for the remote server server2.com:

table <local> { 127.0.0.1 }
table <remote> { server2.com }

Then we have to define a www protocol to setup the proxy behavior for regular HTTP connections. It will forward the request to the right server based on the Host header. We also add special headers to the forwarded request so that the services running behind the proxy can use the information provided with these headers to adjust their behavior, should they need to. Finally, a request that doesn't match any of the expected hostnames is simply blocked.

http protocol www {
        match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
        match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"

        pass request quick header "Host" value "site3.com" forward to <remote>
        pass request quick forward to <local>

        block
}

We also define a wwwtls protocol that is configured almost the same, it just has the certificates for each host we are proxying.

http protocol wwwtls {
        tls keypair site1.com
        tls keypair site2.com
        tls keypair site3.com
        match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
        match request header append "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"

        pass request quick header "Host" value "site3.com" forward to <remote>
        pass request quick forward to <local>

        block
}

The line tls keypair site1.com means that relayd(8) will look for a certificate file named /etc/ssl/site1.com.crt and a private key named /etc/ssl/private/site1.com.key. If your certificates are signed through a chain (like the ones provided by Let's Encrypt), the .crt file needs to contain the intermediate certificates, not just your final one. I use acme-client(1) to manage my certificates, which does not write the intermediate certificates with the default configuration. Thus we need to set this up in /etc/acme-client.conf:

domain site1.com {
    domain key "/etc/ssl/private/site1.com.key"
    domain full chain certificate "/etc/ssl/site1.com.crt"
    sign with letsencrypt
}

After editing the file, you should of course run acme-client to update the certificates. Next come the relays. They define which protocol to use for a request as well as where it can be forwarded. There's one for http and another for https. Nothing special here except that you may have noticed the ports for the local web server are set to 8080 and 4443. That's because relayd(8) is already listening on ports 80 and 443 on the proxy.

relay www {
        listen on egress port 80
        protocol www
        forward to <local> port 8080
        forward to <remote> port 80
}

relay wwwtls {
        listen on egress port 443 tls
        protocol wwwtls
        forward with tls to <local> port 4443
        forward with tls to <remote> port 443
}

Ideally, we would not need to use TLS for the local forwarding. But somehow relayd(8) would not work with TLS enabled only on the remote forward rule. I don't know whether it's a configuration mistake on my end or whether it's a relayd(8) quirk. If you know more about this, I'd be glad to hear about it.

Finally, at the very top of the file, we can ask relayd(8) to log all connections.

log connection

httpd setup

There's not much to do on the httpd(8) side of things, except setting the ports to 8080 and 4443 on the local server, and also setting the log style to forwarded. This allows the IP address of the client which made the request to be logged instead of just the proxy. Please note that this information is read from the X-Forwarded-For and X-Forwarded-Port request headers, so the proxy has to set those on the forwarded request. We set this up in the previous section. An example site could be configured as such in /etc/httpd.conf:

server "site1.com" {
    listen on * port 8080
    listen on * port 4443
    log style forwarded
    tls {
        certificate "/etc/ssl/site1.com.crt"
        key "/etc/ssl/private/site1.com.key"
    }
    root "/htdocs/site1"
}

If any of the services you're proxying requires its configuration to be updated, please make sure to do so.

Why not a VPN to secure traffic over the internet?

I don't know how to setup a VPN. It could be the topic of a future article, but I don't know that it would provide many benefits? If you can think of any, please get in touch!

June 4, 2024

I decided to listen to music this evening. I had a particular song in mind while turning it on, though I ended up choosing to listen to some other album.

When the app reached the end of the album, it kept going by selecting "similar" songs. And the one I wanted to listen to was in there, chosen by the algorithm.

Did the algorithm successfully learn to suggest songs I like? Or did it suggest this song several times already during previous evenings, such that I wanted to listen to it?

October 10, 2023

The blog has not seen many new articles lately, but there is new stuff under the hood nonetheless!

I’ve not written a new article in a while, because life happens and I didn’t feel like any topic warranted a full post of its own. That does not mean the blog is dead though, and I’ve been improving the generation process of the blog, switching to a Perl script. This change has made it a lot more readable than the old Makefile-based script. It also allows to easily extend the generation process with new features, even though the primary objective is still simplicity above all else. For now, I’ve added an RSS feed of the articles, in case anyone is still interested in those in 2023. This improvement was a while back though, more than a year ago according to git.

Now today I made another improvement to the blog and also my git web interface, as they can both now be browsed with HTTPS encryption. Honestly it took me way too long to make this possible, especially as I knew how to do it already. But anyway it’s done now, although unlike most websites, the regular version does not automatically redirect to the HTTPS one. You are still allowed to browse the regular version of this blog with an outdated browser that may not do HTTPS or may be too old for newer certificates, protocols or whatever :)

As it turns out, I’m also working on a new coding project, but it’s a little too early to push it on my public git. Hopefully I get it very soon in a publishable state. Until then, take care and I’ll write more to you soon(ish)!

August 29, 2022

As of today, the Radeon RX 6700 is the latest card from the RX 6000 series released by AMD. As such, it is supported by driver version Adrenalin 22.6.1 and later. Unfortunately, this driver version is also the one AMD chose to deploy a big overhaul of their OpenGL and DirectX 11 driver. This overhaul brings great performance improvements in most applications relying on OpenGL or DirectX11, but sadly, it also breaks a few others. In case of issues, an easy workaround is to stick to Adrenalin 22.5.1 for the time being. That said, the RX 6700 is left in an odd place because this driver does not support the card. So are all RX 6700 owners screwed? Maybe not.

Prerequisites

First of all, if you try to install the 22.5.1 driver with the RX 6700 installed in the machine, the driver will complain that no supported hardware was detected, and it will refuse to install. To follow this guide, Adrenalin 22.5.1 must already be installed on the machine prior to installing the RX 6700. You may install this driver with any supported card in the machine.

The trick

The trick is that both the RX 6700 and RX 6700 XT use the Navi 22 GPU. As a result, those cards are very similar and you can use the 6700 XT driver with the non-XT card. The steps are simple (please note that I have translated the name of the buttons, so they may differ slightly). Needless to say, you have to know that you do this at your own risk, it may break or damage something, you've been warned:

1. Install the RX 6700 graphics card in the machine
2. Open Device Manager (simply search for "device manager" in the start menu)
3. Under the "Graphics card" category, double click on the RX 6700 graphics card (at this point, it may have a generic name like "Display adapter")
4. Go to the "Driver" tab then click "Update driver" button
5. Then choose the second option to search for the driver locally
6. Click on the button at the bottom of the window, "Choose among a list of available drivers on my computer"
7. Untick the checkbox "Show compatible hardware"
8. Select "Advanced Micro Devices, Inc." in the left pane and "AMD Radeon RX 6700 XT" in the right pane. If several versions are available, choose the most recent one while staying before June 2022.
9. At this point, the screen may flicker a little. Even though Windows won't ask for it, I recommend to reboot the computer.

And that's it! I've been using this trick for almost two weeks now, and I've not had a single issue, the RX 6700 works fine with the RX 6700 XT driver :)

May 16, 2022

The past few months, I've been having fun with an old PC from 1999. The machine is surprisingly capable as long as you cater to light programs and of course it won't browse the web. One of the things it's really good at though, is retro games from that era. One hardware component of particular interest in this regard is the GPU. The machine originally came with a Matrox G400 PCI graphics card. I quickly replaced it with a supposedly much more powerful GeForce2 MX that leverages the AGP port on the motherboard. After a while though, I began to wonder if this GPU is a good match for this machine. So I set out to run some benchmarks with a few GPUs I have on hand, to try to decide which one to use. This post will include 3DMark test results as well as discussions regarding 16bit vs 32bit color mode, driver overhead, and issues I encountered setting up the GPUs.

Test platform

For reference, here are the specs of the test platform:

• Intel Pentium III 550MHz (Katmai)
• 256Mb PC100 SDRAM
• Gigabyte GA-6VXE+ (VIA Apollo)

And the tested GPUs:

• S3 Savage4 Pro: 32Mb SDRAM, 125MHz core, 125MHz memory, driver version 4.12.01.8226
• Nvidia GeForce2 MX: 32Mb SDRAM, 175MHz core, 166MHz memory, driver version 28.32 and 43.51
• ATi Radeon 7000: 64Mb DDR, 166MHz core, 166MHz memory, driver version 4.13.01.7075
• Nvidia GeForce FX5200: 64Mb DDR, 250MHz core, 200MHz memory, driver version 43.51

The Savage4 Pro is the oldest of the bunch, having been released in 1999. Then the GeForce2 MX and Radeon 7000 came out in 2001. Finally, the GeForce FX 5200 came out quite a bit later in 2003. All the GPUs were using the AGP interface.

I should also mention that the Savage4 was finicky on this motherboard: I had to disable AGP 2X in the BIOS to prevent it from freezing the desktop on boot. Thus, it runs in AGP 1X mode in all of the benchmarks.

Software

I ran the following benchmarks on Windows 98 SE:

• 3DMark 99 Max
• 3DMark 2000
• 3DMark 2001 SE

I wish I had an actual game or two in this list, but did not include any due to time constraints. Gathering all the data points for this experiment took long enough already.

Test results

The benchmarks were run with their default settings.

First of all, the different GPUs show very similar performance levels, except for a few numbers that stand out. Maybe the GPU is not the main bottleneck here. Still, the Savage4 Pro is the best GPU on 3DMark 99 Max. This surprised me as this GPU has only one pixel pipeline, just like the Radeon 7000, while the GeForce GPUs have 2. Maybe the S3 drivers are heavily optimized for the benchmark. When switching to a more recent workload such as 3DMark 2000 though, it loses its advantage and all the GPUs are in the same ballpark here. With 3DMark 2001 SE, the Radeon 7000 and Savage4 Pro suffer much more than the GeForce GPUs. I suspect it may be because these GPUs were not really intended to run such workloads, and the switch to 32bpp most likely does not help either. To check this, we're going to isolate the impact of color depth next.

Test results: 16bpp vs 32bpp

The Savage4 Pro suffers when rendering at 32bpp, and especially so at 1024x768: performance is basically halved compared to 16bpp. It was common for GPUs of that era to suffer in this mode. Maybe if it had a 128bit memory bus, it would do better. Surprisingly, under 3DMark 99, it manages the same score at 32bpp than the GeForce2 MX at 16bpp. Speaking of the GeForce2 MX, its performance is slightly reduced at 32bpp, but the other GPUs are not really affected.

About drivers

One thing I've heard about when you run a newer GPU than the rest of the system is driver overhead. Newer GPUs are usually intended to be run with newer CPUs, so the drivers for these GPUs might be more taxing on the CPU. If you are in a situation where the CPU is the limiting factor, having more driver overhead can lower performance. Another thing worth considering is that the performance of the same application on the same GPU can vary with driver version. With all this in mind, I decided to test 3 different drivers with the GeForce2 MX:

• 12.41, released in 2001, close to the release of the GPU
• 28.32, released in 2002, this one is more late GeForce3/early GeForce 4. By then you would typically pair your GPU with a CPU like a 2+GHz Pentium 4
• 43.51, released in 2003, this one is late GeForce4/early GeForce FX. CPUs at this point were around 3GHz Pentium 4

You won't see results for the 12.41 driver in the graph below, because this driver had some issues with 3DMark 99 and 3DMark 2001. It only managed to complete 3DMark 2000 with a score of 3350 points. It's more than double of what I got with driver 28.32, which seems odd. But if the score is real, it may be worth to try to find another driver from that time that is more stable with the GeForce2.

As you can see, there is not much difference between the two drivers, except for 3DMark 2001 which regressed a lot. This might indicate that the driver got more optimized towards newer hardware than the GeForce2. As it only concerns 3DMark 2001, it's difficult to conclude whether the driver overhead increased or not.

Conclusion

The GeForce2 MX is a bit disappointing. I know it wasn't a high end GPU when it released but still expected more out of it. Maybe it needs more CPU power to show its strength. The same can be said of the FX 5200. I know it's a low end part as well, but given that it's also much newer, I still expected it to perform better than the GeForce2. I feel like those GPUs require a beefier CPU, like something in the gigahertz range maybe.

The Radeon 7000 is not too shabby but still performs a bit lower than the GeForce2 MX. I also saw some artifacts during 3DMark 2001 SE so I'm not sure about the driver I have used. I did not test any game with it so I can't say whether they would work fine or not.

I was pleasantly surprised by the Savage4 Pro. Of course its performance is reduced at 32bit color depth, but that does not bother me because the games that this GPU can run well don't benefit much from it in my opinion. For now, it is the GPU I am using. It seems to be a good balance between performance and compatibility with the games I want to play, while also fitting well with the rest of the machine. For instance, I can run Wipeout XL just fine with this GPU while it would crash before I got to the menu with the GeForce2. The Savage4 also offers some features that I would like to try at some point, like the Metal API or S3TC texture compression. Maybe you'll hear more about this GPU when I get to do that.

April 8, 2022

Here are a few quick instructions on how to setup a VNC server on OpenBSD. This can give you remote X11 access to your OpenBSD machine if you can run an SSH client and VNC client.

If you selected the default sets during your OpenBSD install, the X11 server is already installed, if not, you should install it now. We'll just need to install a VNC server through the packages, I've settled on x11vnc:

# pkg_add x11vnc

Setting up x11vnc is pretty simple, you just need to give it command line options when starting the daemon. This is very simple with OpenBSD, just add your options to the /etc/rc.conf.local file. Here is an example configuration:

x11vnc_flags="-listen localhost -rfbauth /etc/x11vnc.passwd -logfile /var/log/x11vnc -ncache 0 -display :0 -forever -loop100 -auth /etc/X11/xenodm/authdir/authfiles/A:0-*"

I won't explain all the options here, you should read x11vnc(1) and/or the doc for more details. Nonetheless, the first two options are worth explaining. The VNC server is listening on localhost because the VNC protocol is not encrypted by default, so we will tunnel the VNC connection through SSH. Next, we specify a file containing the password to allow connecting. This file can be created with the following command, of course you should not use verysecurepassword:

# x11vnc -storepasswd verysecurepassword /etc/x11vnc.passwd

According to the man page, this file is not encrypted and just obfuscated with a fixed private key, so you should restrict the permissions on this file. Anyway the server is ready to be started:

# rcctl start x11vnc

You should now be able to connect to the server, after setting up the port forwarding with SSH, as such for example:

$ ssh -L 5900:localhost:5900 myserver

This basically forwards port 5900 of myserver to port 5900 on localhost. To connect to the VNC server, simply use localhost as the server and port 5900. If issues may arise, read the log and x11vnc(1). I've been using this setup for a few weeks now and I'm quite happy with it. As a bonus, here is a screenshot of my openbox VNC session:

January 5th, 2022

This year, or rather last year, I decided to participate in the Advent of code. This post will explain why and how I decided to do it, but also reflect on my progress since it's well over now.

One of the great things about the Advent of code is that you can participate with whatever language you choose. So instead of coding in a language I'm comfortable with, I decided to go with C, for the following reasons:

• it's been 10+ years since I last programmed in C, and I wanted to dive back into it
• maybe I can learn some "modern" C features as I will be targeting C11
• I wanted to develop on OpenBSD and all the tools required for C development are included in the base OpenBSD install
• it's a good way to improve my skills with a terminal-based development environment: tmux, vim, make, gdb...
• C is very portable and it's always good fun to compile and run on Visual C++ 6.0 under Windows 98 with a 22 year old CPU

In the end, I mainly kept pace until day 8, at which point the puzzles started to take a little too much time (that I spent hunting some christmas presents...). You can find my code on my git repo. Though at that point I had (re)learnt a good deal about C, and was getting more comfortable at developing and debugging in text mode only. The code is not perfect and there are still some TODOs and shortcuts, especially regarding memory management. But the main point was to get the right result at the end.

As of today I'm still working on day 9 and maybe will continue to progress in the following weeks.

November 3rd, 2021

I'll give you a bit of context first. Lately I've become frustrated with Xubuntu on my laptop. Long story short, having to update every 6 month and the general direction the OS is taking bothered me (flatpack by default... wait what?). Add to that the fact that every update broke something, so in the end I just reinstalled from scratch every 6 month.

Considering this, a few weeks ago I decided to ditch Ubuntu and go back to Debian. I say "back to Debian" because I actually used it as my main laptop OS a few years back. Although at the time I was using the stable flavor, this time I decided to install the testing flavor to avoid those dreaded updates. As usual I wanted to keep things small and simple, so I went with LXQt as my desktop environment. The project's about page states:

It will not hang or slow down your system

I can confirm it is very light. I don't know if it's Debian or LXQt making magic, or maybe both, but programs open up instantly, even on my 7 year old laptop. It's a refreshing experience.

By default, the mail client bundled with LXQt, at least on Debian, is Mozilla Thunderbird. It's a great client, but not exactly light and it also does not integrate well with my Qt theme. I could install KMail, but it will likely pull half of KDE along. So I went online in search of a light Qt-based mail client. I found only one, Trojita. Sadly, there's no package for it in Debian. Looking at the project's repository and bug tracker, it seems that development has been slow as of late. According to a bug report, it's been recently dropped from Gentoo because it uses an outdated web rendering component (I'll save my opinion on HTML emails for another post).

Even when considering GTK mail clients, there's only a handful of options to choose from. If you push aside those which are still based on GTK2, there is only one remaining: Geary. I've used it in the past, it's quite light and gets to the point, but it won't do better than Thunderbird in my Qt-based environment.

In the end I'm a bit short on options. It is sad that you can't easily install a Qt lightweight GUI mail client nowadays. Of course I could contribute to one of the previously mentioned projects and update it. Or I may explore CLI-based solutions. Or continue to use the webmail that comes with my provider. I haven't decided yet.

October 11, 2021

Lately, I've been browsing small articles that I decided to call "gems" for the purpose of this article's title. And in my opinion they are actually gems. It all stems from my recent discovery of Gemini, which is a new internet protocol.

According to the project page, it "is heavier than gopher, lighter than the web, will not replace either". Basically it's like a text-based web experience. It's mostly static and clutter-free, a gemini document looks like a traditional web page after you've activated the "reading mode" of your browser, except with Gemini it's native. Sounds good doesn't it? Among other things I love about geminispace are the absence of ads, or annoying cookie banners, or auto-play videos, or pages that make your laptop scream while loading... I could keep listing things I don't like about the modern web, but I'm sure you've got the gist of it.

By now you may be thinking "sounds good, how do I hop on?". All you need is a Gemini browser really. I use Lagrange on my computer and Elaho on my phone. The Gemini software page lists some clients you can choose from. What I found on Gemini (those links require a Gemini browser):

• I found Korean children songs translated to English and explained
• I found that SimplyNews allows to read the news without being suggested a thousand more articles
• I found a Wikipedia proxy
• I found a good amount of cooking recipes
• I generally found people talking about things that interested me, or sparked new thoughts

If you've got a bit of time on your hands, I highly recommend wandering a bit in geminispace. Within a few hours you'll most likely have found some capsules (what would be sites in traditional HTTP realm) discussing topics of particular interest to you. You can start with these resources which I found great to discover content:

• Geddit is a kind of Reddit clone
• geminispace.info is a search engine

You may have also noticed a new blog layout here, which is honestly inspired by the way gemini documents are rendered in the two previously mentioned browsers. I was having issues with Pelican, which I used previously, so I decided to develop my own static generator. It's all achieved with a Makefile that you can find on my git page. As it is, it's quite bare and I may improve it a bit in the future... Who knows, maybe I'll add some Gemini capsule magic to it ;)

September 19, 2021, modified on November 11, 2022

A white noise machine can help find sleep or mask ambient noise or even tinnitus. It can also be used to muffle conversation from potential eavesdroppers. I wanted to experiment with a white noise machine for sleep purposes so I decided to build one with a Raspberry Pi I had lying around.

For this you will need:

• A Raspberry Pi equipped with a jack port and an OS installed (I used a Pi 3B with Raspbian OS)
• Speakers connected to the Pi

Actually a Pi 3 is a bit overkill for this. I have a Pi Zero lying around that could fit the bill except it needs a USB dongle to connect speakers and I don't have such a dongle.

Preparing the white noise

First you need to find a white noise sample, preferably a long one. I chose to extract the sound from a 3 hour long YouTube video of a waterfall. Of course, choose what suits you. If you want to extract the sound from a YouTube video, you could use one of the many online tools but I won't recommend that to you. Instead, you can use youtube-dl:

$ youtube-dl -x --audio-format mp3 https://www.youtube.com/watch?v=dQw4w9WgXcQ

Some explanations for the options used:

• -x asks youtube-dl to extract the audio from the video. As stated in youtube-dl's help, ffmpeg or avconv is required for this
• --audio-format should be self-explanatory

Creating a white noise service

Next we are going to create a service to play the white noise automatically at system startup. My Raspberry Pi is running raspbian so systemd is used to manage services. Create a /etc/systemd/system/whitenoise.service file with the following contents:

[Unit]
Description=White noise machine
StartLimitIntervalSec=0

[Service]
Type=simple
User=pi
ExecStart=mpg123 --loop -1 /home/pi/whitenoise.mp3

[Install]
WantedBy=multi-user.target

You should adjust your username and path to the file. I used mpg123 because it's the simplest and lightest audio player I could find. Its loop option is handy to keep playing infinitely. It needs to be installed:

# apt install mpg123

Auto start, auto stop

To start automatically the service on system startup, you just need to enable the service on startup:

# systemctl enable whitenoise

To stop it, you can use a cron job set at the time you want it to stop:

55 6 * * * sudo systemctl stop whitenoise

This will stop the white noise at 6:55am. And that's it! Enjoy your homemade white noise machine!

September 11, 2021

Nowadays solutions like Github or Gitlab are popular to host online git repositories. I think that these tools can be quite bloated with features that I likely won't need for my small projects. So I decided to setup a self-hosted simple git server on OpenBSD. Here is how I configured it.

Creating the repository

Of course, you first need to install git. I personally chose to install the package:

# pkg_add git

Next you need to add a git user, which will be used to push code to the repositories:

# adduser
Enter username []:        git
Enter full name []: git
Enter shell csh git-shell ksh nologin sh [ksh]: 
Uid [1001]: 
Login group git [git]: 
Invite git into other groups: guest no [no]: 
Login class authpf bgpd daemon default pbuild staff unbound xenodm [default]: 
Enter password []: xxx
Enter password again []: xxx

Now you can import the public keys of the developers, by adding them to the file /home/git/.ssh/authorized_keys (one key per line). This process can be simplified with the command ssh-copy-id that is available on Linux systems.

Initialise a repository, in folder /var/www/git-repos:

# mkdir -p /var/www/git-repos/pelican-minimal.git
# chown -R git:www /var/www/git-repos
$ cd /var/www/git-repos/pelican-minimal.git/
$ git init --bare

The folder choice can seem strange but it will allow us to easily publish the repository through a website a bit later. If you want developers to be able to push code with a URL like git@git.vdouillet.fr/git/pelican-minimal, a link does the job:

# ln -s /var/www/git-repos /git

The repository is ready, developers can push code like so:

$ git remote add origin git@git.vdouillet.fr:/git/pelican-minimal
$ git push origin master

Though security is not optimal: developers can open a shell on the server with the git account by using their SSH key. To prevent this, we are going to change the shell of the git account to the git-shell. This shell refuses interactive connections:

# chpass -s git-shell git

It’s better, but developers can still use port forwarding. This can be disabled by prefixing each key in the authorized_keys file you edited earlier with the following text:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Public access

To make the repository publicly available, I’ve chosen to use cgit. It’s a CGI script for a web interface that also allows to clone the repository through HTTP. Let’s first install cgit:

# pkg_add cgit

As noted by the README after installation, you need to create a configuration file /var/www/conf/cgitrc for cgit. See cgitrc(5) for the complete list of parameters, here is a basic file that exposes only one repository:

repo.url=pelican-minimal
repo.path=/git-repos/pelican-minimal
repo.clone-url=http://git.vdouillet.fr/pelican-minimal
repo.desc=minimal pelican theme

The httpd web server still needs to be configured, the sample configuration from cgit’s README works just fine, so I copied it into /etc/httpd.conf:

server "git.vdouillet.fr" {
    listen on egress port 80

    # don't serve static files from cgit CGI: cgit.css and cgit.png
    location "/cgit.*" {
        root "/cgit"
        no fastcgi
    }
    root "/cgi-bin/cgit.cgi"
    fastcgi socket "/run/slowcgi.sock"
}

Finally, launch the two required daemons httpd and slowcgi:

# rcctl enable slowcgi
# rcctl start slowcgi
# rcctl enable httpd
# rcctl start httpd

The repository is now available via git.vdouillet.fr.

Constructive feedback is welcome on Twitter.

Sources

• Git online book
• cgitrc(5)
• OpenBSD cgit package README