Make One Part of the Device Yours

Imagine settling into a headset to work across several floating screens. Your mouse reaches the edge of one window and stops. To use another, you have to change focus with the controller or headset. The computer can show you a room full of work, but moving through it still follows someone else's idea of how you should behave.

That is a small irritation. It is also a useful place to begin thinking about ownership. Can you change the arrangement to suit the work—or only become more practiced at accommodating it?

---

Change the fit, not the whole machine

In his October 5 account, “Nix on the Steam Frame,” John Murray describes installing Nix, a package-management system, on his headset and using Home Manager to specify applications and settings in configuration files. Rather than replacing the operating system with NixOS, he keeps SteamOS and manages a layer within it.

The distinction matters. He does not need to take responsibility for the entire machine to make part of it his own.

His account ends with a concrete payoff: Frametop, software for managing desktops in VR, lets him move the mouse across windows and rearrange them in three-dimensional space. He reports that the default behavior required changing focus with the controller or headset first. The window behavior comes from Frametop; Murray created a separate integration, frametop-nix, to manage it through Home Manager. His account demonstrates that configuration route, not that Nix is required for Frametop itself. The customization answers a particular friction, not an abstract obligation to customize everything.

Start with the friction, not the full list of things you could customize. What do you need to change, and how little of the machine can you take responsibility for while changing it?

Keep the parts already carrying the work. Alter the part that makes the person bend unnecessarily. A device does not become more yours merely because you have replaced more of it.

---

A configuration is a claim about tomorrow

Murray's guide is especially useful because it does not stop at successful installation.

He explains that the Nix store lives under /home, with a boot-time mount making it available at /nix. He also describes the complications around system updates and startup order: files in /etc need a way to survive updates, and a session can start before the Nix store is available. His additional tooling addresses those update and startup problems.

These are details from his account, not steps I have tested on a headset. They make the limit visible: a file describing your desired setup is not, by itself, proof that the device will deliver it after an update.

Still, writing the desired setup down changes the work. Instead of remembering a trail of manual adjustments, you have something to inspect, revise, and apply again. The configuration becomes an explicit account of how you want the machine to behave.

That account remains answerable to the machine. If an application is installed but absent from the launcher, the arrangement is unfinished. Murray describes exactly that problem, along with the extra work needed to expose applications where the interface expects them.

The useful unit is not “a package installed.” It is “a person can now do the thing.”

---

Leave a smaller maintenance bill

There is a trap here for builders. We can turn the freedom to modify into an expectation that everyone should maintain their own stack.

That would buy our preferred arrangement with somebody else's time. A person who wants the appliance to remain an appliance has not failed a test of agency. A shared device is not improved if its new capabilities depend on the only person who understands its configuration being in the room.

So make tomorrow's experiment smaller than Murray's project. Pick one recurring friction on a device you already use: a missing launcher entry, an awkward shortcut, a setting you repeatedly restore. Use its supported customization mechanism before considering deeper system changes.

Before changing it, write a short change record:

• Purpose: What becomes easier for the person using this?
• Recipe: Where is the setting or configuration, and how is it applied?
• Return: What was the original setting, and what exact steps restore it?
• Upkeep: What needs checking after a restart or update?

Keep sensitive information out of any copy you share. Try the change on something nonessential first, and verify the ordinary action—not just the installer's success message. Restart and try the action again. Test the way back, too, before relying on the new setup. If another person uses the device, have them try it without your coaching. Their difficulty is evidence about the arrangement, not a deficiency in them.

This is the scale at which a small capability can become durable: useful enough to keep, legible enough to repair, modest enough not to take over the day.

You do not have to rebuild the machine to stop bending around it. Make one part fit, and leave a clear way back.