It’s a bit insane that we’re past mid-September and my living room is still sitting at 29oC at 7AM, but such is life in the late Holocene, I guess. Regardless, the shift towards Autumn is starting to show, and I’ve had a couple of days where I suddenly realized I was working “late” into the evening and the lights started coming on automatically (never a good sign unless you’re having fun).
I have had to split my free time between a bit of stress at work and working on my health (neck, posture, back, exercise and other things). Yet, things keep happening.
Halfway through the week I decided (again) to do a couple of minor interventions and remove more social media apps from my machines–I have not been using Bluesky, Threads or Reddit at all for months, so those were easy decisions, but I am somewhat besmirched that I can’t really useMastodon (i.e., Ivory) for anything meaningful (and yet am paying a subscription for Ivory because it is the best iOS experience) and that Twitter (yes, I will keep referring to it as Twitter), sadly, remains the “best” window into the tech industry’s collective unconscious today, even as it continues to be a cesspool with no signs of improving.
Even forcing the “Following” tab with chronological order and using a web script to filter out ads is a compromise (ethical, political and mental health-wise), and yet I cannot look away.
Not for the dopamine hits, but for the edgier, more interesting hustles going on 24/7.
There is actual progress everywhere, but there is also a lot of tenuous hype, Silicon Valley bro culture, and subdued (yet sometimes misguided) pushback from the rest of the world.
It’s neither wholesome nor ultimately productive, so I’ve capped Twitter at 15m daily–the same as Hacker News, which still carries a semblance of authority even though the hustle is just as real there.
But I digress, again.
Consider this my usual yearly rant, which is steeped in tradition.
My Codex Open Source account is active again, so during the week I finished a bunch of low-impact polish work I had been meaning to do for ages now:
piclaw now has budget controls, marginally more consistent Settings UI across its two skins, model/session pickers, VNC panes, etc., as well as some timeline SVG fixes.
I took the time to do some “reverse TDD” and generate a shared Gherkin behaviour specification for the piclaw web UI, and then applied it in a consistent UX refactor for both vibes and tau-prime–I kept trying to use their bespoke interfaces and getting annoyed at the differences in agent steering, timeline attachments, session controls, etc., and at least now most of it is broadly consistent.
memento now has… Trash, somewhat saner bulk memory operations, and doesn’t “lose” older revisions when you’re looking at it as a reviewer; old proposals were being invalidated upon new revisions of a node, even if those new revisions didn’t address the proposals, and useful stuff was getting “lost”.
My piclaw agents can now talk across completely different networks using iroh (in fact, that is how I am porting memento to Go now, with two different agents coordinating between Intel and ARM hardware for testing).
Since I am still deep into agentic stuff at work, I decided to add an A2A connector to piclaw-addons. Its main goal is to provide me with all the enterprisey stuff I need for testing other agents: authenticated client/server, durable task mapping, pinned agent-card trust and authenticated push notifications.
There will be a few more additional features for these, but I think we’re hitting diminishing returns here, at least until I need to solve new problems…
Yes, I’ve been looking at TypeSafe’s Jev too, and trying to figure out how to emulate it with various techniques in go-pherence, because I really like the idea of smaller, focused models doing bounded jobs–I’ve never liked the fuzziness of LLM-generated JSON (there was a time when I was hacking on guidance to force schema compliance), and I think the principle is broadly right: most business AI I come across could be solved with a set of steps using BERT/Bayesian-like classifiers–but those classifiers would only work if we could “train” them with general knowledge, and that is what Jev “solves” to a large degree.
I’m poking at every open weights “implementation” out there right now, because I have dozens of scenarios where I can use something like Jev, but local.
For instance, it would have been great to have it back when I was running my feed summarizer instead of hacking my own classifiers, and Shelf would also benefit from a general purpose classifier for a bunch of things.
I got a new amazing KVM this week, which I am having too much fun with and will write about soon. Right now I am trying to clear out my review backlog, so the reason I mention it is that I can finally go back to setting up and testing more machines and clear some desk space, which is delightful since it has been a losing battle for months.
Now I don’t have to bother with anything but providing power for some of them, which makes things a lot simpler.
I’ve been keeping local replicas of my GitHub projects since… forever, but I’ve been neglecting the mechanics of it a bit, so this Friday I asked piclaw to:
Consolidate all my mirrors under a GitHub organization on my local Gitea instance, adding the missing ones from my recent projects.
Audit the inherited polling schedules against repository activity. Old projects now get quarterly checks or less, and we stopped polling things that got removed from GitHub (like emulators and other things I thought were worth preserving).
My old trick for managing polling overlaps is to set distinct intervals using a prime (or product of primes) number of seconds, but I told the model to add one-time jitter to clustered next runs, and this not only cut down Gitea polling from around 90 checks a day to around 20, but also made the overall distribution much nicer:
Longer polling intervals reduce the number of checks; one-time jitter spreads out the next runs.
This took, oh… 30 minutes, tops.
And I didn’t need to keep an eye on it, so likely less in practice.
My Writing Workshop thing is progressing well and has been quite helpful already in putting this draft together, so I am very happy with it so far–in less than an evening, I have a very helpful assistant (perhaps a bit too helpful and insistent, mind…) and the overall experience has been quite positive:
Writing Workshop showing the weekly draft with highlighted passages and a review findings panel
Of course there is a lot of polishing to do (my original intent was to add polish, not too much friction, and right now the 22 kinds of suggestions from the assistant are a bit overwhelming), but it’s a matter of tuning out what I don’t need and focusing on the improvements that truly impact the quality of the draft.
And then, who knows, maybe this will evolve into something even more substantial.
But what I’m most happy with is that I finished both Norse Mythology and Last and First Men this week, which is a positive data point in my return to reading.
I did get piclaw to go into GoodReads and mark them both as read for me from my Nomad, so it wasn’t a completely AI-free experience, but I am pretty sure my priorities are OK.
Still very much in line with the overall return to work mood of the past few weeks, I thought I’d post some notes about work gear.
You see, I have been using a “Surface Laptop for Business 13in 1st Ed with Snapdragon” (I kid you not, that is what it is called) for a couple of months now.
And it might be the best Windows laptop I’ve ever used–at least in summer.
Doesn’t look like a MacBook, or… does it?
Disclaimer: This is a work machine–a loaner, alas, not a permanent replacement–but I’m writing it up under my review policy all the same.
Although I don’t have a MacBook Neo on hand, I’d like to get that comparison out of the way because the general look is quite similar–except for the taller display (which I quite like, by the way) and the Windows logo.
Here’s my MacBook Pro vs Surface Laptop instead.
I looked up the Neo’s specifications and the Surface is a little narrower, slightly deeper front to back and a bit thicker, but they weigh practically the same.
And yes, this looks and feels a lot like a MacBook in general–it has the metal case, large trackpad and even the rounded display corners down pat, which helps establish an overall feeling of polish.
Even though this is a 16GB machine, it is actually one of the entry-level Surface configurations as far as CPU (and size) are concerned–I am using the 13-inch 1st Edition, with the eight-core Snapdragon X Plus. You can check the online specs for the business model, but this is pretty much it:
The basics, straight from Windows (IDs redacted).
8-core Snapdragon X Plus X1P-42-100 (clocked at 3.30GHz)
16GB LPDDR5x RAM (15.6GB usable)
512GB SSD storage
Qualcomm Adreno GPU and Hexagon NPU, rated at 45 TOPS
As you’ve probably gathered by now, I like tall displays, and I am quite fond of the Surface’s, whose 3:2 aspect ratio accounts for that slightly taller feel I mentioned earlier.
The panel has a density of 178ppi (decent, but not Retina), a refresh rate of up to 60Hz and a rated brightness of 400 nits.
The fact that it is a touchscreen is something I happily ignored for a long time with no ill effects, but it is quite useful, and colour reproduction seems quite good–I’ve found blacks to be nice and deep.
The keyboard is a bit hard to pin down–I quite like it, and it feels softer than a Mac’s, but with good travel and a slightly stronger “thock” when typing at speed.
It has a Copilot key (which I remapped to Search inside the first hour of using it), and the power button doubles as a Windows Hello-compatible fingerprint reader, so my hard-wired Touch ID reflex was quickly sated:
Power button with integrated fingerprint reader.
The backlight has three discrete levels, and if you’re used to a MacBook keyboard, you’ll need some adjustment regarding the Fn key (which is to the right of the left Ctrl).
As to the trackpad, it’s large, roomy and responsive, but the OS doesn’t drive it the way macOS does–there’s none of the gradual, weighted motion I’m used to, so gesture feedback feels noticeably different at first.
But the responsiveness is there, just not for scrolling (and yes, one of the first things I did was to enable “natural” scrolling), and Windows swipe gestures work nicely.
One relevant note is that since I’m a “tap-to-click” person, it took me a while to realise that clicking only really “worked” halfway down the trackpad–typically for gestures like clicking with your thumb and dragging windows with a finger.
The Surface has one USB-A port and a headphone jack on the left and two USB-C on the right, with both USB-C ports specified for charging, data and DisplayPort 1.4a, with support for up to two 4K displays at 60Hz.
Surface Laptop ports on either side.
They read out as USB 3.2 ports rather than USB4 or Thunderbolt.
On occasion, only the port farthest from the screen would drive an external display, and the documentation doesn’t explain the difference I saw between them.
That didn’t stop it from being very enjoyable to use for work–I was able to drive a 4500x3000 panel at 60Hz (and a Logitech Brio 4K hanging off its USB hub) with zero issues, and the experience was excellent throughout.
The “Omnisonic” (again, that’s actually what they are called) speakers are invisible–no grille or opening that I can find, and yet they sound surprisingly good, which justifies the Dolby Audio label.
The two “Studio” mics discreetly embedded in the bezel alongside the 1080p front-facing camera also worked fine, and over the past couple of months I had zero complaints during Teams calls.
Two of the reasons why I love this machine are that it is dead quiet (I’ve never heard a fan) and, most importantly, it stayed almost perfectly cool in normal use throughout late July and August.
I did start out by feeling some warmth under load in the first few hours (yes, Windows Update, thank you), but over longer use it has been confined to the underside.
The bottom case never seemed to go past about 42°C under sustained load, and the heat spread pretty uniformly–at least based on my spot IR thermometer.
One of the stranger bits of friction has been Wi-Fi roaming.
The machine uses a Qualcomm FastConnect 7800 adapter, and with my Wi-Fi 6 setup it kept dropping off the network often enough that I did an AP-side audit rather than blame Windows on vibes alone.
Qualcomm FastConnect 7800 driver settings.
The living room AP looked healthy, with continuous telemetry, no LAN or backhaul errors and good 5GHz associations.
But the Surface was the most frequently disconnecting client in the OpenWrt hostapd logs, repeatedly dropping off and reassociating across the access points.
That made client-side roaming or band steering worth investigating, especially with usteer in the mix, but the logs alone were inconclusive, and without Linux support doing any low-level troubleshooting on the Surface was out of the question.
I lowered the driver’s Roaming aggressiveness setting to Medium-low, and that seems to have fixed it.
Preferring 5GHz and disabling adapter power saving would have been my next steps, but it wasn’t necessary.
I am considering delving into WLAN AutoConfig logs further to help distinguish Windows/driver decisions from AP-side steering, but if it works, I’m not going to “fix” it further.
Spoiler: I had zero issues.
I did not think twice about this being an ARM device, nor did I do any weird compatibility tests–in fact, up until I started drafting this I hadn’t even installed WSL (it works perfectly for what I tried, and you get an ARM Linux userland, just as you would expect).
This is because I have been using it almost exclusively for non-developer work (Office, Teams calls, a lot of Remote Desktop–which is where I actually develop), and the occasional CAD session using Shapr3D, which supports Windows on ARM and ran flawlessly.
I also tested exactly zero games running natively on it (and would not use a laptop for gaming, anyway, unless I was streaming to it).
Rather than bore you with random performance figures, I will just say that I never felt it slow down in any relevant way.
And that is considering the massive use I make of an eclectic mix of Office web and native apps with dozens of simultaneously open documents in either flavour–I don’t keep around hundreds of background Edge tabs, but I do have pinned tabs with key documents for each project and use them, which is arguably more demanding.
Since most of my work is actually server-side AI, I barely noticed (or used) any of the AI features that ship with the machine; one I did use was simply swiping in from the edge of the screen and lassoing text to summarise, which was quick and easy enough to draft Teams messages from project documents. I didn’t dig into the mechanics, but it seems to be using a local model to do the summarisation (and OCR).
This class of Snapdragon NPU isn’t particularly useful for LLM work, but the camera effects got more use. Windows Studio Effects does automatic framing (which I found very useful), eye contact correction and portrait lighting (which I honestly didn’t find useful), with no noticeable performance overhead. Again, as a Teams machine, this is pretty much perfect.
The blurbs I’ve seen about the 50Wh battery say it’s nominally rated for up to 23 hours of local video playback or 16 hours of active web use, which feels about right.
Those tests typically use fixed workloads, so neither figure is really representative of how long it lasts with Teams running, but I can tell you that on a quiet week, I was able to use it for around three days with continuous stints of around 4 hours (I need to keep moving around on account of my back and posture, so I roam about the house a bit).
There were a couple of low points (typically associated with meeting-dense days), but I was assured a full day’s worth of battery life on occasional office trips. I didn’t measure charge times, but a 65W charger had it ready to use again over lunch (a Portuguese lunch, mind you).
I love this thing’s size (it is smaller and lighter than my MacBook Pro), simplicity and utter lack of fussiness in design language (even the feet are… cutely minimal), and the only thing I’d change about it would be making it easier to open (there’s no bevel under the trackpad, just a very slightly protruding, sharpish front edge).
Surface Laptop front edge and underside rubber foot.
Windows on ARM might still be a drawback for some people, though.
We actually skipped buying one of these a couple of weeks ago (and went for a Lenovo with a brand new low-power Intel Arrow Lake/Ultra 7 chip) because one of my kids needs to run SolidWorks for college.
But it was a close call, and there were other factors (like an OLED screen and being able to run Linux, not to mention being able to swap storage later).
But if, like me, most of your work revolves around Office and happens on remote machines, this is a very sweet laptop, and I am actually trying to replace my main work machine with one of these…
As my AI policy points out, I do revise my posts with AI, but until now, I’ve resorted to post-draft LLM passes that take a bunch of SKILL.md files and either fix outright typos and misspellings or add editorial blockquotes to my drafts. The entire process feels needlessly technical in the sense that doing it inside vim or VS Code (typically as I bring stuff together for a final draft) detracts–or, rather, distracts me–from the writing experience too much, and sometimes automated replacements slip through.
I’ve been trying to do the techie thing and “shift left” all the stuff involved with revisions so that the final pass is mostly about auto-linking, diagrams, captions and the like. But I am fundamentally tired of trying to use Obsidian as an editor, Dinkus (my current favourite on my laptop) doesn’t have an official iPad port, and iA Writer plain doesn’t work the way it should regarding accessing external folders on an iPad either, so I’ve actually been creating yet another Markdown editor based on swift-markdown-engine.
The problem with that is that I still need to bite the bullet and go against my own ethical principles–which, in this case, means facing the unlikely proposition of finding myself paying for an Apple developer account to be able to run my own code on my own hardware without it expiring after a week.
But this week I stumbled upon this very interesting post about using LLMs for writing.
The AI angle is that the model just points out problems; it does not do wholesale replacements or even allow for an “apply all” button, and forces you to go back and revise things yourself.
That now has me looking at building a web app I can use from my iPad to do focused reviews, with comments attached to passages (possibly with mark or aside tags) and blind comparisons between revisions, and that I can run against a folder in my vault and keep in sync.
Since I already have my own checklists for things like reviews, terminology, etc., the idea seemed interesting enough for me to take a stab at it:
An early look at the writing workshop.
This is being built atop the pi SDK and using ProseMirror (which I’ve avoided using so far), but I’m taking some care to ensure I can port the entire thing to my nascent native Swift editor.
I haven’t actually used it for anything of substance, but I quite like the idea of having one thing to do consistent revisions.
And yes, I know Word has Copilot.
It’s not a guided experience for writers, and, most importantly, it’s not my guided experience and workflow.
This is kind of huge, considering that I’ve always wanted an actual M8 (and built a headless one into a TrackerKB with its own keypad), but the hardware is extremely expensive. Having an iPad version that works as intuitively as you’d expect with an iPad keyboard is a very welcome surprise, and I’ll be trying out Bluetooth gamepads as well ASAP.
It feels good to have something like this pop out of nowhere and grant you some respite from depressing industry hype and even more depressing work stuff… Especially since it sounds amazing on the iPad Pro speakers.
Given how much time I’ve been spending on small native apps and my swift-app-template, Swift Build becoming the default in SwiftPM is probably the bit of this release I will adopt soonest. Having the same build system on macOS, Linux and Windows is welcome, as is Subprocess finally reaching 1.0–I still have plenty of uses for Swift outside SwiftUI. Being able to await inside defer and shield cleanup from task cancellation also sounds useful for the sort of audio and background work I’ve been doing in swift-smart-prompter, but to be honest that’s the kind of thing that I would prefer to do in other languages without weird idioms.
The WebAssembly and Embedded Swift improvements are tempting, though. The WASM SDK is now available directly from Swift.org, JavaScriptKit’s safe bridging is apparently up to 40 times faster than the older dynamic approach, and microcontrollers get more flexible types and error handling. None of this fixes my complaints about SwiftUI, but I would quite like to use more Swift without having to drag Apple’s frameworks along with it…
However, Apple continues to perpetrate unspeakable design crimes upon the Preview app icon, and the much-heralded Spotlight “priming” that was supposed to happen in the last iOS 26 update apparently did nothing, because my iPhone is still indexing.
And, yes, liquid glass is still there. I don’t care about how many sliders they put in, every time I see that I am reminded that if they needed to add it, they blew it.
The only notable thing so far is that our long international horror of multiple inconsistent rounded corners in macOS seems to be over, although I suspect there will be some rough edges (ha!) someplace.
Plus, of course, living in the EU, I have almost exactly zero new AI features on my devices. I suspect the Siri AI waiting list will never let me in and is there just for show.
I would have loved to finally have decent voices in Siri, though, as well as proper Continental Portuguese language support throughout–and why is there still no Scottish-accented Siri? That would have been a hoot.
Following up on my testing of the LattePanda Mu and IOTA, this time I’m looking at the Sigma, which (as is becoming the norm with my recent pieces) I actually got before summer break.
I wanted to have a look at it because it is something else again in the LattePanda universe: consider a laptop-class Intel motherboard with the case, keyboard, and display removed, but with more accessible I/O than most mini-PCs, and you’re close enough:
LattePanda Sigma retail box.
And it doesn’t stop at I/O: the Sigma I’ve been testing has a Core i5-1340P and 32 GB of soldered LPDDR5 (which is probably worth its price in gold right now), making it probably the most powerful “single board computer” I’ve ever used.
Disclaimer:DFRobot was, again, kind enough to send me a Sigma free of charge, and as usual, this article follows my review policy.
Even though I generally prefer ARM and AMD for that, there is a lot of Intel hardware in industrial manufacturing, and I see i5 factory floor machines starting to crop up as replacements for older generations already.
But besides summer break, one of the reasons this post is a tad long is that I took a, well… long look at how to use the Xe iGPU for inference, because I realized llama.cpp has an absurdly large range of techniques baked into it that are a cut above what I have on go-pherence–and why not learn from that?
At 146x102mm, the Sigma is quite a bit larger than the IOTA and the Mu Lite Carrier and feels much more like an industrial motherboard than a hobbyist SBC.
The board is built around Intel’s Core i5-1340P, which was originally meant as a mobile CPU (hence its 28W rating), but LattePanda designed the cooler for a sustained 44W configuration, and that is definitely the first thing you’ll notice when you pick it up:
The single-piece aluminium base of the Sigma.
I must say that having the whole thing bolted to an aluminium slab actually made it quite nice to test, since I didn’t have to worry about getting loose screws or other parts under it.
Removing the aluminium base reveals the mainboard and its components quite clearly, in a very neat layout:
Underside of the Sigma board with M.2 slots, RTC battery and expansion headers.
And yet, there is a lot going on here that is not immediately obvious from the outside or underside:
Core i5-1340P, with 4 P-cores, 8 E-cores, 16 threads and 12 MB cache
32 GB LPDDR5-6400, shared with the Iris Xe GPU–one of the things I really like about this board.
two M.2 M-key slots, one PCIe 4.0 x4 and one PCIe 3.0 x4
two 2.5GbE ports (based on Intel I226-V)
two Thunderbolt 4 ports, as well as HDMI 2.1 and eDP 1.4b
an M.2 E-key for Wi-Fi/Bluetooth and an additional B-key slot with SATA, PCIe, USB and SIM connectivity (you get some nice thermal pads in the box, too)
SATA, internal USB, front-panel, audio and serial headers
A barrel jack for 19V power input (the supplied PSU is rated for 90W, which is plenty of headroom, as we’ll see)
and, finally, an onboard ATmega32U4-compatible LattePanda Leonardo for GPIO, PWM, analogue input, UART, I2C and SPI (which I didn’t test beyond the hello world check below)
This is also a slightly beefier i5 than I’ve seen before–as an example, compared with the i5-1235U in the TerraMaster F4-424 Max, the i5-1340P adds 2 extra P-cores and 4 threads, keeping the 80 execution units in the Xe graphics unit.
For my tests, I dug out a 1 TB WD Blue drive and an Intel AX210 Wi-Fi 6E/Bluetooth module.
The latter worked so well that I ended up freeing the Ethernet ports and just letting the Sigma work wirelessly (at a link rate of 1.2Gbps), but that is why you can see the Bluetooth device in what otherwise is a pretty sparse USB inventory:
# lsusbBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 3343:803a Unknown LattePanda Leonardo
Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
This mix of standard Intel devices and a small onboard microcontroller is still one of LattePanda’s better ideas, and makes it appealing for industrial devices: the host can run an ordinary operating system while the microcontroller handles timing-sensitive tasks and GPIO independently.
As to the PCI bus, I would call it… unashamedly Intel?
I didn’t use the SATA interface for testing, and the WD Blue SN580 I used through the PCIe 4.0 M-key slot behaved as expected, but for the sake of thoroughness, I still wanted to document its performance here using fio benchmarks:
Workload
Result
p99 completion latency
Sequential write, 1MiB, QD32
4.11GB/s
10.68ms
Sequential read, 1MiB, QD1
2.63GB/s
0.57ms
Sequential read, 1MiB, QD32
3.95GB/s
10.03ms
Random read, 4KiB, QD1
10.65k IOPS
0.15ms
Random read, 4KiB, QD32
248.95k IOPS
0.33ms
Random 70/30 read/write, 4KiB, QD32
173.84k/74.55k IOPS
0.62/0.16ms
Nothing unexpected here. I didn’t do a test across more than one slot (NVMes are too precious to wear down on purpose these days), so these figures are for the PCIe 4.0 slot only.
Both I226-V interfaces use igc and advertise 10/100/1000/2500Mbit/s modes, and I had zero issues saturating the links during my tests. By now, 2.5GbE is just rock solid for most local network tasks, the Intel implementation is reliable, and I wouldn’t hesitate to rely on it for demanding workloads. The only reason I switched to my own Wi-Fi 6E card was because it was a bit more convenient and I could get possible fan noise further away from my desk while I tested thermals.
And speaking of that, as you may have seen from the box shot, the board is dominated by its large heatsink and cooling assembly, which covers the CPU and other critical components:
LattePanda Sigma board with large heatsink and cooling assembly.
The only criticism I have of the design is that the slight slope on the heatsink (seen above on the left side of the photo) might make it a bit tricky to design a case that fits snugly (or connects the exhaust to the outside, like I did for the Mu) and has the potential to turn into a dust trap over time, but otherwise the cooling solution appears very effective indeed.
Neither sensors nor /sys/class/thermal worked as I expected at first, but turbostat could read the processor MSRs and supplied package/core temperatures, effective frequency, package power and hardware throttle counters. But after yelling at rpm-ostree for a bit, I got some very usable temperature data anyway:
This was something I wanted to check because the fan was not inaudible (worst case was a persistent whooshing noise, with zero whine), but quiet enough at times for me to wonder if it was on. There’s no stall sensor, apparently, so you can’t directly detect if the fan is stuck or not spinning, but you can still monitor its RPM–and the reason I care about it is that fan monitoring is useful in industrial environments to detect fan failures.
Sustained Load
While doing benchmarks I left intel_pstate, the powersave governor and firmware power limits unchanged, and collected turbostat samples every two seconds through a set of CPU, memory, storage and media runs. And since I did everything in sequence with minimal (but realistic) cooldown periods between runs, the resulting data was so nice that I decided to keep it all in one chart:
turbostat readings every two seconds throughout the benchmark run. Power figures cover the CPU package only.
Low-power operation is amazingly good–the system idles at 39.5C and 2.0W package power, jumping up to 54C and 19.1W (and back down) as needed. During sustained 7-Zip, package temperature averaged 81.3C and peaked at 89C, with power averaging 33.5W and peaking at 39.2W.
At the wall, I measured roughly 44.0W max consumption (including the rest of the system, of course, which the CPU telemetry doesn’t account for).
But (and another reason why I find newer Intel silicon so impressive, and am hoping to look at the Ultra series next), I was actually surprised there was no real throttling. On an i5, which typically would start throttling under sustained load at high temperatures.
Yes, there was a plateau (3.72GHz, give or take), but neither the core nor package hardware throttle counter changed during the entire sweep, and no kernel thermal warnings appeared.
Since the Sigma fits a rather broad range of applications between a personal workstation and a beefy low-power server, I started with the workstation part (by installing Fedora, where I did most of my testing) and, later on, popped in a second SSD with Proxmox to try it out both as a Debian box and as a server.
As you’d expect, both Fedora and Proxmox were completely uneventful to set up, but each is worth a few notes.
Back in June, I landed on Fedora Silverblue 44 with kernel 7.1.5, which had full support for everything: the Iris Xe uses i915, both I226-V Ethernet controllers use igc, and the CPU runs under intel_pstate. But, more importantly, I got a completely stable Vulkan stack for my compute experiments.
There were no vendor kernels, board-specific image builders or mystery boot partitions involved, so the contrast with the ARM boards I keep testing is almost comical.
And yes, Thunderbolt worked fine too, as did the Leonardo when I did a little hello world test–but I did not test them thoroughly yet.
This was by far the easiest installation, because, well, I cheated.
I had previously installed Proxmox on the IOTA for testing before using its internal eMMC instead, so I just popped that SSD into the Sigma (with a 3D-printed jig to hold the half-length board in place) and, as you’d expect, everything worked perfectly.
With 32GB RAM, two extra P-cores and dual 2.5GbE, this is a really good home server, especially considering the power envelope, so it was a no-brainer to temporarily migrate over a few of the things I am running on the Terraserver:
My Gitea instance and two of the CI/CD workers (the other two run on borg, on-demand)
The main piclaw development instance, which is constantly rebuilding itself
The test Jellyfin LXC I have been using to develop jellyfin-livetube, which, despite not having local access to the ZFS video storage, performed just as well over Wi-Fi 6 (it is, after all, using a nearly identical Intel Xe chipset, and the network overhead is minimal).
The test instance for wrdp, which also had zero issues serving Wayland desktops using H.264 acceleration.
This deserves a little more digging into, since VA-API can be fiddly to set up, and getting it to work correctly with Fedora’s media packages when I booted back into it required some tweaks.
In the initial test installation, Fedora’s default ffmpeg-free build disabled the native H.264 and HEVC decoders, so hardware acceleration was effectively unavailable–no H.264, HEVC or even AV1 in sight.
Debian (in the Jellyfin LXC container inside Proxmox) “just worked”, which was annoying, so I went back to the all-Fedora setup and got H.264 acceleration working using rpm-fusion.
All around, transcoding 4K content was smooth and didn’t tax the CPU significantly (depending on the particular codec combo, of course, since audio tends to be piped through the CPU). Multiple streams weren’t an issue, either.
In fact, I am currently using the Sigma as my reference machine to develop my wrdp and go-264 projects since it is already proving to be a very capable platform for media acceleration and transcoding tasks.
One of the quirks of the Sigma is that the i5-1340P has four performance cores with Hyper-Threading and eight efficiency cores without it–that’s 12 physical cores, not 16 equivalent ones. The E-cores are useful, but doubling the thread count doesn’t mean doubling the available compute: first you’re adding SMT threads to the same P-cores, then you’re bringing in a different class of core altogether.
7-Zip makes good use of the extra threads, but the “linear” scaling you’d hope for isn’t quite there.
One P-core thread, four physical P-cores, four P-cores with SMT, and all P- and E-core threads, respectively.
Placement
Threads
Compression
Decompression
Total rating
One P-core thread
1
5,232 MIPS
4,334 MIPS
4,783 MIPS
Four physical P-cores
4
31,643 MIPS
17,219 MIPS
24,431 MIPS
Four P-cores with SMT
8
41,456 MIPS
24,791 MIPS
33,124 MIPS
All P- and E-core threads
16
62,266 MIPS
43,702 MIPS
52,984 MIPS
Going from four P-core threads to eight with SMT raises the total rating by only 36%, not 100%.
Adding the eight E-cores brings another 60%, so even though all 16 threads deliver the best result, they only manage about 2.2 times the throughput of four physical P-cores, despite having four times the thread count.
That’s useful extra performance, but it isn’t proportional scaling–and neither SMT threads nor E-cores truly replace physical P-cores. But for background workloads like what you’d have on a server or during heavy multitasking, the extra threads can still be beneficial.
As to RAM speed, the Sigma’s LPDDR5-6400 does not disappoint.
I pulled out a little memory bandwidth testing to see how the Sigma handles sustained data transfers–not just the peak theoretical numbers, but what it can actually deliver under load. After futzing around a bit, I hit upon a simple STREAM-style benchmark that uses three 256MiB arrays: Copy transfers data from one array to another, while Triad multiplies values from one array by a constant, adds values from a second, and writes the results to a third. The GB/s figures count the data read and written per second, showing the sustained memory bandwidth the CPU can actually achieve:
Three 256MiB arrays, using one P-core thread, four physical P-cores, four P-cores with SMT, and all P- and E-core threads.
Placement
Copy
Triad
One P-core thread
22.31GB/s
25.64GB/s
Four physical P-cores
55.11GB/s
51.93GB/s
Four P-cores with SMT
55.81GB/s
52.88GB/s
All P- and E-core threads
52.74GB/s
57.70GB/s
Four P-cores already saturate the best copy result, so adding more threads doesn’t help much there. The E-cores add around 9% to the best Triad result (probably because they will lean heavily on cache), and it plateaus after that–but it’s nothing to sneeze at.
The upside is that, in practice, the CPU and Iris Xe share this 52-58GB/s pool–there is no separate GPU memory bottleneck, or a need to bucket data across a slow bus.
This is, as usual, where I went totally overboard.
Update: I have tidied up all the tests I did (many of which did not make it into this review, since they were exploratory) into this set of documentation in my private llama.cpp fork, so if you want to reproduce any of this or look into the post-review iGPU work, this is where you will find it.
Based on older experiments on the TerraMaster, I was expecting quite low performance (around 3 tokens/s by default), but I have been tweaking my own fork of llama.cpp, so I had piclaw rebuild it with Clang 22, -march=native, AVX2 and AVX-VNNI support to take advantage of the new CPU features.
Then I downloaded the cool models du jour (Gemma 4, Qwen 3.6 and Ornith–a biased Qwen derivative) and set up a little agentic test suite: Each candidate got the same repository-search agent task (sized to fit under 4K tokens), which prompted the model to do at least one tool call (which when successful was under 200 tokens):
Repository-search task results for models with both prefill and generation measurements.
This is effectively one-shotting a 4K context, and, overall, I can’t complain about the Sigma for this kind of workload:
Model
Selected CPU profile
Prefill
Generation
Gemma 4 E4B
MTP-3, F16 KV, Flash off
61.19 tokens/s
25.30 tokens/s
Ornith 1.0 35B
MTP-2, F16 KV, Flash off
37.53 tokens/s
16.65 tokens/s
Qwen3.6 35B-A3B Q2_K_XL
MTP-3, Q4_0 KV, Flash on
28.36 tokens/s
15.34 tokens/s
Gemma 4 E4B was the obvious winner (as it tends to be in low-resource scenarios), and its performance advantage was clear both in prefill and generation throughput–but, most importantly, it can do tool calls right, which is not something every model can do (even though the other two did fine, Gemma is a bit more predictable at that at the expense of actual coding skills).
Ornith ingested prompts faster than Qwen and was slightly faster for short generation, while Qwen caught up somewhat in longer generation scenarios, but they’re fairly evenly matched.
Then I began trying multi-token prediction (MTP) to see if it could improve throughput without sacrificing accuracy. If you’re new to this, MTP uses a draft head (i.e., a smaller “model”) to propose several tokens and lets the target model verify them together. It is not a generic “turbo” switch–the useful depth depends on the model, and more drafting can make things slower, but it can significantly boost throughput when used appropriately.
After a couple of hours of trial and error (and with longer prompts), I arrived at the following results:
Model
Target only
Best isolated MTP result
Selected depth
Gemma 4 E4B
12.69 tokens/s
22.01 tokens/s
3
Ornith 1.0 35B
12.80 tokens/s
15.41 tokens/s
2
Qwen3.6 35B-A3B Q2
11.04 tokens/s
14.54 tokens/s
3
Then I started poking at other parameters–including stuff that affects memory usage and computational efficiency, and that doesn’t make sense in CPU-only scenarios. Also, I quickly realized that on this i5, the best way to maximize throughput was to carefully balance the load across the P-core SMT pairs (yes, you can do CPU pinning) without overwhelming the CPU–given what I got from the memory bandwidth tests, that was unsurprising.
But from a user perspective this is still essentially one-shotting prompts, which is cute but not very realistic for agents that need to maintain a large working context over time, so I froze a prompt at about 124K tokens and ran it through Gemma and Ornith in one 131,072-token slot:
Gemma and Ornith used comparable prompts of around 124K tokens. Qwen topped out at 99,104, so its timings are for a shorter prompt.
This was a lot more interesting, and a trifle hotter than the earlier one-shot tests (fortunately, again, the CPU did not actually throttle):
Model
Prompt tokens
Prefill
Generation
Peak PSS
Peak temperature
Gemma 4 E4B
124,112
22.49 tokens/s
4.49 tokens/s
10.9GiB
90C
Ornith 1.0 35B
124,341
13.14 tokens/s
2.63 tokens/s
23.3GiB
91C
Qwen3.6 35B-A3B Q2
99,104
4.58 tokens/s
2.10 tokens/s
13.4GiB
90C
The thing is, even though Gemma and Ornith handled the large context without crashing, the generation speed dropped significantly as the context grew. Gemma took up less RAM (and sweeping through weights in RAM more efficiently is, ultimately, why it was able to maintain higher throughput), but for coding tasks that require frequent context updates, this is not really a usable speed–consider it the extreme end of what one might tolerate interactively, and yet perfectly good for batch processing or long-form generation where latency is less critical.
This did not go as expected. I’m used to seeing some improvement with GPU offload, especially for prompt ingestion, but the Iris Xe behaved differently, and I’ve yet to pin down exactly why (but I have some theories).
First of all, there are two main ways to do compute on the Iris Xe: using Vulkan for explicit GPU offload, or using SYCL for a more integrated approach with the CPU. And… they are both quirky, and (initially) worse than the CPU:
Each pair compares CPU and GPU results from the same test. The panels use different tests and scales.
So I just filed that away for future investigation and tried to squeeze more performance out of the CPU path instead.
When I came back to this in September, I decided to use a trick that works well with discrete GPUs: let Vulkan handle prefill, then stop the GPU worker and hand the cached state over to the CPU for generation with MTP. This was a particularly fun trick to pull on the Sigma, because:
Vulkan handles the heavy lifting for the initial prefill, which is usually the most computationally expensive part.
I can just copy across stuff to the CPU in this architecture, without a transfer across PCIe from discrete GPU memory.
The cached state goes across as a checkpointed snapshot (not zero-copy, sadly, because, well, Vulkan and conversions, etc., so the handoff still takes time).
Follow-up tool turns with a warm cache stay on the CPU, so they don’t pay for another handoff.
Getting that working with Gemma required fixing two fairly fundamental things in my llama.cpp fork, though: There was a stupid bug (probably mine) that clipped things to 16K entries, and (this was the bit where Astra was useful) I had to make Gemma’s compact sliding-window attention cache transferable, preserving its valid padding and checking the text/token state format so the CPU could resume without processing the whole prompt again.
Watching it re-use N-1 cached tokens in an N-token test was quite satisfying–no need to chew through the whole prompt again. But compared with keeping everything on the CPU, the gain was more noticeable in the complete workflow, not follow-up turns:
Eight counterbalanced runs in September: 28.8% less time overall and 3.4% more time on warm follow-up rounds, which are included in the total. Lower is better.
And yes, this is not quite a general-purpose speedup: the complete coding workflow took 28.8% less time, but the warm follow-up rounds were 3.4% slower. It helps when there’s a fresh prompt to ingest; once an agent is working from a warm cache, there isn’t an extra turn-by-turn gain here.
I am looking into this further to see if there are ways to generalize the approach or improve the handoff between Vulkan and the CPU, but this is the kind of rabbit hole I can’t really get into these days, so I pivoted to another thing: speech recognition.
Why speech? Well, because that Vulkan/CPU hybrid approach for Gemma got me thinking: Whisper has a much smaller model size and lower computational requirements compared to Gemma, and it might benefit from a similar prefill-and-handoff strategy, potentially allowing for faster speech recognition on the CPU after an initial Vulkan prefill. At least that was the theory.
So far, I don’t have pretty charts because the conversion from Vulkan-prefill to CPU generation is still a pain to do on the fly (even segmenting the audio, etc.), but I got Whisper v3 Large working with that approach at eight times real-time speed on the Sigma already without really optimizing anything and just doing the bulk Vulkan to CPU data conversion repeatedly.
I am now porting that into go-pherence, so I’ll likely update this post once I have repeatable benchmarks.
But the short version is that I can run bothWhisper and Gemma simultaneously on the Sigma–which in turn means that this might well be a killer home automation server if you want fast speech recognition and simple, efficient language model processing all in one place.
Of course, not being a Home Assistant person (I rely on Siri and HomeKit, for better or for worse), I can’t really take the next logical steps here, but I do want a local, private speech transcription solution (I would like to clone the Index 01 to a degree), and the Sigma is working quite well for that purpose already.
I’ve since swapped back to the Fedora SSD full time, and have been using the Sigma as a development server for wrdp, go-264, go-pherence, etc. I am thinking of reinstalling Proxmox on the bigger drive and consolidating most of my development there–including migrating quite a few of my other projects from borg to it as well, since even though borg has ample storage and RAM, the Sigma is just quieter and more power-efficient.
The expandability, built-in 32GB of RAM and the i5-1340P’s core count would already make me choose the Sigma over most Intel mini-PCs I’d otherwise consider. But quiet operation and power efficiency are what make me want to keep using it as a development and home server.
For consolidating services into a custom server build or a small 10-inch rack, I’d also much rather start with this board than stack a bunch of mini-PCs. The two M.2 storage slots and SATA connectivity leave room to expand–if you need more SATA ports, you can use the second M.2 slot with an adapter, and Thunderbolt gives you another option for fast storage. I haven’t tested every expansion option (and, like many times before, I wish I had an eGPU setup to try).
Taking a DIY approach, I appreciate the readily accessible I/O and don’t particularly miss the enclosure (though a proper case would certainly make things tidier).
For now, it’s back on Fedora doing development work while I find the time to design a 3D-printed case that suits me–there are some available, but none is quite what I’d like…
Even though my personal calendar is now filled with a smattering of fresh events, I am quite happy about the ones that don’t involve health, legal and tax annoyances. My back and other ailments seem to be stabilizing thanks to daily exercise and my having dedicated some time to cooking my own meals, which, besides being cheaper (a concern I’ve been having of late), also forces me to stand and move about, not to mention giving me an excuse for handling very sharp knives in very satisfactory ways.
And I’ve lost weight–either from exercise or minor hardship, that is both undebatable and welcome.
My free Codex Open Source plan ended yesterday, which meant I was keeping a close eye on piclaw and a few other projects I wanted to make some significant progress on–as a last hurrah, over the last week I was getting Codex to implement the foundations for family features and budgeting, and to do the usual code audit and refactoring pass.
However, I am very happy to report that I nearly got more free credits, and the reason for the near-miss is pretty awesome: go-264, the SIMD/assembly-based H.264 decoding library that I started building many months ago to quickly extract video frames on low-end hardware without all of the overhead from ffmpeg, is now apparently being used at ChatGPT inside OpenAI.
They reached out, pushed some PRs with fixes and enhancements I had not gotten around to due to lack of suitable hardware, and… gave me an extension to my Codex plan, which expired yesterday.
Sadly, I got a “The promo code is invalid.” error when I finally clicked on the fresh Pro invite this morning, so I guess that’s that (I don’t think you can have multiple extensions back to back, and yes, I made sure I was back on the Free plan before clicking).
Well, that was that
But hey, it was a good run while it lasted, and it was a nice gesture on OpenAI’s part.
My alternative plans to scout OpenRouter and such for suitable open models that would be minimally good enough are now (again) on, and thankfully I did quite a bit of pricing research.
Last week’s plans for “stopping” using AI were unrealistic, but timely enough for me to reassess my usage and plan for alternative approaches.
So I am focusing on other stuff a bit more, especially since I do indeed want to lower my screen time altogether.
Update: Something got fixed and… oh well, I now have Codex Pro again. I guess I’ll have to, you know, AI my way through my hobbies again—but I am still trying to cut down on my screen time…
With that in mind, I have been fixing my Calibre MCP server and making sure I get in at least half an hour’s reading each night.
My propensity for skimming over The Economist every weekend has crowded out regular books a bit and I’ve started building up an arXiv queue again, plus, of course, watching Ted Lasso.
Can’t beat that for a wholesome feeling that nearly makes up for everything else going on.
Besides the showmanship demonstrated by the keynote opening (nice touches there, Tim) and the visual effect when you open it, the iPhone Duo is… strangely familiar, and yet, somehow just strange as well:
I am not a fan of the weird signal/battery status bar indicator or the vertical dock, although the ergonomics of moving toolbars there are undeniable–the bottom-right buttons are going to be very hard to reach single-handedly, though
I am a fan of having Touch ID back, as well as the under-display camera (which I suspect will eventually find its way downrange over the next few years)
I kept wanting to see the typing experience in “laptop” mode and Apple Pencil support (Apple says support for the USB-C Pencil is coming later this year)
Most of the UX we saw so far was both predictable and familiar to anyone who’s played with a Samsung Z Fold (Apple did not invent screen splits, app swaps or drag and drop), and so was the camera placement.
Oh, and the price, of course.
Definitely not a surprise even if shocking.
It won’t stop a lot of people, even if it is about as much as a couple of (sorry, three or four) iPad minis, but I am definitely not getting one–nor any other iPhone this year.
Nor AirPods either, given I have excellent open ear $50 earbuds.
But I am interested in the new Watch, both due to the improved heart rate tracking and battery life (the dark bronze look and redesign versus my Series 9 doesn’t hurt either).
I am, however, more than a bit put off by the Live Rewind and Recap features, simply because it doesn’t sit well with me to have anything listening constantly, even if with a short retention window (Apple says these are opt-in and raw audio is deleted after processing).
That said, as it happens I have been investigating how to duplicate the Index 01 smart ring’s (deliberate) press-and-hold recording and transcription for notes with my Watch, so I found the feature intellectually interesting.
But I find it incredibly frustrating that Apple consistently fails to get even the basics right.
For instance, currently my voice memos from the Watch are neither transcribed nor synced to my Mac (Apple says they should sync), and Apple’s unwillingness to do any sort of useful automation on the Watch has become a huge turn-off.
Update: I forgot to mention that, obviously, none of the AI features are going to be available in the EU. Which only makes the lack of flexibility and automation all the more annoying, because I can’t even script sending audio to my own endpoints to process.
Update 2: Apple has released a whitepaper on Audio Intelligence Privacy that outlines how it works and how audio is handled on-device with only condensed, generalized and encrypted transcripts making it to their private cloud compute (where it is actually summarized), and… Well, OK, fine, I guess. It does require opt-in.
Update 3: Yes, I am aware quite a few of the outdoor sequences for some of the new adverts were shot in Lisbon, thank you–I cannot claim any influence in their picking at least 2 spots within walking distance from my house, though…
Only yesterday I was discussing Mistral off-work and pondering what they might be up to, given both their EU lobbying – which fits rather neatly with the European AI pitch I wrote about in April – and the fact that they haven’t been doing a lot of actual model releases (in practice, nothing really new, or at the same pace as other labs).
I guess that they are positioning themselves squarely in the sovereignty arena, where a few other European companies have already started providing generic open-weight models for privacy- and US-sceptic customers that don’t want to be dependent on the whims of non-EU administrations. It’s a decent market to be in in Europe, but feels too regional, and I hope they get back to improving their own models, which are substantially lagging behind by any benchmark (if you care about benchmarks).
My LG TVs are too old/dumb to fall into this lot, fortunately, but what I want for my next TV is a huge, dumb monitor, and reports like this are why. Gamers Nexus and Level1Techs apparently found LG TVs recording audio with the screen off and storing it for later upload, besides snooping on other devices on the local network. I don’t know how much of this applies to European models (the article doesn’t establish that), but I would very much like someone to check rather than assume GDPR has taken care of it.
I’ve been complaining about TVs spying on their owners since 2012, and about the lack of EU scrutiny in 2024 and 2025, so this is getting a little tiresome. The European Commission keeps harping on Apple, and I suspect that has rather a lot to do with it being a much more recognisable brand–going after Apple has immediate political impact, whereas investigating what LG and the other TV manufacturers collect inside people’s homes seems to be nobody’s priority.
The desire to own an Apple Studio Display has probably been hanging over most Mac desktop users since time immemorial (well, since 1998 at least, but most people are more familiar with the “modern” 2022-era look) for two reasons:
As many people have remarked, the moat between ideas and technical execution is narrower than ever, and that has a number of consequences–both when it comes to investment (in this case, personal, although I am collecting war stories…) and focus.
And I think I need to be more selective about what gets my evenings, since I am back at work and already spending too much of my free time building things on a computer.
I have a long and somewhat embarrassing history with LISP that goes back to the years when it was fading from academia and LISP machines were giving way to Macs and DECstations (a transition that should be familiar to anyone who read the UNIX-HATERS Handbook), so I got properly hooked on Clojure when it came out.
This is indeed the end of an era. As I wrote when the transition was announced, Cook built Apple into what is probably the most formidable product manufacturing and logistics organisation on the planet (I remember when Nokia was considered the same, albeit only for mobile phones), and Patrick McGee’s Apple in China makes the sheer scale–and strategic cost–of that achievement painfully clear.
But Cook was never a product person, in my view, and that showed in the decline of overall software quality over the years. Contrast that with the tremendous growth in services and the sheer volume of the App Store–run by Phil Schiller, who is also changing roles today–and the lasting impression is one of relentless efficiency, perhaps a tad lacking in soul.
Everyone has high hopes for Ternus as his successor, particularly around QA and actual product focus. Cook will stick around as executive chairman to deal with politics (his understated main focus these days), but I am going to reserve judgement for a year or so…
Aug 30th 2026 · 3 min read
·
#eink #productivity #readers #supernote #xteink
I’m now back to work and already embroiled in far too much, so I’m going through my infinite set of mental checklists and trying to relax by offloading some of the stuff I never got around to writing down.
While I was on vacation, one of the things I did was tune out (as much as possible), which meant relying more on my e-ink devices.
I came back to work this week, started catching up on everything, and decided to go out for groceries without an umbrella (it is still August, right?) and got drenched.
This is extremely impressive, not just from a design and kinematics perspective, but because the entire 50Hz control loop runs locally on an RK3566 (not the RK3588 I first assumed), with the ONNX movement policies running on the robot itself.
The repository includes the MuJoCo/PPO training code and Rust runtime, so every shipped behaviour can be retrained–which is quite something for a 25cm, 800g biped with fifteen motors that can walk, skate, grab things and get back up by itself.
It is a completely superfluous thing to spend north of $500 on, and I have no idea what I would do with one or where I would find the time, but it presses all the “shut up and take my money” buttons–and if NVIDIA’s acquisition of Hugging Face goes through, I suppose we may have to call it the Jetson Donald or something…
Aug 28th 2026 · 1 min read
·
#ai #hardware #ram #semiconductors #tariffs #trump
Trump’s timing is impeccable, as usual: after the AI boom helped turn RAMageddon into a sustained memory price surge, he has apparently decided that what data centres, PC builders and everyone buying electronics need next is a tax on the chips themselves.
And this lands just as the AI industry’s “teaser period” is supposed to end–when vast take-or-pay compute commitments become actual bills and utilisation starts to matter. Nothing says “winning the AI race” quite like making the entire stack more expensive just before the economics get real…
Aug 27th 2026 · 1 min read
·
#acquisitions #ai #hugging face #nvidia #open source
Well, this is unexpected. There were rumours while I was away–and Hugging Face reportedly turned down a $500 million NVIDIA investment earlier this year–but buying the entire thing for $12.9 billion doesn’t fit my mental model of NVIDIA, given its… spotty Open Source report card. They certainly have the money, given their current valuation and a quarterly revenue run rate closing in on $100 billion.
This feels like the same sort of stack consolidation that happened as public cloud took off and GitHub was acquired: owning the place where models live is a lot more ecosystem presence than pushing Nemotron models out in a corner and hoping people notice. I guess it makes sense. I am just not sure Hugging Face under NVIDIA is quite the same proposition…
Aug 25th 2026 · 1 min read
·
#ai #apple #apple silicon #mac #mac mini
The big difference Apple isn’t really drawing attention to is memory bandwidth. The M6 tops out at 170GB/s and 32GB of unified memory, whereas the M5 Pro offers 307GB/s and up to 64GB–nearly twice the bandwidth, as well as twice the memory ceiling. That is the number to watch for AI inference, not just CPU and GPU benchmark deltas.
The less amusing part is pricing: a halfway decent M6 configuration with 32GB RAM and 1TB storage lands at roughly €2,000, and an M5 Pro with 64GB RAM and 2TB storage costs about another €2,000 on top. And the Mac Studio can be yours for… a kidney, or two.
Aug 25th 2026 · 1 min read
·
#ai #legal #llm #open weights #privacy
The bit I like most about Thomson Reuters’ new model is that it starts from open weights–specifically Qwen3.6-35B-A3B, via Snowdon–and then uses continual training on Thomson Reuters’ own legal, tax and news material. There is likely an opportunity here for AI labs to provide tailored industry models with much better provenance, rather than aiming for AGI.
I am curious about how hyperscalers will tackle this–fine-tuning and training have always been available in Azure, for instance–but what I would really like to see is a definite move towards entirely local, entirely private models for regulated industries. That would also imply some decentralisation, and might give Europe a chance in this madness.
Aug 23rd 2026 · 4 min read
·
#3d printing #ai #home automation #notes #weekly
Tomorrow I’m going back to work after a rather lopsided summer break (not feeling up to it physically or mentally), and the social network pendulum is swinging back into a bit of normalcy as I progressively tune nearly all of them out.
By the same developer as Ishmael (and all the goodness around the best Python TUI libraries in existence), Dinkus is an equally polished Markdown editor that was an instant buy for me. Full disclosure: I got a code for Ishmael when it was released, but paid for this one, which is rare enough to give you pause.
So far the experience is great, although I miss some of the niceties Obsidian has, like Quick Actions and typeahead find for quickly switching to other files. Still, it is nice to have something else that is snappy, polished and doesn’t look like a code editor.
For me, the only notable omission is that reference links (and footnotes) at the bottom of the document seem to be completely ignored, even if the source view knows what they are.
This is a short follow-up to my Apple Papercuts piece, wherein I bunched together a few more annoyances that I’ve come across while using my iPad Pro extensively on vacation.
This is totally up my alley, given both my recent reflection on infinite software and the fact that I recently started doing small Swift apps again. With agents taking care of much of the incidental work, small native utilities stop looking extravagant and become the obvious alternative to yet another TUI.
Just imagine if we could run our own iOS apps for more than a week without Apple’s restrictions…
Aug 21st 2026 · 15 min read
·
#agents #ai #architecture #arm64 #bun #pi #piclaw #typescript
I’ve spent the better part of six months building piclaw–my personal AI assistant, workspace and, occasionally, agent swarm–on top of Mario Zechner’s pi engine, and I think it’s time to write about not just my motivation but also how I feel about having invested that much time into the whole thing.
Bun has always been divisive because of its approach, and its acquisition by Anthropic and subsequent AI-driven port to Rust haven’t helped (especially given the way some people these days react to both the company and the “process” that led to it).
But amidst the insanity the JavaScript ecosystem has always been, its batteries-included approach (which also has its detractors) and overall performance–RAM use aside–have been pretty amazing and very, very useful to me recently. Yes, it’s starting to show signs of bloat and perhaps even “overfitting” to AI development and automation (case in point: it now includes direct support for webviews and thus “agentic browsing”), but I’m going to keep using it until something saner comes along.
Aug 20th 2026 · 2 min read
·
#ai #llm #saas #software #web
I am most definitely not the first person to mention this, but the past year has seen a Cambrian explosion of two things: AI deniers who base their judgement on very limited exposure (or effort to use it) and thousands of variations on software of all kinds, from the perennial to-do list to AI-infused toothpicks.
This changes effectively nothing I care about and continues to be completely laughable. Apple has rearranged payment options, commissions and eligibility rules for alternative distribution, but there are no changes whatsoever to the Apple Developer Program or to the utter inability to develop and run my own software on my own devices without paying Apple for the privilege of having it not expire after a week.
Rui Carmo
