Tao of MacThe Tao of Mac is the personal wiki of Rui Carmo, featuring a technology-oriented blog, links to articles, several compilations of resources around various key technology topics, and a collection of photos and videos.https://taoofmac.com/atom.xml2026-04-15T10:08:30+00:00CC Attribution-NonCommercial-NoDerivs 3.0Cydintoshhttps://taoofmac.com/space/links/2026/04/15/0718?utm_content=atom2026-04-15T07:18:00+00:002026-04-15T10:08:30+00:00Rui Carmohttps://taoofmac.com
I have a soft spot for tiny Macintosh projects, and this one pushes all the right buttons–an ESP32 Cheap Yellow Display board running a Mac Plus emulator inside a 3D-printed case. I haven’t finished hacking my Maclock yet, but it’s a perfect fit with my ESP8266 hackery, not to mention the collection of vintage emulation hacks I keep filing away and my never-ending ARM64 JIT for BasiliskII, so I had to link to it.
The utterly brilliant part is that doesn’t stop at getting System 3.2 onto a small screen–it adds little Retro68 utilities for weather, Wi-Fi status and hardware control, which turns the whole thing into equal parts retrocomputing in-joke, embedded hack and practical home automation gadget.
It’s already printing (in the obligatory platinum-like PLA I keep around for special occasions), and I am so going to plug this into HomeKit somehow…
]]>Pi.dev Ecosystemhttps://taoofmac.com/space/ai/agentic/pi?utm_content=atom2026-02-24T11:15:00+00:002026-04-14T21:03:13+00:00Rui Carmohttps://taoofmac.comThe Pi coding agent is a terminal-first assistant focused on interactive workflows, extensibility, and running local agents with practical toolchains. The primary distribution today is pi-mono, which serves as the core runtime and extension point for the ecosystem.
This page tracks the Pi-centric projects, adapters, and clients that extend the core agent, including alternate front-ends, web access tooling, and automation bridges within the wider Agentic Systems collection.
while parsing a block mapping
in "<byte string>", line 2, column 1
did not find expected key
in "<byte string>", line 190, column 1
]]>Androidhttps://taoofmac.com/space/com/google/android?utm_content=atom2007-11-17T22:36:03+00:002026-04-13T18:32:30+00:00Rui Carmohttps://taoofmac.comThe mobile platform sponsored by Google as part of the Open Mobile
Alliance, evolved from their 2005 acquisition of the company with the
same name.
Gotta love stats. One little thing, though - Android apps are more likely to be free and ad-driven, so anything coming from an ad server isn’t necessarily a good market penetration metric for a platform.
More pretty charts (US-centric, therefore meaningless). The difference here is that there are umpteen versions of Android devces and far fewer of other platforms…
$529 unlocked, shipping to the US, UK, Singapore and Hong Kong, or with a two year T-Mobile US contract for $179. There go a lot of pipedreams about it being sold direct to the public at “astonishingly low” prices.
This teardown mania is somewhat fun, but one wonders how long it will take until people realise that only a very small minority of what is “unearthed” is news…
Let’s see how this pans out. I’m quite curious, actually, to see if Verizon can pull this off in the sense of generating genuine buzz around an operator-specific set of Android devices.
Although this was fixed fairly quickly, it is the perfect example of why mobile phones aren’t exactly trivial to “improve upon” using today’s technology.
About a year later, one of the first sightings of actual hardware (but running over Wi-Fi. I don’t get the “masked” bit, though - the hardware’s pretty obvious.
]]>European AI: A Playbook to Own Ithttps://taoofmac.com/space/links/2026/04/13/0730?utm_content=atom2026-04-13T07:30:00+00:002026-04-13T07:30:00+00:00Rui Carmohttps://taoofmac.com
Mistral published a 52-minute read on how Europe should build an independent AI stack–talent pipelines, single-market scale, local infrastructure, sovereign compute, the lot. It reads like a policy brief dressed up as a manifesto, and while it has a glaring flaw and some of the proposals are predictably self-serving (Mistral is, after all, the company that would benefit most from “buy European AI” procurement rules), the underlying analysis is hard to argue with.
The five pillars–attract talent, scale the single market, drive adoption in the real economy, build local infrastructure, and secure sovereign AI capacity–are all sensible, and the specific measures (an EU AI talent visa, streamlined regulation, public procurement mandates, European cloud infrastructure) are concrete enough to be actionable rather than the usual Brussels hand-wringing. The 40% figure they cite for Europe’s share of global AI research output versus its minuscule share of commercialisation is the kind of stat that should make policymakers uncomfortable.
Where it completely falls apart, though, is that Mistral, even as an European company, currently doesn’t hire remotely in Europe – so the whole thing feels a tad insulting if, like me, you’re actually in the industry and not in politics.
There is some merit to it, though, and whether any of this actually happens is a different question entirely. Europe’s track record on turning common sense into working industrial policy is, to put it generously, mixed–and the current geopolitical climate makes “digital sovereignty” feel less like an aspiration and more like an urgent necessity that nobody has quite figured out how to fund.
]]>Notes for April 6-12https://taoofmac.com/space/notes/2026/04/12/1700?utm_content=atom2026-04-12T17:00:00+00:002026-04-12T17:00:00+00:00Rui Carmohttps://taoofmac.comThanks to a bit of spillover from Easter break, this was a calmer, more satisfying week where I could actually get stuff done and even have a bit of fun.
My idea of fun, apparently, is to do 3D visualizations in piclaw
Now that piclaw is in cruise mode, I’ve started focusing on actually using it.
So I created an instance called Flint, which manages not only my Obsidian vault but also all of my personal pursuits and most of my homelab: I gave it the API tokens for my Proxmox cluster and Portainer, and over the past week it’s been busy:
It re-tagged most of my notes and drafts (as well as adding reference URLs for ongoing drafts), quizzing me on what to do with specific notes as it went
It rebuilt and redeployed my GPU sandbox (which I broke last week): recreated the VM, mounted the Ubuntu ISO, prompted me to run the installer, and installed the latest NVIDIA drivers, nvidia-docker and a baseline set of utilities.
I then asked it to look at the Portainer stacks in my gitea instance, my Obsidian notes, and what needed to be set up, and it installed the Portainer agent and brand new versions of the stacks with tweaked network and volume settings, updated my notes, and upgraded the pinned image versions (troubleshooting as it went).
It developed and published an OPDS server and an EPUB read later service so I can fetch interesting web pages and read them later on the XteInk X4, including monitoring the CI pipeline and redeploying the containers
It audited my Cudy OpenWRT config and set up centralized stats collection in Graphite, which I had been meaning to do for ages (and I intend to have it set up Telegraf on other machines to collect metrics).
So far, Flint is a resounding success (it’s using GPT-5.4, a fairly sensible and stable model), but it doesn’t just do notetaking and operations.
Flint has also become quite useful to help me tidy up my workflow—I was already using a piclaw instance to convert ancient Textile and raw HTML posts into Markdown in batches, but there are a few things that have been nagging at me for years and that I can finally make significant progress on:
Adding links to my resource pages
Drafting link blog entries
Streamlining static site builds
I’ve had Shortcuts to do the first two for ages, but they both relied on adding bits of text to Reminders that were then post-processed and added to git using either the CLI or WorkingCopy. That worked OK for a while, but my iPad mini’s increasing slowness has made them quite frustrating, especially since I tend to do that kind of quick posting over breakfast and it was taking up too much time.
As it happens, GitHub has a REST API for Git Trees, and what that means in practice is that I can update a JSON changeset with these minor changes, let it accumulate over breakfast, and then apply them in batches–or, rather, have Flint do that, with all the guidance and steps in a SKILL.md file.
So my new breakfast workflow is to just send links to Flint using the iOS sharing pane or a bookmarklet (still experimenting with both), have it create a JSON changeset for links, and occasionally ask it to screenshot a page and create a blank Markdown document for linkblog posts. That is pre-filled with a title, likely tags and the appropriate image reference, and I just pop open the built-in editor tab in piclaw, finish the post and ask it to add the files to the changeset and post them via the API.
So far, it’s been going swimmingly: zero git fetches/commits/pushes, all handled server side, and very little friction–and it works on my iPad mini, albeit still slowly.
Another thing I’ve been working on is porting the Python site builder to Go for both speed and maintainability—the current codebase has some 20-year old hangovers that I wanted to get rid of, and some kind of reset has been long overdue, so I have been slowly poking at this for the past few months.
As it happens, the overall indexing and rendering process was pretty trivial—the real challenge has been to make sure that it looks exactly the same, especially given that my engine has some pretty specific Wiki-linking rules and I’ve accumulated a bunch of rendering helpers and custom plugins over the years.
Plus everything related to HTML rendering has changed: parsing, link resolution, templating, the works. And that’s enough to juggle already, so I don’t want to change the front-end design at all (yet).
I decided to be ambitious and aim for full rendering parity. So what did my little army of AI helpers do?
It converged on doing visual diffs out of random sampled pages: Take a locally rendered version, look at the public page, and generate an image that it can easily rate as “close” or “broken” by just counting the ratio of red pixels:
This is both brilliant and scary at the same time
The process is greatly streamlined: sample 100 pages out of the nearly 10,000 we have now, render, batch compare, show me the worst ones, and then discuss and generalize the fixes (which is the only part the LLM is actively involved in). I could probably use autoresearch to automate this, but some of the fixes have to do with legacy rendering logic that no AI could ever figure out.
Still, this has converged very quickly to minor typography and spacing differences, and once I’m happy with the engine I’ll start looking at optimizing the actual blob uploading part–which I aim to standardize via rclone to remove my current dependency on Azure storage accounts, but greatly optimize with deltas.
It turns out that if you tell an AI that empty catch blocks are forbidden, the thing will just… go and add comments inside them, instead of doing something useful like a warning log message…
I’m now doing another code audit pass over the entire piclaw codebase, and this kind of mechanical fix is trivial to set up and do reliably with autoresearch:
An autoresearch session doing a code audit pass
Now to see if I can get some reading and 3D printing done as well, since the whole point of using AI in the first place was to have more free time… right?
]]>Apple, Stillhttps://taoofmac.com/space/blog/2026/04/12/1330?utm_content=atom2026-04-12T13:30:00+00:002026-04-12T13:30:00+00:00Rui Carmohttps://taoofmac.comI have been having feelings about Apple lately. This blog may have drifted a fair way from its original focus on macOS, but I am still, first and foremost, an Apple user – just not an exclusively Apple user, and perhaps not even a particularly obedient one anymore, since I use both Windows and Linux every day and have grown used to judging platforms by what they let me get done rather than by whatever story they are trying to tell about themselves.
That makes the current moment a little awkward. Apple is still extraordinarily good at making hardware I want to pick up and use, and still more coherent than most of the industry in the broad strokes, but it also feels increasingly prone to sanding off the wrong edges, reinventing the UX wheel, and constantly adding paper cuts to their software.
The iPhone is probably the clearest example of that tension. It is still the phone I would rather carry, and the one whose hardware I trust most, but iOS has become steadily more fussy without becoming proportionally more capable.
A lot of it has been the constant UI friction and pointless balkanization of features like screen mirroring, which I would very much like to have – I see zero point in using Messages on my Mac or futzing around with Handoff and AirDrop when I could just, you know, pull up a window into my phone and type stuff in.
And I know Apple could indeed engineer a way to make those features DMA-compliant if it really wanted to – I suppose breaking the user experience across the board with Liquid Glass had enough priority to preempt allocating engineering resources to, you know, proper features.
Sharing things, moving files around, background activity, browser limitations, the endless little inconsistencies in system UI and the ungainly bloat in Settings – that friction accumulates. None of it is fatal on its own, but the aggregate effect is that the platform feels far less light than it used to, even while Apple keeps insisting that everything is becoming more seamless.
I’m going to say it outright: I found Liquid Glassinsulting. Not just visually, but also because it tells me that instead of fixing glaring gaps in things like automation (Shortcuts is definitely not in good health, and AppleScript is pretty much dead) that could actually have put Apple in the forefront of automation and AI (never mind the miserable failures in Siri and Apple Intelligence), someone at Apple actually decided breaking visual affordances took priority over stability and providing consistent application intents and hooks across the board.
Even then, macOS is in a better place than iOS, but mostly because it still retains enough of its older character to be workable. Remember, I can just patch the visual inconsistencies away.
There is still a proper filesystem, there is still a shell (even if Apple seems intent on breaking the userland in very small increments across releases), there are still enough escape hatches to route around bad decisions, and Apple Silicon has papered over a remarkable amount of software bloat simply by being absurdly fast and power-efficient.
But the cracks are visible there too. System Settings remains a mess, cross-platform application quality keeps declining, and the old Mac assumption – that a user might actually want to understand how their machine works – seems to matter less every year. Meanwhile iOS keeps borrowing bits of the Mac’s vocabulary without acquiring the Mac’s actual flexibility, which leaves both platforms feeling oddly misaligned.
The iPad remains the device I most want to use more than I actually do. I may pick one up every morning to read the news and get drafts started, but the Neo nullifies any interest I might still have in upgrading my iPad Pro. The hardware is excellent, the battery life is still absurd, the pencil is useful, and for reading, sketching, note-taking and casual browsing it remains hard to beat. Fine.
But every time I try to push it into being a serious general-purpose computer, it reminds me that Apple still has not decided what it wants the iPad to be. It can approximate a laptop for stretches at a time – and sometimes very convincingly – but the moment you need proper peripheral support, predictable file handling or sustained tool switching, the abstraction turns into safety glass – and I’m back to my long-held opinion that the only good iPad is the iPad mini.
That’s what I intend to upgrade this year, even if Apple comes out with a decent foldable iPhone (and, by the way, I really like the “leaked” form factor, because phones have become stupidly tall and unwieldy).
And this is where Fedora comes in, because it has become my most useful point of comparison. Linux on the desktop is still Linux on the desktop – gloriously inconsistent, occasionally infuriating, and always willing to expose its plumbing at the worst possible moment – but my experience over the past few years is very conclusive: Fedora has reached a point where, for a lot of everyday work, it is simply easier to reason about than either macOS or iOS.
That does not make it better in every respect. It is not. But it does mean that a lot of the breakage in Apple software now has a reference point, and even considering I was always a UNIX user and deeply technical, the creature comforts that Linux now provides give me a lot more confidence than Apple’s software.
If Qualcomm wasn’t so obtuse about only supporting Windows and ARM laptops were more open, things would be very interesting indeed.
I still like the hardware, still prefer the overall ecosystem in a number of places, and still find myself evaluating a lot of the rest of the industry by standards Apple set years ago.
But I also think it is getting harder to ignore how much of the original appeal has been traded away due to sheer mismanagement of software QA and Apple’s refusal to acknowledge the gaps across iPad, macOS core applications, and a consistent user experience.
Come on, Tim, get your people in line.
]]>Emulationhttps://taoofmac.com/space/emulation?utm_content=atom2005-06-09T09:38:12+00:002026-04-15T07:48:42+00:00Rui Carmohttps://taoofmac.comEmulation and hardware virtualization software of various descriptions, most of them obsolete by now:
Error: Could not parse 'table.yaml'
while parsing a block mapping
in "<byte string>", line 2, column 1
did not find expected key
in "<byte string>", line 421, column 1
]]>The Orange Pi 6 Plushttps://taoofmac.com/space/reviews/2026/04/11/1900?utm_content=atom2026-04-11T19:00:00+00:002026-04-15T06:13:27+00:00Rui Carmohttps://taoofmac.comThis was a long one–I spent a fair bit of time with the Orange Pi 6 Plus over the past few months, and what I expected to be a quick look at another fast ARM board turned into one of those test runs where the hardware looks promising on paper, the software is wonky in exactly the wrong places, and you end up diving far more into boot chains, vendor GPU blobs and inference runtimes than you ever intended.
The Orange Pi 6+ on a corner of my desk
Unlike most of the ARM boards I’ve reviewed until now, this one is not an RK3588 board: The Orange Pi 6 Plus uses the CIX P1 (CD8180/CD8160), with 12 CPU cores, a Mali G720 GPU, a dedicated NPU and a wild set of specs for the form factor. Boards like this promise everything at once–homelab, edge AI, dual 5GbE, low power–but they only matter if the software gets out of the way.
Disclaimer:Orange Pi supplied me with a 6 Plus free of charge, and, as usual, this article follows my review policy.
And, for a change, I decided to make sure the software did exactly that, and made it my concern from the start–i.e., I built my own OS images for it (a fork of orangepi-build) and went in a bit deeper than usual, spending around two months taking notes, benchmark logs and even Graphite telemetry as I went along.
One of the reasons I wanted to test this board is that the SoC is the CIX P1, which Orange Pi bills as a 12-core part with a combined 45 TOPS across CPU, GPU and NPU. The machine I tested came with:
CIX P1 (CD8180/CD8160), 4×Cortex-A520 plus 8×Cortex-A720 cores
16GiB of RAM (roughly 14GiB visible to Linux)
dual Realtek RTL8126 5GbE
Realtek RTL8852BE Wi-Fi and Bluetooth card
Mali G720 / Immortalis-class GPU
A three-core Zhouyi NPU
And if you’ve been paying attention to all my homelab testing, those two 5GbE ports alone make this more interesting than most hobbyist SBCs. But, of course, there is a lot more to expandability than that:
The CPU is interesting in itself–the fastest A720 cluster reaches about 2.6GHz, the A520s top out around 1.8GHz, so like many other big.LITTLE ARM architectures you get asymmetric clusters rather than a uniform twelve-core machine:
lspci is a bit more revealing, especially because you get to see where the dual 5GbE setup and Wi-Fi controller are placed–each seems to get its own PCI bridge:
Nothing exotic, which I rather like. And, by the way, the board ships with Cix Technology Group UEFI, version 1.3, so setting up boot devices and managing (very) basic settings was trivial.
This is where I took a very large detour from my usual approach: I decided early on that I wasn’t going to use a vendor image for this board.
Vendor images for SBCs like this always tend to be good enough to boot, occasionally good enough to do basic benchmarks, and almost never something I want to build on–especially if I’m doing local AI work, host-native services, or anything that requires me to trust package sources, first-boot behaviour and upgrade paths.
I wanted a server-first layout, reproducible fixes and a place to bake in GPU/NPU prerequisites, so I forked orangepi-build and started from there, with a fairly high bar:
I wanted a fully reproducible Debian 13 / Trixie build with features like /dev/kvm present, not a vendor image with stale software and missing features I wanted.
The build needed to stop treating Ubuntu as the only real target–add-apt-repository, PPA logic and software-properties-common had to be cleaned out.
Boot fixes had to be baked in from the start, not applied as post-flash rituals.
First boot had to be deterministic. If the root filesystem resize requires me nearby with serial and patience, the image isn’t finished.
I needed a clean place to stage GPU firmware, vendor userspace and NPU packages.
The Orange Pi repository included kernel 6.6.89-cix, so a lot of the above was already “there”–I just needed to hack at it, but instead of doing it entirely by hand I got piclaw to set things up on an Ubuntu 22.04 VM.
Over a few weeks (this took a while), the above list translated into a fairly concrete set of changes in the build tree:
added Trixie configs under external/config/{cli,desktop,distributions}/trixie
patched scripts/distributions.sh for Debian 13 support
fixed the board config to allow trixie under DISTRIB_TYPE_NEXT
removed Ubuntu-only dependencies from the package lists
forced standard Debian mirrors
made the kernel build non-interactive
started baking in GPU/NPU prerequisites and development tooling for later testing
The package side needed archaeological work too. I patched orangepi-config to stop behaving as though it were on Ubuntu, removed software-properties-common from the Trixie dependency chain, forced regeneration of cached packages, and went hunting through component_cix-next for whatever vendor bits still existed and matched my kernel, taking notes throughout.
My first boot-related note on this board was short: I flashed my custom Trixie image, got as far as GRUB, and it fell over because the EFI stub was wrong. The image did contain the right DTBs (SKY1-ORANGEPI-6-PLUS.DTB and friends), but the build scripts somehow commented out useful menu entries and the default pointed at the ACPI path.
But getting past GRUB was only half the battle. The first real boot surfaced another annoying issue: the partition resize worked, the root filesystem resize didn’t, and the machine failed to reboot cleanly at the handoff. I had piclaw trace the resize helper, found it was disabling itself before the second stage could run, and patched that too.
The whole thing made for a pretty intensive couple of weeks:
Build and fix timeline
In parallel, I made sure to include GPU/NPU support:
firmware symlink so panthor could find mali_csffw.bin
baked in cix-noe-umd and cix-npu-onnxruntime
and a big pile of dev tooling so the board could bootstrap AI experiments without turning into a scavenger hunt
Once the image was booting reliably, I wanted the board off SD entirely. I had a 512GB NVMe drive sitting about, so I had piclaw handle the migration–even though it had just finished patching orangepi-config, the actual cutover was done manually: partition the NVMe into EFI, root and swap, rsync everything across, patch GRUB.CFG to point at the new PARTUUID, reboot, verify, remove the SD card.
So, to recap, I had to fix these things for my custom image:
Boot chain: initially broken because GRUB defaulted to the wrong path; stable once DTB boot was forced
GPU / Vulkan: initially llvmpipe fallback or panvk failure; working with vendor Vulkan ICD on mali_kbase
OpenCL: not useful at first, functional once the vendor userspace was in place
NPU kernel side: visible from the beginning, probe messages reporting three cores
NPU userspace: present only in fragments, inconsistent package references, a lot of manual validation needed
But after the first few steps were done, I had zero issues installing or building software on this–GCC 14.2 from Trixie, Bun as the primary scripting runtime, and the usual complement of build-essential, cmake, clang and ninja for C/C++ projects.
Python 3 and pip are present for the inevitable bits that still need them, and Docker runs cleanly, plus I made sure I had /dev/kvm available for virtualised workloads–and with the CIX patches for the P1 SoC, everything went swimmingly. The kernel is PREEMPT-enabled, which is pleasant for interactive work and inference latency, though I haven’t tested RT workloads.
I even got Proxmox to run reliably on this with zero issues (including creating ARM VMs on it) before wiping the NVMe to do some AI testing.
The one area where the software story gets awkward is the vendor-specific GPU and NPU userspace–covered in the next two sections. Everything else about running Debian on this board is unremarkable, which is a compliment.
Out of the box, the Linux graphics story was absent. The kernel side was in a half-state that looked superficially encouraging–/dev/dri/* present, both panthor and mali_kbase around, the system clearly aware of a Mali GPU, etc.
But Vulkan fell back to llvmpipe, and forcing the Mesa Panfrost ICD produced Unknown gpu_id (0xc870) errors. So I had piclaw go through the Orange Pi and component_cix-next package sources and find the missing pieces: vendor userspace for the CIX stack–cix-gpu-umd, cix-libglvnd, cix-libdrm, cix-mesa and a Vulkan ICD pointing at libmali.so.
Installing those got me partway–the userspace reported No mali devices found, because the board was still on the wrong kernel path. Once I rebound the GPU from panthor to the vendor mali/mali_kbase stack, /dev/mali0 appeared and Vulkan reported actual hardware:
deviceName = Mali-G720-Immortalis
driverID = DRIVER_ID_ARM_PROPRIETARY
OpenCL also came up correctly afterwards, again via the vendor path.
This was pretty good news as far as typical SBC testing goes, since it means you can get decent (if vendor-specific) GPU support working–but getting there involved driver rebinding, vendor package archaeology and a persistent module policy to keep the machine on the right stack across reboots.
The NPU story was, if anything, even more typical of this class of hardware.
Linux clearly knew there was an NPU–dmesg reported three cores during probe–but the userspace was absent or incomplete and the package references inconsistent enough that I had to validate URLs by hand. One package version was simply gone, another worked, and I only reached a coherent install because component_cix-next still had enough usable artifacts lying about.
Not to say the NPU is fake or useless–it isn’t. But the tooling has that familiar feeling of being assembled by several teams who weren’t speaking to each other as often as they ought–and if your interest in a board like this is local AI, that matters more than any TOPS figure on a product page.
This is where the board started being interesting.
Since I have been getting more and more involved in low level AI work, I spent most of my time testing local inference–the Orange Pi 6 Plus is not a universally good AI box, but it is surprisingly usable within a narrow envelope of models and runtimes.
And to make it usable for a few use cases, I needed a model-and-runtime combination that felt like an actual working stack rather than a demo. I ended up trying four inference runtimes–[PowerInfer], [ik_llama][ikl] (which is a CPU-optimized version of llama.cpp), vanilla llama.cpp, and my own Vulkan-patched version of llama.cpp that for the Orange Pi 6 Plus’s GPU (the NPU, alas, like many other ARM SoC NPUs, is designed more for vision processing than LLM work, and I spent a few evenings trying).
I ended up running well over a dozen different combinations of models and runtimes, and these five were the ones I invested the most time in, since I wanted a model that was powerful enough for “production” use even if it was a little slow in practice:
Inference performance by model and runtime|669
The dark bars are generation speed, the lighter bars are prompt processing. The verdicts on the right reflect what happened when I pushed each model through a real agent pipeline with tool calls, not just a short benchmark prompt–and that is where the gap between “fast on paper” and “actually works” showed up.
The Liquid models posted impressive raw tok/s figures but broke down in practice with blank responses and formatting failures. The 35B sparse model was surprisingly fast under ik_llama.cpp but ate all available RAM and failed roughly 40% of the time.
Only the Qwen 4B on Vulkan held up as something I would actually leave running and the best all-round result was Qwen3.5 4B Q4_K_M on Vulkan:
Metric
Value
Runtime
llama.cpp Vulkan
Prompt t/s
8.4
Generation t/s
9.7
Typical response time
6-25s
RSS
~5.3GB
Stability
10/10 pass at -ub 8
Not desktop-GPU territory, but enough to move the board from “cute” to “useful”. More importantly, it was stable–it followed my coding assistant’s AGENTS.md prompt correctly, handled tool calls, and didn’t chew through all available memory.
The production configuration I eventually settled on was:
Every flag has a story–especially (-ub), the micro-batch size, which controls how many tokens llama.cpp tries to process per Vulkan dispatch.
It turns out that the Mali Vulkan backend had a descriptor-set exhaustion issue that needed patching upstream before it stopped crashing (yes, I spent a while debugging Vulkan…), and I ran a set of benchmarks specifically for that:
Vulkan micro-batch tuning sweep|695
Bigger batches should mean better GPU utilisation and faster prompt ingestion, but the Mali G720’s Vulkan driver has a hard limit on descriptor sets–exceed it and the backend either crashes or silently degrades.
The green bars are stable configurations, the orange ones are not–and the dashed box marks where I landed for production. At -ub 16, prompt speed collapsed because the driver was already struggling; at 64+ it fell over entirely.
The tuning sweep showed where the practical ceiling was rather than the theoretical one:
At -ub 2, the setup was stable but underwhelming: about 4.3 prompt tok/s and 9.7 generation tok/s.
At -ub 4, prompt speed improved to 5.9 tok/s with the same 9.7 generation rate.
At -ub 8, which is where I eventually landed, prompt speed climbed to 8.4 tok/s and generation stayed at 9.7 tok/s.
At -ub 16, the whole thing became temperamental and prompt throughput actually collapsed to around 2.0 tok/s.
At -ub 32, it could survive a test run, but not in a way that inspired confidence.
At 64+, it was simply crashy.
So the practical production setting was not some elegant theoretical optimum–it was simply the highest value that stopped the Vulkan backend from crashing. That, in a sentence, sums up a fair bit of the experience of using this board.
llama.cpp on Vulkan was the best all-round practical setup, but only after patching and tuning.
llama.cpp on CPU was useful as a baseline and for sanity checks, but too slow once model size started to climb.
ik_llama.cpp on CPU turned out to be dramatically better for some 2-bit and sparse-ish workloads than I had expected, to the point where it occasionally made GPU offload look silly.
[PowerInfer] remained interesting mostly in theory; in practice it was too awkward and too far behind the other options to matter.
GPU offload was not always the right answer. A lot of the marketing gravity around boards like this points you toward the GPU or NPU as the only interesting path, but once you start timing things, the answer is much more conditional.
Qwen3.5 35B-A3B IQ2_XXS was instructive. Under stock llama.cpp, far too slow. Under ik_llama.cpp, dramatically faster on CPU–to the point where it occasionally behaved like a real system rather than a cry for help. But it had a roughly 40% empty-response rate, consumed nearly all RAM and swap, and was slow enough end-to-end that I would only call it “working” in the same tone one might describe a vintage British car that has just completed a short journey without shedding visible parts.
For that model, the runtime comparison was actually rather stark:
Upstream llama.cpp on pure CPU (-ngl 0) managed about 0.63 prompt tok/s, 1.07 generation tok/s and took 76.67s end to end.
Upstream llama.cpp with a token amount of offload (-ngl 8) was, if anything, slightly worse at 80.03s total.
ik_llama.cpp on CPU was the surprise winner by a ridiculous margin: 16.24 prompt tok/s, 5.24 generation tok/s and 12.75s total.
ik_llama.cpp with -ngl 8 promptly ruined that advantage and fell back to a miserable 71.33s total.
That is one of the more useful things I learned here: for some quantized models on this machine, CPU inference with the right runtime was not just competitive with GPU offload, it was much better.
The Liquid models were interesting for a different reason. LFM2 8B-A1B Q4_K_M managed roughly 46.7 tok/s prompt and ~32 tok/s generation on Vulkan–objectively impressive for the active parameter count–and LFM2.5 1.2B pushed generation to around 45 tok/s. On paper, these look like the hidden sweet spot. In practice both failed when pushed through the full agent pipeline: blank output, formatting failures, over-eager obedience to internal conventions. Useful to know, but not deployable.
For reference, the ranking I ended up with:
Qwen3.5 4B Q4_K_M on llama.cpp Vulkan at 9.7 generation tok/s was the only setup that felt production-usable.
Qwen3.5 35B-A3B IQ2_XXS on ik_llama.cpp CPU at roughly 5.3 generation tok/s was the most surprising result–impressive, but too flaky and memory-hungry to trust.
LFM2 8B-A1B Q4_K_M on Vulkan at roughly 32 tok/s generation posted a great benchmark number but broke down in real agent use.
LFM2.5 1.2B Q4_K_M on Vulkan at roughly 45 tok/s generation was quick but not dependable enough to matter.
Qwen3.5 0.8B Q4_K_M on CPU at about 46 tok/s sounds good until you ask it to cope with a full agent prompt.
So yes, the board can run local models. It cannot run all of them well, and a distressing amount of the work lies in sorting out which bits of the stack are broken on any given day, but it was a much better experience than with Rockchip boards, and I intend to try out Gemma 4 and more recent models soon.
While the above was going on, I kept tabs on both thermals and memory, since I expected sustained GPU or inference workloads to need active airflow. But I had to deal with the fan first, since the Orange Pi 6 Plus ships with a pretty beefy cooling solution that, sadly, is very on the loud side.
And there’s no fan curve–all you get with the CIX kernel is a sysfs interface via cix-ec-fan with three modes:
mute
normal
performance
The first leads to the CPU reaching fairly high temperatures under even moderate load, the last is unbearably loud, and the normal setting ranges from moderately quiet to annoying, so for most of the testing I moved the board to my server closet.
Again, the CIX P1 has 12 cores, but they are not equal–four low-power Cortex-A520 cores clocked at 1.8GHz and eight faster Cortex-A720 cores spread across four clusters at different peak speeds (2.2 to 2.6GHz). The kernel’s cpufreq subsystem treats each cluster independently, which means that it takes a bit of effort to max out all the cores:
sbc-bench reported no throttling during its run, which was encouraging.
The aggregate 7-Zip score landed around 33k, with the best single A720 core around 3874 and the A520 cluster way behind at about 1617–a nice reminder that workload placement matters on this SoC.
Memory bandwidth on the A720 cores was respectable: libc memcpy in the 15-17 GB/s range, memset often 35-47 GB/s.
The A520 results were dramatically lower across the board.
Memory Bandwidth
An interesting twist I lost some time exploring is that you can actually see some differences per CPU cluster, which is new for me in ARM machines:
Memory bandwidth by CPU cluster
Blue bars are memcpy (read-then-write), red bars are memset (pure write). The A520 cluster is roughly half the bandwidth of the A720s across both. This matters for inference because memory access patterns land on whichever cores the scheduler picks, and a hot path pinned to the efficiency cluster is immediately noticeable.
Thermals
On a quiescent system, sensor readings were good–most blocks hovered in the high twenties to low thirties Celsius:
GPU_AVE: 29°C
NPU: 30°C
CPU_M1: 30°C
CPU_B0: 32°C
PCB_HOT: 33°C
The thermal logs during the benchmarks were more reassuring than I expected:
idle and light-load readings sat mostly around 29-33°C across GPU, NPU and CPU blocks
under the longer benchmark runs, board and package sensors generally rose into the mid-30s to about 40°C range, which is very good (but, as you’d expect, audibly noticeable from outside the closet)
frequency traces showed the active cluster spending long stretches pinned at its target clocks before later dropping back, which looked much more like workload phase changes than panicked throttling
One benchmark artifact I largely ignored was the iozone run, because it was aimed at /tmp and therefore mostly measuring the memory-backed path rather than telling me anything meaningful about persistent storage.
Here’s a new chart that tries to capture thermals and frequency a little better than my old ones:
Thermal and frequency trace during sbc-bench run|653
The above covers the full sbc-bench session–roughly 40 minutes of mixed workloads.
The three shaded phases correspond to what was running at the time: a short iozone burst (memory-backed, not interesting), the main sbc-bench battery (OpenSSL, 7-Zip single and multi-threaded, tinymembench across all clusters), and the trailing cooldown.
The key thing to notice is that frequency stayed pinned at target clocks throughout the heavy phases and only dropped back during transitions–there was no thermal throttling, which is pretty amazing.
Temperature peaked around 43°C during the sustained multi-threaded 7-Zip run, which is well within spec for a board with active cooling. The idle baseline was around 29°C, and it settled back there fairly quickly once the load came off.
One thing I could not track was fan speed, since the cix-ec-fan interface does not expose current RPM or duty cycle, and I had no way to correlate the thermal curve with what the fan was actually doing at each point. I could hear it spin up and settle, but I have no real data to overlay, and even though I considered setting up a dB meter, I never got around to it.
All of the above covers the first week or so. But I’ve been running this board as an always-on machine since March 8, and by now have a month’s data on what it’s like to live with.
The board now hosts a piclaw instance (my personal assistant) that I’ve been using for development and model testing, since I realized that LFM2-8B-A1B made for a faster thing to experiment with (31 t/s generation, 47 t/s prompt on Vulkan) even if it’s effectively not that “smart”.
Alongside the assistant work, I’ve been using the board for a real development project: porting the BasiliskII classic Mac emulator’s JIT to AArch64.
Over the past month that has meant a good deal of compilation, linking, automated experiment runs and testing. The JIT now executes real 68k ROM code with basic optimisations–interrupt delivery and display rendering are the active frontier, but it boots to a Mac OS desktop every now and then. The constant rebuilds around AArch64 JIT bugs I hit (broken optflag inline asm bindings, various register allocation and flag bugs in codegen_arm64.cpp, VM_MAP_32BIT allocation failures, repeated runs at fixing emulated 68k interrupt delivery) were genuine low-level issues that exercised the board’s toolchain and memory subsystem in ways no synthetic benchmark would, and it’s been working great.
One thing that came up in every review of the CIX P1 I read–[Jeff Geerling’s Orion O6 writeup][jg] being the most prominent–is power draw, and I have a month’s worth of data to confirm that it’s higher than average–averaging at 15.5W, rather than the usual 13W that I see quoted in other places:
Orange Pi 6 Plus wall power over 30 days
The flat zeros on the left are the setup period when I was reflashing and debugging offline. Once it came up as an always-on machine the power draw settled into a consistent daily pattern.
Orange Pi 6 Plus wall power over 7 days
Zooming into the last week at 15-minute resolution, the daily idle/load cycle is clearly visible–overnight the board drops to about 15-16W, and during the day it hovers around 20-27W depending on what I am doing. Compilation and inference bursts push it briefly toward 30W; the rest of the time it sits comfortably in the low twenties.
That said, the idle floor of 15-16W is noticeably higher than what I am used to from other SBCs. A Raspberry Pi 5 idles around 3-4W, an RK3588 board typically settles around 5-8W, and even a Mini PC with an N100 can idle below 10W.
The Orange Pi 6 Plus never really gets below 15W even with nothing running, and that appears to be a common trait of the CIX P1 reference design rather than anything specific to this board–the Radxa Orion O6 (same SoC) shows a very similar baseline in the reports I have seen.
Whether that is down to the memory controller, the 5GbE PHYs, the always-on fan or some combination of all three, I cannot say for certain. But it does mean the board is less attractive as a low-traffic always-on appliance than the raw compute-per-watt numbers might suggest. At 15W idle you are paying about 130 kWh/year just to keep it breathing, which is not terrible but is not nothing either.
Orange Pi 6 Plus current draw over 7 days
I checked, and current draw mirrors the power profile and stays well under 0.2A on the 230V circuit. The board’s power supply is not doing anything exotic.
Mains voltage on the office circuit over 7 days
The voltage trace is mostly here for completeness–Lisbon mains hovering around 230-232V with the usual overnight sag and daytime recovery. Nothing that would stress any reasonable power supply, and useful as a sanity check that the power readings are not being skewed by wild grid swings.
Reboots over the month: essentially none that weren’t my doing. The board has been stable in a way I did not expect from the early boot-chain experience.
After all of this, the Orange Pi 6 Plus fits a fairly specific set of roles:
local inference experiments with carefully chosen models
edge-side telemetry or monitoring
compact Linux services that benefit from dual 5GbE
infrastructure roles where you want something denser and lower-power than x86 but more capable than the usual toy SBC
I wouldn’t use it as a general-purpose desktop, and I wouldn’t trust the NPU story for anything LLM-related without more soak time. But I would keep it around for the sort of edge-AI and systems work I usually get drawn into–enough real capability to justify the effort, even if that effort is, right now, unreasonably high.
Even considering that I cut a lot of corners on the software side to get to a usable state, the hardware is still very much ahead of the software.
The GPU works, the NPU stack exists in some recognisable form, and local AI is not only possible but occasionally good, and I like what it can do, even if the power consumption and fan noise are higher than I would like for a board in this class, but compared to Rockchip’s offerings, it’s a much more polished experience–and the fact that I can get it to do useful work at all by myself, with my own OS image, is a testament to the progress ARM boards have made in the last couple of years.
]]>Shottrhttps://taoofmac.com/space/apps/shottr?utm_content=atom2026-04-11T08:27:00+00:002026-04-11T08:43:20+00:00Rui Carmohttps://taoofmac.comShottr is a lightweight macOS screenshot and annotation tool that manages to stay focused on the useful bits while still packing in a surprising number of editing features: quick capture, measurement, redaction, OCR, scrolling screenshots, pinning, pixelation, arrows, callouts and the usual visual markup without turning into a full design app. It has the right kind of small-tool energy, and is one of those utilities that is easy to justify keeping around all the time.
It also has a free trial mode and is available via Homebrew, which makes it particularly easy to install and keep up to date:
brewinstall--caskshottr
]]>Markdownhttps://taoofmac.com/space/markup/markdown?utm_content=atom2007-02-28T21:44:57+00:002026-04-11T08:43:20+00:00Rui Carmohttps://taoofmac.comMarkdown is a text-to-HTML idiom, conversion tool and all-out ecosystem for web writers, content editors and… AI, allowing you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid (X)HTML.
Althought I used to prefer Textile for its table support and other niceties, Markdown has won that war and enjoys indisputably wider adoption, as well as making for slightly more readable text when writing essays.
Amusingly, it became the lingua franca of LLMs and is now the de facto standard for most modern documentation as well.
]]>Hyperkeyhttps://taoofmac.com/space/apps/hyperkey?utm_content=atom2026-04-11T08:13:00+00:002026-04-11T08:16:16+00:00Rui Carmohttps://taoofmac.comHyperkey is a tiny macOS menu bar utility that turns Caps Lock into a proper Hyper key, which is one of those small affordances that can make a keyboard-driven setup much more pleasant. The nice bit here is that it does this without dragging in the usual heavier remapping machinery, so it feels like a lightweight answer to a very specific itch.
If you use custom shortcuts or window-management tools, having an easy way to get a full Cmd+Ctrl+Opt+Shift chord out of Caps Lock is surprisingly useful.
TypeWhisper is a rather pragmatic macOS dictation and speech-processing tool that can use Apple’s own speech stack as well as other on-device models, which makes it more interesting to me than the usual cloud-first transcription wrappers. It also layers prompt-driven text processing on top of raw transcription, so it sits somewhere between dictation utility and local speech workbench.
The more appealing aspect here is that it can stay local when you want it to, but still gives you a fair amount of flexibility in engines and workflow. That makes it potentially useful not just for transcription, but also as a general accessibility and text-entry aid across the desktop.
Cotypist is one of the more interesting recent takes on system-wide text completion on the Mac, mostly because it appears to keep processing local and to use screenshot-derived context to improve what it suggests. That makes it potentially useful well beyond the usual “AI writing helper” niche, especially in situations where the surrounding UI matters as much as the current text field.
It also strikes me as a potentially valuable accessibility tool, since this kind of ambient completion can reduce typing effort, help with repetitive text entry, and provide a softer assistive layer across applications rather than inside a single editor.
It is currently free during the beta period, which lowers the barrier to giving it a try.
]]>The Cudy AX3000 Wi-Fi 6 System (with OpenWRT)https://taoofmac.com/space/reviews/2025/09/14/1630?utm_content=atom2025-09-14T16:30:00+00:002026-04-10T20:52:08+00:00Rui Carmohttps://taoofmac.comAs I’ve been writing about once or twice, I’ve recently upgraded my Wi-Fi after an attempt to use ISP-provided equipment to replace my remarkably long-lasting (and extremely reliable) Airport Extreme base stations.
The short of it is that I ended up getting a few Cudy M3000 and setting up OpenWRT on them:
The M3000 standalone router/access point
Disclaimer: Although I sought out (and paid for) several M3000 units myself, I’m following my standard format and review policy for consistency, since this is more or less a “review”.
The long of it has been a somewhat fun journey, so here’s the full story.
In case you’ve landed here without any context, I recently switched ISPs and the initial configuration included a set of Wi-Fi 7 extenders to replace my (very) long-lived Airport Extreme base stations.
Fully local, browser-based management (I don’t mind managing each device individually).
Absolutely zero cloud management features. Zilch. Nada. No setting up a user account with the vendor or any external dependencies (I don’t want or need off-site remote management—and if I did, I could set it up myself.)
No mobile apps required (or desirable) for either initial setup or daily tweaks (which was something I actually didn’t like about the Airport Extremes even if it was very convenient to have management baked into iOS).
Not an ugly arachnoid eyesore (we can’t hang access points off walls or ceilings, and the Airport Extremes became effectively invisible in plain sight).
And the M3000 doesn’t look half bad compared to an Airport Extreme, so that was definitely a reason for me to take a second look (they come in black too, but the white ones were drop-in replacements for the Airports in our decor).
As you can see, they are pretty neutral. I will miss the extra LAN and USB ports, though.
Technically, I had a few more requirements:
I wanted “dumb” access points. No routing, no meshing, no weird/proprietary vendor features—just a box able to turn Ethernet packets into radio and back again.
I decided to aim for Wi-Fi 6/6E (I quickly realized that we only have a couple of MacBooks able to do Wi-Fi 7 and that most of our devices are Wi-Fi 6 capable).
Full control over all Wi-Fi features (channel, SSIDs, power, etc.) with support for an arbitrary number of SSIDs (with VLAN mapping of each) on both 2.4/5 GHz (or 6 GHz if available).
No band steering (it does not really work in our scenario, and one of the biggest gripes I had with our ISP setup was that I couldn’t turn it off).
2.5GbE backhaul (gigabit-plus Wi-Fi is useless if you can’t pipe it through.)
At least one pass-through Ethernet port (the Airport Extreme has three additional GbE ports, which is still apparently a premium configuration over a decade later but has proven very, very handy)
OpenWRT was not really a requirement, but since my first-ever Wi-Fi access points were indeed WRT54G devices and I have a long history with it, that’s where I started my research, and Cudy hardware had quite a few positive references.
Moreover, they actually provide instructions on how to re-flash their devices with OpenWRT, and there is an upgrade path to the currently supported version (as well as a likely runway of official OpenWRT support for a few years at least), so they soon rose to the top of my list.
The factory firmware is actually very nice, and makes an excellent job of exposing all of the features as well as guiding users through initial setup of the devices either as a router or as an access point in various configurations:
The base Cudy UI is very comprehensive.
I didn’t run it for long, but it seems to do a very good job of exposing both OpenWRT core functionality and the additional features Cudy added. Although I didn’t install their app or tried to manage it remotely, I’d say most people would be well served by the factory firmware–and since it even supports TR069 for carrier remote management, ISPs probably should take a look at it too.
But my objective was to make sure I had full control of the hardware and run these on the latest vanilla OpenWRT, so there were a few more steps involved.
The first thing I needed to do was unlock the factory firmware. The white/grey devices I have are “V2” hardware, but Cudy themselves say that the firmware is identical to the V1 (which is black with red trimming) and provide a vanilla OpenWRT 23.05 image, so I started out with that.
That ZIP file contains a Windows version of tftpd (which is an extra nice touch, even if it triggers a bunch of virus warnings), a comprehensive set of instructions for Windows users in a PDF and a few firmware files, which we’ll get to in a moment.
To get the latest supported firmware, I went to the OpenWRT Firmware Selector and looked for the Cudy M3000, downloading the latest sysupgrade file. I downloaded 24.10.2 (r28739-d9340319c6).
I then set up tftpd on one of my Fedora laptops (because, I don’t have personal Windows machines anymore) and wired it up to the LAN port on the M3000.
To enable it to get at the recovery.bin file via TFTP, I copied that file to /var/lib/tftpboot, set my laptop to IP address 192.168.1.88 and restarted tftpd.
I then held down the power button on the M3000, plugged in the barrel jack, waited until the lights settled (solid red in my case) and then reset my laptop to use DHCP, because the next step is to log in to the (now unlocked) Cudy web UI at http://192.168.10.1.
Once you’re there, go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin (checksum d09cdb39e9544b1d33a4daf28964c50b), which is also provided in the ZIP file.
This gives you a vanilla OpenWRT 23.05 install, and you then go to http://192.168.1.1/cgi-bin/luci/admin/system/flash, upload the 24.10.2 file and… you’re done.
Start tftpd with the recovery.bin file in /var/lib/tftpboot.
Plug in the power jack while holding the power button, wait until the lights settle (solid red in my case).
Reconfigure your machine from 192.168.1.88 to DHCP.
Log in to the Cudy web UI (http://192.168.10.1), go to Advanced Settings/Firmware and upload cudy_m3000-v1-sysupgrade.bin (d09cdb39e9544b1d33a4daf28964c50b).
Wait for it to reboot.
Go to http://192.168.1.1/cgi-bin/luci/admin/system/flash and upload the 24.10.2 sysupgrade image.
I initially got a standalone unit to test and then bought a 3-pack and another standalone unit (to keep as a cold spare), so I had a working configuration I could use to set up the new nodes way before I got them all.
Over that initial week with the first unit, I sorted out all of the details:
Disabled the built-in DHCP server
Added both Ethernet ports to the br-lan bridge to allow pass-through (this way I can plug an Apple TV or similar directly into the gigabit port)
Set the timezone, checked that NTP worked correctly, etc.
Installed rsync and luci-app-statistics to play around with configuration files and monitoring
Set up the 2.4GHz radio for a “compatibility mode” that wouldn’t frustrate my IoT devices (including the many low bitrate ESP32s lying around)
Set up WPA3 on the 5GHz radio to enable full 802.11ax data rates (I also punched up the channel width to 160Mhz and set up 802.11r for faster hand-overs)
This bit is probably the most interesting for everyone, so here’s a redacted version of my initial /etc/config/wireless:
To set up the other nodes, I just uploaded the first one’s configuration backup, changed the hostname and IP address (given the vagaries of our new home gateway, I opted for static IPs) and plugged them in.
My iPhone and MacBook Pro can both do 1.2 Gbps down / 1.5 Gbps up within 2–3 meters of any of the access points when connecting to our internal OpenSpeedTest instance—which I’m hosting on one of my TerraMaster’s 10GbE interfaces:
OpenSpeedTest hosted on my 10GbE NAS
Running a second simultaneous test gives obviously lower (but similar) individual results and maxes out the 2.5GbE uplink, so I would say this is about as good as it’s ever going to get, since I suspect that even if we were using Wi-Fi 7 and 6GHz, physics and the 2.5GbE backhaul would start factoring in.
Again, this is in a pure “flat” configuration, with all physical interfaces and radios set as part of the br-lan–no routing is taking place, and no layer 3 handling is happening.
Our staple latency test (streaming games using Steam Link from a 2.5GbE server) is buttery smooth, but then again it was already good with the Airport Extremes (you only really need 30-50Mbps for crisp 1080p streaming), and the Logitech G Cloud (which, ironically, has worse Wi-Fi than any of our iPads) works perfectly.
But I’ll let the data speak for itself:
PHY bitrate in my living room
This is the same kind of performance I was getting with the Wi-Fi 7 extenders from my ISP, but:
I can now see it, monitor it and dive into the nitty-gritty details at will instead of having to guess what was happening.
Even though it’s not Wi-Fi 6E, it is a massive improvement over the sub-300 Mbps I was getting from the Apple Airport Extremes.
There is some occasional flip-flopping between access points, but that only happens in Linux and in places where coverage has strong overlap, so I’m not worried about it (I can always turn off 802.11r if it becomes a nuisance, and I consider it an experiment, not a requirement):
This is a good example--I see a similar pattern in the nearest AP to this one
Looking at the logs from both APs involved it seems to be a client issue:
Sun Sep 7 09:50:00 2025 daemon.notice hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: did not acknowledge authentication response
Sun Sep 7 09:50:46 2025 daemon.notice hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: did not acknowledge authentication response
Sun Sep 7 09:50:48 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: associated (aid 5)
Sun Sep 7 09:50:48 2025 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED a6:a8:e5:87:20:d0 auth_alg=sae
Sun Sep 7 09:50:48 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 WPA: pairwise key handshake completed (RSN)
Sun Sep 7 09:50:48 2025 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED a6:a8:e5:87:20:d0
Sun Sep 7 09:54:34 2025 daemon.info hostapd: phy1-ap0: STA a6:a8:e5:87:20:d0 IEEE 802.11: authenticated
Sun Sep 7 09:54:45 2025 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED a6:a8:e5:87:20:d0
This hasn’t recurred, but I will be keeping an eye on things–and if you want to dig deeper into 802.11r configuration, this great page has a bunch of detail on it.
So far there haven’t been any unexpected behaviors, and since I am not using band steering (which you can add by installing usteer or dawn and their corresponding luci packages, by the way) everything’s been fine with my legacy devices.
While I was going through this process, I got a bunch of feedback from people online:
Why not UniFi? Value for money, plain and simple. I have used Ubiquiti devices before, but I wasn’t going to pay three digits for a “dumb” access point and don’t need most of their features.
Why not Wi-Fi 7? There isn’t anything similar with Wi-Fi 6E/7 support and 2.5GbE backhaul yet–at least not anywhere near this price point. Cudy does have other models, but they haven’t released unlocked OpenWRT firmware (yet, I hope) and besides, I am already getting gigabit-plus speeds for all my devices.
What about meshing? It’s useless for me. We have reinforced concrete walls and two lift shafts in the middle of our flat and even 2.4 GHz has issues, which is partly why I made sure we have at least two Ethernet jacks in each room when we renovated over twenty years ago.
What about roaming? This is a home (office), not an independent country. Standard Wi-Fi handovers work fine even if you walk around the house on a video call. I enabled 802.11r anyway but see no need for it.
What about central management? It’s just four active devices, and they’re all set up as “dumb” access points, so there isn’t a lot to manage except when I’m setting up a new VLAN or need a test SSID. Gathering stats off luci-app-statistics via collectd is a wheel that’s already been invented, so I don’t need a controller for that.
All in all, I don’t even need the LuCI web UI, and if I need to test a complex configuration I can hack something together with ssh and ansible for reproducibility in around 30 minutes.
The Cudy AX3000/M3000 models make for pretty great Airport Extreme replacements, and in this age of networking devices with cloud features nobody asked for OpenWRT turns them into very nice locally managed access points that I will never have to worry about again (until I break the configuration myself, of course).
Although it is much too early to weigh in on hardware reliability (some of the 802.11acAirport Extremes I was using were manufactured over a decade ago), the price/performance ratio is great, and right now I don’t mind it not being Wi-Fi 7.
After all, it took almost ten years for the 2.4GHz band to become saturated in my building, and it doesn’t look as if the 5GHz band is going to be massively swamped anytime soon, so I’m expecting something like 3-4 years of hassle-free operation if the hardware holds up.
A relevant thing I should point out again is that people who have less need for low-level control might actually be fine with the stock firmware—I did not use it extensively (nor did I try the Cudy app or any of the router/firewall features), but it already exposes a lot more functionality (and seems a lot more flexible) than ISP gear, so I would encourage people to give it a go.
I suspect I will eventually come across some OpenWRT corner cases as I succumb to the temptation to fiddle with the configuration a bit more, but given our particular situation there’s a very high chance these will just fade into the background and “just work”, which was the ideal outcome that Apple pretty much nailed with the Airport Extremes…
Update, September 24, 2025: I decided to tweak my settings a little bit and enabled 802.11k/v on both radios, which seems to have improved the flip-flopping. That meant upgrading wpad-basic-mbedtls to the full version (opkg update && opkg remove wpad-basic-mbedtls && opkg install wpad-mbedtls) and the following settings:
I suspect I might have to tweak the 802.11k settings a bit more, but so far it seems to be working well.
Update, December 2025: I've been told that [Cudy] has updated their [OpenWRT page][cudy_support] with newer firmware versions, so if you're doing this now, make sure to check there first since new hardware revisions (serial numbers starting with 2543) require a different recovery image (good thing I bought a spare unit to keep things uniform). So far, I've had zero issues with any of mine.
After a few more months of living with these, I ended up revisiting the 5GHz configuration. The main thing I changed was to stop trying to be clever with HE160. It did work, and on paper it looked great (those headline PHY rates are always tempting), but in practice it made the whole setup feel a bit too fussy for a house where I care more about moving around on FaceTime calls and carrying on with work than about wringing the last possible megabit out of a speed test. In hindsight this was fairly obvious: HE160 is a lot of channel width to throw at a multi-AP setup, and I was also leaving channel selection on auto, which wasn’t helping matters.
So I simplified things.
I kept the 5GHz SSID as the “good” network – WPA3, 802.11r, 802.11k, 802.11v, all the usual niceties – but moved the radios to HE80 and assigned fixed channels to each AP. That gave me a much saner setup: lower theoretical peak rates, yes, but much better behaviour in day-to-day use.
The current 5GHz plan is now:
AP 1: channel 36
AP 2: channel 52
AP 3: channel 100
AP 4: channel 116
And the relevant OpenWRT configuration now looks like this:
HE160 is fine if you care more about peak throughput than roaming, but I don’t.
Fixed channels make overlap and neighbour relationships much easier to reason about.
802.11r only really makes sense if all APs serving a given SSID are configured consistently, so tidiness matters more than “advanced” settings.
Keeping the 2.4GHz network as the compatibility lane for older and IoT devices is still the right trade-off here.
So far this seems to have paid off. The 5GHz metrics now look much more sensible, and the APs are behaving in a way that feels a lot closer to what I wanted in the first place.
The other thing I finally got around to doing was centralising the AP metrics. I already had luci-app-statistics and collectd on all of them, so rather than inventing some sort of controller story for a handful of dumb APs, I just pointed them all at the Graphite instance I already had on the network. This turned out to be mildly more annoying than expected, because although collectd-mod-write-graphite is available, the LuCI-side renderer for it wasn’t present on these installs – so adding a UCI block under luci_statistics wasn’t enough to get a runtime config generated.
The package installation itself is straightforward:
opkgupdate
opkginstallcollectd-mod-write-graphite
The part that actually mattered was dropping a native collectd include file into place:
and after that it was just a matter of restarting collectd:
/etc/init.d/collectdrestart
That was enough to get all the APs reporting centrally, which makes comparing station counts, signal levels and bitrate across the house a lot easier than peering at each box individually.
If anything, this only reinforced my original conclusion: there is still no compelling reason to replace a handful of perfectly good OpenWRT access points with a controller ecosystem when a bit of channel planning and a central metrics sink get you most of the way there.
]]>Clojure(Script)https://taoofmac.com/space/dev/clojure?utm_content=atom2013-08-20T17:09:00+00:002026-04-11T08:16:16+00:00Rui Carmohttps://taoofmac.comClojure is a LISP dialect that targets the Java VM - but that also happens to have a number of other back-ends, including a JavaScript one.
Error: Could not parse 'table.yaml'
while parsing a block mapping
in "<byte string>", line 2, column 1
did not find expected key
in "<byte string>", line 438, column 1
]]>Window Managershttps://taoofmac.com/space/apps/window_managers?utm_content=atom2010-08-05T21:43:06+00:002026-04-10T11:03:57+00:00Rui Carmohttps://taoofmac.comWindow managers on macOS (and Windows) are auxiliary programs that try to complement the system’s own handling of windows, and are not as powerful as X11 window managers. However, there are a few exceptions, and as I started using bigger and bigger (and more) displays I’ve been using them on a daily basis.
My requirements change over time and in different circumstances (sometimes I need an automatic tiling window manager, sometimes I just want good window snapping to predefined zones), so I experiment a fair bit–the listing below contains most of my favorites over time in various operating systems.
Apps are listed as primarily keyboard or mouse driven even though most support both kinds of input. What matters in that classification is the fastest way to arrange windows.
Some commercial solutions (and potentially insecure Mac solutions like yabai, which require you to explicitly disable System Integrity Protection) are intentionally ignored.
My 2012-2021 window manager, which allows you to store predefined layouts but wasn’t scriptable. The 2024 edition adds FancyZones-like functionality and a bit more flexibility.
My 2024 favorite for tiling. Provides a fast, snappy i3-like tiling window manager for macOS with its own workspace support, and the default config uses HJKL as control keys. Only issue I have with it is that it requires relatively new macOS versions, and I sometimes use an older Mac laptop.
a nice, also JavaScript scriptable window manager that includes an IDE. In May 2021, the IDE hangs up weirdly in Big Sur, so I opted for Phoenix instead.
]]>Model Context Protocolhttps://taoofmac.com/space/ai/mcp?utm_content=atom2025-05-01T17:30:00+00:002026-04-10T11:03:57+00:00Rui Carmohttps://taoofmac.comThis page is a collection of notes and links related to the Model Context Protocol (MCP), a proposed standard for extending managing context in large language models (LLMs) via external tools.
local markdown-first knowledge indexing/search engine with hybrid BM25/vector/reranking and MCP transport for Claude-compatible clients, plus context-aware retrieval via CLI.
a WebMCP demo that lets agents compose music in a browser-based sequencer via WebMCP tools
]]>Pythonhttps://taoofmac.com/space/dev/python?utm_content=atom2007-04-15T10:44:37+00:002026-04-13T18:32:30+00:00Rui Carmohttps://taoofmac.comPython is one of my favorite programming languages due to its terseness and amazing flexibility, and after decades using it I find it quite amusing that it is now the language of choice for data science and machine learning.
This will install packages to your Library folder rather than to the
system directory, saving you the trouble to use sudo or risking
messing with the system installation. Of course virtualenv does a
better job for keeping track of project-specific dependencies, but this
is great for common/complex dependencies and is sure to survive
operating system upgrades.
And then you can use easy_install or pip install --user with
impunity, although you might need to do something like:
]]>Xteink X4https://taoofmac.com/space/hw/xteink/x4?utm_content=atom2026-04-09T13:19:00+00:002026-04-11T08:16:16+00:00Rui Carmohttps://taoofmac.comThe Xteink X4 is a small open e-ink reader that has become more interesting because of the growing CrossPoint ecosystem around it. The hardware itself is attractive mostly as a hackable reading device: simple, portable, and now backed by a fairly active alternative firmware community—one that feels more relevant now that it is a device that I recently got.
The most sensible starting point is the upstream CrossPoint Reader firmware, then branch out into more specialized forks only if you need particular UX changes, CJK support, or more experimental features.
Adafruit guide for running CircuitPython on the ESP32-C3-based Xteink X4, including installation, web workflow and display demos
]]>Obsidianhttps://taoofmac.com/space/apps/obsidian?utm_content=atom2022-08-03T12:00:00+00:002026-04-09T18:14:07+00:00Rui Carmohttps://taoofmac.comObsidian is a very popular cross-platform note-taking application that allows you to use plain Markdown as a very flexible notes database and that I have somewhat begrudgingly adopted as a key part of my workflow during 2025.
I don’t exactly remember when I started using Obsidian daily—I suspect it was when I finally figured out how to use it with SyncThing on my iPad, but another (just as important) milestone I remember was when I got the Kanban plugin working, since that gave me a sensible cross-platform way to manage my to-dos across Mac and Linux (Reminders just doesn’t cut it in that scenario).
Don’t get me wrong, I still don’t like Obsidian. It is one of the many Electron-based nightmares that we have to run on our devices because, unfortunately, there isn’t anything demonstrably more developer-friendly (note that I didn’t say better).
In particular, I don’t like that it’s not open source, since despite not minding paying for software I think that anything I commit to using for multiple years should last “forever”. I don’t like how it approaches linking and metadata, and I absolutely didn’t like that it tries to tie you to a proprietary syncing service.
Despite all that, I use it daily on Linux, macOS, and iOS, and the combination of cross-platform access and the Kanban workflow fits my day-to-day needs perfectly.
The Kanban plugin has turned into my master to-do list, and I never managed to get Reminders to work cross-platform in the same way.
There is a plugin that allows me to have my Supernote Nomad notes show up in Obsidian, which is a nice trick. In fact, I can even run Obsidian on the Nomad itself.
The Markdown editor essentially disappears when you’re editing, which I like because it lets me focus on the content rather than the formatting. Somehow iA Writer feels less polished, which is weird—I suspect it’s about it not being truly WYSIWYG.
Obsidian’s secret power on mobile is the iOS swiping keyboard—I’m able to thumb type quite quickly with it, to the point where it’s just ridiculously easy to take an idle moment to jot down ideas.
The Data Tables feature is stupendously powerful, and I am actively resisting using it too much because I know it will make my notes less portable.
There are enough rough edges that I still keep coming up against the same issues:
Its WikiLinks can’t be relative, or link to a page/folder rather than an .md file.
Electron is a resource hog and feels sluggish on older hardware, so I end up editing in Vim or another editor quite often.
It cannot deal with front-matter “properly” (at least not the way I want it to), so importing this site into it never worked (and it is highly likely that it never will). That also means I can’t use it as a primary editor for this site directly, or, in fact, for a few MkDocs-based sites I maintain.
It’s proprietary in key ways (syncing, mobile app limitations, not open source).
The Canvas feature is a nice idea, but it is nowhere near as good as a proper mind-mapping app like XMind (or even Apple’s Freeform).
The graph view is cute, but not really useful for anything other than showing off.
Setting a common look and feel across platforms is tricky, especially on iOS where CSS tweaks are limited.
Plugins are very brittle, and hit-or-miss in quality. After a few months of trying out various plugins, I have no clue as to whether my current set of plugins will be maintained in the future (a couple that I use already bear deprecation notices, and I certainly don’t want to maintain them).
It really doesn’t understand about folders, or about “one note per folder with all attachments” approaches. With the right plugins you can just paste an image into a note and it will store the attachment in the same folder, but it still feels hacky.
I eventually worked out a set of alternatives and workarounds that make Obsidian usable for me:
On iOS you can use Möbius Sync to keep a local folder and then use SyncThing to sync a single vault. You do have to be careful about it, since the mobile app is way behind the desktop apps in functionality and feels artificially gimped—for instance, you cannot pick a vault location at will, so you need to be creative with workarounds (this is even true if, like me, you’re used to iOS folder sharing).
Thanks to the Linter plugin, I can enforce a set of formatting and metadata rules that make my notes consistent across platforms and editors, even if Obsidian itself doesn’t really understand them.
I have a little script that takes an Obsidian note and moves it across to this site, where I finish editing it and publish it using VS Code. In fact, if VS Code had a decent live Markdown editor and a comparable Kanban editor, I might just use that instead of Obsidian altogether.
I suspect that some day I will take something like Foam and hack it into a workable notes system that I can run in VS Code, but for now Obsidian is “good enough” despite its many flaws.
local-first CLI for Obsidian vaults that operates directly on markdown files without the Obsidian app, designed as a memory system for AI agents using progressive disclosure.
Plugin that gives Obsidian agents a dedicated, persistent memory interface to retain and recall conversation context and project notes across sessions.
Zero-terminal real-time sync engine for Obsidian using your own Cloudflare Worker instead of conventional file sync or self-hosted database-heavy setups.
Agent Skills bundle for Obsidian that teaches compatible agents to edit Obsidian Markdown, Bases, JSON Canvas, and interact with vaults via the Obsidian CLI.
AI-powered assistant panel that plugs into GitHub Copilot or BYOK providers, bundles agents/skills/tools/prompts/triggers, offers ghost-text autocomplete and editor context menu actions, and boots a sidekick/ folder with sample configs.
Probably the nicest, most straightforward LLM plugin for revising grammar and overall formatting. Supports LiteLLM and custom endpoints without any issues.
a static site generator that can directly publish Obsidian vaults. It’s beautiful, but suffers from the usual PWA stupidity of downloading a contentindex.jsonwith your site’s entire plaintext to facilitate search.
