afonso jorge ramos

You Can Just Do Things

Fri, 28 Aug 2026 00:00:00 GMT

You could always just do things. What AI changed is the time an attempt costs, and time was most of the decision of whether to do something. If you only want that argument, it is at the end; everything between here and there is the evidence.

This started with one of those things that bugs you every day until you break.

Plex buffering while playing Silo

Plex would play for a while on my Xiaomi TV Box S 3rd Gen, stop to buffer, recover, and eventually become annoying enough that I restarted the box. The restart usually helped and mostly avoided the problem, which made the diagnosis feel obvious: the hardware was underpowered, Xiaomi had filled Android with too much garbage, or the firmware had reached the point where replacing it would be easier than understanding it.

I started looking for custom ROMs. I wondered whether rooting the box would make it faster. I was already thinking about replacing it with a more easily rootable Android TV device and rooting that instead.

None of those things would have fixed the problem.

But, by the time I finished this journey, the Xiaomi was still running its stock firmware and Plex no longer buffered. The more interesting work eventually moved to my LG C3, which was now rooted, stripped of several layers of optional data collection, and running a small webOS application I had not intended to build.

As with my homelab, there was no plan connecting those outcomes. I was purely exploring how much better I could make the hardware I already owned, and each irritation led me to the next one.

I nearly rooted the wrong device#

My initial goal was to root the Android box. Plex was reporting Direct Play, and I had been treating that as evidence that the path between the server and the box was healthy, which left the box looking like the problem. I did suspect the router, since I am temporarily on a cheap ISP-provided one, but I never thought it was just because I was on 2.4 GHz instead of 5 GHz.

But as soon as I started going deep into this, I noticed that the measurement that mattered was below Plex entirely. The Xiaomi had associated with the 2.4 GHz band of my combined network, and its average latency to the router, not to Plex, not to the Internet, but to the first hop across the room, was roughly 1,323 ms, with 5% packet loss. I added a 5 GHz-only SSID and moved the box onto it. Latency fell to 4.65 ms and packet loss to 0%. The same Plex file stopped buffering.

Rooting the box would have been an impressively complicated way not to fix a bad wireless connection. That is the failure mode of cheap experiments: they are just as cheap to point at the wrong thing.

I just hate all tracking and advertising#

The box still deserved a cleanup. Wireless debugging gave me ADB without opening anything or unlocking the bootloader, and I removed what I did not want: the Xiaomi telemetry packages (com.xiaomi.statistic, com.miui.tv.analytics), the preinstalled streaming apps, and the ad-filled Google TV launcher, which Projectivy replaced. Twenty packages uninstalled, twelve more disabled, nothing flashed.

Four of the removals were com.android.adservices.api, com.android.sdksandbox, com.android.ondevicepersonalization.services, and com.android.federatedcompute.services. On this Android 14 build, system_server crash-loops without them. The first time, the loop only surfaced at a cold boot after a power cut, and Android’s Rescue Party escalated to a factory reset: every removal reverted, and my own apps went with them. When I re-removed the same four during the second pass, the box reset immediately.

They stay installed now. Of everything I deleted, from TalkBack to the calendar sync adapters, the packages this television box refused to live without were the advertising machinery. Anyways, blocking that traffic can live in the router firewall rules once I replace the ISP router with a UniFi Wi-Fi 7 one.

The LG was a different kind of problem#

Fixing the Xiaomi should have ended the project. I mean, I already had Button Mapper on it, so its buttons were already custom: the Netflix button led to Plex and YouTube to SmartTube. But instead, it made me look at the LG C3 it was connected to and ask a different question: if I could remove the things I did not want from Android, how much of the LG experience could I make mine?

The LG was not slow. I was bothered by the promotions, branded remote buttons, ACR (automatic content recognition), opaque privacy controls, and the general feeling that buying the panel had not quite bought control over the computer attached to it. This is why I usually recommend that no one connects their TVs to the internet unless there is a specific firmware update to be made.

The lower half of an LG Magic Remote, crowded with branded buttons for streaming services.

This time, root access was relevant.

The TV was running webOS 25 on firmware 33.31.68. I checked the exact model and firmware against the community compatibility data, read through SlopBro, and used a recorded source revision rather than an unknown binary. There is no useful percentage for the risk of bricking a television this way. The exploit itself normally either works or fails; the more durable risk begins after it succeeds, when a root shell makes bad ideas possible.

SlopBro installed and elevated Homebrew Channel 0.7.3. The icon appearing was encouraging, but it was not proof of root. A shell returning this was:

uid=0(root) gid=0(root)

I then rebooted the TV and checked again. Root SSH returned automatically, the Homebrew startup hook ran, and the same shell still had UID 0. That distinguished persistent root from an application that happened to launch once.

The first job after gaining access was reducing how much access I had created. I installed a dedicated Ed25519 public key, required key-based SSH authentication, disabled the unauthenticated Telnet service, and confirmed port 23 stayed closed after reboot. I also enabled Homebrew’s firmware-update block. Rooting a television and leaving a passwordless root service listening on the network would have been a strange definition of taking control.

The privacy screen was only one layer#

Several visible settings were already off: home promotions, content recommendations, screensaver advertising, personalised recommendations, and customised advertising.

The underlying consent state told a less reassuring story. The TV still recorded permission for marketing, data-partner processing, viewing-information collection, interest-based advertising, voice-information processing, shopping-related processing, and ACR/LivePlus-related processing. The mic button was the daily reminder: pressing it did not open a microphone, it opened a terms-and-conditions screen asking me to accept voice processing, a menu that does not have an option to refuse those terms :)

The LG User Agreements screen, asking for consent to viewing, voice, and advertising agreements.

LG’s User Agreements screen, spelling out that viewing data collected through ACR “can be used and shared with our third-party partners for advertising purposes”. Source: Nielsen Norman Group.

I saved the existing state under Homebrew’s persistent data directory, then used webOS’s own settings service to revoke the optional agreements. Network access and the essential service terms stayed enabled; the advertising, voice, shopping, partner-sharing, and additional-data flags did not. I read the values back through the same API and updated the user-facing agreement list so the interface and effective state agreed.

Homebrew also redirected LG’s firmware-update hosts locally and mounted the standard telemetry upload queues read-only. Both mechanisms were verified again after reboot.

That still does not justify saying the TV makes no requests to LG. Its built-in tools were not enough to capture and attribute every DNS request and payload. I could see connections involving Google, GitHub, Cloudflare, AWS-hosted infrastructure, and local casting services, but an IP address is not proof of a hostname or purpose. A local resolver with per-device query logging would be the next honest step.

Root gave me enough leverage to disable known collection paths. It did not turn incomplete evidence into certainty.

Root does not make old software compatible#

The first Homebrew disappointment made the same point from another direction. I installed Custom Screensaver, and it did nothing.

The failure was not permissions, it was just that webosbrew does not have a way of detecting app compatibility with specific webOS versions. So, for example, Custom Screensaver 1.0.1 expected an old QML entry point at com.webos.app.screensaver/qml/main.qml. webOS 25 had replaced that implementation with a compiled Flutter application, so the path simply did not exist. Aerial and the other available replacements depended on the same older architecture.

But, having root meant I could inspect the failure clearly. In this case though, it did not mean forcing an old patch onto a new system was sensible, so I removed the inert application and left the stock screensaver alone. Next goal: disabling the branded remote buttons.

The button that installed Rakuten#

Now that I had restored internet access to my LG TV, the dedicated remote buttons went back to auto-installing services I do not use: Netflix, Prime Video, Disney+, Rakuten TV, and Alexa. LG Input Hook looked like the right tool for disabling them, so I configured the four streaming buttons through its web interface and was about to add Alexa.

Then I pressed Rakuten, and the TV started installing Rakuten.

The configuration was correct; the hook was not running. On webOS 25 its injector failed while resolving an internal glibc dlopen symbol, so none of its saved rules could intercept anything.

Magic Mapper took a different approach. It grabbed the Magic Remote input device, consumed configured buttons, and forwarded everything else to webOS. I pinned and reviewed its source, started it interactively with only the five branded buttons disabled, and pressed Rakuten again. This time the log said Button rakuten is disabled, and nothing opened.

I added a guarded startup script so the mapper returned after reboot. Functionally, the problem was solved.

Operationally, it was not.

Magic Mapper was a Python script, a JSON configuration file, and a startup hook. It had no launcher tile, no status screen, and no way to remove itself from the television’s UI. Installing an invisible root service is easy. Leaving behind something another person can understand and safely undo is what makes it usable in a house where not everyone is technical (even if it is just a button mapper).

So there was a missing UI#

I initially imagined a small manager showing whether Magic Mapper was running, which buttons were blocked, and one large removal button. Once I looked further at the upstream feature set, that scope stopped making sense.

Magic Mapper could already adjust OLED brightness, change energy-saving and eye-comfort modes, turn off the panel, launch applications, simulate other remote buttons, send IR and HDMI-CEC commands, call webhooks, open TCP connections, toggle PicCap, and disable the Magic Remote pointer. So, huge props for that feature set! A UI exposing only the five actions I happened to need would make the underlying project look much smaller than it was.

The result became Magic Mapper for webOS: a standalone Homebrew application around a pinned, checksummed upstream runtime. It can discover a button while suppressing its normal action, present every upstream action through remote-friendly categories, validate the inputs, show authoritative runtime status, restore individual mappings, and remove its own state and startup hook cleanly.

The Magic Mapper home screen on the TV, listing each remote button with its current mapping and status.

The interface is deliberately television-shaped. There are no tiny form controls, browser-like sidebars, or seventeen equally weighted actions in one modal. Common actions come first; picture and screen controls, devices and automation, experimental commands, and global settings sit one level deeper. Back moves up one level (which turned into the hardest bug in the project).

The action catalogue, with upstream actions grouped into remote-friendly categories.

Back did not mean Back#

With Magic Mapper holding the input device, pressing Back inside another application’s nested menu exited the whole application instead of closing the menu. The UI was not mishandling navigation; every application on the television changed behaviour while the mapper was running.

Once again, the model went back to work, and together we reduced the problem to the two webOS output devices. Replaying the remote’s raw Back sequence through the existing [2] passthrough caused an app exit. Sending a clean, complete Back keypress through [1] closed only the current menu, even while the physical input was exclusively grabbed.

The fix suppresses the original Back sequence on webOS 25 and replays one fresh keypress through the correct device. We tested it on the actual C3: Back closed only the nested menu, arrow and OK responded immediately afterward, and Netflix and Rakuten remained blocked.

That change belonged in the mapper rather than the new interface, so I separated it into a one-file upstream pull request. The standalone app keeps its UI, packaging, validation, and managed lifecycle separate from the clean upstream fork.

The frontend eventually moved to Vite, while giving SolidJS 2’s release candidate a try. But the cool part is not the stack; it is how easy it became to bundle everything webOS needs and ship it to the TV.

The volume bar that would not go away#

Then came the final issue: pressing volume up left the bar on screen until I pressed something else. My first guess was the mic button, because I had disabled it and disabling buttons might well interfere with other buttons’ behaviour. A quick test proved that assumption wrong. What settled it was capturing what webOS actually received:

 95.617  EV_KEY  code=115  value=1   # volume up, pressed
104.557  EV_KEY  code=115  value=0   # released, nine seconds later
104.707  EV_KEY  code=103  value=1   # the D-pad press that flushed it

The key-up for volume arrived nine seconds after the key-down, at the exact moment I pressed the D-pad. The television was not failing to dismiss the bar. It believed the button was still being held.

The mapper opened the remote with a buffered reader and watched it with select(), which reports readability from the kernel queue. An evdev device writes a key and its SYN_REPORT together, so the buffered reader pulled both into user space in a single syscall, handed back one, and left select() looking at an empty kernel queue. Every event after that arrived one behind. The D-pad never dismissed anything; it was just flushing the release that had been sitting in the buffer.

The fix was simply setting buffering=0. The bug was in the first commit of the wrapper, so every release before 1.1.1 carried it, and it affected every button. Volume is just where a stuck key-up is visible.

Version 1.1.1 is available on GitHub and installable through Homebrew Channel by adding https://mm.afonsojramos.me as a repository. I also submitted it to the webOS Homebrew repository.

The route I would have taken#

Would I have gone through this rabbit hole without AI? Maybe I would have dipped my toes, but time seems to run out more and more with age, the list of things I am involved in only grows, and the depth I reached here would have been very different.

Without a model to argue with, I would 100% not have rooted the television. I would have done the cheap thing and never connected it. The Xiaomi box was already attached to the panel and already doing the work. A C3 that never sees a network shows no promotions, sends no telemetry, and has no button that installs Rakuten, because there is nothing for it to install from. That route costs one decision and no evenings.

What changed is not that I became more capable. It is just that the interesting route stopped costing weeks. Reading SlopBro’s source, checking the recorded consent flags against webOS’s own settings service, working out why an old QML screensaver cannot load against a Flutter implementation, building a webOS application in a stack I had not used: each of those was previously a whole evening, or several, and most of them would have lost to whatever else the week wanted. Compressed, they became things I could attempt on a Tuesday and abandon on Wednesday if the evidence said stop.

And it is not like the model made the decisions. What to try, what to measure, and when to stop stayed mine; what the model removed was the cost of acting on them. AI is great at enabling curiosity, the same way it is great at enabling a quick MVP.

None of this means I fully trust it to do everything. A model tends to run with whatever framing you hand it, and I handed it wrong framings the whole way through: the box is underpowered, the mic button broke the volume bar. What kept those errors cheap was insisting on measurements before conclusions: the latency test, the event capture. Agreement is a model’s default state, not evidence.

There is a cost to this though, one that arrives later and that not everyone is willing to take. AI made the app cheap to build, not cheap to own. Magic Mapper for webOS can now run on other people’s TVs, where I cannot watch it fail, and its first release shipped a bug I lived with for two weeks, the way I treat most small annoyances: ignored until it bugged me enough to dig in. No speed of building would have caught it. And if you check my other open-source projects, you will see that I tend to take care of things and make sure that issues are quickly resolved, but I’m not sure I can say the same about everyone’s AI projects, and that can get annoying and pollute the open-source scene a bit. But when that is the case, a small fork will surely emerge from someone more willing to maintain something that helps others, because that is what keeps open source alive.

Steering into the rabbit hole#

I did not fall into this rabbit hole. I steered into it, one question at a time, and most of those turns were possible because root made the hard-to-read parts readable: consent flags, input events, failures. All I needed to do was ask.

The application that came out of this was not even a goal, it was just a conclusion from a series of questions that derived from the one the Xiaomi planted: if I could remove the things I did not want from Android, how much of the LG experience could I make mine? I was not looking for an open-source project to build. The exploration simply exposed gaps in what I wanted my experience to be, and given that similar projects existed for Android TV, they were not super hard to conceptualize. And if what I made makes other people’s lives easier, all the better!

AI makes attempts like these cheap. The steering does stay expensive though, because you still need to know the right question to ask. But give in to the curiosity, read more about stuff, maybe even let AI help you through the journey, and at some point you will know what to ask. Because, at the end of the day, you can just do things!

Yet Another Package Manager

Fri, 17 Jul 2026 00:00:00 GMT

When nub showed up on my radar, my first reaction was the xkcd standards comic. I already had a working split: bun for the personal sites, pnpm for the serious apps, mise pinning versions across machines. The Node ecosystem does not have a package manager shortage. It has a package manager surplus with a discovery problem.

What got me to actually try it was the combination of an ambitious filesystem model and a migration story that barely qualified as a migration. nub is a single Rust binary with its own install engine, but it does not require a nub-specific lockfile. It infers the incumbent package manager and mirrors it: npm, pnpm, and Bun lockfiles round-trip in their existing formats, while Yarn lockfiles are read-only. Point it at a pnpm-lock.yaml or bun.lock and it keeps that format; if the resolved graph has not changed, it leaves the lockfile untouched. Your teammates do not have to switch just because you tried nub locally. That is a very different pitch from “regenerate your lockfile and pray”, and it lowered the cost of an experiment to roughly zero.

It also runs TypeScript directly (nub file.ts), runs package scripts, and replaces npx, and in my case bunx, with its own nubx. Nub still runs the code on stock Node, but one command surface replaced most of the separate tools I had accumulated around it.

The Oxc signal#

I have developed a small bias towards projects that use or build on Oxc. Not because Rust automatically makes a JavaScript tool good, but because those projects often share priorities I like: native performance, compatibility with the existing ecosystem, and focused components that can be embedded without asking you to move into an entirely new world.

Nub uses Oxc for a clear reason. Its TypeScript support does not come from replacing Node with another runtime. It transpiles the source in memory using Oxc, through a native addon, and then gives the result to the stock Node binary. That lets it support TypeScript, JSX, decorators, and newer syntax across the Node versions it targets while keeping Node’s runtime compatibility. Oxc handles the part it is good at; Node remains Node.

I have never seen someone so obsessed with performance, and I love it. When Yuku published results faster than Oxc, Boshen did not dismiss the comparison. He praised its data-oriented design, said there was something for Oxc to learn, and immediately started considering the breaking changes it might take to catch up.

A post by Boshen praising Yuku for outperforming Oxc and saying he would consider major breaking changes to reach the same level of performance.

Credit here belongs to Oxc project lead Boshen and the team around him. Building fast infrastructure is one thing. Building it as a set of useful parts that other tools can adopt without inheriting an entire platform is much harder, and I keep finding that I like the projects that make that choice.

So I migrated one repo. Then ten.

The global store#

The feature that actually sold me is the global virtual store. That name is easy to misunderstand, because it is not merely a download cache.

Most modern package managers, pnpm included, already have a global content-addressed store. Identical package files are saved once and then hard-linked, reflinked, or copied into projects. The project normally still gets its own virtual store, though: the fully wired directory tree that encodes which exact dependency tree each package is allowed to see. Rebuilding that tree is why deleting node_modules can still mean creating thousands of filesystem entries even when every byte is already cached locally.

Nub, through its embedded aube engine, moves that virtual store into a machine-wide cache too. A project’s node_modules becomes mostly symlinks into package trees that have already been materialised elsewhere. Those trees are not keyed by package name and version alone. Their identity includes the recursively resolved dependency graph, patches and, when lifecycle builds are involved, the operating system, architecture, and Node version. Two projects share a package directory only when its surrounding graph and build context make that safe. The source files underneath remain content-addressed, so separate graph variants do not necessarily mean separate copies of every byte.

This part was not invented by Nub. pnpm has an optional global virtual store, and the aube graph hasher shipped inside Nub explicitly describes itself as a port of pnpm’s implementation. The difference that mattered to me is how Nub deploys the idea. pnpm leaves the global virtual store disabled for normal project installs. Nub enables it by default on a developer machine, regardless of whether the repository belongs to Bun, pnpm, npm, or Nub itself. Both tools disable the shared layout in CI, where an external machine-wide store would make the resulting tree non-portable.

Making that the default is the interesting work. A package inside a machine-global store can no longer walk upward and find undeclared dependencies or project files. pnpm’s global virtual store handles hoisted dependencies through NODE_PATH, but Node does not use NODE_PATH for ESM; pnpm therefore points affected projects towards packageExtensions or a custom ESM loader. Nub takes a more targeted route. Nub 0.4.12 scans installed package code for those undeclared imports and materialises only the affected package closure back inside the project. The rest of the graph remains shared.

The same problem appears when a dependency mutates its own installation. Prisma, for example, writes a generated client beside @prisma/client. A globally shared directory cannot safely hold generated clients for projects with different schemas, so Nub detects packages with this behaviour and keeps them project-local. This is the recurring design: share the common case globally, then identify the pieces whose correctness depends on project-local state and pull only those pieces back.

Some tools need a wider escape hatch. Next.js and Metro-based React Native projects resolve modules by crawling within the project and cannot see packages whose real paths live in a machine-wide store, so Nub falls back to a project-local virtual store for them. Expo releases before SDK 56 follow the same path, while newer versions can retain the shared store. Vite gets its own compatibility path: Nub writes the external store into node_modules/.modules.yaml, which Vite 8.1 and later understand directly, and backports the same check into older installed versions. It preserves global sharing without requiring a vite.config change or a Nub-owned runtime process.

This is a much more interesting distinction than dependency isolation alone. pnpm already has an isolated linker, although its default layout deliberately hoists dependencies into a hidden directory for ecosystem compatibility. Nub’s default is stricter: undeclared imports fail unless its compatibility analysis finds a reason to materialise that package locally. Its underlying graph-addressed store owes a great deal to pnpm, but Nub’s bet is that a global virtual store can be the normal local-development path if the package manager is willing to detect and contain the exceptions automatically. That extra machinery is also where several of the sharp edges I found came from.

After migrating everything, my machine-wide store sits at 7.4 GB total while per-project node_modules directories dropped to roughly 100-400 MB of residuals. A cold install of a 782-package app takes about 16 seconds; a warm one takes six. And rm -rf node_modules stops being an event, because there is almost nothing in there.

Phantom dependencies, or: my repos were lying to me#

The stricter layout comes with a stricter philosophy: if you did not declare a dependency, you do not get to import it. I expected this to be an annoyance. Instead it was an audit I did not know I needed, because the migration immediately surfaced bugs in my code that bun’s flat node_modules had been hiding for months:

One site referenced @cloudflare/workers-types in a triple-slash directive without ever declaring it, through a path that had also been dead since v5 of the package. It type-checked by pure hoisting luck.
Another app’s SSO test suite imported samlify undeclared. Under the flat layout those tests silently resolved it; under nub they failed to load, and it turned out three test suites had effectively never run. Declaring one devDependency took the suite from 256 to 259 tests.
This very site threw SessionStorageInitError in production because Astro’s Cloudflare session driver dynamically imports unstorage, which only existed transitively. The documented fix is to declare it. The flat layout had simply been papering over it.

None of these were nub bugs. They were my bugs, and nobody had told me about them.

Install scripts are permissions#

The install policy follows the same pattern. Dependency lifecycle scripts do not run indiscriminately: packages must be explicitly approved or pass Nub’s curated default-trust floor, which combines registry provenance, advisory vetting, and a 24-hour cooling window. The permission is written using the incumbent package manager’s own configuration—pnpm.onlyBuiltDependencies, Bun’s trustedDependencies, or Nub’s neutral allowBuilds—rather than introducing a Nub-only decision that collaborators cannot see.

This was not what made me try Nub, and modern pnpm has also moved towards safer supply-chain defaults. What I like is the combination: Nub preserves the repository’s existing package-manager identity while applying a deliberately conservative install policy underneath it.

The sharp edges#

It was not all smooth, and this is where it got fun. Migrating ten real repos in a weekend is a decent stress test, and it shook loose a series of genuine nub bugs:

The global store’s isolation broke TypeScript’s peer-type resolution in three different disguises: astro-icon’s <Icon> losing its prop types, TanStack Start inference collapsing into 30-something implicit any errors, and @react-pdf/renderer components refusing to be JSX. The root cause, dug out with tsc --traceResolution, is that a package’s realpath escapes into the global store, so the type-checker’s upward walk never finds the project’s @types (#450).
nub import converted bun lockfiles without running peer resolution, producing lockfiles the install path assumed were already peer-resolved. Result: Cannot find package 'vite' at runtime (#453).
Playwright’s default webServer teardown is SIGKILL, which no userspace signal forwarding can catch, so nub run wrappers orphaned dev servers and pinned a CI job for two hours (#463).
Cloudflare’s build image had no way to provision nub at all (#454).

From bug reports to commits#

I did not treat these issues as simple “found this, fix pls” reports. They were excuses to dive deeper into nub’s codebase, and they led to three PRs. #452 taught the phantom detector to see type-only imports inside Astro/Vue/Svelte components; the maintainer stacked two commits on top of my branch extending it to .d.ts surfaces and merged the lot. #464 arms PR_SET_PDEATHSIG on the script child so a SIGKILL on nub can no longer orphan the workload; merged untouched, kill-9 regression test and all. Both shipped in v0.4.12 within a day, at which point I got to delete every node-linker=hoisted workaround I had scattered across the fleet and verify zero type errors under full isolation. A third PR is still open, covering a related edge case. Nub maintainer Colin McDonnell and I happened to arrive at similar fixes independently and at roughly the same time.

For the Cloudflare gap I built asdf-nub, an asdf/mise plugin that installs the official release binaries. It has since been adopted into the nubjs org, and there is a request open with Cloudflare to support it natively.

Verdict#

Nub did not invent dependency isolation or the graph-addressed global virtual store. What sold me was its opinionated version of the idea: make machine-wide reuse the normal local path, build compatibility machinery around the places where that breaks, and do it while preserving the lockfiles already spread across my Bun and pnpm projects. I could use the filesystem model I wanted without first standardising every repository on the same package manager or asking collaborators to change their workflow. The stricter layout then exposed real mistakes in my projects, tests, and this site, but that was a useful consequence rather than the reason to switch.

I have gone far enough that the other package-manager commands in my shell are now aliases to nub. The repositories still keep their Bun or pnpm lockfiles; my muscle memory just no longer gets to choose the installer.

Yet another package manager. This one earned it.

Quality Is How You Move Fast

Thu, 16 Jul 2026 00:00:00 GMT

The recent dispute between Bun creator Jarred Sumner and Zig creator Andrew Kelley made me uncomfortable enough that I went back and updated an old post.

I had ended that post by saying I was “extremely bullish” on Bun. I wrote that its built-in server might eventually make us reach for frameworks like Hono and Elysia less often. I still use Bun in production, and much of what impressed me then still impresses me now. But I have also dealt with memory leaks in long-running Bun processes, along with surprise Railway bills. I upgraded Bun immediately, but the public discussion around its rewrite from Zig to Rust made me less willing to treat those incidents as version-specific bugs that were safely behind me.

Bun’s account of the rewrite is unusually candid about the memory leaks, use-after-free bugs, crashes, and other stability problems that motivated it. Kelley responded with a much harsher explanation: the problem was not Zig, he argued, but a culture that accumulated technical debt while racing from feature to feature. The exchange became personal, and I have no interest in refereeing the history between them. Both are far better systems programmers than I am.

What unsettled me was the engineering philosophy underneath the argument.

AI made an old trade-off cheaper#

The software industry’s fixation on speed did not arrive with LLMs. “Move fast and break things” predates ChatGPT by more than a decade. Startups have always raced to launch, disrupt a market, copy a competitor, or reach feature parity before the runway runs out.

LLMs did not create that instinct. They removed a great deal of the friction that used to constrain it.

If code is cheap to generate, why spend time making it maintainable? If an agent can rewrite the implementation tomorrow, why understand the one it produced today? If the test suite passes, why read a million-line diff?

Those questions sound new because the scale is new, but the values behind them are not. We have always had teams that treated code as disposable output and teams that treated it as a system somebody would have to understand later. Coding agents simply let both groups move faster in the direction they were already heading.

That is why the Bun rewrite is such a useful case study. Sumner describes using around 50 Claude workflows over 11 days to translate more than half a million lines of Zig into Rust.

A heatmap of 6,502 commits made over the 11-day Bun Rust migration, with a peak of 695 commits in one hour.

This was not a one-line “rewrite Bun” prompt: before the translation, Sumner worked with Claude to produce a detailed Zig-to-Rust porting guide that mapped types, lifetimes, naming conventions, and common idioms for the agents to follow. It is an extraordinary demonstration of what coding agents can do. It is also a million-line change that no human could review in the conventional sense. Bun instead relied on its test suite and adversarial review agents to establish confidence in the result.

A replay of Bun’s Claude Code migration workflow, showing 1,610 fix commits divided among 64 Claude agents across four worktrees.

Maybe that works. I genuinely hope it does. But passing tests and maintainable software are not the same property. Tests can show that the behaviours somebody anticipated still work. They cannot prove that the new implementation is understandable, that its abstractions will survive the next five years, or that the test suite covers the assumptions carried silently from the old code.

The rewrite changes the language. It does not automatically change the incentives that produced the original codebase. That does not mean Bun’s Rust codebase is necessarily bad. The porting guide, test suite, and adversarial reviews may have produced something excellent. It does mean that the primary goal of its creation was a fast, faithful translation, not the slow cultivation of an idiomatic Rust codebase that humans had reviewed line by line. That trade-off is acceptable for plenty of software. I am less certain about it in a runtime that may become the foundation underneath everything else an application does.

Bun is not alone in testing that boundary. Node.js core maintainer Matteo Collina opened a large, AI-assisted virtual file system pull request, disclosing that he had used a significant amount of Claude Code and personally reviewed every change. The implementation grew to around 9,200 lines, alongside more than 11,000 lines of tests, and the resulting debate caught even one of Node’s most experienced maintainers in a much larger argument about authorship, reviewability, and responsibility. Former Node core contributor Fedor Indutny responded with a petition to reject LLM-generated pull requests from Node core. The comparison makes the question harder, not easier: Node has mature governance and an experienced maintainer explicitly accepting responsibility for the code, yet the scale of AI-assisted work still strained the community’s idea of what meaningful review looks like.

And AI is not required for review and process to fail. Collina recently described triaging a Node.js vulnerability, writing the fix, and pushing it through the security process, only to conclude later that it should not have been a CVE at all—and that the fix had broken a large part of the ecosystem.

A post by Matteo Collina explaining that he triaged and fixed a Node.js vulnerability, but later concluded it should not have been a CVE and that the fix broke much of the ecosystem.

Michael Arnaldi highlighted two uncomfortable details from the aftermath:

A post by Michael Arnaldi with a graph arguing that AI increases the gap in skill between top and mid-level developers.

A post by Michael Arnaldi with a graph arguing that AI can increase mid-level developers’ confidence even as their relative skill falls.

The point is not that Collina is careless. It is almost the opposite: experience, tests, and an established security process still did not make the consequences obvious before the change shipped. AI increases the volume of decisions we can make, but it does not proportionally increase our ability to understand their consequences. A green test suite cannot be the whole definition of quality, because both humans and agents can optimize the evidence while missing what the software will do in the wider ecosystem.

Quality is not the opposite of speed#

We often talk about quality and speed as opposite ends of a slider. Move one up and the other must come down. That framing is convenient because it makes every shortcut sound like an explicit business decision: yes, we know this is messy, but right now we need velocity.

In my experience, the trade-off only works that cleanly over very short periods.

You can move quickly through an empty codebase. You can also move quickly through a codebase whose boundaries are clear, whose behaviour is tested, and whose previous authors left enough context for the next person. What slows a team down is the middle state: software that ships rapidly but makes every subsequent change more uncertain.

The pull request that skips an edge case saves an hour today. The missing test costs a day when somebody changes the same path six months later. The abstraction nobody understood was faster to generate than to design, until five features depend on it and every modification requires another workaround.

This is why the engineers who appear most preoccupied with quality are often the ones moving fastest over a meaningful span of time. They review the pull request. They ask what happens on the strange input. They remove ambiguity before it spreads. None of that looks fast while it is happening, because the time saved belongs to the future and is difficult to put in a sprint report.

Today, that scrutiny does not have to begin when a pull request reaches somebody else. It can happen while you build: iterating with an LLM, asking it to challenge the approach, inspecting its diff, and testing the assumptions together before the change leaves your machine. A later review still matters because a fresh context can see what the author and agent normalized along the way, but quality is stronger when it is part of the implementation loop rather than a gate at the end of it.

Quality, in this context, does not mean clever architecture or adherence to every fashionable best practice. It means maintainability: correct software that can continue changing without requiring its authors to rediscover the entire system each time.

The smallest useful habit#

I am not writing this from a position of purity. I have shipped plenty of software I would not want used as evidence of my engineering philosophy. I use coding agents every day, often aggressively. I like that they let me build more than I could before, and I am not interested in returning to an era where typing speed or tolerance for repetitive work determined what got made.

The lesson I take from all of this is not that generated code is bad, that Rust is better than Zig, or that moving quickly is irresponsible. It is that abundant implementation makes judgment more important, not less.

When producing another version is nearly free, the scarce work is deciding whether the version is good. Someone still has to understand the trade-offs, inspect the boundaries, question the happy path, and decide what the software should be able to survive. An agent can participate in all of that, but asking it to review its own output twice does not make those decisions disappear.

Linus Torvalds recently made a similar distinction from the maintainer’s side. Linux is not anti-AI; he considers the tool plainly useful. But its use should help maintainers rather than transfer more work onto them. That feels like the right standard. The question is not whether AI touched the code, but whether somebody understood the result, accepted responsibility for it, and left reviewers with something worth reviewing.

The smallest useful response is still code review. Read what your agents produce. Read what your colleagues produce. Ask the annoying question about the edge case. And follow the small code smells instead of automatically working around them. If a function name does not quite describe what the function does, find out why. Read the surrounding code, understand the current state of the system, and decide whether the mismatch is local or evidence of an abstraction that has drifted over time.

Leave things better than you found them. That advice used to come with a real risk: a thirty-minute change could trigger several days of refactoring before you were confident enough to ship it. Coding agents have made that investigative work much cheaper. You can trace callers, rename an unclear concept, update the tests, and verify the surrounding behaviour without immediately disappearing into the kind of refactoring loop that once made this instinct difficult to defend. That does not mean expanding every task into a rewrite. It means we have fewer excuses for preserving confusion when understanding and improving it is now so much faster.

Software has always rewarded speed, and that pressure has produced plenty of remarkable things. But once you have worked in the same system long enough, the relationship starts to look reversed: quality is not what you sacrifice to move fast. Quality is how you keep moving fast after the first release.

Relentless by Default

Wed, 17 Jun 2026 00:00:00 GMT

Simon Willison wrote up a debugging session with Claude Fable 5 that’s been rattling around in my head. He noticed a stray horizontal scrollbar in a chat input, took a screenshot, and gave the model one line: “Look at dependencies to help figure out why there is a horizontal scrollbar here.”

Then he walked away. When he came back, his machine was opening browser windows on its own.

Fable had built its own way to screenshot browser windows, enumerating every open window on macOS through pyobjc and grabbing PNGs with the screencapture CLI. It stood up a small Python web server with permissive CORS headers so a page could POST measurements back to disk. It edited Datasette’s own templates to inject JavaScript that fired the / keyboard shortcut on page load, just so the modal it needed to inspect would open by itself. Then it reached through a Web Component’s shadow DOM to read the computed styles it was after.

The fix, in the end, was two lines of CSS. The session cost about $12.

A comment I saw summed up a reaction I’ve seen a lot: this is evidence none of these models are actually intelligent, because any junior dev would have fixed it faster and with far less ceremony.

I think it shows the opposite.

Looking at what it actually did#

No junior developer would have actually chained that together. And it is not because these individual tricks are black magic. Grabbing screenshots of windows is something AltTab and DockDoor already do, so the technique is out there. Deriving the whole pipeline from a one-line prompt is the part that isn’t.

Artificial Analysis Intelligence Index bar chart with Claude Fable 5 ranked first at 64.9, just ahead of Claude Opus 4.8 at 61.4 and GPT-5.5 at 60.2.

This is not a dim model overreaching. Fable launched at the top of Artificial Analysis’ Intelligence Index, with Opus 4.8 (the model it later falls back to) the closest thing behind it.

Obviously, a senior who needed those computed styles would simply open DevTools. Fable built a web server instead.

That is not what unintelligent looks like, necessarily, but it is what intelligence with no sense of scale looks like, which is not necessarily a bad thing, if the goal is to get the job done quickly and efficiently. What is more expensive, the model or the human? More often than we admit, the answer is the human, which makes even an overzealous model the cheaper way to get the job done.

A ten-cent job, a twelve-dollar answer#

So the thing Fable is actually missing isn’t intelligence. It’s proportion, a sense of scale.

It threw an entire research project at a scrollbar. There’s no internal voice telling it that this is cheap, the stakes are low, so just stop digging. Proactivity cranked to eleven, with no instinct for when to ease off. Simon put it perfectly: Fable will “quite happily burn $12 in tokens inventing new ways to debug your CSS.”

But, to be fair, it worked. Fable found the bug, tested a fix, and verified it. Expensive and theatrical, sure, but correct.

And it’s that last part, the checking its own work, that I don’t want to skip past. Early on, you had to babysit these models into doing it. You’d end a prompt with “now write a test and actually run it,” or “are you sure? go back and double-check,” because left to themselves they’d hand you something plausible and call it done. Fable closed that loop on its own, unprompted. That’s a genuine shift in how much you can trust the thing: you can hand it a task, wander off like Simon did, and come back to an answer it has already tried to break itself. The same relentlessness that overshoots on a scrollbar is what makes it check its own work without being told, and honestly, I’ll take that trade most days.

Of course, the spending cuts both ways. For Anthropic, a model this eager sells more tokens today, and that suits the company doing the billing just fine. For the rest of us, $12 is nothing next to an hour of a senior engineer’s time, so maybe you genuinely don’t care. But a model that can’t tell a ten-cent job from a twelve-dollar one is also exactly what makes people call it dumb in the first place.

Artificial Analysis scatter of intelligence against blended price per million tokens. Claude Fable 5 sits alone on the far right near $7.70, while a green “most attractive quadrant” holds a cluster of nearly-as-capable models, including Claude Opus 4.8 at roughly half the price.

The proportion problem, drawn out. Fable is the lone dot stranded on the far right, paying frontier prices, while a whole quadrant of models gets you most of the intelligence for a fraction of the cost. Source: Artificial Analysis.

The industry is already building the governor#

And here’s the part I find most interesting. Somewhere in the middle of that session, Fable hit some invisible guardrail and quietly downgraded itself to Opus, a step down from where it started, which then picked up the full transcript and carried on to finish the job. That little switch is the tell. The platform, not me, decided which model was going to answer, did it mid-task, and never really asked. Nobody flipped a setting. It just happened.

And silent switching like that is exactly what a lot of people are furious about right now. Days after Fable launched, someone dug a paragraph out of its 319-page system card showing that the model will deliberately weaken its own answers when it decides you’re working on cutting-edge AI development, and do it without telling you. Not a refusal, not a visible “I’ve moved you to a smaller model,” just a quietly worse response you’d have no way of knowing was worse. Anthropic reckoned it touched around 0.03% of traffic. It didn’t matter. Fortune wrote it up, critics called it “secret sabotage,” and even researchers who usually defend Anthropic were appalled. Nathan Lambert, fresh from leading open-model work at AI2, said having his access to the frontier model “rug pulled in an under the table fashion” was “appalling,” and that it painted Anthropic as “anti-science.”

From a pure benchmarking point of view, the anger makes complete sense. If you don’t know which model actually ran, you can’t reproduce a result, you can’t compare two of them, you can’t even tell whether your prompt got worse or the model did. The platform knows exactly what changed; you’re left guessing. And paying for the top tier while quietly being handed something weaker isn’t routing, it’s just being shortchanged.

But step out of the benchmark mindset and into normal day-to-day usage, and there’s a point hiding underneath all this that I think gets lost. Most of what I actually ask these tools to do doesn’t need the absolute frontier model. If a cheaper one quietly finishes the job just as well, faster and for less money, have I really lost anything? Usually not. The benchmark crowd cares which model ran. The rest of us mostly care that the thing got done. Those are genuinely different requirements, and routing only curdles into a betrayal when it crosses from “right-sized the job” into “gave you less than you paid for, and hid it.” The fix was never to ban the routing. It’s to make it visible, which, to their credit, is roughly what Anthropic ended up doing within a couple of days, apologising that they’d “made the wrong tradeoff.”

And underneath all the Fable drama, plainer cost-driven routing is coming whether we like it or not. Two recent launches show that version of the idea handled in two very different ways.

Cursor’s Composer 2.5: the honest version#

Cursor’s Composer 2.5 is basically a bet on proportion as a product. The whole pitch is speed and cost. When it started powering Bugbot, the reviews got “over 3x faster,” “22% cheaper,” and caught about 10% more bugs per review. The model’s tuned to do one focused job quickly and cheaply, which is exactly what you want for the daily grind of code review and small edits.

Cursor is also pretty open about how it’s built: Composer starts from an open checkpoint, Moonshot’s Kimi K2.5, with a load of continued pretraining and reinforcement learning layered on top. When that got out, some people treated it as a bit of a gotcha. “Oh, it’s just Kimi.”

But that’s not the argument they think it is. Taking a strong open base and specialising it into a fast, cheap coding model is exactly the right move when proportion is the goal. You don’t need a frontier model’s full generality to go track down a CSS bug. Cursor took something already capable, narrowed it down, and made it cheap to run. If anything, the Kimi base is the most sensible thing about the whole approach.

GPT-5’s router: the cautionary version#

OpenAI tried the same idea, only at scale, and got badly burned on the framing. The GPT-5 launch in August 2025 replaced the model picker with an automatic router that decided, per prompt, which model should answer you. Then on launch day the autoswitcher broke. Altman himself admitted GPT-5 “seemed way dumber” and that OpenAI had “totally screwed up some things on the rollout.” People were convinced their prompts were being quietly shunted off to weaker, cheaper models, and whether or not that was the intent, that’s exactly how it landed. OpenAI walked it back fast: GPT-4o came back for paying users, the explicit Auto / Fast / Thinking controls showed up, and the company promised to be clearer about which model was actually answering.

OpenAI’s GPT-5 launch chart for SWE-bench Verified, in which the 52.8% bar for GPT-5 without thinking is drawn taller than the 69.1% bar for OpenAI o3, and GPT-4o’s 30.8% bar is nearly as tall as o3’s.

It did not help that the launch itself shipped the now-infamous “chart crime”: GPT-5’s 52.8 drawn taller than o3’s 69.1. Source: OpenAI’s GPT-5 livestream, via TechCrunch.

And it’s the same underlying mechanism as Fable’s silent switch to Opus, automatic and per-prompt, only here it landed the complete opposite way. The routing itself was never really the problem. Not being able to see it happen was. On a product you’re paying for, an invisible downgrade just reads as a breach of trust rather than a feature.

Where this should go next#

Which all brings me to what I actually want out of these tools.

Claude Code’s heavier modes, the ultracode-style “fan out a swarm of agents and be exhaustive” workflows, are genuinely great when the task is big. But they tend to run the whole fleet at a single tier. And a lot of what those agents do is just legwork: grepping the codebase, summarising a file, checking a single claim. That’s not frontier-model work. You’d want the cheap, fast model doing the legwork and the expensive one held back for the synthesis and the genuinely hard reasoning.

The primitive for this already exists. Workflows let you set the model per agent. What’s missing is a sensible default policy that does the routing for you, so the small, parallel, low-stakes subtasks go to the cheap model and the hard, central reasoning stays on the expensive one. That’s just proportion, productised. The governor, built in.

So, not a failure#

So no, I don’t read the Fable story as proof the model is dumb. I read it as a model that’s relentless by default, pointed at a problem far too small for it, with nothing yet in place to throttle it back down.

Point that same relentlessness at a large, genuinely ambiguous problem with no obvious path, and it’s suddenly exactly the trait you want. The skill now isn’t really about getting the model to be smarter. It’s about matching the model to the size of the job, and, increasingly, about deciding how much you trust the platform to quietly make that match for you.

Just make the routing something I can actually see. I’d much rather pick the right tool myself than find out, after the fact, that one quietly got picked for me.

Update — 17 June

I spent this whole post on who gets to decide which model you run: the model, the platform, a router. I missed a candidate. On 12 June, three days after Fable went public, the US government issued an export-control directive citing national security, and Anthropic disabled Fable 5 and Mythos 5 for everyone within roughly ninety minutes. The directive technically only bars foreign nationals, but since nobody can check your nationality mid-prompt, every customer lost access. The reported trigger was a claimed jailbreak that unlocked the vulnerability-finding skill Anthropic had once called too dangerous to ship, though Anthropic says the technique only surfaced minor, already-known bugs that other public models find anyway.

It’s meant to be temporary, and Anthropic says it’s working to restore access. But for now the relentless model isn’t quietly downgrading itself to Opus. It’s just gone, and this time not one of us got a say.

The Accidental Homelab

Tue, 05 May 2026 00:00:00 GMT

In 2016, as a university student, I installed Plex on my gaming desktop and started serving local media off it. The desktop was an i7-4770K with a GTX 770, the first PC I’d built myself, back in 2013 at 15. Nine years later, that same Plex install has grown into a TrueNAS server running ~30 self-hosted apps, ~40 TiB of usable storage on a raidz2 pool (with a story behind that number, see below), and serving roughly 20 people across a few countries. None of it was planned. Every step came after the previous one started to break, and was paid for whenever the budget caught up.

Before Plex (2010–2016)#

I’d been torrenting since 2010. I was twelve, uTorrent was the client, and the workflow was strictly manual: pick the show or movie I wanted, search for it, find a healthy seed, download, watch. The uTorrent download folder was my entire media library. Half of it was things I’d already watched, half was things I was queuing up for the weekend, and the only “library management” was my own memory plus a TV Show Time account that kept track of which episode of which show I was up to.

This was the KickassTorrents era, and KAT was awesome - moderators, comment threads on every release, a community that would flag bad rips and call out fakes. The site got taken offline in a US-led operation in 2016, and the gap eventually got filled, for me at least, by private trackers, where ratios are enforced and quality gets policed much more directly. Tens of terabytes of seeding later, I’m still on the same ones.

Plex, when I found it in 2016, was the abstraction I’d been missing. It turned that flat folder of files into something I could actually browse - metadata, posters, subtitles, watch progress - and, more importantly, share with people who weren’t going to learn what .mkv meant.

The Gaming-Rig Era (2016–2020)#

The first version was the laziest possible setup: Plex on my main Windows desktop, drives merged with Windows’ built-in Storage Spaces so 2×1TB + 1×4TB looked like a single mount point, port-forward so a couple of family members could stream from outside. The “server” was whatever happened to be on the gaming PC at the time. I held out on Plex Pass until 2018, when I caught one of their 50%-off lifetime sales - still easily the best money I’ve ever spent on this whole project.

It worked exactly as well as you’d expect. Plex transcoding is CPU-bound, gaming is GPU-bound, but they both fight for memory bandwidth and disk IO. Three people watching from outside the house on shaky connections, and my gaming session noticed. I could pause my game, kick people, or accept that nobody’s experience was going to be great. But to be honest, this did not happen that often back then.

The i7-4770K as Always-On Server (2020–2023)#

In 2020, with my first salary out of university, I bought a new gaming desktop - Ryzen 9 5900X, RTX 2060 Super - and “retired” the i7-4770K. Retired meaning “moved to a corner with the drives still attached and never turned off again.” First time the home server became a separate machine from my gaming PC.

The stack matured a bit. Sonarr and Radarr came online (or maybe before, not entirely sure when I brought these on); access to a couple of decent private trackers and a few reliable public ones meant new media just showed up without me babysitting it. Parsec gave me remote access. Overseerr arrived later and took requests off my hands - friends and family could ask for content directly (I did share *arr access for a bit before this).

This is also when the user count grew past family, and transcoding got real. Three concurrent remote streams on the 4770K’s iGPU was the limit. I never wanted to disable transcoding entirely (some people had genuinely bad upstream connections), but the 4770K just didn’t have the headroom.

The whole thing was still on Windows. NTFS had a lot of data on it; a clean Linux migration was always “next year.” I knew Storage Spaces would haunt me eventually, but it kept working. Should I have just shipped the whole library to S3 and dealt with the migration cold? Probably. But moving 8 TB of Linux ISOs to a cloud bucket on a non-fiber upload is a project of its own (to be fair, we did eventually get fiber a year or two later).

In 2021 I bought my first 18 TB drive. Single drive, no redundancy, “I’ll figure out RAID later.” That made the eventual migration even more daunting with even more Linux ISOs to migrate!

The 2023 Reset#

By 2023 the smell was real. I wanted out of Windows, I wanted real ZFS, and I wanted a server that wasn’t living in fear of a Windows Update at 03. I also didn’t want to take the existing setup down while building the new one - there were ~16 people relying on this thing by then, and “your media is broken for two weeks” wasn’t something I wanted to do to anyone.

So I bought a used PC from a local secondhand site: Ryzen 7 5800X, RTX 3080, 64 GB of RAM. The point of the deal wasn’t the 5800X - it was the GPU and the memory. I swapped both into the 5900X gaming rig (which got a meaningful upgrade for almost nothing), stripped the used box down to CPU + motherboard + chassis, and stood it up next to the running 4770K as the new server. Built the new platform fully, copied data across, swapped people over. User-facing downtime was a few hours.

Why TrueNAS (and Not Unraid or Proxmox)#

Most homelab content for media servers points at Unraid: mixed disk sizes, single parity, paid license, very forgiving of “I bought one drive at a time over four years.” For someone whose drive collection grew organically - like mine had - Unraid is the obvious answer.

I went with TrueNAS Community Edition (formerly TrueNAS Scale) for three reasons.

ZFS is first-class. Unraid only added real ZFS support recently, and even then its core array layer is XFS-per-disk with parity. ZFS gives me snapshots, scrubs, send/recv, end-to-end checksums, and a pool layer I trust. After a year of running this I’ve caught zero silent bit-rot, but it’s the kind of thing you only know is working because nothing’s gone wrong.

All same-size disks anyway. My organic-growth phase ended in 2021. Going forward I knew I’d buy 18 TB drives until I died - they sit at the sweet spot for €/TB. Once you commit to one drive size, Unraid’s flexibility advantage evaporates and ZFS’s rigidity stops mattering.

The apps platform. TrueNAS’s built-in app catalog runs containers as first-class objects on the host, with iXVolumes (ZFS-backed) for app state. I don’t need a separate Proxmox + LXC + manual ZFS layer. One UI, one auth, one upgrade flow.

If you have ten differently-sized drives accumulated over a decade, get Unraid. If you’re starting fresh and willing to commit to one size, get TrueNAS. I did wipe my old non-18TB drives and sold them, by the way.

The Present: 5×18TB raidz2, ~30 Apps, 16 People#

Today the pool is five 18 TB Seagate IronWolf Pros in a single raidz2 vdev: two-disk redundancy, ~40 TiB usable today (currently ~79% full), with about 7 TiB stuck behind a legacy parity layout that I only noticed while writing this post - more on that further down. Single-vdev is fine here because the IOPS-sensitive apps run on a separate pool - ZFS scales IOPS per vdev, so a 5-disk raidz2 has the random-read throughput of roughly one disk, which doesn’t matter for sequential media streaming. Most of the drives came from ServerPartDeals, a recertified-disk shop that ships enterprise drives at a meaningful discount over new. Worked out at roughly half of new-IronWolf-Pro pricing, the trade-off being that the 5-year warranty runs from manufacture date rather than purchase date.

The host is on a UPS that easily handles half an hour of operation. Nothing’s port-forwarded anymore: family-facing apps come in through a Cloudflare Tunnel at *.afonsojramos.me (no exposed home IP, TLS handled at the edge), and everything admin - the *arrs, qBittorrent, dashboards, the lot - stays behind Tailscale. Two access tiers, one running it, the other consuming it. The stack, in rough shape:

storage: 5×18TB raidz2 plus a separate apps pool for fast app state
media: Plex (1,400+ movies, 21 TB of TV, 874 GB of music), Jellyfin alongside it for redundancy (and external downloads, since the Plex Pass only allows Home User downloads), Tautulli for stats, Maintainerr for retention rules
photos: Immich
cloud: Seafile, plus Filebrowser and SMB shares for the unencrypted stuff
auth: Authentik fronts SSO across the public apps and gates the admin tools behind a homelab-admins group; Wizarr at invite.afonsojramos.me is the family onboarding door, bootstrapping both Plex and Jellyfin from a single invite
plumbing: Sonarr, Radarr, Bazarr, Overseerr, qBittorrent, Dockge, Glance, plus a handful of custom Dockge stacks for things the catalog doesn’t ship

Grafana dashboard showing 83 running containers across the homelab at 0.481 CPU cores and 16.3 GiB of memory, with zero restarts and per-service CPU, memory, network, and restart breakdowns.

The Drive Failure (Which Is Why raidz2)#

A few weeks ago, Scrutiny - the SMART dashboard I have watching the pool - lit up with UNC errors against /dev/sdd, one of the recertified IronWolf Pros (8,682 power-on hours, roughly a year of always-on, 18 TB), and a failed extended self-test soon after. It’s still online, but the pool reports READ=1 against it. The drive is firmly dying.

This is why raidz2 exists. With raidz1 (single-disk redundancy) you can lose another disk during a 4–6 day resilver window, which is a real risk: large drives mean long resilvers, the resilver itself stresses the remaining disks, and those remaining disks are also a year old and also from the same recertified batch. With raidz2 I can lose this one and another during the resilver and still be fine. The math on a five-disk pool of 18 TB drives wants two parity disks.

The drive came from ServerPartDeals; the RMA paperwork is in flight. The vdev still has both parity disks intact while I’m waiting on it, so the cost so far is “wait and watch.” And I’ve also ordered a new drive, which I’ll add to the pool once it arrives.

What Writing This Post Turned Up#

When I expanded this pool from 4-wide to 5-wide raidz2 with a zpool attach almost a year ago, I did the napkin math for the new geometry - 5×18 TB raidz2, ~49 TiB raw, ~44 TiB usable after ZFS overhead - and then never went back to check whether the running pool actually matched. The number sat in my head as fact for almost a year. Writing this section was the first time I’d looked at it again, and it turns out that that is not what I’ve been looking at at all.

I am currently getting ~40 TiB total, ~4 TiB short of the number I’d been carrying around since the expansion. Turns out that OpenZFS raidz expansion has a footnote I’d glossed over: it only changes the layout for new writes. Records already on disk keep their pre-expansion parity ratio forever. 4-wide raidz2 is 50% parity (2 of 4 disks); 5-wide is 40% (2 of 5). Everything written before the expansion still pays the 4-wide rate, and nothing in zpool or zfs will restripe existing records - not scrub, not resilver, not property changes. I had, honestly, assumed that that would be done in the expansion process, but it turns out that the only fix is to rewrite the data so ZFS reallocates it under the current geometry.

The tool for that is markusressel/zfs-inplace-rebalancing.sh: walks the dataset, copies each file to a sibling tempfile (no --reflink, so it’s a real fresh write), verifies size and checksum, atomic mv back over the original. Resumable across runs. Napkin math says I should reclaim about 7 TiB on ~36 TB of pre-expansion media - 36 × (1 − 40/50) = 7.2 - which would push the pool back past the ~44 TiB I’d always had in my head.

The catch: it’s a multi-day full-pool I/O storm, and /dev/sdd is exactly the wrong disk to be running it against. After replacing it I’ll need to resilver, scrub, and only then rebalance.

The takeaway, if you’re starting fresh: zpool attach raidz expansion is a one-shot operation you should plan around, not a casual capacity-add. Either commit to a rebalance pass after every expansion, or grow the pool by replacing all five disks one-by-one with larger ones (autoexpand=on), which keeps the geometry constant and avoids the legacy-tier problem entirely. Given /dev/sdd is going RMA anyway, the replacement could itself be the first 20 TB drive in a gradual disk-size upgrade - no parity-ratio drift, no rebalance debt, just bigger drives over time.

Edit — 29 May 2026

I did all of the above, and it worked. The replacement drive turned out to be a Toshiba MG09 18 TB rather than a 20 TB - a same-size swap, but it breaks up the all-Seagate, all-same-batch monoculture, which is good in my books. It was also a drive that had a good reputation in Backblaze’s reports.

zpool replace resilvered in 39 hours at full redundancy (online replace - the failing disk stayed in the array the whole time, so parity never dropped to raidz1), a verification scrub came back clean, and then I let the rebalance run. It took 9.5 days for ~32 TB - I’d budgeted 3-5, and the estimate was about half what it should’ve been, because the cost is per-file cp/verify overhead, not throughput: a 30 GB remux and a 2 KB .nfo each pay the same fixed tax, and the TV library alone is 31,000 files. In total, it reclaimed 5.2 TiB (the pool went from 82% to 75% full), a bit under the 7.2 I’d predicted because a chunk of the library was written after the expansion and was already on the efficient layout. Two gotchas worth flagging if you try this on TrueNAS: the rebalance script’s cp -ax dies instantly on datasets with aclmode=restricted (flip it to passthrough for the run), and any snapshot predating the rebalance pins the old-layout blocks so the pool grows as you go - I had to drop five stale snapshots mid-run to avoid filling the pool before it could shrink. The honest verdict: the rebalance is the rare homelab chore that delivers exactly what the napkin math promises.

No Regrets#

Looking back, I don’t really have any. Self-hosting in 2016 was a much lonelier hobby than it is in 2026. No /r/selfhosted at its current size, no Tailscale, no TrueNAS Community Edition, no recertified-drive economy you could trust at scale, and homelab content on YouTube was a tiny fraction of what it is today. Most of what looks obvious in 2026 had to be figured out from scratch back then, and a lot of the choices that look “wrong” in retrospect were the only realistic option at the time.

The hurdles were also good for me. Storage Spaces taught me what I wanted from a real filesystem. Running Plex on my gaming PC taught me why isolation matters. The Windows years taught me what I was willing to pay for in operational simplicity. None of that would have landed the same way if I’d been handed today’s tooling on day one.

A few opinions that have held up, regardless of when you start:

Storage Spaces is fine until it isn’t. Use it, then leave it before your library makes the migration scary.
Don’t run Plex on your gaming PC. The moment your library has more than a couple of viewers, it deserves its own machine.
Recertified enterprise drives are great once you trust the supplier. ServerPartDeals’ IronWolf Pros land at roughly half the price of new for the warranty trade-off.
Pay for Plex Pass when it goes on sale. The 50%-off lifetime promos come around. Best deal in self-hosting. (Edit (29 May 2026): turns out, this was an even better deal than I thought, since from July 2026, Plex Pass will be available for 750$)

The thing the homelab guides on YouTube don’t tell you is that it never actually starts as a homelab. It starts as one Plex install on whatever’s nearest, and a few years later you catch yourself reading about ECC memory on a Sunday afternoon.

The Abstraction Imperative: Why Framework-Defined Infrastructure is the Next Step in Software Evolution

Sat, 22 Nov 2025 00:00:00 GMT

Every major leap in software development has followed the same pattern: we abstract away complexity that no longer needs manual attention. Framework-defined infrastructure is not merely another deployment strategy; it is the logical continuation of a decades-long trajectory allowing developers to focus on the problem, not the plumbing. At no point in this blog post will I argue that we don’t need plumbers. Instead, I will argue that we should worry less about plumbing by trusting well-tested abstractions that others have carefully refined over time.

The History of Software is the History of Abstraction#

In the 1950s, programmers wrote in machine code, toggling switches to represent binary instructions. Assembly language abstracted machine code. High-level languages like C abstracted assembly. Garbage collection abstracted memory management. Virtual machines abstracted operating systems. Cloud computing abstracted physical hardware.

Each abstraction faced resistance. “Real programmers” supposedly needed direct memory access. Garbage collection was “too slow” for serious applications. Virtual machines added “unnecessary overhead.” Cloud computing meant “losing control.”

In each case, the abstraction became dominant, though not universal. Not because it was perfect, but because it let most developers solve most problems at a higher level. Assembly still exists for embedded systems, manual memory management remains critical for certain performance-sensitive applications, and some organizations still run their own data centers. The question was never whether to abstract completely, but when the abstraction became good enough to trust for the majority of use cases.

Where We Are Now: The Infrastructure Abstraction Gap#

Modern application development has reached an inflection point. We’ve abstracted nearly everything about software except how we deploy it.

The move to web applications itself represents a massive abstraction, instead of writing platform-specific native code for Windows, macOS, Linux, iOS, and Android, developers write once for the browser and let the browser handle platform differences. APIs and microservices abstracted monolithic architectures. Containerization abstracted runtime environments. The pattern is consistent: each generation removes another layer of manual platform-specific work.

Yet deployment remains stubbornly manual. We’ve moved beyond FTPing files to servers, yes, but consider a typical web application today. Developers write code using framework conventions, routes, components, server functions, middleware. But when deployment time comes, they must translate these high-level concepts into low-level infrastructure primitives: Lambda functions, API Gateways, load balancers, CDN configurations, caching layers.

This translation layer is where things break down. As the evolution of Platform as a Service (PaaS) has shown, the progression from bare metal to virtualized infrastructure represents “the evolutionary nature” of modern software. Yet even with traditional PaaS offerings, developers still face somewhat of a gap between application code and infra configuration.

With traditional Infrastructure as Code (IaC) approaches, you write a server-side rendering function in your framework, then spend hours configuring the serverless function, its memory limits, timeout settings, IAM roles, and API Gateway integration. The gap between framework concept and infrastructure primitive remains stubbornly manual. Terraform fatigue is real.

Framework-Defined Infrastructure Closes the Gap#

Framework-defined infrastructure eliminates this translation layer by making the framework itself the interface for infrastructure decisions. As Vercel describes it, “the deployment environment automatically provisions infrastructure derived from the framework and the applications written in it.” The platform reads your framework code and provisions infrastructure automatically based on what it understands your code needs.

This isn’t an entirely new concept. In fact, the roots trace back to 2006 when Zimki introduced what Simon Wardley called “framework-as-a-service”, a fascinating early attempt that could have made Canon one of the first major cloud providers before the industry settled on the term Platform as a Service. Though Zimki ultimately closed, Heroku launched in 2007 and successfully commercialized this vision with their mantra that developers should “focus on what they do best: building great apps” while the platform handles infrastructure. Heroku’s architecture was designed to remove obstacles so developers can focus on building rather than managing servers.

Similarly, Netlify popularized the JAMstack architecture, a term coined by CEO Mathias Biilmann, which emphasizes prerendering content and deploying directly to the edge. As Netlify explains, their approach is fundamentally about “abstraction and simplicity”, where build automation understands framework patterns and automatically optimizes deployments.

The framework conventions themselves become infrastructure declarations:

When you export getServerSideProps in Next.js, you’re declaring that route needs server-side compute
When you set output: 'server' in Astro, you’re declaring the entire site needs SSR capabilities
When you create a +page.server.ts in SvelteKit, you’re declaring that route requires server-side data loading
When you use export const prerender = false in SolidStart, you’re opting that route into dynamic rendering

The framework has already made the infrastructure decision, it just needs a platform that understands it. This isn’t magic. It’s pattern recognition applied to infrastructure. Frameworks impose structure and conventions specifically to make code predictable and understandable. Framework-defined infrastructure leverages that predictability to automate infrastructure provisioning the same way frameworks automate application structure.

Why This Matters Beyond Any Single Platform#

The power of framework-defined infrastructure isn’t tied to any particular deployment platform. Multiple platforms, Vercel, Netlify, Cloudflare Pages, AWS Amplify, Azure Static Web Apps, have independently converged on the same insight: let the framework define infrastructure needs. Though implementations vary in how much configurability they expose, the core principle remains consistent.

This convergence validates the abstraction. Just as multiple operating systems implement virtual memory and multiple languages implement garbage collection, multiple platforms implementing framework-defined infrastructure proves the concept has staying power.

As Vercel notes in their piece on avoiding vendor lock-in, “Framework conventions like the Next.js App Router, Remix loaders, SvelteKit endpoints, and Nitro storage adapters work differently. You build against the framework, not the platform. Multiple platforms can run the same framework code, keeping your application portable across any infrastructure that supports it.”

The competitive advantage shifts from proprietary primitives to better implementations of the same abstraction. Platforms compete on performance, developer experience, observability, and pricing, not on lock-in. In fact, approximately 70% of Next.js applications run outside of Vercel, with companies like Walmart, Nike, and Claude.ai self-hosting at massive scale.

There are legitimate concerns about vendor lock-in when platforms handle multiple aspects of your stack. As one developer notes, “when one provider handles your hosting, manages automated deployment, runs a few dozen micro-services and serverless APIs, provides your database through their proprietary API, and more, migrating away to somewhere else becomes very expensive.” But framework-defined infrastructure actually addresses this concern by keeping the abstraction layer in the open-source framework, not in proprietary platform APIs.

The Developer Experience Transformation#

The real benefit surfaces in daily development work. With framework-defined infrastructure, your local development environment matches production behavior because both run the same framework code. There’s no simulation layer, no mocked services, no “works on my machine” debugging.

As Vercel explains, platforms built on vendor primitives need complex simulators for local development, Cloudflare provides Wrangler to simulate Workers locally, AWS developers use LocalStack or SAM CLI to mock Lambda and other services. These tools approximate production behavior but never match it exactly.

This echoes Heroku’s original insight: by abstracting away the underlying infrastructure, developers “don’t have to worry about anything except for application logic.” With framework-defined infrastructure, you test your application by running next dev or remix dev, the standard framework tooling. What you see locally is what runs in production because the framework, not the platform, defines the behavior.

This eliminates an entire class of problems. You don’t need to maintain separate local development simulators like LocalStack or Wrangler. You don’t need to keep IaC configurations in sync with application changes. You don’t need platform-specific tooling that only half-works on your operating system.

Tools like SST represent an interesting middle ground—they use framework conventions to generate IaC (CloudFormation/Terraform) rather than bypassing it entirely. This hybrid approach still requires maintaining infrastructure code, but reduces the manual translation burden by inferring infrastructure needs from your application code.

Abstraction Enables Specialization#

Critics worry that abstraction means losing control. But abstraction doesn’t eliminate control, it enables specialization.

When you write a Next.js application, you’re not locked out of infrastructure. You can still deploy to EC2 and manage every detail if needed. Companies like Walmart and Nike do exactly this at massive scale. The difference is that you can also choose not to, letting platforms that specialize in infrastructure handle those concerns while you specialize in your product.

This is how every successful abstraction works. You can still write assembly if you need to, but most developers rightfully choose to write in higher-level languages and let the compiler handle optimization. You can still manage memory manually, but most developers let garbage collection handle it. You can still provision servers, but most developers let cloud platforms handle it.

As the evolution of cloud computing shows, PaaS sits between IaaS and SaaS specifically to “abstract infrastructure complexities, allowing developers to focus on building and innovating.” Framework-defined infrastructure extends this progression. You can still configure infrastructure manually if you need to, but most developers can let the framework and platform handle it automatically.

The Economics of Abstraction#

Abstractions succeed when the economic value of simplification exceeds the cost of flexibility lost. Framework-defined infrastructure passes this test decisively.

Consider the engineering cost of a typical deployment:

Writing and maintaining IaC configurations
Keeping infrastructure in sync with application changes
Managing environment differences between development and production
Training new team members on platform-specific tooling
Debugging issues caused by misconfiguration

Now consider the alternative: writing framework code that automatically deploys correctly. As Vercel found when studying high-impact web teams, “when developers control their entire workflow, teams previously balancing both hardware and software can focus solely on the strategic aspects of product delivery. Conversations shift from ‘how’ and ‘if’ to ‘what’ and ‘when,’ as infrastructure is no longer an obstacle to launching products.”

The reduction in cognitive load, time spent, and error rate represents genuine economic value. A Forrester Total Economic Impact report found that teams using framework-defined infrastructure saw higher customer conversion rates generating $2.6 million in incremental profits and higher website traffic generating $7.7 million in incremental profits.

Netlify’s experience with the JAMstack architecture demonstrates similar benefits. By automating the build and deploy process, platforms ensure “code can be shipped with little to no opportunity for error,” while the architecture itself is “designed to scale only when needed” rather than requiring premature optimization.

Some applications have special requirements that framework-defined infrastructure doesn’t handle well. That’s fine. Those applications can opt out and configure infrastructure manually. But for the majority of web applications, the standard patterns that frameworks encode work perfectly, and automating their infrastructure deployment makes obvious economic sense.

What This Means for the Industry#

Framework-defined infrastructure represents a maturation of the platform-as-a-service model. Early PaaS offerings like Heroku abstracted infrastructure but required you to build against their specific deployment model. Modern framework-defined infrastructure abstracts infrastructure while letting you build against open source frameworks.

This distinction matters. When the abstraction layer is proprietary, adoption requires trust in a single vendor. When the abstraction layer is an open source framework, adoption requires trust in the broader ecosystem. The latter scales better.

This is reflected in what Vercel calls their Open SDK strategy: “We want what we build to work extremely well on Vercel, but not at the cost of lock-in… We will build first on Vercel, where we can iterate fastest to ensure the best end-to-end developer and user experience. And as we become confident projects are mature, we’ll invest in ensuring our SDKs and tools are deployable to any platform.”

Similarly, Netlify and Cloudflare have come together to support open frameworks like TanStack and Astro, recognizing that “a rising tide lifts all boats.” As they note, “the strongest projects emerge when multiple organizations align behind shared goals, giving developers the broadest opportunities for success.”

We should expect framework-defined infrastructure to become the default deployment model for framework-based applications, just as cloud computing became the default infrastructure model for most applications. Some organizations will continue self-hosting and managing infrastructure directly, just as some organizations still run their own data centers. But the center of gravity will shift.

The Evolution Continues#

The pattern is already extending beyond basic deployment. Vercel’s recent introduction of their Workflow Development Kit shows how framework-defined infrastructure concepts apply to durability and long-running processes: “Functions can pause for minutes or months, survive deployments and crashes, and resume exactly where they stopped.” Rather than manually configuring message queues and retry logic, developers write standard async functions with durability directives, and the platform handles persistence automatically.

Similarly, their self-driving infrastructure initiative explores how production data can inform infrastructure optimization: “Code defines infrastructure, production informs code, and infrastructure adapts automatically.” This closes the loop between application behavior and resource allocation without requiring manual intervention.

Vercel’s approach to application-aware routing demonstrates how deeply framework understanding can integrate with infrastructure: “Vercel uses your framework code to define infrastructure and how requests are handled at runtime. This tight integration gives the platform full visibility into your app’s structure: routes, layouts, rewrites, middleware, functions, static assets, and routing logic.”

Conclusion: Abstraction is Inevitable#

Software development has always moved toward better abstractions. We abstract when the benefits of simplicity outweigh the costs of lost control, when patterns emerge that are stable enough to codify, when the manual work no longer creates competitive advantage.

Framework-defined infrastructure meets all these criteria. The patterns are stable, server-side rendering, static generation, API routes, and edge middleware aren’t going anywhere. The manual work, translating framework concepts to infrastructure primitives, creates no competitive advantage. The simplification, automatic infrastructure from framework code, delivers real value.

As Heroku’s evolution demonstrates, “ever-increasing complexity means developers need to build and operate more adaptable systems.” Framework-defined infrastructure represents exactly this kind of adaptability: composing infrastructure from framework patterns rather than manual configuration.

The question isn’t whether framework-defined infrastructure will become standard practice, but how quickly it will happen. Given that multiple platforms have independently adopted similar approaches, given that major companies successfully deploy framework-based applications across different infrastructure models, and given the clear economic benefits, the trajectory seems clear.

Abstractions that work become invisible. In a few years, explaining that you used to manually configure infrastructure for every framework route will sound as strange as explaining that you used to manually manage memory allocation. We’ll wonder why we ever did it differently.

How to Sync Apple Reminders with Android (When You're Hooked on the Menubar)

Tue, 23 Sep 2025 00:00:00 GMT

If you’re like me and have discovered reminders-menubar, you know exactly why leaving Apple Reminders isn’t an option. This open-source menubar app transforms Apple’s basic reminder system into something genuinely great - instant access with a keyboard shortcut, natural language input, and that satisfying feeling of capturing tasks without breaking your flow. And I’ve looked at other options, but nothing else comes close to the seamlessness of reminders-menubar on macOS, even if you’re willing to pay (and I’m not).

The problem? I also use an Android phone. And Apple Reminders doesn’t exactly play nice outside the walled garden.

So here’s my situation: I’m completely sold on the workflow that reminders-menubar provides on my Mac. It’s become part of how I think about task management - quick capture, always visible and with number that I hold myself accountable to. But when I pick up my Android phone, those reminders might as well not exist, or I might need to mimic them in another app - which was Google Keep for a while, but I kept forgetting to check it.

Fair warning, the solution I’m about to share isn’t perfect, as it does involve having a middleman, Microsoft, but after you try the reminders-menubar workflow, I’m pretty confident you’ll embrace it, like I have, as this is currently your best option when needing Android access.

Why Reminders-Menubar Changes Everything#

But before we dive into the Android sync solution, let me explain why I’m going through this trouble instead of just switching to multi-platform tool such as Todoist or TickTick.

Reminders-menubar is a lightweight menubar Mac app that expands on Apple Reminders by gives you instant access to it through the menubar, or a quick keyboard shortcut. No opening apps, no clicking through menus, no friction.

The magic is that it uses Apple’s native EventKit framework, so everything syncs perfectly with iCloud. Your reminders appear instantly on your iPhone, iPad, and Apple Watch (even if in my case I only have my Mac). At the end of the day, it’s free, it’s fast, and it just works. Which is exactly why I don’t want to give it up just so I can have the same ToDos on my phone. I tend to avoid paid subscriptions when free alternatives exist, even if they aren’t quite as polished and require a bit more tinkering.

The Microsoft Bridge Solution#

Here’s the workaround: it is actually quite simple, we’re going to use Microsoft’s ecosystem to bridge Apple and Android. Microsoft Outlook can sync with Apple Reminders on iOS, and Microsoft To Do can access those same reminders on Android. Plus Microsoft To Do has a pretty nice widget.

Setting It Up#

The setup is surprisingly straightforward, even if the underlying architecture feels a bit convoluted.

macOS Setup#

First, we need to configure your Mac to sync Apple Reminders with Microsoft:

Open macOS System Settings → Internet Accounts
Add your Microsoft account if it’s not already there
Make sure “Reminders” is checked in the account services
That’s it! Nothing else to configure here.

iOS Setup#

On your iPhone or iPad:

Open iOS Settings → Apps → Reminders
Tap Reminders Accounts → Add Account
Add your Microsoft Outlook account
Ensure the “Reminders” toggle is ON
That’s it! Nothing else to configure here.

This creates the bridge so that reminders created through reminders-menubar (or the native Reminders app) sync to Microsoft’s servers.

On Your Android Device#

Install Microsoft To Do from the Play Store and sign in with the same Microsoft account. That’s it. Your reminders should start appearing shortly. And since you’re using Microsoft To Do, you can actually use other platforms that integrate with it, such as Samsung’s native Reminder app.

The Only Downside Is Actually An Upside#

Here’s the one quirk you should know about: when a reminder’s alarm fires, it rings on BOTH devices. And dismissing it on one device doesn’t dismiss it on the other.

Set a reminder for 3 PM, and at 3 PM both your iPhone and Android buzz. Dismiss it on Android, and your iPhone keeps nagging. This is particularly noticeable with recurring reminders (not that I have daily reminders that bug me on multiple devices simultaneously 🫣, but still).

This happens because each platform maintains its own notification state. The reminder data syncs perfectly, but the “I’ve handled this” status doesn’t.

But here’s the thing - I’ve actually started to appreciate this “bug” as a feature. It’s pretty hard to miss an important reminder when two devices are insisting you pay attention to it. Now, I hear you, notifications can be annoying. But for truly important deadlines or time-sensitive tasks, having that redundant notification system isn’t the worst thing in the world - we’re talking about reminders, after all.

The Bigger Picture#

What strikes me about this whole situation is how it highlights the state of cross-platform compatibility in 2025. We’re still using workarounds and compromises to make basic productivity tools work across ecosystems.

Apple’s walled garden provides genuine benefits - the integration really is excellent when you stay inside it. But it punishes flexibility. The fact that a free, open-source Mac app (reminders-menubar) can make Apple’s basic reminder system more compelling than premium cross-platform alternatives says something about the value of deep platform integration, as well as the imense capabilities of open-source software.

Microsoft, ironically, has positioned themselves as the peace broker by building quality apps on both platforms and enabling sync between them. For now, if you need Apple Reminders on Android like me - especially if reminders-menubar is part of why you’re committed to Apple’s ecosystem - this Microsoft bridge approach is your best bet.

Is it elegant? No. Does it preserve the workflow that makes reminders-menubar so valuable? Absolutely. And honestly, once you get it set up, you’ll forget about the Microsoft middleman entirely - it just works seamlessly in the background while you focus on actually getting things done.

Hono vs Elysia for Astro on Cloudflare: What I Chose

Tue, 11 Mar 2025 00:00:00 GMT

When building an Astro application, one of the first decisions you’ll face is how to handle API routes. If you value type safety and developer experience, you may have considered Elysia or Hono, two popular TypeScript web frameworks.

I recently went through the process of migrating (on the same day 😅) from Elysia to Hono for my personal website, and I wanted to share my experience, particularly when deploying to Cloudflare Pages and dealing with environment variables.

Hono vs Elysia: The Short Answer#

For Astro API routes deployed to Cloudflare, I chose Hono. Both frameworks handled my routes well in development, but Hono let me pass Cloudflare environment bindings from Astro’s runtime context directly into the app. At the time of this migration, I could not find an equally clean way to do that with Elysia’s request handler.

	Elysia	Hono
Astro endpoint handler	`app.handle(request)`	`app.fetch(request, env)`
Cloudflare bindings	Available through the experimental Worker adapter	Available through `c.env`
July 2026 dry-run build	155.03 KiB gzip	15.39 KiB gzip
My existing Astro setup	Would require retesting the adapter or changing how bindings are read	Already deployed and working

This is not a universal benchmark or a claim that Hono is always better. It is a comparison of the integration problem I encountered: getting Cloudflare bindings into API handlers while keeping the Astro deployment simple.

The Initial Setup: Elysia#

Let me be honest upfront - I didn’t strictly need a framework for my simple API routes. Astro’s built-in API functionality would have been perfectly adequate for my use case. But as developers, we often choose technologies not just for practical reasons, but also for the sake of experimentation and learning. I wanted to try something new and see what these Bun-optimized frameworks had to offer.

My journey began with Elysia, a framework that promises “sub-millisecond” performance and a delightful developer experience. Setting up API routes in Astro with Elysia is straightforward:

import { getTopTracks } from "~/api/lastfm";
import type { APIRoute } from "astro";
import { Elysia } from "elysia";

const app = new Elysia({ prefix: "/api", aot: false });

app.get("/top-tracks", getTopTracks);

const handle: APIRoute = ({ request }) => app.handle(request);

export const GET = handle;
export const POST = handle;

This worked perfectly in development. The API routes were fast, type-safe, and the developer experience was excellent. However, when I deployed to Cloudflare Pages, I encountered a significant limitation.

The Cloudflare Challenge in 2025#

Cloudflare Pages uses a runtime environment that differs from your local development setup. One key difference is how environment variables are accessed. In Cloudflare, environment variables are not directly available through process.env but are instead passed through the request context, which means that it is not globally available like in your local development environment.

With Elysia, I couldn’t find a clean way to access the Cloudflare runtime context and pass it to my API handlers. My Last.fm API key was stored as a Cloudflare secret, which then is available as an environment variable, but my handlers couldn’t access it because Elysia’s handle method only accepted the request object, not the full Astro context. This describes the integration I tested in March 2025, not Elysia’s current Cloudflare support.

const handle: APIRoute = ({ request, locals }) => {
  // No way to pass locals.runtime.env to Elysia handlers 😭
  return app.handle(request);
};

Enter Hono: The Solution#

So, if Elysia was out of the question, I needed to find a new framework that could handle the Cloudflare runtime context. And who’s the second most popular framework after Elysia? Hono! And to be honest, Hono is becoming a way more exciting framework with a ton of built-in features.

Now, being aware of the problem at hand, I was quick to discover that Hono does offer a more flexible approach to handling contexts.

// [...slugs].ts
import { getNowPlaying, getTopTracks } from "~/api/lastfm";
import type { APIRoute } from "astro";
import { Hono, type Context as HonoContext } from "hono";
import type { BlankInput } from "hono/types";

type Bindings = {
  LASTFM_API_KEY: string;
};

export interface Context extends HonoContext<{ Bindings: Bindings }, string, BlankInput> {}

const app = new Hono<{ Bindings: Bindings }>().basePath("/api");

app
  .get("/now-playing", async (c) => getNowPlaying(c))
  .get("/top-tracks", async (c) => getTopTracks(c));

const handle: APIRoute = async ({ request, locals }) =>
  // To get the locals.runtime object correctly typed, we need to first follow the guide: https://docs.astro.build/en/guides/integrations-guide/cloudflare/#typing
  // Then we can pass the environment variables to the Hono app
  app.fetch(request, { ...locals.runtime.env });

export const GET = handle;
export const POST = handle;

The key difference is that Hono’s fetch method accepts a second parameter where you can pass environment variables and other context. This allowed me to pass locals.runtime.env from Astro’s context directly to my Hono app, making those environment variables available to my API handlers.

Refactoring the API Handlers#

With this change, I also needed to update my API handlers to accept the Hono context:

// Before with Elysia
export const getTopTracks = async () => {
  const API_KEY = process.env.LASTFM_API_KEY;
  // Rest of the handler
};

// After with Hono
export const getTopTracks = async (c: Context) => {
  const API_KEY = c.env.LASTFM_API_KEY;
  // Rest of the handler
};

This approach has several advantages:

Improved type safety for environment variables
Access to Cloudflare-specific features
Cleaner separation of concerns
Better testability since dependencies are injected (not that I’m going to write tests for my personal website 🫣, but still)

Is my codebase heavily tied to Cloudflare Pages? A bit, but I’m okay with that. Moving from it, if I were to move away from the amazing Cloudflare experience that I’ve been enjoying, would still be easier than the migration from NextJS (with CSS Modules) to Astro.

Updated Hono vs Elysia Results (July 2026)#

I retested with Elysia 1.4.29, Hono 4.12.30, Node 24.18.0, Bun 1.3.14, and Wrangler 4.110.0 on an Apple Silicon Mac. Both Cloudflare Worker implementations exposed the same dynamic text route and read the same environment binding.

First, the result that matters most for this article: both frameworks now compile successfully for Cloudflare Workers with environment bindings. The Elysia build used its experimental CloudflareAdapter and cloudflare:workers; the Hono build used its documented c.env binding API. Wrangler’s dry-run output produced these bundle sizes:

Framework	Gzip bundle
Elysia	155.03 KiB
Hono	15.39 KiB

I also ran a small handler-dispatch benchmark: 25,000 warm-up requests followed by seven runs of 250,000 requests to a dynamic hello/:name route. These are the median results:

Runtime	Elysia requests/second	Hono requests/second
Node	653,565	686,000
Bun	5,047,077	1,205,095

Treat those numbers as a framework dispatch microbenchmark, not as production throughput. It excludes Astro, the network, Cloudflare’s runtime, cold starts, and application work. The useful conclusion is that both are fast enough for my tiny API, Elysia benefits enormously from Bun, and Hono produced a much smaller Cloudflare bundle in this test.

Conclusion#

The migration from Elysia to Hono was relatively painless and solved my specific issue with accessing environment variables in Cloudflare Pages. Today, both frameworks have documented Astro and Cloudflare paths, so the limitation that triggered my migration is no longer a fair summary of Elysia as a whole.

If you’re building an Astro site with a handful of API routes, start by asking whether Astro’s built-in endpoints are enough. If you do want a framework, Hono remains my default for Astro on Cloudflare because its binding model is direct, its Worker integration is mature, and it produced the smaller bundle here. Elysia is now a credible option too, especially when Bun performance and its end-to-end type system matter more to you, but its Cloudflare adapter is still documented as experimental.

Sometimes the best technical decisions come from experimentation rather than strict necessity. And I do like to experiment with new technologies, so I’m glad I went through this experience.

As a closing note, I’m extremely bullish on Bun as a JavaScript runtime. Its built-in HTTP server capabilities are becoming increasingly powerful with each release, potentially making it a compelling alternative to dedicated frameworks like Elysia or Hono (or even Vite for that matter) for certain use cases. As Bun continues to mature, we might find ourselves reaching for these frameworks less often, especially for simpler API routes. That said, the ecosystem around Bun is thriving precisely because of innovative frameworks like these, and I’m excited to see how they all evolve together.

July 2026 update

I’m less bullish today. I still use Bun in production and value what it gets right, but I have also encountered memory leaks in long-running workloads. Bun’s account of its rewrite from Zig to Rust openly describes the memory leaks and crashes that motivated the change. Zig creator Andrew Kelley disputed Bun creator Jarred Sumner’s framing, arguing that the deeper problem was Bun’s engineering practices and accumulated technical debt rather than Zig itself; the public exchange also became more personal than the technical disagreement warranted. I don’t see Bun’s problems as an indictment of Zig, nor do I assume that changing languages automatically fixes the underlying engineering trade-offs. Taken together with my own production experience, the episode reduced my trust in Bun as a runtime for long-lived services. It remains an impressive project that I will continue to use where it fits, but with more caution than this original closing note suggests.

Optimising prompt engineering for better AI outputs

Mon, 03 Mar 2025 00:00:00 GMT

Remember when searching for information online involved typing in a few keywords and sifting through pages of results? Thankfully, those days are long gone.

Today’s search engines have transformed the way we find information online. From simple keyword matching to advanced technologies like semantic search and natural language processing, search engines have come a long way. But, have you ever stopped to consider the UX design choices that make these search experiences possible?

An effective UX/ search experience design involves a deep understanding of how humans interact with machines and the ability to adapt to that relationship. It’s not an innate skill, but rather something that can be developed over time, much like the act of googling is a skill that many of us have honed through years of practice. Similarly, interacting with Generative AI models requires a certain level of skill and knowledge which involves Prompt Engineering.

This article aims to provide a comprehensive guide to Prompt Engineering, helping you understand its importance, techniques, and best practices. You’ll be equipped to create effective prompts that maximise the potential of AI models and enhance user experiences.

Why is Prompt Engineering important?#

Well-crafted prompts are essential for maximising the potential of AI models, particularly LLMs. They enhance AI performance by providing clear instructions and context, leading to more accurate and relevant responses.

Prompt Engineering improves user experience by making interactions more intuitive and reducing ambiguity, minimising the risk of misinterpretation. It enables AI models to handle complex tasks, adapt to different use cases, and ensure consistency in outputs, which is vital for integrated systems.

Precision in Prompt Engineering#

Prompt Engineering is a discipline that involves developing and optimising prompts to efficiently use language models for a wide variety of applications and research topics. This discipline is particularly useful for developers, researchers, and anyone looking to leverage AI models for various applications and research topics. It encompasses various skills and techniques essential for interacting with and developing LLMs. Mastering this discipline enables you to optimise these interactions, achieving more accurate and relevant outcomes.

A prompt refers to a statement or question that is employed to trigger a response from a language model or other AI system. Prompts are generally crafted to offer context or instructions to the AI model, directing it to produce a specific type of output or carry out a particular task. A prompt can be provided to the language model by the user or by the system itself, serving as a means to define its default behaviour.

Creating effective prompts requires a deep understanding of both the AI model (various models respond uniquely to different types of prompts) and the user’s intent. Just as search engines use algorithms to understand the user’s query and return relevant results, Prompt Engineering involves designing prompts to communicate the user’s intent to the AI model.

Experimenting with different formats, testing various instructions and contexts, and refining the prompt based on the AI model’s responses are key to creating prompts that produce the desired response from the AI model while minimising the risk of misinterpretation or ambiguity.

The images below demonstrate how slight prompt variations can lead to very different results. However, consistency is crucial in integrated systems. A good prompt aims to produce repeatable outputs with minimal variation, ensuring reliable and predictable AI performance.

Screenshot of the first prompt: “What is spaghetti made of?”

Screenshot of the second prompt with a slight variation: ”What is spaghetti?”

When it comes to the daily interaction with an LLM, a varied yet similar result would be acceptable. But, when it comes to using an LLM as part of an integrated system, consistency is an important factor. What makes a prompt “good” is about producing a somewhat repeatable output with minimal variation.

Are all prompts equal?#

No. Not all prompts are created equally because different types of prompts serve different purposes and can significantly impact the quality and relevance of the AI model’s responses. Understanding the various types of prompts and their applications is key to effective Prompt Engineering.

As a way to scientifically define methods of communication with LLMs, many have tried to create both techniques and frameworks that systematically define how to write these prompts.

Here are some common types of AI prompts that serve unique purposes:

One-Shot and Few-Shot prompts: If you want to follow a structure for a JIRA ticket, providing a well-structured template will help the AI generate similar ones. Few-shot or One-Shot prompts both help the AI adapt quickly to new tasks by providing a small set of examples, enhancing its ability to generate relevant and accurate responses. These prompting techniques involve providing the AI with examples of the desired task or output before asking it to complete a similar task. By showing the model what is expected through one or a few examples, the AI learns the context and format needed and applies it to new inputs.

Zero-Shot prompts: A practical use case is asking the AI to translate a sentence from English to French without providing any examples; the AI must rely on its pre-training to understand and perform the task. This approach is particularly useful for assessing how well the AI can handle novel or unexpected queries, demonstrating its ability to apply learned patterns to new contexts. Unlike few-shot prompts, zero-shot prompts require the AI to perform tasks without prior examples, relying solely on its pre-training. This approach is valuable for evaluating the AI’s adaptability and versatility.

Chain-of-Thought prompts: These prompts guide the AI to follow a logical progression or reasoning pathway to reach a conclusion or solve a problem. The prompt encourages the AI to detail its Each of these Prompt Engineering techniques can be adapted and combined depending on the specific requirements of the task at hand and the capabilities of the AI model being used.

Hybrid prompts: Combining multiple techniques, hybrid prompts might integrate direct instructions with creative challenges or conditional elements with exploratory questions to guide the AI more effectively according to complex needs. For example, you might provide the AI with a Few-Shot prompt to understand the structure of a report, then add a Chain-of-Thought prompt to ensure it details its reasoning, and finally include a Meta-prompt to ask the AI to reflect on its approach. Hybrid prompts are versatile and can be tailored to meet the specific requirements of various tasks, making them particularly useful for complex and multi-faceted projects.

Effective Prompt Engineering involves a deep understanding of these techniques and the ability to apply them creatively. By leveraging the right prompt type, you can significantly enhance the AI model’s performance and the overall user experience. If you want to read more about the several types of prompts, check out Prompting Guide’s techniques page.

Writing your best prompt#

Crafting the perfect prompt is like giving directions to a slightly distracted, incredibly smart friend - you need to be clear, concise, and maybe even a little clever.

Start with a basic prompt and refine it iteratively based on the responses you receive, fine-tuning the AI’s outputs to your specific requirements. Incorporate relevant keywords and specific details to guide the AI more effectively towards the desired output.

Moreover, don’t use jargon or assume knowledge. Be aware of the model’s limitations to craft prompts within its capabilities, avoiding overly complex requests that lead to poor responses. Utilise feedback to continuously improve your prompts, as insights from users or the outputs themselves can guide adjustments for better results.

Mind the length of your prompts to prevent confusion and higher token consumption, which can increase costs.

Although the model may be equipped to handle specific challenges like trick questions about prime numbers, this doesn’t guarantee it can manage every query type. Even after conjuring the best prompt, the model can still confidently reply with false information. In some cases, it might only succeed because similar examples were included in its training data, as shown in the examples in the screenshot below:

Screenshot showing an interaction with an AI model, where the prompt contains trick questions, making it unlikely to provide a factual answer.

Screenshot showing an interaction with Gemini, where the prompt contains trick questions, making it unlikely to provide a factual answer.

Screenshot showing an interaction with an AI model, where the prompt contains trick questions, making it unlikely to provide a factual answer.

Screenshot of prompting ChatGPT to provide unbiased, factual mathematical answers about the possibility of prime numbers ending in 42.

Closing thoughts#

If you find yourself facing a complex problem and need assistance in crafting effective prompts, don’t hesitate to ask AI for help. Leveraging the AI’s capabilities can provide valuable insights and suggestions to refine your prompts, ensuring you get the best possible outcomes. If you feel confident in your prompting capabilities, put yourself to the test against Gandalf.

Finally, different types of prompts complement each other, and combining them can lead to more effective and nuanced interactions with AI models. Whether you’re using One-Shot prompts for quick adaptation, Zero-Shot prompts for versatility, or hybrid prompts for complex tasks, understanding how to leverage these techniques together can significantly enhance the AI’s performance and the overall user experience.

The Future of AI Computing: WASM and GenAI

Mon, 02 Dec 2024 00:00:00 GMT

While Generative AI (GenAI) has taken centre stage, Web Assembly (WASM) works in the background, complementing GenAI by shifting how we approach performance, portability, and security in web and cross-platform applications.

While these technologies may seem distinct, their combination unlocks exciting possibilities: WASM’s ability to deliver near-native performance in constrained environments perfectly complements the computation-heavy demands of GenAI models.

Together, they create a powerful partnership, improving how we deploy and experience AI-driven applications.

This article explores how GenAI and WASM work together to unlock new possibilities for businesses using AI applications. You will also learn some strategies to harness their full potential with accessibility and scalability in mind.

A perfect pair for the future of AI computing#

WASM is a low-level, portable binary instruction format designed for safe, efficient execution across various environments. Initially created to enhance web application performance, it has quickly extended its reach to edge computing, serverless platforms, and embedded systems. Its appeal lies in three key strengths:

Near-native performance
Portability as a universal execution target
Security through its sandboxed environment (especially in browsers)

By decoupling code execution from specific platforms or architectures, WASM allows developers to build once and deploy anywhere, making this function an ideal approach to developing modern, distributed applications.

The rise of Vercel-like WASM-focused companies highlights the growing adoption of WASM’s unique benefits for developers. With WASM, developers gain greater autonomy and flexibility, enabling them to build and deploy high-performance applications without being tied to specific platforms. Additionally, companies using WASM can optimise performance while minimising resource usage, making the process of building and deploying applications much more efficient.

Generative AI, on the other hand, has rapidly advanced with models like o1 and Deepseek-R1 now capable of creating human-like text, generating realistic images, and even writing functional code. These models rely on vast amounts of training data and significant computational power, highlighting their potential for major innovation. At the same time, they spark important discussions about the resources required and the ethical considerations surrounding this powerful technology.

Opportunities, challenges, and key considerations#

GenAI models are computationally intensive, making them difficult to deploy in resource-constrained environments. Real-time applications, which require fast responses, face challenges with traditional deployment methods, as they struggle to process data quickly enough. This leads to slower performance or, in some cases, failure to deploy. While tools like Ollama have proven that most models can run locally, the performance that you can find on basic devices, such as entry-level smartphones or laptops, is typically much lower than on more powerful systems like the one you’re reading this on.

However, despite these limitations, GenAI makes an excellent candidate for optimisation through WASM because WASM can make AI applications more accessible across a range of devices. While WASM offers a lightweight and portable execution environment, its ability to address GenAI challenges largely depend on the specific use case and optimisation strategies. Here are some key points to consider:

Portability: GenAI models compiled into WASM modules can run across platforms like browsers and edge devices. However, achieving smooth operation may require significant optimisations and adjustments for each environment.
Efficiency: WASM can improve inference performance in local setups, but the benefits may be limited for larger GenAI models or more complex workloads due to WASM’s current hardware limitations.
Scalability: Serverless platforms adopting WASM can simplify GenAI model deployment.
Privacy: WASM can help prioritise privacy by enabling GenAI models to run locally, but this approach may involve trade-offs in terms of model complexity and computational overhead.

For example, a WASM module could host a language model directly in a web browser, enabling offline chatbots without needing server connectivity. While tools like Ollama already offer similar functionality, WASM allows for browser-based deployment, which brings the flexibility that comes with the browser.

Real-world use cases#

In the real world, we’re already seeing examples of WASM and GenAI working together, like Whisper running directly in the browser. This hybrid approach allows users to choose the model and adjust performance according to their needs. There are exciting possibilities on the horizon where WASM and GenAI could combine to create innovative solutions. Here are a few examples:

In-Browser AI Assistants: Deploy lightweight GenAI models directly in browsers using WASM, providing real-time assistance without network latency.
Edge Device Applications: Run WASM-optimised GenAI models on IoT devices for tasks like image recognition or anomaly detection.
Serverless AI APIs: Host GenAI models as WASM modules on serverless platforms, reducing operational costs while improving scalability.

These use cases demonstrate how WASM empowers GenAI to operate efficiently in diverse environments, from cloud servers to smaller edge devices.

Overcoming barriers to realise WASM and GenAI’s full potential#

While the combination of WASM and GenAI promises a lot of great things, several challenges must be addressed:

GPU Limitations: WASM currently lacks native GPU support, making it difficult to accelerate GenAI workloads that rely on parallel processing, a critical feature for handling large-scale AI tasks.
Memory Constraints: This compute boundary is a significant hurdle for WASM when working with AI workloads requiring high levels of parallelism. Furthermore, large GenAI models often exceed WASM’s default memory limits, necessitating careful optimisation to fit these constraints.
Early-stage Ecosystem: While WASM is evolving rapidly, tools and libraries for integrating WASM with AI frameworks are still maturing, highlighting the ecosystem’s early-stage nature.

Emerging tools like WebLLM and platforms such as Turso are addressing some of these limitations in innovative ways. For example, WebLLM demonstrates the feasibility of running large language models directly in the browser by leveraging WebGPU for acceleration. It’s important to note that WebGPU is still an experimental API, and its integration with WASM for AI workloads is in its early stages, requiring further development and testing.

Similarly, Turso, a distributed database built on libSQL, has introduced features like native vector search and 1-bit quantisation for vector embeddings. These advancements make it easier to deploy AI applications that prioritise local-first processing and efficient resource usage. However, both WebLLM and Turso highlight the gaps in WASM’s ecosystem, such as the need for GPU integration and optimised toolchains for AI workloads. Addressing these challenges will be key to unlocking the full potential of this pairing.

How WASM and GenAI are redefining the future of software development#

Looking ahead, advancements in both WASM and GenAI promise to deepen their integration through the following ways:

WebGPU Support: Introducing WebGPU to WASM environments will enable hardware acceleration for AI workloads. However, it’s worth noting that WebGPU is still an experimental API, and its integration with WASM for AI workloads is in the early stages, requiring further development and testing.
Model Optimisation: Techniques like quantisation and pruning will make it easier to deploy GenAI models within WASM’s constraints.
Standardised Toolchains: Improved tooling will simplify the process of compiling and deploying GenAI models as WASM modules.
Private Personal Assistants: Having the model run locally will open up the possibilities to protect the end user from endless data-sharing, one that is a given if the benefits of using AI keep increasing.

These developments are set to enable real-time, AI-driven applications that are fast, portable, and accessible to a wide range of users.

WASM and GenAI are two disruptive technologies poised to change how we build and deploy software. WASM’s portability and performance make it an ideal runtime for GenAI, enabling the creation of applications that are both powerful and accessible.

As these technologies continue to evolve, now is the time for developers to explore their synergy. Whether you’re building the next-gen AI assistant, a cutting-edge edge computing solution, or serverless applications, the pairing of WASM and GenAI offers endless possibilities to be unlocked.

Spicetify - An open-source journey

Mon, 12 Dec 2022 00:00:00 GMT

According to my message history, it all started around February 2020 when I found out about Spicetify through some random Reddit post in the illustrious r/unixporn - a subreddit where the highest tier of nerds share their Unix setups and configs - and I was immediately intrigued.

I had been using Spotify for a while, but even though the UI is not awful, they do have some very anti-user behaviours. Initially, I was simply a user, but then ideas to improve it started coming up, and I started to develop a more active role in the development. One of my first contributions was to the New Releases Custom App. This extension creates a page where we can see all the new releases for the artists we follow. Conceptually, it is a simple feature, however, Spotify’s “notifications” were practically useless, even to this day¹, which made it quickly become one of my favourite Spicetify features, which also led to my first contribution (spicetify-cli#247).

Spicetify’s core, what we call spicetify-cli, is a Command-line Interface (CLI) tool that goes through Spotify’s binaries mutating them through regex matching to allow for the promised customisation. It is written in Go, which is a highly performant language that I learnt a couple of years prior to give a workshop on it at IEEE University of Porto Student Branch, a student branch of the IEEE that I was a member of at the time - and later was elected Vice-President for a year.

With time, I started helping out more and more in handling issues, developing small features, and keeping the latest Spotify version supported². Eventually, khanhas made me a maintainer on GitHub to help with everything. In late 2021, Spicetify’s popularity truly blew up and we had to start handling a lot more issues and pull requests, which was a very exciting time for me. However, it was also the last time we saw khanhas, as he decided to leave the project and focus on other things. Thankfully, he left the project in a very good state, and I was able to take over as the new maintainer. Additionally, there were a small group of people that were already helping out with the project, which helped immensely.

It was September 2020 when I started working full-time, but it was in 2022 that my workload, other side-projects and overall life started pilling up a bit more, and, eventually, I noticed myself not being able to dedicate as much time to Spicetify as I would have liked. This is when I shifted to a more managerial role, where I would help out with the more complex issues, but also help out with the more mundane tasks, such as reviewing pull requests and merging them. I also created the Spicetify Documentation website, which is a very important part of the project, as it is the first place people look at when they want to customise their Spotify, unlike previously when people could only look at GitHub’s wiki, which was not very user-friendly for newcomers. And also created the Spicetify GitHub organisation, which is where all our repositories are hosted since previously they were hosted across several different contributors’ accounts.

Spicetify Docs Visitors

Overall, it has been quite a ride, but seeing hundreds of thousands of downloads per GitHub release and over 200K unique visitors per month to our documentation is a very rewarding feeling. I am very grateful to all the contributors, users and maintainers that have helped out in this journey, and I hope that we can continue to make Spicetify better and better.

They did do something on mobile, but if you follow more than 30 artists the list gets pretty polluted with singles. The only filter available is either Music or Podcasts, which is not very useful. And I mostly listen to Spotify on my PC anyway, so it doesn’t really matter. ↩
Spotify releases most of the times do not break the CLI itself, but when they do it is because we need to apply updates to the regexes that match the Spotify binaries. This is a very tedious process, but it is crucial to keep the CLI working. ↩

Welcome to my blog

Mon, 14 Jun 2021 00:00:00 GMT

println!("Hello World!");

As a learning rustacean, I’ve chosen to start this blog with a classic, but rustic (has this joke been made before?), Hello World!

Bad programming jokes aside, I will use this blog to write posts about tech, music, states of mind, opinions, etc. Maybe I’ll even do one about beer 🍺! In reality, I don’t quite have any idea what I will write about, maybe about everything and maybe about nothing. But I’ll certainly try to write about something, even if it is an excuse to fuel my creative side!

As an engineer, I often consider myself too analytic in the creative process. Not that it is a bad thing, it’s just something that is part of me and that I am aware of. It is not for no reason that I’ve decided to focus on backend development, as problem-solving is my jam! However, if it involves designing, I’ll probably rely a lot on the “inspiration” phase, which roughly translates to “look at other designs and rip off all the good ideas”. Again, this is also not a bad thing - I think - but it means that my creative work will never be truly original and be based on building on what’s good ✨ out there ✨.

In the end, my admiration for the creative process of artists, designers and writers is immeasurable. It’s something that can be easily noticed by looking at the amount of music I listen to and concerts that I go to, but it goes way beyond that! We all have some sort of creativity within us, but some people are so much better at using it and that makes them amazing. And I hope that by creating this blog I can practice that, expand my creative side and that you enjoy this journey I am embarking on.

See you in the next post! ✌