boundary.labs

Field report / Hardware reuse / Omarchy

Old laptops.
Useful work.

The recent work of turning the laptops already in the lab into machines we want to use—with local dictation, a desktop that fits the operator, and a few failures worth documenting.

The encouraging part of the last few weeks has been how much useful work we can get out of hardware we already own. An older Dell and a later-generation ThinkPad have become working Omarchy machines: places to write, dictate, manage the lab, and work with agents. The desktop is becoming something that fits how I actually operate.

That progress has involved microphone repairs, launcher fixes, a custom dock, and a stubborn display/input problem on the Dell. The useful story is the combination: real daily-work gains, with enough attention to the failures to know where the limits are.

The testbeds

Start with the machine on the desk.

Omarchy gave us the desktop environment to build around. The two laptops represent different generations; calling both equally old would miss an important part of the comparison.

MachineRole in this workWhat we learned
Dell XPS 15 9570
2018 generation; i7-8750H, 32 GB RAM, GTX 1050 Ti
Desk workstation, local dictation, desktop customization, and CPU agent experimentsStill useful for interactive work. Its hybrid graphics and external-display path have required the most troubleshooting.
ThinkPad T14 Gen 3 AMD
A later-generation comparison
Portable Omarchy workstation with voice input and the lab's agent toolsGetting the microphone and push-to-talk path right mattered more to daily usefulness than chasing a benchmark number.

The Dell was reinstalled on Omarchy in late August. The ThinkPad moved to Omarchy on August 28. A September 6 check confirmed Omarchy 4.0.2 on the Dell, its dictation service running, and the custom dock plugin installed. Those checks establish configuration and service state; they do not prove uninterrupted reliability.

What is going well

The everyday workflow is coming together.

Both machines have been brought into the same working environment: agent tools, shared operating knowledge, remote administration, and the applications used to do the work. A laptop can become another useful place to operate the lab without reproducing the entire inference system inside it.

That distinction matters. The agent interface and its surrounding tools can run on a laptop while the model runs elsewhere. The lab's production gateway was verified against an external API backend on September 6. Calling the resulting workflow useful on old hardware is fair. Calling all of that model inference local would not be.

At the laptop

Interact

Desktop applications, terminal work, and voice input.

In the lab

Coordinate

Memory, tools, and a common inference gateway.

Per workload

Choose compute

Local speech models, CPU experiments, or API-backed agent inference.

There were ordinary integration failures along the way. After rebuilds, agent launchers still pointed at old executable locations. Fixing those paths and checking an actual execution round trip restored the workflow. A shortcut existing on disk was not enough; the tool had to launch and do useful work.

A practical win

Voice input made the laptops more useful.

Local dictation has been one of the clearest improvements. It shortens the path from an idea to text in the application where I need it. The work was choosing an appropriate speech model, getting the microphone into the audio system, wiring up a comfortable key, and making the output land at the cursor.

On the Dell, the working choice was Whisper small.en through Voxtype using the NVIDIA GPU's Vulkan path. The hardware does not need to be suitable for a large language model to be useful for a smaller, focused speech workload. We kept the setup that worked well on that machine instead of forcing the same engine onto every box.

The ThinkPad initially had no functioning microphone in applications. Investigation traced the problem to the audio profile setup for its AMD digital microphone. A targeted WirePlumber configuration change made the capture sources appear. A later permission problem stopped the push-to-talk listener from seeing the keyboard, despite the dictation daemon looking healthy.

Both were solvable integration problems. Once the microphone, hotkey, model, and text insertion path were connected, voice input became part of the normal workstation workflow. That is the kind of improvement that makes an existing machine feel worth keeping.

Something reusable came out of it

A mouse-first dock for Omarchy.

I want a desktop that accommodates the way I work. That led to omarchy-dock, a public, MIT-licensed plugin built with Quickshell/QML.

The dock brings pinned launchers, running applications, window switching, a right-click menu, drag-to-reorder, and auto-hide into one place. It is a practical mouse-first companion to the rest of the desktop. The original problem was personal workflow friction; the result is something other Omarchy users can inspect and try.

Building it also produced a lesson about verification. A plugin reload message did not always mean a persistent panel had adopted the new code. We had to restart the shell and inspect the visible result. Working software is the behavior on the screen, not the reassuring line in a log.

Inspect the dock and installation notes →

Where the machines pushed back

Useful does not mean trouble-free.

The Dell's display/input freezes remain a real limitation.

In early September the Dell experienced recurring input freezes while docked. The initial suspicion fell on the docking hardware. Later checks shifted the investigation toward the Intel display-driver and compositor path: display FIFO errors appeared while the expected signs of a USB or Thunderbolt link failure were absent in the examined logs.

Device hotplug aggravated at least one incident, but later notes do not support treating it as the only trigger. Some recovery attempts worked by restarting the graphical session remotely; at least one incident required a reboot. An update attempt did not deliver a demonstrated fix.

The evidence points toward a software/display-stack regression on this combination of hardware. It does not establish a universal Omarchy defect or conclusively certify the dock. The honest status at publication is that the problem is not resolved.

The memory upgrade did not work as expected.

A larger memory kit failed to initialize in the Dell and was moved to another compatible machine. The Dell stayed at 32 GB. That is a result about the kit and machine we tested, not proof that every possible larger-memory configuration is impossible.

Reusing hardware still requires compatibility work. A socket accepting a module is not the same as the system successfully training and running that memory.

Maintenance is part of the cost.

We also cleaned up obsolete boot entries, checked firmware availability, repaired synchronization that could report success after a failure, and reviewed workstation security settings. Those jobs belong in the account of how things are going. The acquisition price of an older machine is only one part of its cost; operator attention is another.

A separate question

Can the old laptop also run the model?

The Dell's CPU-only agent-fitness experiment provides a useful boundary. In the August 24 single-shot test, the sparse Qwen model completed tasks faster than the smaller dense Ornith model and performed better on the tool-use rubric. The follow-up multi-turn diagnostic workflow still was not viable.

August 24 CPU evaluationMedian task latencyTool rubric
Qwen3-30B-A3B-Instruct-250714.5 seconds7/7
Ornith-1.5-9B34.3 seconds6/7

Both used CPU-only llama.cpp with six threads and Q4_K_M quantization. These are manually judged capability receipts from a small task set, not a broad ranking of models or a measurement of desktop responsiveness. Read the methodology, follow-up failure, and source artifacts.

The workstation result and the inference result can coexist. A machine can be good at writing, dictation, tool execution, and operating an agent interface while remaining a poor choice for demanding multi-turn inference on its own CPU.

What carries forward

Keep the workflow gains. Respect the limits.

What has gone well is concrete: the laptops are doing useful work, voice input is integrated, the desktop has been adapted to the operator, and a local customization became a public project. We have learned which parts of the workflow benefit from local compute and which are better served through a shared gateway.

The next decision should follow the remaining friction. If a display path repeatedly consumes attention, a different hardware combination may be justified. If the daily workflow is responsive and dependable, the age on the specification sheet is not a reason by itself to replace it.

For Boundary Labs, this has been a productive stretch of practical systems work. The older hardware gave us somewhere inexpensive to experiment, and the experiments produced improvements we can actually use.

Evidence and scope

How to read this report.

This is an operator field report assembled from late-August setup records, early-September repair notes, and a read-only Dell configuration check on September 6. It is not a controlled operating-system comparison, a battery-life study, or a fleet-wide reliability benchmark. The diagnosis of the freezes reflects the latest investigation, with uncertainty preserved.

Operational observations are summarized here rather than publishing private machine logs. No new benchmark campaign was run for this article.

Compare notes

Putting an older machine back to work?

I'm interested in the workflow you made useful, the problem that took the most time, and what you could actually verify.

Share your experience →