• 4 Posts
  • 26 Comments
Joined 1 个月前
cake
Cake day: 2026年9月17日

help-circle
  • on the fear part, in a healthy team the author still owns the change, the reviewer is a second pair of eyes not an insurance policy. what helped my people a lot was asking the author how they tested it and what happens if it goes wrong, if they can’t answer that’s your review comment right there. and if something breaks after you approved it, you fix it together and add a check so it doesn’t happen again, nobody serious blames the reviewer for that


  • They don’t go away on their own, every installed snap is mounted as its own loop device and snapd keeps an older revision or two so it can roll back, so the number moves around after updates. snap list --all shows which snaps they are, if one says disabled that’s the old revision and you can remove it with sudo snap remove <name> --revision=<rev>. about libation, if it’s installed as a snap itself that could be the actual problem, snaps are confined and can’t read folders outside your home or on other drives unless you connect the removable-media interface, so I’d check that before worrying about the loop devices.












  • Same conclusion here from the other side, I have a small multiplayer browser game where everyone paints cells on one shared grid (node, postgres, SSE), the client applies the paint right away and the server either confirms it or answers with a 409/429 and the client puts the old cell back. the rejection part is the one that took me longest honestly, a mutation that is valid locally but the server says no (out of charges, same color already there, world paused) and you need a different message for each, otherwise people think it’s lag. conflicts are just last write wins per cell, but that works because every write is a row in an append only events table, so nothing is really lost and you can replay or undo. and on reconnect I don’t try to merge anything, the client asks for the whole state again, at that size it’s cheaper than being clever.