Ryan Whitwam’s piece on switching to eSIM is a good reminder that a lot of “modernization” is really just moving failure modes around, and seems like a great way to kick off 2026 since it mirrors my own past experiences: my Truphone/iPad “side quest”, and my broader worries about eSIM-only iPhones.
A physical SIM is dumb and boring, but that’s exactly why it works: when you need to swap devices, it’s a 30‑second hardware shuffle that doesn’t depend on carrier apps, backend state, or a support queue.
With eSIM, the swap becomes a workflow—and if it fails at the wrong time you can end up locked out of your own number (and everything that still treats SMS as a magic identity token), with the delightful resolution of “go to a store and wait”.
If eSIM-only phones are the future, carriers really need an account recovery story that does not default to “we’ll text the number you currently can’t receive texts on”…
Dec 31st 2025 · 13 min read
·
#emulation
#hacking
#homelab
#music
#node-red
#notes
#observability
#photography
#projects
OK, this was an intense few days, for sure. I ended up going down around a dozen different rabbit holes and staying up until 3AM doing all sorts of debatably fun things, but here’s the most notable successes and failures.
Incidentally, this post is a great example of why I think AI is a force multiplier when you have the ability and skills to guide it–without GitHub Copilot, I wouldn’t have even begun to scratch any of the more complex things I put together this week.
And scratching I did, very much so. I went through many of my long-term itches and annoyances regarding a bunch of semi-random things I care about, and tackled the most I could fit into the week for sheer fun.
To begin with, I decided to modernize and (re)automate one of my usual year-end chores once and for all: Curating and filing the year’s photos off my iPhone and saving a snapshot to my NAS.
This has become a volume enterprise now that we have the new iCloud Shared Photo library, to which I and my wife and kids save photos we want to keep/share.
Even without Apple (finally) blessing us with that feature, exporting all of my photos off iCloud and saving them to my NAS with a coherent, reproducible naming convention and include all the original formats has been a recurring issue for many years. It goes all the way back to one of the very first HOWTOs on this site, and I keep revisiting it.
Of course I built a set of scripts to help over the years, but guess what, macOS Tahoe and Apple’s utter neglect of automation have made those untenable (there isn’t even a decent Shortcuts action to export photos).
So this year I did it again, but using Swift (in the perhaps naïve belief that Apple won’t break it) and the result was PhotosExport–a typically “me” tool in the sense that it does the absolutely bare minimum I need in the simplest possible way with the least amount of dependencies and frills.
It’s not even a proper Mac app, just a highly opinionated CLI tool that you can build and run yourself without any significant tooling except for the Xcode CLI tools.
And since I was a bit annoyed at Apple’s cloud features (including the fact that I can’t get at any of the interesting extra metadata and tagging), I decided to adorn the README with a suitable picture:
Record scratch: You may be wondering if this is self-referential
I didn’t think anyone else would be interested in it, but somehow it took off and got 160+ GitHub stars and 5 forks in a couple of days, as well as quite a bit of direct feedback–including from people who see it as a way to migrate off iCloud/Apple altogether.
In parallel, I proceeded to bite off more than I could chew in various other fronts.
For instance (and this is one of the failures), I had a go at building on my drawterm port and trying to get Acme-SAC to work, but I would have to port Inferno and dis to 64-bit and that was a bit too much–but I did take a stab at it.
Somehow, that led me to something that consumed me way into the wee hours last night–trying to improve Basilisk II performance on low-end ARM hardware.
I could have spent these quiet days installing the new LCD display I got for the Maclock or finishing the design for a new case for my SE/30 replica.1 Instead, I decided to see if I could:
Build a “baremetal” version that leveraged the Pi’s opengles2 support (which I sort of already had, since my manual builds used the frame buffer directly)
Add an ARM JIT engine.
And then I thought–heck, why not make it two engines? (cue the “five blades” meme)
After all, I have had to run Basilisk II on fairly low-end 32-bit hardware in the past, and the 32-bit builds are actually faster on 64-bit Raspbian for some things, so I took the partial ARM32 JIT engine from ARAnyM and paired it with the Unicorn Engine. It lacks FPU emulation, but seems to be able to JIT chunks of 68k code OK, if disappointingly slowly.
Only the 32-bit one actually boots for now and seems snappy, but has some SDL and screen corruption issues I’m trying to figure out (this is one of the most extreme cases, it’s a little better now):
Yeah, I know even the case looks rough...
…but I have just spent one of the most fun late nights in years fighting with raw, unfettered low-level C, and even if I have to thank AI for a lot of the guidance and exploratory code, it was totally worth it.
The only thing that bugs me is that this took away nearly all of the time budget I had allocated to either finish the 3D model for a new case or opening the Maclock and start figuring out how to mount the hardware inside (although I have started collecting references for classic Mac case recreations).
I started doing it almost exclusively because of this Dashboard 2.0 issue, which has been open since 2024, and it sort of ballooned from there.
Truth be told, I’m also doing it because I think that the original dashboard is a much better fit for my needs in general, especially given the way it is deeply integrated into Node-RED.
And I had a bunch of ulterior motives:
I wanted to do a sizable project in TypeScript, and I might as well do some refactoring work to get started since I can compare it to the original.
I have always wanted to get rid of the Angular layer and have a single, unified modern CSS file that didn’t require additional tooling to maintain.
I really need a dashboard that works the way the old one did. And I am 400% positive I am not the only one.
I’ve also always been a fan of the utterly no-frills, very lightweight take Preact has on handling components, so I guess things just clicked the moment I started using bun heavily.
Right now I have most of the components “working”, although there are a few differences and nearly all the charts are buggy (I am still mostly refactoring and generating tests to ensure UX and behavior compatibility), but it is… usable in a way:
Cue the CSS blinds meme
Once I start daily driving it I’ll likely do the unthinkable and end up maintaining an npm package.
As a nice bonus, I added a bunch of locales that had never been supported, bringing the total up to 12:
🇺🇸 en-US (English)
🇩🇪 de (German)
🇪🇸 es-es (Spanish)
🇫🇷 fr-fr (French)
🇮🇹 it-it (Italian)
🇯🇵 ja (Japanese)
🇵🇹 pt-pt (Portuguese - Portugal)
🇧🇷 pt-br (Portuguese - Brazil)
🇨🇳 zh-cn (Simplified Chinese)
🇹🇼 zh-tw (Traditional Chinese)
🇰🇷 ko (Korean)
🇷🇺 ru (Russian)
Pro Tip: If you’re doing this kind of localization work, build a tool that does random sampling of your locale strings (I’m doing five sets of three - the English base plus two translations), and any LLM ((even the simplest local model) will churn through the mistakes in minutes.
After almost a year of poking at ways to keep things cooler in my closet, I finally fixed my TerraMaster’s fan controller (or, rather, found the Linux daemon that could deal with its proprietary PWM controller).
I haven’t pushed any of my scripts or notes to GitHub yet, but they’re going to end up on this repo.
Serendipitously, borg’s CPU fan died sometime this week, and I had to do some open heart surgery on it:
Yes, of course I modded the PSU fan to bring in extra cooling
Fortunately, I have spares of this kind of thing lying around, but it led me down another rabbit hole, which is taking another stab at fixing one of my long-time outstanding issues–having comprehensive metrics and alarms (i.e., observability) for all of my hardware (and home automation, and app metrics).
Proxmox has built-in monitoring for CPU, storage, etc., and I have long stuck to a very simple SQLite-based approach for my home automation temperature and power charts.
But I didn’t have a unified view of a lot of things–including baremetal data like CPU temperatures, fan speeds, etc.–and no real alarms other than a ZFS monitoring script that I put together when I repurposed some old HDDs.
After avoiding it for years I decided to look into InfluxDB, quickly steered away from the “big data style” version 3 rewrite and set up InfluxDB 2.0 on my main NAS.
Pointing Proxmox at it was a very trivial setup from the Datacenter settings–a few clicks and all my nodes, VMs and LXCs were sending metrics to it.
But were they?
Well… not really. The baked-in PVE collector is really picky about settings, and the only way I got it to work was to set up a dedicated proxmox bucket (it refused to send LXC metrics to anything else, which I suspect is a bug).
Pro Tip: Check the Proxmox forums whenever you come across this kind of inconsistency. Sadly, it seems this bug has been around for years and surfaces inconsistently.
Since I absolutely loathe Grafana (it’s overly complicated), I decided to have a go at building dashboards on InfluxDB directly, which… Nope.
So of course I started another project:
I forked steward and am building yet another agentic dashboard creation application that will eventually make it easy for me to create Vega or Giraffe grammars and Flux scripts from just talking to an AI.
Yes, I know this is a trope, but I figured I might as well get on that bandwagon, even if it is too close to what I actually do at work.
This is going to be a slow-burning project, so in the meantime I have already started piping zigbee2mqtt metrics into InfluxDB and I am setting up telegraf on all my physical machines and Docker hosts for both temperature/hardware sensor monitoring and detailed container statistics.
But first, I’m automating the heck out of the roll-out with ground-init to ensure it’s repeatable. Watch that for templates over the next few weeks.
And yes, I eventually caved in and installed Grafana to make do. But I intend to “experience” it again at leisure to see how much simpler I can make my own dashboarding experience. I hate it, but at least it works for now:
As anyone who's done Ops will tell you, flat charts are the best charts--they mean there's no trouble
The only thing I’m missing now is proper OpenTelemetry-like application performance metrics. Most of my cloud stuff uses Azure Application Insights for metrics, tracing, and exception logging, and even if I might be able to shoehorn part of it into InfluxDB, any suggestions on something I can do about it (and yes, I have Signoz on my shortlist) are welcome.
Update, the day after: Boy, a new year sure changes your perspective. Anyway, I decided to ditch InfluxDB given the artificial limitations in 3.0 and their deprecation of Flux and use Graphite instead, since I just want simple time-series storage and graphing without all the bloat, and a single container gives me everything I need for initial exploration. More on that later as I fine-tune my telegraf setups and figure out alterting, which is the one missing piece for me now.
This one is completely off the wall, but worth mentioning since it’s been on my back-burner for years and I have finally gotten around to it.
In short, the Hologram Electronics Microcosm is a very fancy granular effects pedal that took the synth world by storm a few years ago, and that I have always wanted to play with.
But my music hobby only really happens when I’m happy at work (and that hasn’t happened often of late) plus there is no way I could ever justify spending that much on one, so I have been tinkering with the idea of replicating most of its features in software somehow.
And then I remembered I have a Norns Shield I built a few years ago that can do most of it on paper, and I had a wild idea: I got the Microcosm PDF manuals, rendered them in Markdown, extracted all the feature descriptions and built a very comprehensive, LLM-ready SPEC.md with absolutely everything I could glean from the documentation.
The result of around 30 minutes of feeding that to GitHub Copilot was nanocosm:
I was completely blown away by the fact that the spec resulted in a working UI
…and, even more mind-blowingly, the first effect just worked.
I plugged in my Xsynth, piped the audio through, and it did some of the granular synthesis/looping/reverb I expected. I was hooked, and ended up spending most of last Friday fiddling with it.
Now for the reality check: I have no idea if it actually sounds like the Microcosm. After two days “implementing” all the effects I am constantly coming up against Supercollider issues and UI glitches, and the Norns has a pitiful amount of physical controls when compared to the Microcosm.
Still, I now have an effects toy that is a lot of fun to tinker with–it’s a great Christmas present for myself.
The icing on the cake is that I also ended up building an MCP server for it that is sophisticated enough for me to “show” Copilot what is in the UI and what sliders I’m tweaking so we can refine the Lua part:
Yes, I hacked the websocket connection from the web UI
Once I can sort out the Supercollider bugs (right now I’m not releasing all of the filters in some UI interactions) and figure out if this is actually releasable. It is, after all, a clean room re-implementation of the Microcosm, and as any synth nerd will tell you, Behringer is still very much in business… but I need to think about it, and if I reach a positive conclusion I will put it up on GitHub as well.
Finally, there were a few other minor successes/failures:
I finally got wisp to a usable state (for me), although I have completely failed at removing its recursive dependency on itself (like many LISPs, the compiler was rebuilt with itself, which means it’s a pain to deal with)
These had nearly daily fixes, since real life keeps coming up with corner cases–but they were all simple enough to be fixed using toad and the free OpenCode models using nothing but my iPad and a terminal window, so that was great.
But even though I’m quite happy with all of these hacks and this was arguably one of my best grown-up holiday weeks ever, I think I need to go back to dealing with hardware again.
I have been meaning to build my own ZigBee devices, but I also have new single-board computers and mini-PCs to test, so I think I’ll try to switch gears to those for the remaining few days before I go back to work (which is effectively Friday, but I’m looking forward to the weekend).
This is likely going to be the last post of the year, so I would very much like to thank:
Everyone who’s visited or supported this site (and hence a good deal of my hobbies)
All the vendors who’ve gracefully provided review samples throughout the year (and hence not just provided unique opportunities to gauge the state of various pieces of hardware, but also indirectly helped my private consulting engagements, since all that testing helps me keep my technical skills sharp)
But, most importantly, if you’ve read this far, I wish everyone a very Happy New Year.
May 2026 be a much better year for everyone all around (regardless of whether my predictions pan out or not).
I kept finding avahi-daemon pegging the CPU in some of my LXC containers, and I wanted a service policy that behaves like a human would: limit it to 10%, restart immediately if pegged, and restart if it won’t calm down above 5%.
Well, turns out systemd already gives us 90% of this, but the documentation for that is squirrely, and after poking around a bit I found that the remaining 10% is just a tiny watchdog script and a timer.
Then create a generic watchdog script at /usr/local/sbin/cpu-watch.sh:
#!/bin/bashset-euopipefail
UNIT="$1"INTERVAL=30# Policy thresholdsPEGGED_NS=$((INTERVAL*1000000000*9/10))# ~90% of quota windowSUSTAINED_NS=$((INTERVAL*1000000000*5/100))# 5% CPUSTATE="/run/cpu-watch-${UNIT}.state"current=$(systemctlshow"$UNIT"-pCPUUsageNSec--value)previous=0[[-f"$STATE"]]&&previous=$(cat"$STATE")echo"$current">"$STATE"delta=$((current-previous))# Restart if pegged (hitting CPUQuota)if((delta>=PEGGED_NS));thenlogger-tcpu-watch"CPU pegged for $UNIT (${delta}ns), restarting"systemctlrestart"$UNIT"exit0fi# Restart if consistently above 5%if((delta>=SUSTAINED_NS));thenlogger-tcpu-watch"Sustained CPU abuse for $UNIT (${delta}ns), restarting"systemctlrestart"$UNIT"fi
…and mark it executable: sudo chmod +x /usr/local/sbin/cpu-watch.sh
It’s not ideal to have hard-coded thresholds or to hit storage frequently, but in most modern systems /run is a tmpfs or similar, so for a simple watchdog this is acceptable.
The next step is to make it executable and figure out how to use it via systemd templates:
sudochmod+x/usr/local/sbin/cpu-watch.sh
# cat /etc/systemd/system/[email protected][Unit]Description=CPU watchdog for %iAfter=%i.service[Service]Type=oneshotExecStart=/usr/local/sbin/cpu-watch.sh %i.service
# cat /etc/systemd/system/[email protected][Unit]Description=Periodic CPU watchdog for %i[Timer]OnBootSec=2minOnUnitActiveSec=30sAccuracySec=5s[Install]WantedBy=timers.target
The trick I learned today was how to enable it with the target service name:
The magic, according to Internet lore and a bit of LLM spelunking, is in using CPUUsageNSec deltas over a timer interval, which has a few nice properties:
Short CPU spikes are ignored, since the timer provides natural hysteresis
Sustained abuse (>5%) triggers restart
Pegged at quota (90% of 10%) triggers immediate restart
Runaway loops are contained by CPUQuota
Everything is systemd-native and auditable via journalctl
It’s not perfect, but at least I got a reusable pattern/template out of this experiment, and I can adapt this to other services as needed.
Dec 27th 2025 · 1 min read
·
#circus
#cirque
#entertainment
#ovo
#photo
#photography
#soleil
It’s not their legendary boot floppy, but a QEMU image with a desktop environment for QNX 8.0, with support for self-hosted compilation, using XFCE on Wayland (sadly, their Photon UI is long gone) and providing a number of development stacks and editors. The installation process seems overly contrived (and I am not doing it this holiday season, as I have far too much to play with already), so I would have loved to see an ARM bootable image for a Pi or similar.
I’m sure some enterprising souls will hack their way through this to get it to run on bare metal somehow, since QNX has always been a fascinating RTOS (even if they lost a lot of audience to embedded Linux due to their commercial approach).
If they keep tightening the bootstrapping story, this could become a surprisingly effective bridge between “I have a QNX target” and “I can ship software on it without ritual sacrifices.”
Dec 26th 2025 · 7 min read
·
#ai
#apple
#business
#predictions
#tech
Last year I had a go at doing predictions for 2025. This year I’m going to take another crack at it—but a bit earlier, to get the holiday break started and move on to actually relaxing and building fun stuff.
So let’s see how I fared last year at this prophesying stuff and what I think is going to happen next year:
The AI bubble slowly deflates—not with a bang, but via data hygiene and enterprise pilots.
Guess what, 2025 wasn’t the start of a second AI winter after all.
But it might herald a slow, quiet AI autumn, and we are quite likely to witness a slow bubble burst next year as companies that rely solely on AI become obviously untenable (and OpenAI is quite well placed in that regard). But I did see that as inference costs decreased (artificially or not), AI became ubiquitous in the enterprise for just about anything.
So I missed that one. But I’d rather wager we’ll see a couple of major (if slow) implosions and a readjustment of the stock market than keep feeding the fantasy that LLMs will solve everything.
Diminishing returns take a while to kick in, even if things are “improving” in terms of model capabilities and the “agentic” approaches have mutated into variations of the “big data” playbook: clean up your data first, and your agents will work more reliably.
We still haven’t found the next new thing here, but at least the industry can’t deny we’re heading down a blind alley anymore.
So I’ll stick to the bit where I said:
I’m not even going to go there other than to say the hype-to-reality gap will, eventually, result in a cooling period for AI. My money’s on this year, but considering how long crypto hung around, the bubble might only deflate (with a whimper rather than a bang) in 2026.
Given that the US seems to have devolved into a sort of Wild West regarding AI legislation, I’m going to skip this one for 2026.
I was also wrong when I said:
I fully expect 2025 to be the year where I refuse to work on a project due to ethical concerns, and I suspect I will not be the only one.
People have been remarkably sane regarding practical applications of AI, and I’ve stopped seeing creepy HR evaluation agents and stuff. Plus I’ve actually been involved in a lot of discussions about responsible AI and accountability for its use.
Apple's Liquid Glass design language, as they would like it to be in real life...
I opened this section last year with this doozy:
Apple Intelligence, despite Apple’s clever marketing, will remain plainly distinguishable from useful AI.
Nailed it.
There is now solid evidence that Siri is going to be powered by Gemini by WWDC 2026 (thus “improving”), and rumors of a “HomePod with a screen” are thick on the ground. So I’m going to claim that last one as correct but mistimed.
What I didn’t expect at all were:
The M5 not making it to the Studio range (or, in fact, the lack of any substantial Studio upgrades)
The Liquid Glass nightmare–which might be “fixed” now that Apple leadership is undergoing a bit of churn and we’re getting actual UI designers steering the company back from the brink of the bad taste abyss.
And of course my usual gripe panned out, as reliable and recurring as taxes:
Apple will still not allow you to run your own applications on iOS devices for more than a few days without the Developer Program or its kill switches.
For 2026, I am willing to wager that:
Apple gets its software QA under control (if not effectively, at least to the point where the next OS releases won’t be nightmare-inducing)
The UX guidelines get toned down heavily into something sensible
We get new minis (Mac and, hopefully, iPad)
We don’t get decent-sized iPhones (the foldable is pretty much certain, but not something you can use with one hand)
Apple will start treating the EU as a second-tier market—not just by still withholding features like iPhone mirroring, but actively removing existing ones.
Gemini, sorry, Siri will make a shy debut because Apple isn’t willing to rely on AI for anything, and they are fully aware of how badly their previous attempts failed.
I still won’t have an iPad able to run VS Code natively.
PC builders have no real hope against the datacenter profit mirage
Well, AMD rocked on through most of 2025, Intel weirdly got into bed with NVIDIA, and the PC builder market seems to be imploding, so I’m going to chalk all of those as wins.
I was off about NVIDIA getting strong competition in the datacenter, though. That is a severe, strategic weak spot in everyone’s AI hardware investments where I was hoping someone would step in to fill the gap, but Cerebras and its peers haven’t really taken off yet.
My prediction for 2026 is that they won’t. For someone to be able to do that, NVIDIA needs to miss their growth targets first, so that’s my prediction for 2026.
I did get the continued fragmentation of the low-end market mostly right, and no, RISC-V still isn’t relevant, although there were enough RISC-V product launches that I’m now willing to wager that 2026 will be the year where we see a small, feisty development board or reference design that will outpace similar ARM-based devices.
Return-to-office mandates and infrastructure outages are going to just keep on coming
I was wrong about there being at least one major AI ethics scandal in the news (and no, the unfortunate killing of a cat by a Waymo doesn’t qualify).
But I do expect more news about serious AI mishaps in 2026, solely due to its extended adoption everywhere.
The telco market hasn’t bottomed out yet (so I missed that too). But I think I’m going to claim I was right about internet outages having become more common (I wasn’t factoring in AWS or Cloudflare when I wrote that, so I got lucky, I guess).
I do think outages will be more frequent in 2026, especially now that more services are relying on AI infrastructure. But I’m pretty sure that won’t be the only reason.
As to technology and jobs, well… The market is still a mess. I think I can say I was wrong to pin that on AI. I’m positive AI will just mean we need more people in IT and technology, just not in the current kinds of roles we have.
I did nail RTO, though. 2025 was a year where every month there were new dictates about moving back to (at least) a hybrid workplace culture, and my prediction is that that will be the default for 2026.
Even if, ironically, we will still sit on video calls at the office, and mostly alone at that.
It's not going to be that much of an improvement until the US settles down a bit
We all know how well the US tariff policy went, and in general how it’s going over there. So I will offer my sympathies as I claim blanket correctness on all counts (except for Taiwan, which hasn’t happened yet) and defer economic downturn to when NVIDIA makes the stock market hit the brakes.
I am bearish on 2026 where Ukraine is concerned, since the “at least” I used referring to that last year is, as far as I’m concerned, still pretty valid.
And although X surprisingly hasn’t imploded (wrong again, and I suspect it will keep stumbling along), I will stick to my guns and wager that Meta will keep dropping the ball on Threads in the EU.
In fact, I fully expect that, given the DMA and the passive-aggressive showdowns between Silicon Valley and the EU (including Apple’s malicious compliance), we will have much more friction regarding US-led digital services (and AI) in 2026.
Dec 26th 2025 · 1 min read
·
#accessibility
#airdrop
#apple
#ios
#usability
I just don’t get why Apple keeps breaking things. AirDrop used to be one of Apple’s best “it just works” features: get two devices close, pick the target, accept, done.
Adding a six-digit code step might make for a marginally stronger confirmation flow, but it also adds unnecessary friction in exactly the moments when AirDrop is most useful—quick, in-person handoffs.
It’s also the kind of interaction that breaks down fastest when there’s a language barrier, poor audio conditions, or an accessibility/disability barrier: the more you turn a fast tap into an out-loud “read me the code” dance, the less universal the feature becomes.
Somehow, someone at Apple must have thought this was a good idea. I’d love to hear the rationale, because right now it just feels like they’re hell-bent on making all of their best ecosystem features more complicated for no good reason.
Dec 26th 2025 · 1 min read
·
#apps
#macos
#provenance
#quarantine
#security
#tools
#xattr
This is a terrific little tool that Howard Oakley released as a Christmas gift to the Mac community.
Providable is a handy way to inspect Provenance IDs and Quarantine extended attributes (xattrs) at scale.
It can index your installed apps, crawl folders for large batches of files, or show full xattr listings for a handful of dropped files–and if you’re extra curious, it can also export results to CSV for further analysis.
Dec 24th 2025 · 4 min read
·
#ai
#dev
#docker
#hardware
#homelab
#keyboards
#notes
#plan9
Work slowed down enough that I was able to unwind a bit more and approach the holiday season with some anticipation–which, for me, invariably means queueing up personal projects. So most of what happened in my free time over the past couple of weeks was coding-related.
Like last year, this is my somewhat rushed recollection of the year that was, and as usual it’s a mix of personal and professional reflections, with some thoughts on technology and trends thrown in for good measure.
I’ve long had a fascination for digital picture frames, and that harks back to the Vodafone 520 Photo Frame, which was, at the time, a pretty wild concept–you could send pictures to it over GPRS and have them show up on a tiny LCD screen, way before social networks and ubiquitous connectivity made that a non-issue.
This is absolutely fracking insane, and one of the things that terrifies me the most about the way Apple (or Google) handle account blockages and support. The complete blanket blocking of all services, the lack of any meaningful support, and the complete absence of any recourse or appeal process (including the Kafkaesque “you can only contact us from a device signed in to your account” requirement) is a recipe for utter disaster.
The worst part is that it is completely impractical to have “backup” accounts for all the services you use–or even self-service ways to retrieve your data in alternate ways if this happens. And $DIVNITY help you if you’re the head of a family account, or a business account, or if you have any kind of shared services.
Apple can do much better than this. They must do much better than this. Because the current situation is untenable, and without human contact points or sane checkpoints it is only a matter of time before someone figures out how to do this at scale to purposefully lock other people out of their accounts. I bet that having a few Apple execs go through this process themselves would be a real eye-opener for them.
Dec 8th 2025 · 3 min read
·
#3dprinting
#ai
#keyboards
#notes
#video
Thanks to local bank holidays we had a couple of consecutive extended weekends, which I spent doing a bunch of long overdue chores, including replacing kitchen lights, organizing my office a bit better, and generally ticking off various small tasks that had been piling up for a while.
Much ado is being made about AI being the root cause of the current memory price surge, but the reality is a bit more complex than that. While AI workloads do demand significant memory resources, the underlying issues stem from a combination of factors affecting the entire semiconductor industry–the fact that Micron is shutting down Crucial shocked many PC builders, but if you look at all the charts and ponder the situation, you quickly realize that:
Older RAM started climbing in price earlier as fabs switched to DDR5 production, which is now the standard across just about any kind of hardware (consumer, mobile, server., etc.)
PC Part Picker’s charts don’t show that server RAM prices have actually been climbing slowly but steadily for over a year (just like flash storage, CPUs and other things that, guess what, are mostly fabbed in Taiwan and need to be shipped to the US).
A sizable chunk of this is a direct consequence of the uncertainty created by tariff policies and geopolitical tensions affecting supply chains. Everyone has been padding their margins, just in case.
And yes, it will always be more profitable to sell to data centers than to consumers. NVIDIA was the prime example of that, but of course cumulative pressure “spread out” that load to supporting components.
Plus there’s an inconvenient truth–most people do not build (or even upgrade) their own PCs anymore, so the market for custom builds is shrinking, which means less competition and higher prices for those who do.
I do find it highly amusing that people find that Apple’s M-series Macs are now in line with the market, especially since this dynamic doesn’t really apply to Apple–remember they fab the RAM directly into their CPUs, so they’re largely immune to discrete component pricing fluctuations.
Plus, of course, Apple can negotiate far better pricing even if they were to buy discrete RAM, given their scale and influence in the market. At best, they would be affected by IP licensing for specific RAM technologies, but that’s a different matter altogether.
What I don’t find amusing, though, was that I completely forgot to buy RAM for one of my machines over Black Friday. Good thing that borg was padded out with 128GB two years ago when it was cheaper…
Dec 4th 2025 · 4 min read
·
#gaming
#homekit
#homelab
#node-red
#steam
#wol
I started doing it because bun is the closest thing I’ve come across yet to a “batteries included” JavaScript runtime: it bundles SQLite support, HTML parsing and sane HTTP primitives, can generate standalone executables, and the fact that it installs packages with sub-second delays and bundles its own TypeScript implementation is just icing on the cake.
Do I like JavaScript any better because of bun? Heck, no. Do I think it’s especially useful for AI development? Not really, other than the fact that TypeScript removes some of the ambiguities of API calling and bun itself is well suited to ship flexible CLI tools (which is what Anthropic wants it for).
Does it mark a significant shift in the landscape of JavaScript tooling? Nah. The ecosystem has always been there–it is a great milestone for bun and Zig, and it’s a good sign for bun in terms of long term runway and support, but the only risk I see is that the hype overtakes reality and Anthropic starts shoving in AI-specific garbage into the bundled runtime.
Should Claude Code competitors heed this shift? Not really. Anything can be an AI tool helper these days, as long as it can do API calls, and bun is just more expedient in a JavaScript-infested industry.
Me, I’d probably have picked Go, but native code (or AOT builds like you’d get from C#, which is shunned by most but quite interesting for cross-platform compatibility) are not really needed for AI tooling now that we’ve come to accept the fact that models (nearly) always live on remote services.
Nov 26th 2025 · 1 min read
·
#arturia
#gas
#hardware
#music
#synths
#wishlist
I know I already own a three-year-old copy of V Collection and an Essential and that I can always use those, but the form factor (even if it has mini keys) and the sheer amount of shipping presets makes this an amazing little synth.
(And yes, before you ask, it would be amazing to have an iPad version of Arturia’s soft synths, even if simplified, but that is unlikely to ever happen under Apple’s App Store tax.)
Too bad it doesn’t have speakers and a battery like the Yamaha Reface series. And it’s on the pricey side, but I could always sell my OP-1…
Nov 24th 2025 · 6 min read
·
#alarm
#classic
#clock
#hardware
#mac
#retro
#reviews
If you’re anywhere near the intersection of Apple nostalgia, retro-computing and DIY electronics, This Does Not Compute’s latest video was probably on your radar. If not, the gist is simple: there is an 11 cm tall alarm clock shaped like a Classic Mac, and I grabbed one off AliExpress for roughly EUR 20.1
Rui Carmo
