The reasonable fix is a €3 USB-C adapter. But the adapter is three days of shipping away, and the other PC — a little Rockchip ARM board that lives on my desk — was right there, with free USB-A ports and a network connection to my laptop. On Linux, "the mouse is plugged into the wrong computer" is not really a hardware problem. It's a routing problem.

Pick your layer

There are two ways to ship a USB device across a network:

Forward the USB device itself — that's usbip, which is in the mainline kernel. The remote host sees a real USB device, URBs get shuttled over TCP, and everything that could talk to the physical device can talk to the remote one. That's the right tool when something needs the device — firmware flashers, smartcard readers, license dongles.

Forward the input events — a mouse is not an interesting USB device. By the time applications see it, it's just a stream of tiny input_event structs coming out of /dev/input/eventN: relative X, relative Y, button, sync. The kernel will happily accept the same structs back through /dev/uinput and synthesize a new input device out of them. So instead of tunneling USB, you can read events on one machine and replay them on the other. Less protocol, less latency sensitivity, and it works regardless of what's on the other end — Wayland, X11, a bare console.

For a mouse, events win. The tool for this is netevent — a ~130 KB binary with two relevant subcommands: cat (open an event device, dump its events to stdout) and create (read events from stdin, create a uinput clone). It's netevent-git in the AUR.

The five-minute version

Find the mouse on the machine it's plugged into. /dev/input/by-id/ gives you stable names, unlike eventN which reshuffles on replug:

$ ls -l /dev/input/by-id/
lrwxrwxrwx 1 root root  9 platform-noserial-if01-event-mouse -> ../event8
lrwxrwxrwx 1 root root 13 usb-Logitech_USB_Receiver-hidraw -> ../../hidraw0

Then, from the laptop, one pipe:

$ ssh zxc-pc 'sudo netevent cat /dev/input/by-id/platform-noserial-if01-event-mouse' \
    | netevent create

That's genuinely all of it. netevent cat grabs the device exclusively (EVIOCGRAB — the server machine stops seeing the mouse), streams events over the SSH connection, and netevent create conjures a virtual "Logitech USB Receiver Mouse" on the laptop that the desktop picks up like any hotplugged device. The cursor moves. SSH gives you encryption and auth for free.

I used exactly this for about an hour. Then the sysadmin brain kicked in, because the pipe has problems:

• it needs sudo on the server (/dev/input/* is root:input),
• it dies silently on suspend, roaming, or a Wi-Fi blip, and takes the mouse with it,
• it drags my interactive SSH config — agent forwarding, a GPG socket RemoteForward — into what should be a dumb transport,
• and it plants a landmine that I would step on two hours later. We'll get there.

The grown-up version: socket activation

What I actually want is an appliance: the server exports the mouse, permanently and cheaply; the laptop attaches when it wants to; the grab — the mouse going dead on the server — should last exactly as long as the attachment. That maps one-to-one onto systemd socket activation:

Two unit files on the server. The socket:

# /etc/systemd/system/zxc-mouse.socket
[Unit]
Description=Export Logitech mouse over Tailscale (netevent)

[Socket]
ListenStream=8763
BindToDevice=tailscale0
Accept=yes
MaxConnections=1

[Install]
WantedBy=sockets.target

And the per-connection service it spawns:

# /etc/systemd/system/zxc-mouse@.service
[Unit]
Description=netevent mouse stream to %i

[Service]
ExecStart=/usr/bin/netevent cat /dev/input/by-id/platform-noserial-if01-event-mouse
StandardInput=socket
StandardOutput=socket
StandardError=journal
DynamicUser=yes
SupplementaryGroups=input

Almost every line here is doing security or lifecycle work:

• Accept=yes is inetd mode: each TCP connection spawns a fresh instance with the connection as stdin/stdout. netevent cat doesn't know the network exists — it writes to "stdout" and systemd has already wired that to the socket.
• BindToDevice=tailscale0 scopes the listener with SO_BINDTODEVICE: connections arriving via any other interface never reach it. The mouse is reachable over the tailnet and nothing else — no LAN exposure, and Tailscale brings the encryption and authentication that raw TCP doesn't.
• MaxConnections=1 — a second client gets refused instead of fighting over the grab.
• DynamicUser=yes + SupplementaryGroups=input is my favorite part. The prototype needed sudo for exactly one reason: reading /dev/input/event8, which is root:input 0660. But that's not a root problem, it's a group problem — so let systemd mint a throwaway user that exists only for the lifetime of the connection and holds exactly one privilege: the input group. No sudo rules, no long-lived root process, no real user to keep in the group forever (permanent input membership is a standing keylogger license — every process you run can read every keystroke).

The lifecycle falls out of the socket activation for free:

Nobody is grabbing anything while no one is attached. The mouse is a shared resource with connection-scoped ownership, which is exactly the semantics you'd want and exactly what an always-running daemon wouldn't give you.

On the laptop, the attaching end is one more unit:

# /etc/systemd/system/zxc-mouse.service
[Unit]
Description=Attach Logitech mouse exported by zxc-pc

[Service]
ExecStart=/bin/sh -c 'socat -u TCP:zxc-pc:8763,keepalive,keepidle=5,keepintvl=5,keepcnt=2 STDOUT | netevent create --duplicates=resume'
Restart=always
RestartSec=2
RestartSteps=8
RestartMaxDelaySec=60
DynamicUser=yes
SupplementaryGroups=input

Same trick on this side — netevent create needs /dev/uinput, which is also root:input 0660, so the same throwaway-user-plus-one-group pattern covers it. socat instead of nc because of the keepalive knobs: a mouse stream is silent when the mouse is idle, so without keepalives a dead peer looks identical to a boring evening. With keepidle=5,keepintvl=5,keepcnt=2 a vanished server is detected in ~15 seconds, the pipe exits, and Restart=always walks the backoff (2 s → 60 s) until the server is back.

One deliberate omission: this unit has no [Install] section. It cannot be enabled at boot, even by accident. systemctl start zxc-mouse is the new "plug in the mouse"; systemctl stop zxc-mouse is unplugging it — and handing it back to the machine it's physically attached to.

Did the interface scoping actually work? Two checks:

$ ssh zxc-pc ss -tln | grep 8763
LISTEN 0  4096  *%tailscale0:8763  *:*        # the % is SO_BINDTODEVICE

$ nc -z -w3 192.168.88.247 8763               # via LAN: refused
$ systemctl start zxc-mouse && systemctl is-active zxc-mouse
active                                         # via tailnet: streaming

The landmine

I promised a landmine. First start of the polished new service:

sh[1510469]: error: error while expecting hello packet: Success

The client connects, expects netevent's protocol hello, and gets EOF — reported with errno 0, the error message equivalent of a shrug. The server journal has the real story:

netevent[61925]: error: failed to grab input device: Device or resource busy

Something already held the exclusive grab. It was the prototype — the SSH pipe from two hours earlier. I had killed my end of it, but the remote netevent cat had no idea: it only touches its dead socket when the mouse moves, and the mouse, grabbed and therefore inert, had not moved. A process whose only job is to report motion, kept alive by the absence of motion, holding the grab forever. The new service died against it on every retry.

One pkill on the server later, the service came up and stayed up.

Was it worth it?

Latency over the LAN (Tailscale negotiates a direct path between machines on the same network) is imperceptible — mouse events are a few dozen bytes each, and the event clock is carried in the protocol. The whole thing cost three unit files and one 130 KB tool, runs with no root process and no sudo rule on either machine, exposes one port on one virtual interface, and gives the mouse back the moment I stop the service.

The dongle is still not here. The mouse never found out it's being forwarded.

And "existing" no longer means old. In the agentic era a codebase can reach that state — drifted design, blurred patterns, obsolete docs — in a matter of weeks, sometimes days, often with an agent as the original author. The archaeology now has to happen on sites that are still under construction.

I want to walk through why I think this happens, and why I suspect it's not a temporary weakness.

Two forward passes

When an agent builds a project from scratch, the pipeline is:

requirements → design → code

The user states what is needed. The agent converts requirements into a software design, picking patterns that fit — it has seen thousands. Then it converts the design into code, step by step.

Both arrows point the same way, and both are forward passes — and humanity has documented them exhaustively. Every architecture book, every pattern catalog, every tutorial, every open-source project is a record of someone moving in this direction. A model trained on public text has effectively watched this pipeline run millions of times. It's not surprising that agents are good at it. It would be surprising if they weren't.

Refactoring runs the pipeline backwards

Now the opposite situation. The agent is dropped into an existing project. What it holds is the pipeline's output — the code. The inputs are exactly what's missing:

• The design has drifted; the code no longer matches any design that was ever drawn.
• The patterns are blurred by local, not-so-clean fixes and workarounds.
• The documentation and comments describe a system that no longer exists.

The engineer's task — human or AI — becomes:

1. Recover the actual current requirements (they've drifted from whatever the docs claim).
2. Discern the real patterns inside the noisy code.
3. For each anomaly, figure out why it exists: legacy? An unfinished plan? A past mistake? A requirement that moved?
4. Correct the requirements picture based on what the code investigation revealed.
5. Decide what design would be ideal for the corrected requirements.
6. Plan a path from the current code state to the target state.
7. Write the code.

Look at the direction of these steps. Steps 1–4 run backwards: from code to design, from design to requirements. Steps 5 and 7 are the familiar forward passes — the easy, well-trained part. Step 6 is neither: it's plotting a route through a live system that has to keep working at every intermediate state — changing the tires while the car is moving.

And the backward direction has a problem the forward one doesn't: it is underdetermined. Many different pairs of (requirements, design) could have produced the code in front of you. The forward pass loses information; running it backwards means guessing what was lost. The only thing that disambiguates the guesses is history. And while git preserves the what perfectly — it's all there in the repo — the why mostly isn't: it lived in review comments, chat threads, and the heads of people who have moved on.

Step zero: the smell

Worse, you rarely know in advance that refactoring is needed. It is almost never a ticket. You sit down to add a feature or fix a bug, and every implementation you sketch smells: each one fights the current design, each needs two workarounds to fit. The decision to refactor is the recognition of that smell — noticing a mismatch between the design you have and the requirement that just arrived.

This is a background process, not a step. A human engineer runs it constantly, motivated by their own future suffering: the person who will maintain this mess is them. An agent's episode ends when the diff lands. Nothing in its loop rewards stopping to question the design; if anything, the training signal runs the other way — "sure, here's your feature" reads as helpful, "we should restructure first" reads as evasive. The agent never has to live in the house it builds.

Refactoring is a compression task

Strip it down and refactoring is, first of all, compression. Given tens of thousands of lines of code, extract the internal structure. And not only the current structure — also the historical one, because step 3 (why is this here?) is a question about time, not about code.

Two compressions, then. The first — what the design currently is — is hard, but at least the input fits in a context window. The second is harder in principle: the rationale was never written down, or was written down and has rotted along with the docs. If the code was written by an agent, the problem inverts rather than disappears: the why is on record in exhausting detail — but uncompressed, too voluminous to load, and impossible to tell which of it is still true. The agent is asked to decompress a lossy archive with the dictionary thrown away.

What a good human engineer brings here is a prior — and note what the prior is over. Not over patterns, but over decay. Having watched hundreds of codebases evolve, they can look at a warped shape and reconstruct the erosion: this was once a clean separation, then a deadline happened, then a hotfix happened. Their mental library includes the degraded versions of every pattern, because they have personally watched the degradation happen.

Models are trained mostly on snapshots — final states, clean tutorials, curated open source. Their library holds the pristine versions. So faced with drifted code, a model does what it was trained to do: it matches the mess to the nearest clean shape and confidently describes the codebase as the textbook version of whatever it most resembles. But which clean shape, if any, this mess descended from is precisely the question that was supposed to be investigated, not assumed away. Pattern-matching the noise to a pristine archetype is guessing at the story instead of recovering it.

What agents do instead

Deprived of the story, agents default to greenfield style: take the existing code as ground truth, assume everything in it is intentional, and build the new thing on top. A new abstraction here, a new entity there. Nothing is ever deleted; each session adds a stratum. The result is geological: layers on layers, each written as if everything below it were load-bearing.

If you've watched an agent work on a mature project, you've seen this: it doesn't refactor the workaround — it respects it. Wraps it, generalizes it, builds on it. The workaround becomes architecture.

One clarification, because it causes a lot of confusion: agents are quite good at the mechanics of refactoring. Tell one "extract this logic into a module, keep behavior identical, update all call sites" and it will do a decent job. This fools people. Fowler's catalog — extract method, move field, rename — is the last mile of refactoring. The hard part was never executing the moves; it's deciding that moves are needed, which ones, and toward what design. Judgment, not mechanics. Agents pass the mechanics test, and it tells us nothing about the judgment.

The economics flip

So here is my suspicion: maybe with AI it is simply cheaper to throw the code away and regenerate it. Look at what a rewrite actually involves:

1. Extract the requirements — explicit and implicit.
2. Design against them.
3. Write the code.

That's the greenfield pipeline with one pre-step attached. No smell detection, no archaeology, no step-6 migration plan — most of the seven-step backward pipeline simply disappears. Mass production killed the repair shop for exactly this reason: when manufacturing a new unit costs less than diagnosing the old one, nobody fixes anything. Code generation is heading toward free. Code diagnosis is not.

Open the interactive edition

Package removal does not work because it's a dependency of many other packages. What actually works is to remove all ways of starting gnome-keyring-daemon like so

mkdir -p ~/.local/share/dbus-1/services
cp /usr/share/dbus-1/services/{org.freedesktop.impl.portal.Secret.service,org.freedesktop.secrets,org.gnome.keyring.service}.service ~/.local/share/dbus-1/services
# replace last line with "Exec=/usr/bin/true"

cp /etc/xdg/autostart/gnome-keyring-{pkcs11,secrets,ssh}.desktop ~/.config/autostart
for f in ~/.config/autostart/gnome-keyring-*.desktop; do echo "Hidden=true" >> $f; done

BTW, may be it's simpler to sudo chmod -x /usr/bin/gnome-keyring-daemon

google_analytics: G-XXX # https://support.google.com/analytics/answer/9306384
remote_theme: jekyll/minima
plugins:
- jekyll-remote-theme
minima:
  skin: dark

Thanks to https://github.com/jekyll/minima/issues/561#issuecomment-748793956

1. reboot to fastboot adb reboot bootloader
2. boot to TWRP fastboot boot twrp.img
3. after booting twrp decrypt /sdcard using your pin/pattern
4. connect to device using adb adb shell
5. copy boot partition to sdcard dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img
6. reboot to system adb reboot
7. launch MagiskManager
8. press "Install" in "Magisk" card
9. uncheck "Recovery Mode"
10. press next
11. select boot.img file on the sdcard root
12. after successeful patch pull patched boot image to pc adb pull /sdcard/Download/magisk_patched-*.img ./
13. reboot to bootloader again adb reboot bootloader
14. flash patched boot image fastboot flash boot magisk_patched-*.img
15. reboot to system fastboot reboot
16. profit!

yay -S lnd

Configure

mkdir ~/.lnd
cat <<EOF
bitcoin.active=true
bitcoin.mainnet=true
bitcoin.node=neutrino
feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json
no-rest-tls=true
EOF > ~/.lnd/lnd.conf

Create wallet

lnd &
lncli create
# pass password here and save seed phrase afterwards
kill %1

Setup autounlock and start lnd

echo "<password-for-the-wallet>" > ~/.lnd/wallet.password
echo "wallet-unlock-password-file=~/.lnd/wallet.password" >> ~/.lnd/lnd.conf
lnd &

Obtain inbound liquidity

• go to https://lnbig.com
• initiate the payment
• provide node id lncli getinfo | jq -r .identity_pubkey
• use NodeID@Host:Port to connect to the node lncli connect <addr>
• wait for on-chain confirmation