{"version":"https://jsonfeed.org/version/1.1","title":"Nikolay Bryskin","home_page_url":"https://zxczxc.dev/","feed_url":"https://zxczxc.dev/feed.json","description":"Notes on systems, Linux, and engineering","language":"en","items":[{"id":"https://zxczxc.dev/posts/mouse-over-wifi/","url":"https://zxczxc.dev/posts/mouse-over-wifi/","title":"Mouse over WiFi","language":"en","content_html":"

Today I found that I needed to connect a USB mouse to my laptop — and both\nUSB-C ports were occupied, one by the monitor, one by power. Turns out it's\nnot a huge deal on Linux if you have another PC nearby.

\n

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

\n\n

Pick your layer

\n

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

\n

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

\n

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

\n

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

\n

The five-minute version

\n

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

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

Then, from the laptop, one pipe:

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

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

\n

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

\n\n

The grown-up version: socket activation

\n

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

\n

\"Events

\n

Two unit files on the server. The socket:

\n
# /etc/systemd/system/zxc-mouse.socket\n[Unit]\nDescription=Export Logitech mouse over Tailscale (netevent)\n\n[Socket]\nListenStream=8763\nBindToDevice=tailscale0\nAccept=yes\nMaxConnections=1\n\n[Install]\nWantedBy=sockets.target\n
\n

And the per-connection service it spawns:

\n
# /etc/systemd/system/zxc-mouse@.service\n[Unit]\nDescription=netevent mouse stream to %i\n\n[Service]\nExecStart=/usr/bin/netevent cat /dev/input/by-id/platform-noserial-if01-event-mouse\nStandardInput=socket\nStandardOutput=socket\nStandardError=journal\nDynamicUser=yes\nSupplementaryGroups=input\n
\n

Almost every line here is doing security or lifecycle work:

\n\n

The lifecycle falls out of the socket activation for free:

\n

\"Sequence

\n

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

\n

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

\n
# /etc/systemd/system/zxc-mouse.service\n[Unit]\nDescription=Attach Logitech mouse exported by zxc-pc\n\n[Service]\nExecStart=/bin/sh -c 'socat -u TCP:zxc-pc:8763,keepalive,keepidle=5,keepintvl=5,keepcnt=2 STDOUT | netevent create --duplicates=resume'\nRestart=always\nRestartSec=2\nRestartSteps=8\nRestartMaxDelaySec=60\nDynamicUser=yes\nSupplementaryGroups=input\n
\n

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

\n

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

\n

Did the interface scoping actually work? Two checks:

\n
$ ssh zxc-pc ss -tln | grep 8763\nLISTEN 0  4096  *%tailscale0:8763  *:*        # the % is SO_BINDTODEVICE\n\n$ nc -z -w3 192.168.88.247 8763               # via LAN: refused\n$ systemctl start zxc-mouse && systemctl is-active zxc-mouse\nactive                                         # via tailnet: streaming\n
\n

The landmine

\n

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

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

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

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

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

\n

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

\n

Was it worth it?

\n

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

\n

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

\n","tags":["linux","systemd","networking","tailscale"],"date_published":"2026-07-24T00:00:00.000Z","image":"https://zxczxc.dev/uploads/mouse-over-wifi/cover.jpg"},{"id":"https://zxczxc.dev/posts/why-ai-agents-are-bad-at-code-refactoring/","url":"https://zxczxc.dev/posts/why-ai-agents-are-bad-at-code-refactoring/","title":"AI agents are bad at code refactoring","language":"en","content_html":"

Give an AI agent an empty directory and a page of requirements, and it will impress you. Give the same agent an existing codebase and a one-line feature request, and there's a good chance it will leave the project slightly worse while fully satisfying the request.

\n\n

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.

\n

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

\n

Two forward passes

\n

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

\n

requirements → design → code

\n

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.

\n

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.

\n

Refactoring runs the pipeline backwards

\n

\"Mental

\n

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:

\n\n

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

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

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.

\n

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.

\n

Step zero: the smell

\n

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.

\n

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.

\n

Refactoring is a compression task

\n

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.

\n

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.

\n

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.

\n

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.

\n

What agents do instead

\n

\"Drake

\n

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.

\n

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.

\n

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.

\n

The economics flip

\n

\"Vince

\n

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:

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

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.

\n","tags":["ai","refactoring","programming","softwareengineering"],"date_published":"2026-07-23T00:00:00.000Z","image":"https://zxczxc.dev/uploads/why-ai-agents-are-bad-at-code-refactoring/cover-lis3cjixcg02u0l36n8n.jpg"},{"id":"https://zxczxc.dev/posts/kilobyte-utxo-set/","url":"https://zxczxc.dev/posts/kilobyte-utxo-set/","title":"The Kilobyte UTXO Set: Utreexo, SwiftSync, and Bitcoin's state problem","language":"en","content_html":"

Every Bitcoin node drags a 12 GB database through its whole life just to answer one question: does this coin exist? This article — published as an interactive edition — shows how Utreexo compresses that answer into about thirty hashes. Add coins, watch equal-height trees carry-merge, and spend them with Merkle proofs, right in the page.

\n

\"Playground

\n

Open the interactive edition

\n","tags":["bitcoin","cryptography","datastructures"],"date_published":"2026-07-16T00:00:00.000Z","image":"https://zxczxc.dev/uploads/kilobyte-utxo-set/cover-bfjad0ppv1wiq78l2c2p.png"},{"id":"https://zxczxc.dev/posts/no-gnome-keyring-daemon/","url":"https://zxczxc.dev/posts/no-gnome-keyring-daemon/","title":"How to stop gnome-keyring-daemon prompts","language":"en","content_html":"

In Gnome there is gnome-keyring-daemon that should be unlocked to provide access to keyrings. By default it unlocks using login password,\nbut if you use fingerprint or face unlock then it will prompt you to enter password every time any process try to access keyring.\nFor my setup it's 6 times after login and 2 times when I start the browser.

\n\n

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

\n
mkdir -p ~/.local/share/dbus-1/services\ncp /usr/share/dbus-1/services/{org.freedesktop.impl.portal.Secret.service,org.freedesktop.secrets,org.gnome.keyring.service}.service ~/.local/share/dbus-1/services\n# replace last line with "Exec=/usr/bin/true"\n\ncp /etc/xdg/autostart/gnome-keyring-{pkcs11,secrets,ssh}.desktop ~/.config/autostart\nfor f in ~/.config/autostart/gnome-keyring-*.desktop; do echo "Hidden=true" >> $f; done\n
\n

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

\n","tags":["linux","gnome"],"date_published":"2022-05-24T00:00:00.000Z"},{"id":"https://zxczxc.dev/posts/github-pages/","url":"https://zxczxc.dev/posts/github-pages/","title":"How to make a personal blog on GitHub Pages (with Google Analytics)","language":"en","content_html":"

Create regular Github Pages repo, then edit _config.yaml:

\n
google_analytics: G-XXX # https://support.google.com/analytics/answer/9306384\nremote_theme: jekyll/minima\nplugins:\n- jekyll-remote-theme\nminima:\n  skin: dark\n
\n\n

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

\n","tags":["jekyll","github-pages"],"date_published":"2022-05-09T00:00:00.000Z"},{"id":"https://zxczxc.dev/posts/tucana/","url":"https://zxczxc.dev/posts/tucana/","title":"How to install Magisk on Xiaomi Mi Note 10 (tucana)","language":"en","content_html":"
    \n
  1. unlock bootloader
    2. \n
  2. install MagiskManager
    3. \n
  3. download TWRP
    4. \n
  4. enable USB debugging and connect adb
    5. \n
\n\n
    \n
  1. reboot to fastboot adb reboot bootloader
    2. \n
  2. boot to TWRP fastboot boot twrp.img
    3. \n
  3. after booting twrp decrypt /sdcard using your pin/pattern
    4. \n
  4. connect to device using adb adb shell
    5. \n
  5. copy boot partition to sdcard dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.img
    6. \n
  6. reboot to system adb reboot
    7. \n
  7. launch MagiskManager
    8. \n
  8. press "Install" in "Magisk" card
    9. \n
  9. uncheck "Recovery Mode"
    10. \n
  10. press next
    11. \n
  11. select boot.img file on the sdcard root
    12. \n
  12. after successeful patch pull patched boot image to pc adb pull /sdcard/Download/magisk_patched-*.img ./
    13. \n
  13. reboot to bootloader again adb reboot bootloader
    14. \n
  14. flash patched boot image fastboot flash boot magisk_patched-*.img
    15. \n
  15. reboot to system fastboot reboot
    16. \n
  16. profit!
    17. \n
\n","tags":["android","magisk"],"date_published":"2022-05-06T00:00:00.000Z"},{"id":"https://zxczxc.dev/posts/lnd-node/","url":"https://zxczxc.dev/posts/lnd-node/","title":"How to create an lnd node ready for accepting payments","language":"en","content_html":"

Install lnd

\n
yay -S lnd\n
\n\n

Configure

\n
mkdir ~/.lnd\ncat <<EOF\nbitcoin.active=true\nbitcoin.mainnet=true\nbitcoin.node=neutrino\nfeeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json\nno-rest-tls=true\nEOF > ~/.lnd/lnd.conf\n
\n

Create wallet

\n
lnd &\nlncli create\n# pass password here and save seed phrase afterwards\nkill %1\n
\n

Setup autounlock and start lnd

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

Obtain inbound liquidity

\n\n","tags":["bitcoin","lightning","linux"],"date_published":"2022-05-03T00:00:00.000Z"}]}