I’ve been playing around with a new infrared library for Arduino - IRMP, as I wanted a project to make use of the TTGO Display I got - the ESP32 devboard with a built-in TFT and LiPo charger. I never had any luck previously with the IRRemote library. I’ve made a proxy or repeater that reads a remote code that you teach it by pointing a remote control at it, and then it replays it to the TV or whatever.

I’ve made the final iteration of my earlier Tiny LED Strip Driver project. I made the PCB in Kicad and sent it to be fabbed at JLCPCB for under a Pound per board, delivered in under two weeks! Schematic: PCB: 3D render: I then used Fusion 360 to make an enclosure for it. That wasn’t as easy as I thought, but I think I still have some things to learn - for example extruding the screw terminals from the PCB STEP file to make the holes in the case didn’t update when you moved the PCB up a bit to give more clearance.

Today I finally got my macOS Catalina VM working again on Debian Sid. I basically did a complete fresh install using macOS-Simple-KVM, tweaked some settings, imported it to virt-manager then optimised. Looking at it, what was breaking VFIO on 5.6/5.7/5.8.0 (yes I even compiled 5.8.0-rc5!) was probably the clock/pit settings, as kvm-pit using a lot of CPU was one of the symptons of the crashing, qemu did the whole install fine, then as soon as I imported into virt-manager it crashed.

In my earlier post about ELK over TLS, I left syslog as plaintext over UDP. I’ve since been looking into how to use TLS to encrypt the TCP transport for syslog, and mutual authentication using certificates as laid out in RFC 5425. I’m not really interested in using DTLS. I just happen to be using the same VM as the CA and the rsyslog server, but the CA server should be a totally separate machine, probably even air-gapped; the client is a different VM.

After the recent shenanigans regarding macos VFIO being broken in 5.6/5.7 kernels, the Debian qemu 5.0-6 package stopped booting macos whatsoever! Rolling back to 5.0-5 fixes things, as does compiling from source the release tagged v5.0.0 or even v4.2.1 So I raised a bug report to the Debian packagers, who identified the patches they got from upstream since 5.0-5 but with no real idea which one broke things. Next I raised a bug on the upstream qemu launchpad where they recommended a git bisect, which basically consists of working backwards from git/master to tag/v5.