I have followed M5Stack for years and have a couple of their ESP cameras running, plus one of the original stackable Core modules (complete with battery) somewhere in a drawer, but I had not written code for any of them in quite a while (the cameras are running ten-year-old code at this point, I think, and have been rock solid).

Getting my hands on a Tab5 was completely random, but I spent the next couple of weeks trying it as a Home Assistant terminal, a firmware playground and, unexpectedly, a tiny HDMI monitor.

Disclaimer: M5Stack sent me a review unit of the Tab5, for which I thank them. And, as usual, this article follows my review policy.

I have a weakness for portable gadgetry, and the Tab5 is very much to my tastes–it looks like a chunky little Android tablet and boots into something closer to an industrial HMI, with a polished demo app that lets you test all the sensors and hardware, but underneath it is “just” an ESP32.

Except this is the ESP32-P4, rather than the somewhat vanilla chips you get with cheap yellow displays, and it can plausibly drive a 720p MIPI display and a camera while handling audio. The CYD boards are pretty good bang for the buck, but even before I started abusing them for emulation I spent most of my time fighting their constraints–a slow parallel or SPI panel, single-digit megabytes of PSRAM and a UI that visibly lurches whenever Wi-Fi wakes up.

I did not run into those problems with the P4. The Tab5 adds a MIPI-DSI panel, 32MB of PSRAM and a dedicated ESP32-C6 radio co-processor, and feels much closer to a small Raspberry Pi than to a vanilla ESP8266.

There is, of course, a catch–the slot-in battery makes the Tab5 grow from 128x80x12mm bare to 128x80x31mm, and mine went from 118g to 230g with the third-party battery I used.

The Tab5 is a little constellation of chips:

• ESP32-P4NRW32 with two 360MHz high-performance RISC-V cores and a separate 40MHz low-power core
• ESP32-C6-MINI-1U radio co-processor over SDIO, providing 2.4GHz Wi-Fi 6, Thread and Zigbee
• 16MB flash and 32MB octal PSRAM
• 5-inch 720x1280 portrait-native IPS panel over MIPI-DSI, with capacitive touch
• SC2356 2MP camera
• ES8388 audio codec, ES7210 ADC, dual microphones and a 1W speaker
• BMI270 six-axis IMU and RX8130CE RTC
• IP2326 charge management and INA226 current/voltage monitoring for an NP-F550 7.4V 2000mAh (14.8Wh) battery

Besides a 3.5mm audio jack (a thing that Apple still seems unable to include in its devices), it has a pretty impressive array of connectors:

• microSD slot
• USB-C with USB 2.0 OTG
• USB-A host port, which is unusual enough on an ESP32 device
• RS-485 via a SIT3088, with a switchable 120-ohm terminator and 6-24V input
• 30-pin M-BUS connector that harks back to M5Stack’s stackable module line
• a small menagerie of Grove-style connectors for specific applications, including access to the USB bus
• two software-selectable MMCX ports complementing the internal antenna

Besides the (always awesome) way in which M5 tends to label their devices, there are two things about the form factor that deserve to be called out.

The first is the NP-F550 slot–yes, the classic Sony camcorder pack people my age typically have three of in a drawer. The batteries are cheap, hot-swappable and available everywhere, which is a smart bit of BOM design even if they do make the assembled setup chunky.

I did not have any, so I got two USB-C rechargeable packs that were already on my “someday” list for powering a camera light, and they fit perfectly:

M5Stack quotes the Tab5 at 118.4g bare and 217.3g with their standard battery kit; my third-party USB-C battery brings it to 230g.

The second thing is the 1/4-inch tripod mount next to the microSD slot. Together, the battery and tripod mount make the Tab5 feel like a field device, while the sheer number of connectors still makes it useful on the bench. There are also six threaded inserts around the edge and four around the M-BUS connector, giving you plenty of options beyond the tripod mount.

I didn’t open mine, but according to CNX Software’s teardown, there is a flexible PCB carrying the GT911 touch controller, the SC2356 on an FPC cable and the C6 module wired to both the internal 3D antenna and external MMCX connectors–so tearing it down seems like a lesson in patience that I decided to forego.

This is probably the first ESP device where this kind of testing is warranted, since the P4 is passively cooled inside a sealed handheld with a 0-40°C rated operating range. In casual use–UVC viewer running, screen at full brightness–the bottom gets noticeably warm, but not alarmingly so–I measured 39°C after half an hour of continuous use, though.

As I pointed out above, out of the box the Tab5 runs M5Stack’s demo firmware with a launcher-style UI, and as usual with their products, you are probably best served by using ESP-IDF–the P4 needs a recent release, and the C6 relies on esp_hosted plumbing. Arduino support is always a little iffy on fresh SoCs, but the option is there already.

But M5Stack also provides an entry-level UI for education and entry-level coding called UiFlow2, which lets you use blocks or MicroPython instead of C.

Yet, before you write any of that, you have to flash it, and this is where M5Stack lost me a little, because M5Burner for the Mac is still an Intel-only binary in 2026. It runs on Apple Silicon under Rosetta, but I had to run:

xattr -d com.apple.quarantine /Applications/M5Burner.app

…just to get past Gatekeeper, and I got this semi-persistent reminder:

Additionally, it insists on living in /Applications rather than running from wherever you unpack it like a well-behaved modern Mac app, and has that unmistakable Electron heaviness–slow to launch, sluggish to draw and memory-hungry for what is fundamentally a catalogue-based serial flashing tool–but I will grant that it is a nice and practical one:

None of the above stops you from using it, but it is a bit of a disappointment from a company whose hardware is very polished.

I did most of my actual development in Linux, though, where esptool.py is, as usual, the escape hatch and I could hack into the ESP toolchain at leisure and play around with a few projects I found interesting.

The ESP-IDF SDK runs just fine on ARM, and it took no time at all for me to get my Orange Pi 6 to figure out how to get some test patterns on the screen (as usual, I just pointed a camera at the display, told my AI agents what I wanted, and they set up the basic LVGL scaffolding in no time):

Besides all the other stuff that I was already doing with cheap yellow displays (including my R-Type port, which runs on this at around 33fps without any real optimisation), I went down a few interesting rabbit holes:

Even though I don’t use Home Assistant myself, I am very much interested in ESPHome these days because of voice agents, and ESPHome supports the original Tab5 revision, including the C6 radio, MIPI-DSI display, GT911 touchscreen, ES8388/ES7210 audio path, RTC, IO expanders and battery monitor.

And the microphones run at 16kHz through its AEC front-end, which makes the board a very nice local voice terminal that is directly supported in Home Assistant.

But as it turns out there are two display revisions: My unit uses the ILI9881C display driver and GT911 touchscreen, detected when the GT911 answers at I2C address 0x14. Later units use ST7123/ST7121 parts, detected through the display controller at 0x55, and ESPHome does not support those yet. If ESPHome is the reason you are buying one, check the display revision first.

Besides my own Mac Plus core, I also tried the Basilisk II port, which can run classic 68k Mac OS on the P4 in living colour. It is slow, but a US$60 RISC-V terminal pretending to be a Macintosh at all is pleasantly absurd–and after the contortions involved in getting Mac emulation and arcade games to behave on CYD-class hardware, having enough memory and display bandwidth to make it viable (even if slow) felt like quite a leap.

A UVC host viewer turns the USB-A port into a video input, and plugging in a cheap UVC/HDMI capture dongle turns the Tab5 into a standalone HDMI monitor. This is where the tripod mount stops being a curiosity and becomes the point: screw it onto an arm or mini tripod, connect the capture dongle, and you have a self-contained, battery-powered 5-inch 720p monitor for a camera, a headless server console, a Raspberry Pi or a retro machine.

Latency is fine for a console or a slow-moving camera feed, and the screen is sharp enough at 720p. For the price of the Tab5 plus a cheap capture dongle, it is a useful field monitor that doubles as a hackable computer the rest of the time, and I make it a point of reflashing the UVC firmware between experiments–the USB-C rechargeable NP-F550 pack makes it perfect for emergencies like figuring out why your headless box won’t boot.

But the thing I am really keen to get working on this is an M8 Tracker display–I have a “headless” M8 that needs a computer to both render the display (via its own protocol, implemented in m8c and other clients) and provide audio out, and I have been trying to get the Tab5 to do that:

Right now the biggest problem I have is the ESP-IDF USB stack, which is very confused by the fact that the Tab5 not only has a little USB hub on its host USB-A port, but that the hub also has a particularly challenging combination of a data port, an audio and MIDI device and a keyboard–three things the stack struggles to manage and initialise consistently.

This is not a Tab5 hardware problem, but the Espressif SDK was clearly never designed to cope with this kind of situation, so even though I can get the display protocol going and (apparently) the audio, the highly custom keyboard doesn’t seem to be recognised and I can’t get the Tab5 to send control events back into the Teensy inside the keyboard…

I have not run formal benchmarks, but all the data I have points to the P4 being 2-4 times faster than the CYD devices I had, although that will depend a lot on what you get each core to do and the use you make of PSRAM.

In lieu of more scientific numbers, here’s a chip-level comparison for the three SoCs in the Tab5 and the CYD boards I have been playing with, and what little I was able to glean from the research I did on the YOLO/vision ports I’ve yet to play around with:

Poking around with the R-Type hacks, I’d put the very rough relative performance estimates like so, taking into account the optimisations I tried to do:

The bottleneck for all of this is memory bandwidth, not clock speed, CPU architecture or even display rendering. All of the stuff I tried (Cydintosh/R-Type/M8) tried to push a full framebuffer through PSRAM every frame, with different optimisation techniques like using SIMD for blitting, and I don’t think you can do a lot of data transfer on the smaller displays at anything resembling decent speed, so the Tab5 wins out on that alone even considering its display is comparatively huge…

The P4’s 360 MHz cores and cache should give it a substantial scalar speed-up, but its nicest trick is the PPA 2D accelerator (hardware blit/scale/rotate) offloading the exact framebuffer work the others do in software–that’s why the Tab5 was able to render at 33 fps on a 720×1280 panel while also running an HS-USB host for the M8.

The Tab5 is a very nice device for prototyping just about anything you’d like to do with an ESP32, as long as you don’t need 5GHz networking.

Having a camera and decent microphones is already enough of a distinction, but the plethora of connectivity options that M5Stack provides will enable you to do away with dozens of wires and additional glue chips on the first iterations of any hardware project, and for that alone I’d say it’s worth the asking price.

However, and since I came from lower-performing devices to it and had to slog my way through a lot of slow, painful debugging before switching to the Tab5, do keep in mind that you’ll be spoiled by its performance and smoothness if you intend to develop something that will run on a cheaper display. The touch screen is buttery smooth, the LVGL rendering performance is great, and, of course, iterating on anything is always faster when you have fast hardware, but take the time to optimise your code heavily if you need to target something smaller.

But hey, it’s still a remarkable achievement. A fast MIPI-DSI display, a camera, a proper audio path and enough PSRAM to run a full 68k Mac emulator now fit into a sub-US$70 ESP32 device instead of a Raspberry Pi, and that is an excellent thing.

The hardware is unusually practical, and, again, I am loving having that ingenious UVC viewer hack around to test other stuff when I’m not doing ESP development–that alone might be more than enough reason to get one if, like me, you keep having to test random SBCs.

The only downside for Mac users is that M5Burner feels like it escaped from a much less polished product, but to be honest I suspect that won’t be a problem for long, and that most people using it are probably on Windows. But I couldn’t let that go unmentioned.

So I thought it would be a good idea to have a policy in place to make sure everyone is on the same page:

1. I don’t do paid reviews. I realize there is a fine line between getting “free” stuff to review and being paid to review it, but I’m not interested in crossing it–this site does not generate any form of income for me, and I’d like to keep it that way.
2. I only review things I have a personal interest in (i.e., things that I would ordinarily have an actual use for, learn from or would otherwise consider buying) or that would be interesting for the people I occasionally provide consulting services to.
3. I don’t do scripted reviews (i.e., there is no content placement, I write about the features I find important, etc.)
4. There are no editorial tweaks–vendors get to read my reviews at the same time as the general public.
5. I don’t participate in vendor affiliate programs–I’m OK with handing out discount codes or linking to the vendor’s site with a utm referral tag (so they can check attribution), but other than my usual (automatic) Amazon/AliExpress linking (which I started using for books decades ago and now do for electronics components), there are no other affiliate links on this site to ensure I don’t get any direct revenue from the reviews.
6. When applicable, scripts used for performance measurements and benchmarks will be published here or on GitHub.
7. Benchmarking will be focused on the aspects I value (although I will try to use standard tooling where appropriate).
8. I review what’s “in the box”, not what’s promised for future releases or what might be available in a future version.

I’m also open to reviewing books–I’ve done pre-publishing reviews in the past, and I’m always happy to read and review books on topics I’m interested in.

I have also recently started a YouTube channel called @TheTaoOfTech that I am slowly populating with videos that complement the content on this site. I will try to keep the same review policy there, although I might do some sponsored videos in the future (but I will always disclose that).

So if you have something you’d like me to review, please get in touch and we’ll take it from there.

Many people ask me about page views, statistics, Google rankings, etc. This is what I have to say about it:

• This site does not use Google Analytics for privacy reasons, nor any other mainstream analytics or tracking platform. The flip side of that is that it is (incorrectly) down-ranked in just about every single public site ranking.
• It does, however, use Cloudflare Analytics, which is privacy-preserving and a more accurate than most other tracking sites because it automatically filters out bots, referrer spam and other things that contribute to site traffic inflation. However, it can provide some interesting figures (updated for August 2024):
  • Over 2M monthly pageviews (and steadily rising).
  • Over 110K unique human visitors per month, mostly from the US, UK, Germany, and Singapore (if I add in figures from Japan and Australia, I get almost as much traffic from APAC than from the UK, which has always been interesting to me).

You can check this PDF for a sample Cloudflare traffic report.

This audience reach comes down to four main factors:

• My emphasis on consistently solid technical content–which ensures continued reader interest.
• No fake audience engagement on site (I interact with readers directly via e-mail correspondence)
• Posts are automatically broadcast to X/Twitter, Mastodon and a few sites that consume my RSS feed directly.
• I get a lot of traffic from places like Reddit, Hacker News, etc. (especially when I post something with an unusual technical angle).

All of my posts are automatically broadcast to my X/Twitter and Mastodon accounts, and I also post occasional links to my LinkedIn profile.

I am also (slowly) starting to produce YouTube videos. This will be a slow process, as I am not a professional video editor and I have no intention of becoming one. I will, however, try to produce some videos that complement the content on this site, and am curious to explore the medium a bit more (and not just in Youtube).

Links to all my social and video accounts can be found on the site footer.

This is a non-exhaustive list of things I’ve reviewed in the past:

Date	Category	Link	Notes
2026	Accessories	Logitech Combo Touch (long-term)	Purchased by me (discount from Logitech)
	E-ink Readers	The Xteink X4	Purchased by me
	NAS	YouYeeToo NestDisk	Supplied by YouYeeToo
	SBCs	Orange Pi 6 Plus	Supplied by Orange Pi
		MilkV Jupiter 2 / SpacemiT K3	Supplied by Radxa
		M5Stack Tab5	Supplied by M5Stack
2025	3D Printing	Polyphemus Filament Dryer	Supplied by EIBOS
	Accessories	The Maclock	Purchased by me (AliExpress)
	Apple	HomePod Mini
	E-Ink Tablets	SuperNote A6X2 Nomad	Supplied by Supernote, six month review
	E-ink Displays	The TRMNL (DIY Everything Edition)	Purchased by me from Seeed Studio
	Homelab	Sipeed NanoKVM Cube
		JetKVM	Supplied by JetKVM
	Laptops	MiniBook X N150	Supplied by Chuwi
	Mini-PCs	iKOOLCore R2Max	Supplied by iKOOLCore
		Chuwi LarkBox S	Supplied by Chuwi
		Chuwi AuBox 8745HS	Supplied by Chuwi
	Music	ESI Xsynth	Supplied by ESI
	Networking	Sodola SL902-SWTGW218AS	Purchased by me
		Cudy AX3000 Wi-Fi 6 System	Purchased by me (multiple units)
	SBCs	ArmSoM AI Module 7	Supplied by ArmSoM
		Orange Pi RV2	Supplied by OrangePi
		ArmSom Forge1	Supplied by ArmSom
		LattePanda Mu	Supplied by DFRobot
		LattePanda IOTA	Supplied by DFRobot (expansion boards included)
2024	3D Printers	Two Trees SK1	Supplied by Two Trees
		Two Trees SK1 Enclosure Kit
	Accessories	3DConnexion SpaceMouse Wireless
	Gaming	Logitech G Cloud
		BSP D8 Bluetooth Controller
	Homelab	AURGA Viewer	Supplied by AURGA
	Keyboards	Logitech K380
		Keychron K7 Max	Supplied by Keychron
		Keychron K11 Max	Supplied by Keychron
		Keychron K2 HE
		Hexgears Immersion A3	Supplied by Hexgears
	Mini-PCs	AceMagic AM18	Supplied by AceMagic
		GMKtec G2
	NAS	CM3588 NVMe NAS Kit	Supplied by FriendlyELEC
		TerraMaster F4-424 MAX	Donation
	Networking	TP-Link L-SG108E
		wisdPi WP-UT5 5GbE USB adapter	Supplied by wisdpi
		SL-SWTG124AS	Supplied by Sodola
		SL-SWTGW218AS
	SBCs	Orange Pi 5+	Supplied by Orange Pi
		YouYeeToo R1	Supplied by YouYeeToo
		Orange Pi Zero 3	Supplied by Orange Pi
		Banana Pi M7	Supplied by Banana Pi
		Luckfox Pico Mini B	Supplied by Luckfox
		Radxa X4	Supplied by Radxa
		XPI-3566-Zero	Supplied by Geniatech
		Banana Pi M5 Pro	Supplied by Banana Pi
		Debix Model A	Supplied by Debix
2023	3D Printers	Kingroon KP3S Pro V1	two year review
	Accessories	OBSbot Tiny 4K, RODE NTG1
	Android	Lenovo ThinkSmart View
	Apple	Mac Mini M2 Pro
		iPhone 15 Pro, Watch Series 9
	Keyboards	Bluehand
	Mini-PCs	Beelink U59 Pro
	Monitors	LG 28MQ780-B
	PC Builds	ASRock DeskMeet B660
	SBCs	Radxa Zero
2022	Android	Xiaomi Mi Stick 4K
	Apple	iPad Pro M1
	Gaming	Xbox Series X
		Retroid Pocket 3
	Keyboards	Avatto Folding Keyboard
		Dierya 63, Adafruit Macropad
		Logitech Combo Touch
	Laptops	Lenovo ThinkPad X1 Yoga	Work issued
	Music	Novation Circuit Tracks
		Monome Norns Shield	Built from kit
	SBCs	Banana Pi M2 Zero
2021	Laptops	Lenovo IdeaPad Flex 5
		MacBook Pro 14" (M1 Pro)
	Monitors	LG 34WK95U-W
	Music	Teenage Engineering OP-1
		Arturia KeyLab Essential 61
2020	Laptops	Surface Book 3	Work issued
	Music	Yamaha Reface DX, AG06
	NAS	Synology DS1019+
2019	Apple	iPad Mini 5
		Watch Series 5
	Laptops	Surface Laptop	Purchased by me
	Music	Roli Songmaker Kit, Korg Nanokey Studio
2018	Apple	iPhone XS
2017	3D Printers	BQ Prusa i3 Hephestos	Built from kit
	Laptops	Surface Pro 4	Work issued
	Mini-PCs	Z83ii
2016	Apple	Apple Watch (Sport)	Purchased by me
	Keyboards	Logitech Keys-To-Go
	Mice	Citrix X1 Mouse
	PC Builds	Streacom ST-F1CB WS Black Aluminum Case
2014	Laptops	Acer C720	Surprisingly still working in 2024
2013	Phones	HTC One	Test sample
2010		Samsung Wave 8500	Purchased by me
2009	E-ink Readers	The Sony Reader
2008	Accessories	DisplayLink DVI	Supplied by DisplayLink
	Cameras	Panasonic Lumix DMC-FX33	Purchased by me
	Laptops	Asus Eee PC 901

]]> https://taoofmac.com/space/blog/2026/07/17/1601?utm_content=atom 2026-07-17T16:01:00+00:00 2026-07-17T16:08:57+00:00 Rui Carmo https://taoofmac.com I’m going to get on my soapbox again and call out Apple once more on the extremely limited HomeKit automation experience–and how they can fix 80% of the gripes I have with it by just cloning a small subset of the Shortcuts user experience.

The most infuriating, they-are-so-close annoyance I have with it is that automations can only have one trigger, and extremely basic conditions, to the point where they are effectively useless in real life.

Right now, HomeKit automation is effectively as simple as this pseudo-code:

if office.presence = true
then scenes.office_ambient.light = on

One trigger, one outcome. There are some conditionals, but they are extremely limited:

if office.presence = true
   and schedule = "daytime"
then scenes.office_ambient.light = on

Conditionals are just a schedule and somebody (optionally me) being home, which is not enough for the way people actually live in a house. For instance, I can’t set up logic like this:

if office.temperature.celsius > 27
   and office.presence = true
   and office_window.closed = true
then
   office.heatpump.target = 25
   office.heatpump.mode = cool
   office.heatpump.fan = 50%

This is the sane way to automate a heatpump (obviously), but there is zero way for this to be configured in HomeKit in any way whatsoever. I can, of course, do it “out of band” in Node-RED, but the moment I do that it becomes unfathomable to anyone else in the house.

And yet, it would be pretty much trivial to add both to the Home app (by just stealing the visual if construct from Shortcuts) and to any home hub.

You also can’t have alternate triggers without duplicating the entire thing (or creating scenes for the common outcome, which clutters your scene list):

if office.presence == true
   "I have two presence sensors that actually don't overlap"
   or office.desk.presence == true
then
   office_desk.light = on

And, finally, there is no way to chain automations after a period of time:

if office.presence == true
   and schedule = 'nighttime'
then
   for 3m
      "Turn on the light so I can search for stuff on my desk"
      office_ceiling.light = on
      office_ceiling.light.intensity = 0.5
   then
      "Make it dim enough so I can still find things if I linger"
      office_ceiling.light.intensity = 0.25
   until office.presence == false
      then office_ceiling.light = off

I don’t have any garage doors (so this is a bit of a contrived example), but I can’t tell you how many times I had to step into the office in the late evening for a little while and needed to adjust the lights.

The basic principle would translate to much better and more useful automation overall–if you replace lights with space heaters and times with temperature thresholds, you can cut your power bill by up to 50% (which is what I did last winter with Node-RED).

Complex triggers alone would make HomeKit tremendously more useful:

if tv.power = on
   and input = "apple tv"
   and schedule = "night time"
   and sofa.presence = on
then
   tv.soundbar.volume = 6
   sofa_lamp.intensity = 0.7

And, of course, something like this:

if office.presence = on
   and schedule == "nighttime"
then office_homepod.Siri("Will you be staying long?")
   if answer == true
      ...

…etc. Again, this is not rocket science, and I think the real cause is that nobody at Apple who works on HomeKit actually uses it beyond the basics. I’m willing to bet they use Home Assistant instead…

Google is playing the EU game much better than Apple, but the EU still doesn’t seem to understand how privacy and security work in modern platforms. Letting people swap the onboard agent is being treated much like the ancient argument over shipping/default browsers–politically correct, bureaucratically led and technically much harder than changing a default handler.

An agent may need access to personal data and privileged APIs, and keeping a third-party agent away from things it should not access is difficult–or impossible for some features. The EU’s framing is therefore somewhat stupid, but Apple will have to deal with the same demands (and has already held features back), so Google is setting a lot of useful precedents here. Apple certainly won’t like this.

The implementation combines a Rust core and WGPU/WGSL shaders with a Tauri and React front end–a much better fit for this kind of app than Electron.

The author says it is not yet as polished as Darktable or RawTherapee. It already includes masks, parametric curves, LUTs, HDR merging, noise reduction, lens correction and batch editing.

]]> https://taoofmac.com/space/links/2026/07/16/1320?utm_content=atom 2026-07-16T13:20:00+00:00 2026-07-16T13:20:00+00:00 Rui Carmo https://taoofmac.com

This is going to be the end of an era for me. One of the first things I did with the early versions of Google Earth was wire it up to Vodafone’s mobile network data, producing some genuinely unique–for the time, at least–visualisations of network usage over time.

The hotspots were fascinating to actually see: high schools where kids saturated GSM cells with SMS, highways, sports stadiums, the places where 2G/3G hand-overs kept failing. It was extremely useful to us at the time–far more so than the normal GIS systems–because I could just have a CGI script spit out a .kml file and get “live” data straight onto the globe. I also used gps2geX with a Garmin GPS to build our own overlays.

This is about what I’d expect. If it works, it will seem revolutionary and magical to most people–including in the EU, though that is another matter entirely–and yet I still think they could do better. People like me will carry on using more sophisticated, squirrelly, hacky things, and that might well be all we’re allowed to do in the EU anyway.

To compensate, I ended up writing a fair bit more than usual and taking the time to play around with some novelties (like the new SOTA models). But all this additional personal entropy/dispersion overhead also put me behind on my review schedule, and I have been chastising myself for not turning off as many distractions as possible, reminding myself that all it takes is another interesting project for me to become passionate about work again, and generally trying to do better across the board.

But hey, sometimes welcome distractions literally drop out of the sky.

My new Flashforge Creator 5 Pro arrived this week–if you’ve been paying attention, you’ll know that I have taken my usual long, circuitous (and, let’s face it, miserly) approach to buying a new 3D printer since I started tracking both the Flashforge AD5X and the Snapmaker U1 early last year, and it’s finally here.

I will write a dedicated review when I’ve poked at it enough, but the background story is, in short, that:

• I still quite like (and intend to keep using) my SK1 and KP3S Pro, but have long felt I needed a better printer for technical filaments
• I don’t intend to print multi-colour frippery, but rather to use multi-material printing
• I hate the waste from single-nozzle multi-colour systems, so a toolchanger is the only thing that ever made sense to me
• I took a bet on Flashforge’s Kickstarter because, well, I’m not made of money

Even so, this was something I’d been saving up for since before I got the SK1 as a review unit, so it wasn’t really a splurge or impulse thing–as a somewhat depressing comparison, I have been putting money aside to upgrade my Mac mini for about as long, aiming for a four-year replacement cycle–but after the recent price hikes, I’m now looking at… eight at this rate?

The only thing I regret is that it arrived while my enthusiasm was at a fairly low ebb, so it will take me a while to make full use of it. But at least OrcaSlicer already supports it fully, and even though Flashforge has decided not to expose the full Klipper UI, I have started building a native Swift app (based on an existing Electron app) to monitor it; I essentially tossed UI.md and the Electron source code into a blender, and thanks to Codex and GPT-5.6, I had this working in under four hours:

Following up on my photogrammetry trials from a couple of weeks ago, I took a look at AI-assisted mesh (re)construction, with pretty interesting results:

The papers I found are, as such things go, already somewhat dated (the first and its sibling were published in 2024 and 2025). What surprised me was how trivial the process is.

The mesh above was the result of feeding Hunyuan3D-2 MV a couple of semi-random, non-orthogonal shots of an SBC I found through an image search. It clearly got some of the connectors wrong, but is still much better than my earlier results.

I stumbled upon this completely by accident while researching 3D mesh generation, and to my delight I was able to get Direct3D (which is, incidentally, an unfortunate and nearly impossible name to search for…) to work on my puny RTX 3060, which then led me to Direct3D-S2 and Hunyuan3D-2 MV.

The idea of going straight from diffusion to a mesh (and then using marching cubes) is pretty neat, and even though a bazillion people are using this to create game assets, 3D-print miniatures and the like, having a passable, proportionally correct shim for bootstrapping SBC enclosures from just two photos seems worth poking at–even if some of my friends keep pointing out that I’d have them done by now if I just used a pair of callipers.

At the other end of the process, I’ve decided to reinvent the wheel and bootstrap my own Wayland environment, which is going… slowly. I’ve started by upstreaming some of my changes to IronRDP and have a mostly working solution, although I did spend an embarrassingly long amount of time patching labwc (which is the compositor I’m vendoring) so that it rendered Platinum-like window decorations:

I also had yet another go at getting Shapr3D to run under WINE, but it is so dependent on unimplemented Windows APIs that I gave up after a few hours. I may try again later since I would very much like to have a semi-permanent remote CAD setup, but for now I am content to use my iPad to run it.

Besides maintaining piclaw, I have been poking at Shelf and creating the Flashforge monitoring app I discussed above. Both are native Swift apps, a departure from my usual stance of hacking the least possible amount of code to wrap something as a Mac app.

Neither is fully usable yet, but I’ve learned quite a bit in the process, including that using /goal in Codex to explore the limited printer API and figure out what else we could do can have hilarious effects when it involves running a Swift app repeatedly over lunchtime:

Now if you’ll excuse me, I need to get back to testing some of the hardware that has been piling up on my desk, some of which had to be relocated hastily when I swapped out the SK1 for the Creator 5 Pro and needed to find a new place for it…

Update: Also, a minor home automation note: my hacky doorbell extender finally gave up the ghost after seven years of faithful service because its micro-USB connector got torn off. I replaced it with a Tuya ZA03, but I actually miss the buzzer. Either way, this is a chance to move the debouncer logic out of Node-RED, and another lovely inconsequential-but-satisfactory micro-project to have on hand in case of further workplace madness.

Update, July 16th: This isn’t aging well–for the record, and even though I haven’t yet spent a lot of time with Kimi 3, I’d say you should read the Moonshot AI section with a dollop of salt, because it’s way better than 2.7–but it’s still too early to do a full write-up.

I suspect I wasn’t the only one doing this over the past few weeks, but now that both Fable and Sol are “back”, I decided, as a distraction from the mild chaos at work, to sit down and tidy up my notes while they were still current.

This isn’t a benchmark, and I don’t much care about anyone’s leaderboard: the existing ones are either pointless or gamed (or both), because the numbers stop meaning anything the moment you point a model at a real codebase with a real SPEC.md and real tests.

So take this as a set of caricatures instead–exaggerations of the behaviours I’ve run into week after week, switching between models for coding, auditing and the occasional bout of retrocomputing madness. They’re unfair, as caricatures tend to be, and mostly true.

I can’t help but think that Fable is very, very aptly named, because nothing about it feels quite real.

Opus writes a beautiful UI, tells you everything is done, and breaks three unrelated files on the way out. It is irritatingly fluent, West Coast glib and confident, and often verbose about what it claims it built and wrong about what is actually there–a salesman spinning a beautiful yarn while I check the diff. I’ve had it cheerfully lie about implementing MMU and I/O emulation and then act wounded when I checked.

Its saving grace has been that 4.8 is good at both front-end code and turning a pile of requirements into user stories–even little Sonnet, bless its silly little heart, can do that faster than any committee.

But ask either to write tests and they will plain cheat at them, papering over corner cases and, sometimes, entire chunks of any SPEC.md you throw at them.

Fable, sadly, has been no different, at least not for me.

Opus, despite being the “grown up”, consistently mangled long files, did drive-by edits on tangentially related ones, and has a sycophantic streak I’ve never managed to fully beat out of it. Fable improved on that and certainly feels different, although I may merely not have used it long enough to catch it in the act.

More to the point, Fable seems to ignore entire sections of directives or existing program modules and cheerily duplicate them “better”, not really explaining why. I haven’t (yet) caught it outright lying about its achievements, but I trust it about as far as I can throw Opus.

Sonnet, in general, lies less than Opus simply because it understands and achieves much less (and no, judging by the couple of hours I spent with Sonnet 5, it isn’t much of an improvement), but those shared foibles are, generally, the reason I didn’t particularly regret not having access to Fable for a while.

Older versions could be competent–Opus 4.6 once reverse-engineered an STL into a stupefyingly accurate OpenSCAD file, which is the sort of thing I’d never have managed alone. Then 4.7 shipped feeling lobotomized, and it was plain that Anthropic was nerfing it too much.

And that takes me to a tangential issue that certainly tinges my viewpoint–the part I like least isn’t the models so much as the posture: Anthropic is betting hardest on mainstream adoption while locking you into its own harness, which is of increasingly dubious value when the harness itself becomes context overhead.

That said, I’ve had decent results using both Opus and Fable as a “manager” for OpenAI sub-agents, but the arrangement sometimes worked out about as you would expect: just like a human team, when the GPT models implemented their tasks successfully, the manager spewed out glorious progress reports. When they didn’t, it offered “guidance” that was only marginally useful because it was outside the immediate context the agents were pursuing.

Tier: B. Brilliant and slippery. Keep a diff open and one finger on the cancel button, because it will shove bugs under the rug.

I have a Codex trial subscription for my OSS work, so I’m biased. Judging by Twitter, there are… dozens of us.

GPT 5.5 was already pretty good–output felt like it was coming from a senior engineer who never uses emoji, never pads a reply with adjectives, and finds the bugs in your pull request without making a song and dance about it. I tuned out of Claude the moment I tried the sober, emoji-free GPT 5.x replies, and I never regretted it.

When I make the mistake of letting Anthropic’s models break something, 5.x is what I bring in to audit–the fixes are usually solid, it seldom goes and tramples unrelated code, and in my experience OpenAI models really do clean up after Anthropic ones.

That restraint matters more than it sounds after a few hours spent putting up with Opus’s slop.

It’s the only family of models that writes halfway-decent tests; Codex 5.3 was what made my blog engine port and most of my TDD projects very workable indeed. But it has no taste: it’ll design an API surface that makes sense on paper and is miserable to use, and the family has drifted off a bit since then. GPT 5.4 was less thorough than Codex 5.3, and 5.5 initially felt “worse” in some way I can’t yet pin down–chattier, friendlier, and somehow worse at finding a logic error in a 2000-line file.

In practice, I can give GPT 5.4-mini a SKILL.md file, well-defined tools and a task to do, and 90% of the time it will just work. I could never get anything like that to work reliably with Sonnet.

The 5.x family also seems to have a penchant for building its own scaffolding and tooling, like when 5.4 crafted a visual diff tool to compare site rendering engines rather than trusting either of us to eyeball the output.

Sol (which is the only model from the 5.6 family that I’ve used extensively so far) is very, very good at low-level code–it has been systematically plugging holes in my JIT and emulator stuff not by trial and error, but through static analysis. Like 5.5, it can also use delegate very effectively in piclaw, totally unprompted.

I’ve run it against a few of my ongoing projects, and it not only fixed stuff Fable had gotten wrong, but also came up with a much saner set of API endpoints than the other models–and tested it, with sane tests for the API, the underlying data schemas, and the UX.

I’ve been using 5.5 to go from user stories to Gherkin to Playwright tests in a few steps, but 5.6 just went and did it quickly, end-to-end, for one of my web tools, unprompted other than for the spec.

(Note that I don’t do one-shot prompts–I go through the entire PRD to SPEC to plan cycle, and piclaw supplies models with bare tooling, but the repo this happened in did not have an AGENTS.md file or skills).

Tier: S. The one I trust with sharp objects. It still has no taste, but it gets low-level code right and leaves working tests behind.

We have a myth here in Portugal where King Sebastian, who was lost to us in an epic battle, will one day return from the mists and deliver us.

Well, I don’t think Mistral is likely to do that for Europe, but I sure have tried using it. The model I keep underestimating and the company I keep rolling my eyes at are, awkwardly, the same outfit.

Vibe, their TUI, has been surprisingly capable–it played nicely with tmux, the clipboard handling never once tripped me up, the free tier was generous enough to experiment with, and it ran Mistral inside my agent containers doing real work without much fuss.

For a pairing I only expected to tolerate, it earned a permanent slot until I moved to Codex, and I’d call it a competent, much less snooty Sonnet.

And for a model this unapologetically French, it has one baffling failing: it never once sauntered in like Pepe Le Pew, tail aloft, to christen anything le this or le that. All that Gallic charm on the box, and not one amorous skunk in the actual tokens–the only stray le I ever saw was the brand name on Le Chat. That is to say that it never hallucinated, lied to me, or otherwise tried to gaslight me, and the code was (and is, since I still have access to it in Azure Foundry) unremarkable but competent.

The company is harder to love. Mistral published a 52-minute manifesto on how Europe should build a sovereign AI stack–talent, single-market scale, local compute, the lot–which reads like a policy brief from the company that would most benefit from “buy European” procurement rules.

Mind you, the underlying analysis is hard to argue with. It’s also hard to take entirely seriously from a European company that, at the time, wouldn’t even hire remotely in Europe (Anthropic, by the way, already has a few offices open in key locations–all too distant for me, though).

The irony is that if the Chinese government ever decides to curtail access to models from its own research labs the way Washington just has, Mistral might be the only credible supplier of SOTA models in Europe. And like most European compromises, it would get us absolutely nowhere–unless they are secretly brewing a Fable-class model, which is hardly apparent despite all the “le gros chat” parodies that flooded the net a few weeks back.

Tier: C. The TUI was better than expected; the models are competent enough not to be interesting. The sovereignty sermon together with lack of visible motion is very European indeed.

Gemini is… weird. I have it (via GitHub Copilot) on every machine I use and have reached for it on almost none of them. It rides along in my agent containers “for kicks”, it’s the third pane in a Copilot side-by-side I mostly use to confirm I prefer the other two, and I can’t remember it ever fixing any of the stuff I handed over to Codex–I’ve never found a reason to start selling out to Gemini with actual money.

This leaves Gemini in the least useful category: a model I have everywhere and no reason to choose. It has one strength I’ve pinned down, and an unsurprising one–architecting Go packages–but I’ve never had the patience to see it through a whole project because nothing it did made me want to keep going.

The joke, of course, is that it’s the model everyone is going to use without choosing it: Apple Foundation Models are derived from Gemini, so half the people who’d never install it are running it by proxy. Nobody picks Gemini.

Tier: C. Present everywhere, chosen nowhere. Very Google.

DeepSeek is, thanks to Salvatore Sanfilippo, now very much available “locally” if you can spare a kidney (or, given Apple’s recent pricing increases, almost two).

As a model, though, I’ve found it somewhat unremarkable–good, but not good enough that I reach for it before GLM. Its MoE architecture and copious documentation make it a more plausible basis for useful local inference than anything Qwen or Gemma offers now, though.

The thing is, it barely counts as a model in the grand scheme of things–it’s now mostly a flag for the local AI movement, and, to a degree, more of a hardware problem than a software one. The interesting part is neither its origin nor its capabilities but @antirez’s brilliant hack of a bare-metal inference engine that makes running it locally (well, the Flash variant, at least) actually feasible at usable speeds.

And I get the excitement–I, too, have been chasing that vision within my meagre resources by porting it to Go in go-ds4. It turned “run a frontier-ish model at home” into a weekend of SIMD and Go assembly, which is how an open model became yet another project gated behind hardware most of us can’t justify buying.

In practice, though, I have had a couple of piclaw instances running it almost exclusively for weeks on end without much complaint, switching between Flash and Pro on Azure Foundry–where it is both cheap and readily available, unlike the hardware required to run it at home.

Tier: B. Perfectly useful in the cloud. At home, you had better be prepared to spend a lot of money on hardware.

I’ve topped up my OpenRouter account twice, largely to spend the credits on GLM. 5.1 was OK but not ground-breaking (and I have access to it via Azure Foundry), while 5.2 has something of GPT 5.4’s directness (at least with my AGENTS.md) and just enough of Claude’s flair to be the most interesting open model I’ve used since DeepSeek was let loose.

I haven’t spent enough time with 5.2 to draw a fair caricature, but running it alongside Opus 4.8 and GPT 5.4 it did a perfectly serviceable job of the chores I threw at it–mostly porting a couple of things to Go and Rust. Nothing major, but also nothing it seemed to mess up.

And then there’s the local angle–GLM keeps getting held up as one of the open models that will democratise all this, and every time I look, the latest GLM release still needs an eye-watering amount of resources that puts it firmly out of reach of the hardware most people actually own.

The catch is that the “local” part still requires hardware owned by a very small and conspicuously well-funded slice of the market. I’d be delighted to be proven wrong on something I can afford, but every release so far has moved the goalposts for hardware requirements.

Still, over two weeks and $50 in OpenRouter credits I had zero issues with it as long as I kept my expectations reasonable. I don’t care if the weights were created by a Chinese company–it’s a perfectly good model to host and rally around in Europe if both the US and China go into lockdown mode (politicians, alas, will never understand this).

Tier: A. Cheap, capable, and the one I’d point European hosters at. Calling it “local” still requires the sort of hardware that costs a kidney.

Kimi felt much the same. I mostly played with 2.6 for a couple of evenings (nothing special) and have yet to really use 2.7, but until the new GLM came out it was the most interesting model in the pricing tables that ship with piclaw–and cheap enough that I never begrudged the tokens.

Tier: B. Probably. I haven’t used 2.7 enough for anything more elaborate than that.

Everything above only runs at useful speeds in someone else’s datacentre. Over the past few months my llama.cpp fork has been where I’ve tried to do without one–first as part of my K3 testing, then as a more serious attempt to get usable inference at decent speeds with tool-calling and enough context.

Because, well, the models I actually “own” all have to squeeze into a 12GB RTX 3060, and the pattern has always been the same: promising on paper, but always one VRAM tier short of usable.

Gemma 4 is, actually, the one I like best, mostly because it finally got fast. After some messing about with the E4B variant’s QAT and MTP weights and a few patches to llama.cpp, I got the E4B quants running at nearly 90 tok/s–quick enough to surprise me.

It is also dim and forgetful: the context window is far smaller than I consider usable, and for anything past “if this (and maybe that) then this other arbitrary set of things” it just barely qualifies. piclaw can drive it, but it gets off-track too early and the results are reliably frustrating.

Qwen 3.6 is the one I keep trying to cram into the same card and never quite manage. I’ve spent real time shoehorning it in with MTP and KV-cache optimisations and still don’t have a usable solution–it is always a couple of gigabytes away from fitting. The architecture is clever, but the VRAM requirements just don’t help.

Until hardware gets cheaper–and recent price hikes suggest it won’t soon–anything you want to run locally is going to require both VRAM and bus speeds that the vast majority of people just don’t have–and no, my 36GB MacBook Pro is not where I want to run these things; I love my battery.

Tier: D. I still cannot fit the models I want into the hardware I own.

None of this is, as you might have gathered, scientific or prescriptive, and I don’t actually pick a winner. On any given day piclaw is running a cheap GPT-5-Mini-class model for the boring parts, reaching for Opus when it needs to interpret something fuzzy, and switching to a Codex model the moment real code is needed, with tests to catch whatever Anthropic broke behind my back. We anthropomorphize models and ascribe them personalities, but we need to stop pretending that any single one of them–or any company creating them–is our friend.

I am, in the long term, rooting for open-weight models. Even if we can’t run them on local hardware cheaply, European hosters already can, and in the meantime (with any luck) Europe will get off its collective ass and invest in doing something more than tiny towers of Babel.

I know it’s a start, don’t get me wrong. But it is not where we should be right now.

You know, before all hell broke loose and we got 300 variations on impersonal blogging platforms (ahem Medium), entirely too many walled-garden social networks and utterly unmanageable spam?

Well, back in those days I used something called Shelf, created by Tom Insam, which did a pretty amazing thing for the time (because Apple actually had working desktop automation, but I digress):

It looked at the current foreground application, and tried to figure out if what you were looking at corresponded to a person in your address book–and then gave you more context on them

It was pretty amazing, really:

I spent quite a while hacking on it 16 years ago, and one of the things I really wanted was for it to show me related emails. At the time, AI was not a thing, but Apple was surprisingly ahead of the curve and was shipping a Latent Semantic Mapping framework that I used to build myself quite a nice Mail.app extension–that Apple kept killing, again and again, as it progressively neutered what developers could build atop Mail.

Eventually Apple killed much better, downright brilliant extensions like Mail Act-On, which I had used for years, and all we got is that stupid little “Filing Suggestions”/Move To button in Mail, which, besides being available only on macOS, seldom works and is hardly deterministic.

Well, guess what, LSM is still there, and thanks to the power of AI I have resurrected Shelf to a degree:

The code is up on GitHub, as usual, and I kept the original philosophy of capturing context from the foreground app (via a hideous pastiche of Apple Events and Accessibility, but it “works”), matching it to additional content from the same app (I’m focusing on Mail) and providing “Next Best” actions–which are entirely deterministic, by the way. I also tacked on a smattering of local Apple Intelligence support thanks to SwiftIntelligence (because I might want to use external models later).

And it works beautifully so far, even if I clearly need to remove the nerdy diagnostics and re-think the UX.

Not common sense, I’m afraid.

First off, after creating three or four desktop apps using nothing but Swift, I now get both why some people love it and why some people absolutely hate it, especially compared with the ancient ObjC/AppKit combo. LLMs released since spring 2026 can finally generate Swift code that is actually usable, so I mostly let GPT-5.5/5.6 do the heavy lifting and focused on search ranking and the criteria for suggestions.

Also, oh goodness, how utterly useless Apple’s automation/AX APIs can be for this sort of thing. I have a lot of admittedly dated experience with Apple Events and Accessibility, but even I was surprised at how many things that should be trivial are either impossible or require a lot of workarounds to get right (like just finding the right window in a multi-window app, or getting the right item to glean context from).

And, finally, Apple’s Spotlight APIs in macOS 26 are completely and utterly broken because it is impossible for my app to find the exact same thing I can find with system Spotlight. Even with Full Disk Access, it seems that the only way I can programmatically search for an email message that I can find nearly instantaneously with Cmd+Space is to go and read the Mail SQLite storage myself, which is ridiculous:

• It’s not a question of ranking, predicates, anything
• It’s not a question of query timeouts
• It’s not a question of just about anything I can send to the API (and I’ve pretty much fuzzed it)

There are no decent modern examples, either, so all I get are some messages from some accounts, not any message that matches the criteria I set from across all accounts.

This makes my little email filing helper only partially useful, so I’ll probably shelve it (pun intended) until macOS 27 comes along, and by then I will also see if I can get on-device models to actually file things for me properly.

And no, creating email rules doesn’t scale, and I also only want messages filed after I’ve marked them as read, which is another thing I was able to do just fine with Mail Act-On before Apple nerfed Mail.

I’ll probably write about this again come Christmas, with any luck.

I wasn’t expecting quite so dramatic a shift, but it makes perfect sense for Anthropic to use its acquisition as a high-profile engineering success story–which doesn’t detract from the achievement (and I’m doing similar things on much smaller projects myself, so I know it works), but should be noted.

It also doesn’t surprise me in the least that Jarred caught Claude blatantly lying about implementation details–stubbing out functions to fake compilation, then papering over them with verbose comments. I’ve never had that issue with Codex, but I’ve had it several times with Anthropic models, and that is why, ironically, I don’t trust them for coding.

Also, I can’t even begin to estimate how much that all cost in tokens at their current rates… (actually, it seems to have cost $165,000).

Five paragraph meeting agendas. Four-page responses to a planning inquiry, because that way I get “all the facts”. A one-line question turns up dressed as a formal memo with a summary, three bullets of tangentially related sub-questions and a partridge in a pear tree. Documents that used to run a page now run six, padded out with restated context that nobody wrote by hand and nobody reads. Words are now effortless, so people produce more of them–whether or not they still mean anything.

The immediacy is a bigger dopamine hit than you’d expect. Type a prompt, get six paragraphs and two tables in seconds, and it feels efficient. The sender reckons they’ve saved twenty minutes, and from where they sit, they have: what took twenty minutes now takes two.

Except the time didn’t vanish, it shifted and multiplied. Every recipient now has to wade through the padding, work out which sentence actually matters, and mentally rebuild the one-liner that should have been sent in the first place. Sender spends two minutes; ten people downstream lose fifteen each–if they read the whole thing at all.

People in tech love AI because, well, let’s face it, few of them can write; the average coder isn’t very communicative. And if you do spend a lot of time communicating, the illusion above soon has you in thrall.

AI in the hands of people who can’t use it effectively simply dumps cognitive load on everyone else. I’m something of a speed reader (part of my slightly off neurological makeup), and it’s driving me nuts that a context switch which used to be instant now means ploughing through pages of vaguely dressed-up pseudo-facts.

Hilariously, one of the last times I replied to a verbose e-mail – in my usual terse one-liners and bullets – I pointed out that the data fed to the AI that helped create that e-mail was slightly off. The response was baffling: people actually mistook my British-leaning vocabulary… for an AI-generated response. Because, yes, I use em dashes.

The worst part is that management usually can’t tell the difference, and increasingly doesn’t try. More emails, longer documents, quicker turnaround–it all looks like productivity, and output is easy to count in a way quality never is. So the person firing off ten inflated reports looks busier than the one sending a single tight paragraph that actually settles the question.

This runs top to bottom of the org chart, and it comes down to a basic confusion about what AI is for. The point is to save effort–same result for less, or a better result for the same. Instead people use it to inflate the same result into something that looks bigger. Leadership watches the volume tick up and reads it as a gain. All that’s really happened is the work got louder.

And given the constant pressure to “sell”, to be noticed, to “achieve more”, we’re actually rewarding volume and calling it work because the worst KPIs are the easiest to measure: count of emails, length of documents, speed of reply. Just like measuring the number of PRs landed, or lines of code.

Nobody is measuring the cognitive load being dumped on the other end, or whether the message actually landed, or how many recipient-hours were wasted. So on paper the overload doesn’t exist–it just compounds, off the books, while some management dashboard stays in the green–“line go up”, right?

Blaise Pascal once quipped “I would have written a shorter letter, but I did not have the time.” Being both factual and concise is the expensive option, not the lazy one. Halving a document means understanding it well enough to know what can be trimmed away. Getting a paragraph down to the pair of sentences that are really key takes judgement, a couple of revisions and, yes, time. And (this is what really annoys me) we still haven’t nailed the art of the concise slide presentation–instead, we’ve now weaponized it to… a nuclear degree.

And since I’ve mentioned slide decks: taste is one of AI’s main casualties, visual and textual alike. I abhor the sleek corporate jargon now available as e-mail ammunition to everyone–but that deserves its own post. And, like Pascal, I’m starting to feel I didn’t spend enough time trimming this one down…

I can’t really say anything about this, but I wanted to record it anyway, because id Software had a profound impact on my early career. Some of the most fun I ever had at work was running Quake servers at Portuguese ISPs–which is, quite literally, how I ended up in marketing instead of engineering. I still keep a Quake III Arena page around, clan banners and all, for old times’ sake, and somehow this feels harder than the mainstream layoff news.

Well, I still have a job–though I won’t say any more than that. But going through smaller versions of The After is not something I want to be doing every year.

Although I can run most AI agents inside ios-linuxkit, I keep getting bitten by the fact that Apple won’t let me run my own apps permanently on my iPad, so every now and then the build expires when I am either a) away from home or b) with every single Mac in the house off or otherwise inaccessible (or both), which is a giant pain.

And I do want to be able to run some form of terminal-based agent on the iPad, if only for helping me proofread and auto-link drafts (which I could theoretically do with an Obsidian plugin, but none of those are reliable in the long term). So when I got wind of tau and realized it was pure Python, I immediately tried to install it inside a-Shell, which has a very complete Python runtime and has been my go-to for all sorts of CLI tooling for years–and after some creative hacking, it mostly works:

My fork adds a bunch of things like GitHub provider support, hiding the sidebar and a few workarounds for common iPad foibles (like the lack of an Esc key, and a-Shell’s weird lack of support for Command + .), and like pi, is self-modifying to a degree where I can expect it to keep adapting to the way I work.

Since I have a love-hate relationship with air conditioning, I set up an additional Tuya ZG-204ZM to keep track of presence in the office and only turn it on when absolutely needed, which led me down the usual rabbit hole of Homekit not having any sort of useful logic to do something as simple as “only turn this thing on if I am in the office and it is over 27^oC”, which takes all of three minutes to wire up in Node-RED – but is now undiscoverable by anyone else in the house since it won’t be visible in the Home app.

And yes, I know there are alternatives to the Home app. That is not the point.

Truly useful automation like “only turn this thing on if I am in the office and it is over 27^oC and my kids didn’t leave the window open” (which takes two more minutes) is, alas, something that Apple will likely never really understand.

That said, this class of microwave-based presence sensors is very good. I’ve been using one for a year to turn on ambient lighting when I sit at my office desk (and dim everything when I walk away), and it’s been stupidly reliable. However, it seems that the really interesting, zone-aware ones that have been coming out require wired power, and if any smart home manufacturer truly believes people want to have wall warts to push 5V to these things through a highly visible wire, well, that’s just not happening (the model I’m using takes 2 AAA batteries, which apparently last forever).

I have been playing with Ideogram 4 a bit again, but this time on my puny RTX 3060 (which manages one decent-quality image every… 5 minutes or so), as well as with automated video generation via Remotion, mostly to figure out how some of the current commercial SOTA slop generation pipelines (the output of which we’re constantly exposed to in social media) can be scaled down to more useful pursuits, like helping teachers create grounded educational assets. Since I have long had a local Kiwix instance on my NAS (yes, I like the idea of having offline copies of iFixit and selected Stack Exchange forums), there’s no shortage of material, but I started out with a simpler thing–a piclaw intro:

So far, I see two major challenges:

• Fact-based storylines/scripts are (as I expected) quite challenging to put together (LLMs have no taste, hence no decent criteria for emphasizing the right aspects of the source material). This seems like a relatively easy thing to handle using a multi-step curation process and better skill authoring, but requires time.
• Consistency in visual depictions. Themes and templates go a long way, but anything that involves a visual prompt is just too prone to error–which is why I’ve been looking into Ideogram 4 as a possible way to improve things.

And yes, there’s a lot of pseudo-infographic stuff out there, but it’s all pretty much crap–any pointers on actually reliable techniques or open-weight models are welcome.

Faced with the prospect of years without significant hardware upgrades and the heat, I decided to revive my Linux thin client setup, with a twist: I need to run modern graphical apps on the server, and right now that means Wayland.

xrdp still works great for most essentials, but we keep getting told that Wayland is the future for what–two decades now?–and it’s high time I explored RDP support in Wayland properly. After all, I know the wire protocol well, and I have extra motivation:

• I’ve been meaning to fix a critical part of the Steam experience (pairing a new/updated device remotely to a headless machine) for ages, and getting view-only output out of Gamescope would be nice, because Valve clearly never gave much thought to the notion of headless Steam boxes.
• GNOME Remote Desktop is… bad. I’m sorry, but it just is, not just because I want proper multi-user headless support but also because of various protocol support gaps.
• I would very much like to, sometime in the future, have something that works at least as well as xorgxrdp and sesman to have minimally accelerated desktops (rendered using the GPU on the server side) streamed via RDP (preferably H.264) to an arbitrary client.

The current state of the art in the X11 world lets me do the latter (with minimally usable audio) pretty well, but there’s nothing equivalent in the Wayland ecosystem… Until I found out about lamco-rdp-server and started hacking at my own fork to implement the bits I wanted.

And oh boy, is Wayland broken by design if you try to do something like this… Right now the current setup is, roughly, an in-memory, headless Weston instance that, via some duct tape and wishful thinking, is screen captured through the “portal” abstraction by lamco-rdp-server, which feels like a tremendous waste of resources instead of, you know, just having a process hold both the compositor and the protocol renderer per logged-in user.

But I got most of the interesting bits to work already:

Screen resizing, in particular, is a pain, but then again input has been much worse… I wasn’t particularly fond of the idea of reinventing this wheel to the point where it’ll be a full-fledged thin client solution, but a few hours with Codex led me to a usable xrdp-like solution with an equivalent sesman-like session manager, PAM support and a few other niceties, and I’m certainly up for experimenting (and learning) with it over Summer.

Which doesn’t mean things don’t get too hot. I woke up the other day to find that borg had halted at around 5AM, and I immediately suspected thermals, so, again, I popped it open, swapped out the CPU fan (some things are so predictable I keep spares) and, while I did that, asked one of my agents to check telemetry–which, despite my best efforts, I’ve been neglecting to turn into alarms:

It’s pretty obvious, even looking at the monthly data (which I pulled out to get an idea of the overall trend), that one of the fans started failing over the weekend–and it was the Noctua NF-A9x14 that I’ve been using for the CPU cooler.

Since those slim profile fans seem to die on me around every 18 months or so, this time I got an Artic P9 Max, on the spurious grounds that:

• It has a much higher CFM
• I can still fit a 25mm fan into the B660 (there’s enough clearance below the PSU)

It is, of course, much noisier, but we are in the middle of a heat wave and I expect it to throttle down eventually. Either way, I did get another Noctua to keep around as a spare, because fans are probably the only PC part that is cheap enough to keep a spare of these days…

While I waited for the new fan to arrive, I decided to whip up a stupidly visible temperature monitor to keep an eye on it, and the results were… dramatic:

I don’t expect this to be the last time I do this, but I hope it will at least be a while before I have to do it again. The B660 is an amazing motherboard/case combo, but it is not designed for high-performance cooling–or Portuguese weather.

And, again, as the fiscal year rolls around, so does another reorganization. I have no clue what is going to happen, but this is relevant to me as Industry Solutions Delivery (the previous-to-this designation of the ancient Microsoft Consulting Services organization I initially joined some seven years ago) is now going to slot under this somehow.

I, too, find the squircles aesthetically offensive and utterly pointless. Tahoe didn’t just dumb down Apple’s own icons, it dictated the shape of everyone’s, shrinking any icon that refused to conform into an ugly grey cell–icon jail for the crime of having a silhouette. Decades of distinctive Mac icons flattened into bland uniformity, and the usability argument is the one that really stings: shape was a way to tell things apart at a glance, and now it’s down to colour alone (good luck with that if, like me, you often can’t readily distinguish Slack from Photos).

What I yearn for is the era when an icon had room to be something distinctive, with enough real estate to carry a bit of personality. Golden Gate walking back the worst of Liquid Glass is encouraging, so maybe the people inside Apple who clearly know this was a mistake will find it in themselves to fix the rest.

The part that genuinely breaks my brain, though, is that I now find icons on Linux more distinctive than on macOS, which would be impossible for my ten-year-ago self to believe. The platform that built its reputation on craft and visual identity has spent a year sanding it off, while the one everyone used to mock for its inconsistency is where individuality survives. Funny how that goes.

Other than it being the last fiscal month at work, that is–my thresholds for patience have become somewhat elastic over the years, but it’s still a busy part of the year.

That, and the ongoing industry madness pushed me into another reassessment of how I have been spending my time, and I decided to go back to more hands-on work.

Since I have a bunch of CAD work to do, I tried my hand at photogrammetry over the week to see if I could speed up creating SBC cases:

The main conclusion so far is that although the photogrammetry process itself worked (and I could probably write a fairly detailed post about the C++ libraries I used and how I automated the process), even with 4K inputs and a few passes at refining the mesh it’s just not accurate enough to do what I need, partially because the BRIO 4K’s autofocus is a bit of a wash:

Now, that is tweakable, but the process is still a bit too manual and error-prone to be worth it for me.

In comparison, flipping the script on my previous attempts at using AI and just feeding photos to piclaw has been working stupendously well, and even if the dimensions are off, I can fix them easily in CAD once I have a STEP file:

As much as I would love to get my hands on a 3D scanner, I suspect this will be my go-to approach from here on out–although I’m currently investigating if I can re-use the image-processing pipeline to guide the model:

Tiny Local Models

Before shifting back to more pragmatic pursuits, I still “finished” a few AI-related things, mostly related to Gemma 4.

In short, after some messing around with QAT and MTP weights, I have finally gotten a reasonably smart and speedy version of Gemma4-E4B to run on my RTX3060 at nearly 90 tok/s, but…

It still isn’t as smart (or fast) as I would like for running my agents, and the context window is much smaller than what I ordinarily consider usable. Even for automating “if this (and maybe that) then (this other arbitrary set of things)” workflows… It just barely qualifies.

I might poke at it a bit more, but the core issues I had during my K3 review still stand: both context and capabilities of this kind of model are still far below what I need for regular use (piclaw can use it, but the results are always frustrating), and SOTA models are still much, much more effective than anything else.

Recent price hikes have put me off the notion of ever getting good enough hardware to run anything useful locally unless I win the lottery or something, so this might be a dead end for the rest of the year.

I also went after my daily news intake–the news is bad enough as it is, but I can at least try to make it less stressful to consume.

Back when I was moving away from Feedly to FreshRSS I briefly considered Miniflux but discarded it because I thought it lacked features I ended up never using, so this week I decided to fork it, replace its PostgreSQL database with SQLite and create something even more minimalist I dubbed picoflux – which seems to work just fine with Reeder and takes up a whopping… 70MB of RAM when running as a dedicated service.

That’s far less than the PHP and database baggage that FreshRSS brought, and it let me downsize the (already) tiny Azure VM I run “insecure” services in to half the capacity, so that’s a win right there.

Migration was, as usual, another opportunity to prune/fix stale feeds, but completely uneventful other than NetNewsWire not having support for Miniflux–which is not a problem since I am still using Reeder, but said support seems to be coming, and if my UX gripes (which revolve around scrolling and overly garish iconography) get fixed, I might well switch to it.

After three years of experimentation and around nine months of daily use, I am bringing my feed summarization experiment to a close, for the following reasons:

• My reading habits and schedule changed to a point where I was not really reading all of the bulletins (especially the noon and evening ones) and they just piled up.
• The bulletin structure itself, despite being great for a few of the feeds I wanted to keep a cursory eye on, was just not good enough to surface important news.
• Following the links inside bulletins was a bit fiddly (they were too small a target to pick out from a page of text, and turning the entire summary into a hyperlink to “fix” that just didn’t work inside any RSS reader).
• I realized that my brain is just better at scanning hundreds of headlines and ranking them as they scroll past on the iPad.
• It is another service to run and maintain, and I wanted to focus on other things.

To be fair, it has had exactly zero code changes other than a couple of cosmetic fixes and the LLM API costs were under $5/month, but asking myself “why” didn’t surface a lot of value.

That is not to say that the summaries were not valuable, but it’s just easier to prune noisy, spammy feeds. I have also considered using the summaries to feed a “smarter” agent that would notify me of “interesting” news, but my interests are so wide (and shift priorities so often) that it would be tough to get consistent output out of that, too.

I suspect I will circle back to this with a fresh point of view (and I have been thinking about how to refactor it into a pure functions/workers construct), but for now it’s just easier to wind it down for the holidays.

sashimi Soak Testing

I picked up sashimi (the Go port of this site’s static generator) again this week, and after running the numbers on visual rendering parity (which piclaw and Codex helped me with by generating some nice visual diffs), it is now at a point where it can render the entire site with pretty much 100% fidelity to the current renderer–except for a few corner cases, and with some bits already looking better.

It is blazingly fast, and incremental rendering is ridiculously fast, but more to the point it’s finally good enough to run alongside the main engine, generating a complete staging site entirely inside GitHub Actions (with a somewhat complex but quite fun set of cascading, low-impact actions) that do the required incremental/partial rendering in seconds instead of several minutes.

It’s probably interesting enough to deserve a dedicated write-up, and that will happen after a couple weeks’ soak time. I’ve already done a bunch of “live” testing, but I’m sure regular posting will surface more things to fix.

The Remote Desktop Protocol, which has a long and colorful history. I much prefer it over VNC due to its vastly superior performance and extra features.

On Windows 10/Server 2016 and above, you can enable nearly 60fps connections between clients using H.264, which considerably improves the user experience. To do that, on the server:

1. Run gpedit.msc (Windows 10 Pro or above, although there are ways to enable it on Home)
2. Go to Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment
3. Enable Prioritize H.264/AVC 444 Graphics mode for Remote Desktop
4. Enable Configure H.264/AVC hardware encoding for Remote Desktop
5. If your machine has a discrete GPU, enable also Use hardware graphics adapters for all Remote Desktop Services sessions
6. Run gpupdate /force
7. Create a DWMFRAMEINTERVAL DWORD (32-bit) under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations with the value 15 (decimal) to set fps to 60.

Modern versions of Remmina support this as GFX AVC 444, although the results will greatly vary depending on the client.

This is a more detailed version of the above which I gleaned from various sources when I needed to re-tune a server and had to re-do the whole thing.

If you intend to use UDP, make sure you can receive traffic on port 3391.

Run gpedit.msc and configure these settings, using gpupdate /force in an admin prompt afterwards:

Computer Configuration:
  Administrative Templates:
    Windows Components:
      Remote Desktop Services:
        Remote Desktop Session Host:
          Connections:
            - Select RDP Transfer Protocols = Enabled, Use both UDP and TCP
          Device and Resource Redirection:
            - Do not allow supported Plug and Play device redirection = Disabled
          Remote Session Environment:
            - Configure compression for Remote FX data = Enabled, Do not use an RDP compression algorithm
            - Configure H.264/AVC Hardware encoding for Remote Desktop Connections = Enabled,  Prefer AVC hardware encoding = Always attempt
            - Configure image quality for RemoteFX Adaptive Graphics = Enabled, High
            - Configure Remote FX Adaptive Graphics = Enabled, Optimize for server scalability
            - Enable RemoteFX encoding for RemoteFX clients designed for Windows Server 2008 R2 SP1 = Enabled
            - Prioritize H.264/AVC 444 graphics mode for Remote Desktop Connections = Enabled
            - Remote FX Adaptive Graphics = Enabled
            - Use hardware graphics adapters for all Remote Desktop Services sessions = Enabled
            - Use WDDM graphics display driver for Remote Desktop Connections = Disabled
            Remote FX for Windows Server 2008 R2:
              - Configure Remote FX = Enabled
              - Optimize visual experience when using Remote FX = Enabled, Highest (Best Quality) for both Screen Capture Rate and Screen Image Quality
              - Optimize visual experience for remote desktop sessions = Enabled, Rich Multimedia

Save this out to a .reg file, edit to taste, import and reboot.

Windows Registry Editor Version 5.00

;Sets 60 FPS limit on RDP.
;Source: https://support.microsoft.com/en-us/help/2885213/frame-rate-is-limited-to-30-fps-in-windows-8-and-windows-server-2012-r
;YMMV, since policies also have an impact on this
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations]
"DWMFRAMEINTERVAL"=dword:0000000f

;Increase Windows Responsiveness
;Source:https://www.reddit.com/r/killerinstinct/comments/4fcdhy/an_excellent_guide_to_optimizing_your_windows_10/
;Not really sure how much this helps in Windows 11
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile]
"SystemResponsiveness"=dword:00000000

;Sets the flow control for Display vs Channel Bandwidth (aka RemoteFX devices, including controllers.)
;May not be very useful if your client negotiates other protocols.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermDD]
"FlowControlDisable"=dword:00000001
"FlowControlDisplayBandwidth"=dword:0000010
"FlowControlChannelBandwidth"=dword:0000090
"FlowControlChargePostCompression"=dword:00000000

;Removes the artificial latency delay for RDP.
;Again, not sure how much this helps in Windows 11
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]
"InteractiveDelay"=dword:00000000

;Disable Windows Network Throttling.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"DisableBandwidthThrottling"=dword:00000001

;Enable large MTU packets. Might cause some issues over VPNs, so if things start acting funny, revert this.
"DisableLargeMtu"=dword:00000000

;Disables WDDM Drivers and goes back to legacy XDDM drivers (theoretically better for performance on NVIDIA cards, you might want to change this setting for AMD cards.)
;Of dubious effect in Windows 11 given policy settings.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"EnableWddmDriver"=dword:00000000

Also, if you have a dual GPU system, open the NVIDIA control panel and set it as the preferred graphics processor (Windows 11 has somewhat deprecated this, but it worked for me).

If you need to share USB devices (including webcams, although those rely on your client having UVC pass-through support), do this:

Run gpedit.msc and configure these settings, using gpupdate /force in an admin prompt afterwards:

Computer Configuration:
  Administrative Templates:
    Windows Components:
      Remote Desktop Services:
        Remote Desktop Connection Client:
          RemoteFX USB Device Redirection:
            - Allow RDP redirection of other supported RemoteFX USB devices from this computer = Enabled, Users and Administrators

gpupdate /force

Since the official Mac Remote Desktop clients lack a lot of settings, I’ve found that these may help for LAN connections in some regards:

networkautodetect:i:0
connection type:i:6
videoplaybackmode:1

However, Jump Desktop tends to do a better job connecting to xrdp in Mac OS. On iOS, the official RD Client is often better.

Add this to /etc/xrdp/xrdp.ini as a workaround:

new_cursors=false

Category	Date	Link	Notes
Alternatives	2025	Kasm	A set of pre-baked containers that provide web-based (non-RDP) desktops
	2024	selkies-gstreamer	A WebRTC desktop streaming platform
	2023	rdesktop	The old classic open-source RDP client.
		rdpy	A set of Python tools to access and test RDP servers.
Clients		CoRD	My favorite Mac client around 2009 or so.
		IronRDP	A Rust-based RDP client with RFX support
		Rustdesk	A new cross-platform client.
		Thincast Client	A cross-platform RDP client that supports GPU acceleration and ARM64.
Gateways	2026	lamco-rdp-server	Wayland-native RDP server for Linux desktop sharing with hardware encoding and clipboard sync
	2025	rdpgw	an implementation of the Remote Desktop Gateway protocol.
		myrtille	A Windows-based simple and fast web Remote Desktop client
		rdp-html5	A simple HTML5 RDP client
		guacozy	a HTML5 browser based VNC/RDP/SSH remote connection manager based on Guacamole
		guac	Apache Guacamole client ported to Go
	2023	Guacamole	A Java-based gateway providing HTML5 access to RDP, VNC, and SSH.
		FreeRDP WebConnect	A C++ gateway providing HTML5 access for FreeRDP servers.
Mods		Duo	A multi-seat solution that uses RdpWrap and Moonlight to enable remote gaming.
		rdpwrap	A library wrapper to enable multiple remote desktop connections on Windows.
Ports		FreeRDP	A well-maintained open-source RDP implementation, including a DirectFB client.
Tools	2025	BetterRDP	a Windows Registry file that optimizes RDP server settings in Windows.
	2023	RemoteApp Tool	Manages application access for RemoteApp sessions.
		X11RDP-o-Matic	An automated installer to set up a native X11-based RDP server.

]]>