FerrumFluxFenice

The problem

On my Chromebook, a cold boot with Tailscale installed could leave the Linux Terminal unable to open. Garcon, which connects Linux apps to ChromeOS, was crashing. The issue thread had been open since May 2024, with workarounds that helped some people and not others.

The work

I compared 4 cold-boot configurations. Both tests with tailscale0 present crashed; both without it did not. But avoiding the crash was not enough: one configuration left Tailscale nonfunctional. Userspace networking let both the Terminal and Tailscale work without creating the interface. That gave me a useful default to propose.

The result

Tailscale detects Crostini before Debian and defaults to userspace networking when that mode is available, avoiding creation of tailscale0. Anyone who wants the interface back can still pass --tun=tailscale0.

if buildfeatures.HasNetstack &&
   distro.Get() == distro.Crostini {
    return "userspace-networking"
}

This changes Tailscale’s default, not garcon’s code. My comparison covered one Chromebook running Debian 12 on aarch64, with one cold boot per configuration. The same investigation led to the ChromiumOS change in the next case.

The problem

Garcon helps connect Linux apps to ChromeOS. While setting up Android app sideloading, it looked through the network interfaces for an IPv4 address. It tried to read an address even when an entry didn’t have one, which could crash garcon.

The work

At this point I didn’t even know what a CL (changelist) was. I jumped into the docs, started setting up Ubuntu for the build and got to work. I added a check to skip entries without an address, then took the change through ChromiumOS review and the commit queue.

The result

One file, one check. ChromiumOS CL 7881724 guards the null address in arc_sideload.cc. A Chromebook receives the fix when Google ships a ChromeOS build containing it.

if (current->ifa_addr == nullptr) {
  continue;
}

This guard covers the Android app sideloading path. Its merge does not establish that every cold-boot or GUI failure reported in the Tailscale thread was fixed.

The problem

Find out what the business actually needed from the site and how it fit the work already happening. Services, quote requests, returning customers. A website was the first ask, but the conversation kept going.

The work

From discovery, design and critique through deployment, I worked with the owner to build the site the business needed, paying attention to load times and how business and customer data were handled. Once the site was up, we added a Housecall Pro lead form and customer portal. I continue to update and maintain the site. The business owns the code and can move it elsewhere.

The result

9+ months in as of September 2026 and we’re still moving along. A few tweaks to the site but mostly behind the scenes: a pricebook integrated into the CRM to help make estimates more efficient and accurate, process improvement, and tech fluency.

Website / CI/CD / maintenance
Housecall Pro form / customer portal
Pricebook / process improvement

The problem

I was just reading and scrolling Google Issue Tracker and ran across an issue I thought I could at a minimum reproduce. I couldn’t, but it led me to this area of the codebase and that is how this CL came to be. Linux desktop entries describe how to launch an app. Garcon was parsing their Exec commands, but discarding explicitly empty quoted arguments. Empty and missing mean different things when an app expects its inputs in a particular order.

The work

I changed the parser to keep a quoted argument when its closing quote is reached, even if it’s empty. Then I added regression tests for empty arguments at different positions, quoting, escaping and file expansion.

The result

The 27-test DesktopFileTest suite and 3 related test binaries passed in the ChromiumOS SDK. Explicitly empty arguments now keep their place in the generated command.

- if (in_quotes && !curr_arg.empty()) {
+ if (in_quotes) {

This fixes desktop-entry argument parsing in garcon. It is a different garcon path from the Crostini crash.

The problem

This started with trying to get voice input working in Claude Code on my phone. I opened a Termux PR and was still learning how to contribute. Even squashing commits gave me trouble. In July, I got pinged to retest. The original input problem no longer reproduced, but getting back into the audio work led me to a different failure in OpenAL Soft. With its Oboe audio backend enabled, repeatedly creating audio devices and resetting playback left streams open until there weren’t enough left. Now I needed to find out whether my Termux changes had caused the problem or exposed something upstream.

The work

Having the lab phones meant I could leave a device running a repeated test without tying up the phone I use all day. I reproduced the failure with stock NDK r29 and unpatched Oboe 1.10.0, outside the Termux packaging. A move to shared pointers had removed the cleanup that closed each stream. Testing the original code against the fix showed why releasing ownership was no longer enough. The stream needed an explicit close.

The result

The fix closes streams during playback probing, reset and backend destruction. The original build reproduced the device-creation and playback-reset failures; the fixed build passed those comparisons. Android 32-bit and 64-bit builds passed too. OpenAL Soft PR #1322 was reviewed and merged. The larger Termux audio work is still separate.

if(mStream)
{
    mStream->close();
    mStream.reset();
}

I also checked audio capture. Those tests passed with both the original code and the fix. The change keeps Oboe’s shared-pointer API.

The problem

I wanted to learn how to contribute properly. Read CONTRIBUTING.md, find a scoped issue, pick something I could test on my own phone. CUPS had an issue with useful diagnostic work already behind it: broken web UI permissions, missing runtime directories and a configuration problem that blocked administration.

The work

Almost the entire PR happened in Claude Code through Termux on my S26 Ultra, using claude-code-android. The Docker builds went to my PC, ole Frostbyte-Ferrum. I worked from the earlier issue findings, fixed the package, tested it on the phone and learned from the review. Even the chmod needed to happen at the right build step or it wouldn’t survive into the package.

The result

The web interface loaded again, the runtime directories were created and the administration configuration was restored.

mkdir -p …/var/spool/cups/tmp
mkdir -p …/var/cache/cups
chmod -R o+rX …/share/doc/cups

Earlier issue contributors identified the permissions cause and the missing runtime-directory problem. Their diagnostic work is credited in the linked PR.