Today, I received the redundancy letter. End of November, I'll be free.

13 full-time years… doubt I'll have that sort of innings again. (Plus a couple as a contractor, so 15 in total.)

Not in a rush for a new position, and to be honest in this job market, I'm not certain one will come up… but some time in 2027, I'll be starting to look around again.

Worth noting that this isn't my first foray into XMPP. I did use it about 20 years ago, using OpenFire XMPP server. OpenFire now has some LLM slop in it, whereas ejabberd is clean (for now).

Apparently ejabberd also supports Matrix, so maybe if I do formally decommission the Matrix server I set up, I'll just migrate to using my XMPP server for joining Matrix.

The test channels I set up, I'll see if I can bridge them between XMPP and Matrix too… but for now, I'm just waiting for `pkgsrc` to do its thing.

6 months ago, I stood up a #Matrix server using synapse and #OpenBSD as an experiment for Brisbane WICEN.

Matrix is great, feels a lot like Slack in terms of how it operates from the user. The fact it supports end-to-end encryption out-of-the-box is good for those that need that.

Not so great is its insistence that this be mandatory: the user has to be knowledgeable enough to back up their private key somewhere and know how to upload it back in, or have an existing client logged in that can "vouch" for any new client that logs into their account. I feel this will confuse and confound some of the less technical members of our group, so maybe not quite the holy grail I was after, but very close.

I won't ditch the server just yet, but time to evaluate something else: #XMPP. I've just installed #NetBSD (because, stuff LLM slop) on a VM, and I'll start working through getting ejabberd going.

XMPP isn't as far ahead on the many-to-many video chat that Matrix is (still in the design phase for XMPP, whereas Matrix Call has a working proof-of-concept based on LiveKit), but it is stable and well supported, so we'll give it a look.

```
Your request for Annual Leave for the period 31/8/2026 - 15/9/2026 has been
approved.
```

…ahh and we use up the annual leave too. Good, good. I guess I'll be packing up the desk tonight as I don't fancy lugging it home on the train tomorrow.

```
Your request for Long Service Leave for the period 16/9/2026 - 26/11/2026 has
been approved.
```

Thank-you!!! One last stint before I'm out the door and hitting up the #FediHire tag.

Mucking around with #CoW this afternoon to slowly migrate my #FVWM set-up.

It's showing some great promise. The new menu features are letting me do most things I could do in FVWM. I need to figure out a few things, but I might be able to jump ship to #Wayland some day. Some of these things relate to CoW and others are more general of Wayland.

1. I do use FVWM as a manual tiling window manager quite a lot, and have shortcuts that split the desktop area in halves or quarters, with windows being placed on one half or one quarter of the screen. FVWM gives me a lot more freedom than a dedicated tiling WM like Awesome (which I tried for a while).

For this to work, I've got to figure out how to window-resize a window to half the viewport area; using CSS parlance for example to split the screen vertically and put a window on the left half; I move it to 0vw,0vh and resize to 50vw,100vh. Bottom-right I have to move to 50vw,50vh and resize to 50vw,50vh.

Haven't figured out how to do that yet, I need to compute the 50% somehow, and also account for frame borders. Might be doable with a script that calls `moocow` but I'll have to investigate.

2. Bringing up a window list temporarily like the old FVWM `WindowList Root c c`; so I can just choose a number for the window of interest and it closes the menu and switches. Right now I'm using `cowiconman`, but that's not quite there. Again, maybe some external tool is the answer.

3. Enumerating the XDG menu tree, or spawning a launcher that can do that (most seem to emulate the "run" box in Windows with some auto-complete smarts… never did find one that worked the way I'd like) — need to see if maybe I can pipe commands in like FVWM's `PipeRead` to integrate `fvwm-menu-desktop`.

4. (for my tablet) Decent on-screen keyboard *with* all standard keyboard keys… the set up I use now is Onboard (which is X11 only) with the IBM Model M theme and a 6 row layout including arrows, CTRL/ALT/shift and function keys.

5. Need to find a good replacement for XScreensaver. Maybe something that can work with an on-screen keyboard too.

Whilst researching this, I had a look at some of the libraries out there to see how they do it on different operating systems.

Microsoft Windows and Apple MacOS X provide system APIs for doing this.
On Linux, some libraries go poking around in `/dev/serial/*`, others go nosing through `/sys/class/tty/*`. Some just look for specific names in `/dev` and hope for the best. `pyserial` also checks `/proc/tty/drivers` on Linux, but everywhere else in POSIX land it uses `glob`.

Most do not consider BSD at all. You're on your own to learn what serial ports your computer has. It's a mess.

#NetBSD has a `/kern` virtual filesystem which is similar to `/sys` in Linux… so there *is* scope there to maybe put some sort of virtual text file that dumps a mapping of devices and what device nodes they're at. My mind also thinks about OpenFirmware's DeviceTree.

BSD in general, has the same problem Linux had years ago: it assumed the hardware never changed. In the 80s and 90s, that was mostly true, your devices were hard-wired into "busses". You mostly ignored that there was a ISA bus, you just "knew" you had a device at address 0x300 and "talked" to it. It was there at power on, and there at shutdown.

SCSI was a little more complicated, you spoke to your disk drive *through* this HBA card.

Then came along Firewire, USB and Bluetooth. Devices could come and go as they pleased. Moreover, USB is a tree structure and Bluetooth is a mesh radio network. A flat structure doesn't quite describe the situation. I'm seeing a lot of wisdom behind the idea of Open Firmware's DeviceTree… and it seems to me, the kernel of a modern OS needs to track a live changing representation of this. A big part of keeping track will be providing a mechanism for the userspace to learn of changes in this tree, and to find where things are.

While I don't expect them to wholesale copy Linux, I think there is merit in the kernel calling a userspace application to "set up" devices when they are detected, and "tear down" those devices when they are removed.

This is `udev` in Linux and it is very handy even if it can be a pain in the bum to debug.

I've also seen the virtual `/dev` filesystem route used. Linux used to have `devfs`, and SyllableOS also used such a system. Not saying that's the best approach, but it is another way of exposing this information to the system.

Not sure which is the "right" approach, but I don't think a static "nothing ever changes" approach is viable here.

Playing around with #NetBSD again… so I have a Intel NUC running it. One of the thing I frequently have to deal with, being an embedded software developer *and* an amateur radio operator, is #SerialPorts.

More often than not, USB serial ports. Now, I'm used to the Linux way of doing things, where everything is accessed through a /dev/tty* device.

We used to do it the BSD way with a device like /dev/cua0 (16550 UART on ISA 0x3f8 IRQ 4; COM1 for you DOS people) being your serial port ignoring carrier detect, and /dev/ttyS0 was the same serial port but required CD to be up. This got deprecated years ago, so /dev/cua0 disappeared, and we were left with /dev/ttyS0.

I grabbed a test rig I made for work, this is Zephyr RTOS on a Raspberry Pi Pico. It enumerates two CDC-ACM serial ports, one with the Zephyr shell, and the other is a USB serial port. You use the shell port to tell it how to route the RXD/TXD lines on the other serial port, with the board supporting RS-485, RS-422 and TTL serial. On Linux, it shows up as `/dev/ttyACM${n}` and `/dev/ttyACM$(( ${n} + 1 )`. `udev` also creates these symbolic links:

```
stuartl@rikishi ~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jul 26 10:58 usb-WideSky.Cloud_Pty_Ltd_WideSky_Hub_Test_Rig_E663AC91D3665F30-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul 26 10:58 usb-WideSky.Cloud_Pty_Ltd_WideSky_Hub_Test_Rig_E663AC91D3665F30-if02 -> ../../ttyACM1
stuartl@rikishi ~ $ ls -l /dev/serial/by-path/
total 0
lrwxrwxrwx 1 root root 13 Jul 26 10:58 pci-0000:00:14.0-usb-0:2:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul 26 10:58 pci-0000:00:14.0-usb-0:2:1.2 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Jul 26 10:58 pci-0000:00:14.0-usbv2-0:2:1.0 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul 26 10:58 pci-0000:00:14.0-usbv2-0:2:1.2 -> ../../ttyACM1
```

This is handy because if I have two of these, it doesn't matter which gets detected first, I know which device is which. The links ending in `-if02` or `.2` will be the data port, and the `-if00` / `.0` ones will be the shell control port.

In NetBSD, I plug this same MCU in and I get 4 devices:
- `/dev/dtyU0`
- `/dev/dtyU1`
- `/dev/ttyU0`
- `/dev/ttyU1`

The files actually always exist, but they get mapped to this physical device when the driver detects it and enumerates it on USB.

If I plug in another dongle, I get another pair, a `/dev/dtyU2` and a `/dev/ttyU2`. The choice of `/dev/dtyU[012]` is dependent on which order the devices is detected… which on USB is indeterminate as they can be hotplugged.

The only clue I get is the `usbdevs -v`; it shows a device number and serial number information.

```
vk4msl-nbsd# usbdevs -v
Controller /dev/usb0:
addr 0: super speed, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
port 1 disabled
port 2 disabled
port 3 disabled
port 4 disabled
Controller /dev/usb1:
addr 0: high speed, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
port 1 powered
port 2 addr 17: full speed, power 100 mA, config 1, USB-Serial Controller D(0x2303), Prolific Technology Inc.(0x067b), rev 4.00(0x0400)
port 3 addr 1: low speed, power 100 mA, config 1, CASUE USB KB(0x6a21), vendor 2a7a(0x2a7a), rev 0.01(0x0001)
port 4 addr 18: full speed, self powered, config 1, WideSky Hub Test Rig(0x5678), WideSky.Cloud Pty Ltd(0x1234), rev 4.03(0x0403), serial E663AC91D3665F30
port 5 powered
port 6 powered
port 7 addr 3: full speed, self powered, config 1, product 0a2a(0x0a2a), Intel(0x8087), rev 0.01(0x0001)
port 8 powered
port 9 powered
port 10 powered
port 11 powered
…
```

lacking is the knowledge that there are *two* devices allocated to device 18 (the test rig).

Given a `/dev/ttyU${n}` or `/dev/dtyU${n}` device node, how do I find out about the device attached to it? Seems assuming a device node is fraught with danger.

RE: https://mastodon.world/@funhouseradio/116972659438868307

I can see @futurebird reciting: "ants are friends, not food!" ;-)

Hmm, so gfortran (part of the gcc suite) now has slop in it.

https://slopscan.ava.pet/repo/https%3A%2F%2Fgcc%2Egnu%2Eorg%2Fgit%2Fgcc

Of course it's got a long way to catch up to LLVM…

https://slopscan.ava.pet/repo/https%3A%2F%2Fgithub%2Ecom%2Fllvm%2Fllvm%2Dproject

Given Zig uses LLVM, I wonder where that puts them?

#NoLLM #gcc #fortran #llvm #zig

Checking the #CopyFail #CVE_2026_31431 status on #AlpineLinux, again nothing heard officially from @alpinelinux but I did see this:

https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/4#issuecomment-4354558846

Maybe the issue has been quietly dealt with or was never an issue to begin with? It'd be nice to know for certain.

Now that I've had some time to wake up…

ICNS: Apple Icon image format — https://en.wikipedia.org/wiki/Apple_Icon_Image_format
PGM: netpbm Portable Greymap Format — https://en.wikipedia.org/wiki/Portable_Graymap_File_Format
XWD: X Window Dump — https://en.wikipedia.org/wiki/Xwd

I guess XWD meets the "legacy" tag given the X window system is nearly as old as I am… `netpbm` is a rather handy command-line suite of image processing tools that is current maintained open-source software and ICNS is the current format used by Apple MacOS X for its icons.

I guess you might deal with ICNS if you're doing software development for Apple systems. PGM might come up if you've got an image processing pipeline in a shell script.

I can't think of where you'd use XWD, there are easier mechanisms for taking a screenshot that don't involve esoteric formats.

RE: https://social.heise.de/@heiseonlineenglish/116119657532773300

Gimp users: beware of dodgy operators offering ICNS, PGM or XWD files. There is a remote code execution exploit. Patch first! #InfoSec #Gimp

RE: https://mastodon.social/@VeroniqueB99/115918603027941868

In the interests of Science… what's your age group?

DuckDuckGo is running a poll on whether people are in favour of "AI" or not.

https://duckduckgo.com/vote/

#AI

This is a bit worrying for a few reasons:

1. the US is actively discouraging the use of vaccinations for common respiratory conditions, making the population more susceptible to infection
2. surveillance of these conditions has been wound back in the US, reducing the chances of new strains being detected early
3. the protections in the US for workers who fall ill are practically nonexistent, with workers often forced to work whilst ill
4. legislators preoccupied with promoting "raw milk" (drinking raw milk from an infected cow is a sure-fire way to cop a dose of H5N1 yourself!)

https://www.sciencefocus.com/news/bird-flu-2026-analysis

We're already seeing a "summer wave" of Influenza (the K variant) due to a strain that is a poor match for the 2025 shots. This can be seen in hospitalisation data already (Queensland Health: "88 people were in hospital with Influenza, 50 (57%) were aged 65 years and above.").

Hopefully the Australian CDC is on the ball, and not here to do dirty deeds dirt cheap.

#H5N1 #Influenza

I wonder if we'll be reciting this quote back to China in the event they invade Taiwan? I guess we'll see.

https://www.abc.net.au/news/2026-01-04/how-world-leaders-reacted-to-venezuelan-strikes/106197592

#China #Taiwan #Venezuela

Well… all the lights are off here, the TV set turned off… the new video recorder has a show scheduled to record, we'll check how that went tomorrow.

In a bit over 4 hours, we'll tick the new year in and I plan to be snoring it in.

Probably the thing we'll do tomorrow: go for a walk… not sure where, but it seems sensible that we get out into the open and get some exercise in… too much Christmas cake hanging around the gut to be couch potatoes.

I'll have to re-start my exercise program that I had going last year… it got de-railed by a combination of house renovations and Cyclone Alfred.

2025 has been a shitter of a year. While 2026 is probably standing off to the side waiting to say: "hold my beer and watch this!" I'm still in my rights to hope that it'll be a better one than the last 12 months.

#HappyNewYear

Had some fun and games with my VPS today. It's an OpenBSD machine on BinaryLane in their Brisbane data centre.

I was using the bottom tier plan, which was working okay, but the disk (20GB) was a bit tight. For a small fee, I could up it to 30GB, which would allow me to move `/var/www` into its own partition and give me some breathing room. I'm contemplating setting up Matrix on there too.

The fun bit: I had used `fdisk -e sd0` to resize the OpenBSD partition to the full disk, but `disklabel` wasn't seeing it, even after a reboot.

Turns out, when you run `disklabel -E sd0`, in order to "see" and utilise the rest of the space, you need to use the `b` command to extend the OpenBSD boundary to the rest of the disk. After that, adding a couple of partitions, running `newfs` on them and adding them to `/etc/fstab` was plain sailing.

#OpenBSD

Heads up for the BlueSky people… if you see a identifier ending in `ap.brid.gy`… we might see your replies, but we won't be able to respond to you because we're not *actually* on BlueSky. To interact: follow `@ap.brid.gy` and we'll be able to converse properly.