Callum Bryce

The one thing that genuinely matters is that you tested the PCB before committing. Everything else is speed, and speed is worth nothing on a board you build once every two years.

Ear plugs. The filtered kind musicians use, not foam. Sounds absurd and it took a bar evening from unbearable to fine.

Ring the card issuer and ask for a rate reduction before you start. Nine years of on time payments is leverage and the worst outcome is that they say no. Took me four minutes and 4 percentage points once.

The ethernet socket point is right. Half the rooms I stay in have a dead looking port behind the desk that turns out to be a clean 100 meg line with nobody else on it. Carry a short cable and a USB adapter.

Before you buy a board, get someone to look at the board. Nine times out of ten a drain fault that intermittently trips out is a burnt relay or a bulged capacitor on the pump circuit, and both are visible if you take the board out and look at it under a lamp. A relay is a two dollar part.

There are people who do board level repair on these by post for 60 to 90 with a warranty, and there is a decent used market for the same board number. Full price from the manufacturer is the worst option on the list.

Clipping the two plastic legs off five pin switches is also completely fine if the plate holds them. Saves a lot of grief on hotswap boards.

Quick way to tell where to look in general: a dead row points at a row trace or its diodes, a dead column points at the controller pin or the column trace, and scattered dead keys point at switches. Also worth flashing the stock firmware again and checking the matrix definition, because if you touched the keymap at any point you can produce exactly this symptom in software.

That is textbook tap hold ambiguity on an LT() key, and it is worse on a key that sits under a strong finger in the middle of a roll.

Things to try, in order. Raise TAPPING_TERM to about 200 and see if the failure rate drops; the default is often too short for a key you hold while typing fast. Then, for layer keys specifically, HOLD_ON_OTHER_KEY_PRESS is usually what you want, because it says that if another key is pressed while this one is down, treat it as a hold immediately rather than waiting out the timer. PERMISSIVE_HOLD is the alternative and it triggers on the other key being released instead, which behaves differently in rolls.

If raising the term globally makes your other keys mushy, use per key tapping term and only lengthen that one key.

The deeper issue is that a nav layer on a home row alpha will always be the hardest case. If you can move it to a thumb, the problem stops existing rather than being tuned around.

Sent the overlap message. They replied fine with that in eleven minutes, which is annoying given I spent six weeks not asking.

It is translating your apps into a form your specific phone can run fast, and it has to redo it because the update changed the thing it translates against.

Apps are shipped in a portable intermediate form so that one download works on many different phones. Running that form directly is slower, so at install time the phone compiles it into native machine code for its own processor and stores the result. That compiled copy is what actually runs when you tap the icon.

When the system updates, the runtime libraries underneath change, so every one of those stored copies is stale and potentially invalid. Rather than have every app be slow the first time you open it, the phone does the whole batch up front. That is the counter you are watching.

Nothing is being scanned for problems, nothing is being deleted, nothing is going anywhere off the device. It is a build job. The reason you should not interrupt it is simply that it is doing heavy work and yanking power mid write is a bad idea, not because something delicate is being repaired.

The battery drain afterwards is the same story continuing. Caches and search indexes get rebuilt in the background over the following day, and then it settles.