If a Tauri 2 app fails while it boots, the user sees nothing. I found this out with a missing environment variable: the app panicked, the terminal got a stack trace, and anyone launching it from an icon would have seen an app that refuses to open. This post is the fix I used, which is a native error dialog shown before Tauri starts, plus a clear account of which boot errors it traps and which it does not. ...
The first Excalidraw file Claude Code wrote for me opened as a page of colored rectangles with nothing written on them. No error, no warning in the console. It had put a text property on each rectangle. Excalidraw loads that without complaint and then draws nothing. That was the first failure. It was not the last, and the later ones were quieter. This is a report from one agent on one project, not a rule about agents. Over a few sessions Claude Code wrote, and then rebuilt, a 13-frame architecture diagram for a platform design, working from a design doc. It failed in five ways. Each one got a constraint that turns the failure into an error, and those constraints are now a Claude Code skill. The list below is what happened, in the order I hit it. ...
A step-by-step SSH hardening guide for a first VPS on the RHEL 10 family (AlmaLinux, Rocky, CentOS Stream). Key-only authentication, no root login, brute-force limits, a safe port move, and SELinux left enforcing, with every command shown and the lockout traps called out.
A checkout flow that reserves inventory, charges a card, and creates a shipment touches three services, each with its own database. If the charge succeeds but the shipment service is down, the order is now paid with no shipment record, and nothing rolled back the inventory reservation either. That’s not an edge case. Any transaction that crosses a service boundary has this failure mode, because there’s no single database transaction wrapping all three writes. ...
Somewhere in your stack there’s a payment flow that died between “card charged” and “order marked paid,” and nothing remembers the gap. Or a “remind the customer in 48 hours” job that lived in a scheduler’s memory until the scheduler restarted. Or an onboarding that spans five services and three days, and the only way to answer “where is it now?” is grepping logs across all five and reconstructing the timeline by hand. None of these are exotic failures. They’re the standard cost of building long-running business processes out of queues, cron jobs, and status tables, and every team that does it long enough hits all three. ...
I used to build VMs by hand. Click through the wizard, guess an IP, forget which VLAN it went on, and a month later nobody remembers why vm-1042 exists. This post is the replacement: OpenTofu + Terragrunt cloning from a golden template on vSphere, driven by a least-privilege SSO user. Everything here survived a real production estate, including the parts that cost me actual debugging time: the permission model in vCenter is full of silent traps, and I’ll point at every one of them. ...
This is Part 2 of the Solana Authorities series. In Part 1 we covered the authority pattern itself: what authorities are, how they differ from ownership, and what None means. Now we go deep on the two authorities every SPL token has. Disabling the mint authority does not disable the freeze authority. A token with a “renounced” mint can still have every holder locked out of their tokens. These are two independent fields in a single 82-byte account, and checking only one of them is not enough. ...
This is Part 1 of the Solana Authorities series. If you work with tokens, NFTs, staking, or governance on Solana, this series maps every authority field you will encounter, what each one controls, and what happens when you hand it off or burn it. The problem Every Solana intro tutorial mentions “the mint authority” once, in passing, when teaching spl-token create-token. Almost no tutorial explains: That the mint has a separate freeze authority that can disable transfers for any holder. That Token-2022 added roughly a dozen additional authority slots through extensions, several of which can move user funds without consent. That stake accounts have two authorities (stake and withdraw), and losing the withdraw authority is permanent loss of principal, not just rewards. That Metaplex metadata has its own update authority that controls how wallets and marketplaces render an NFT, independent of who holds it. That governance programs (SPL Governance, Squads, Realms) are themselves just programs that hold authorities on behalf of a DAO, and the security model collapses to whatever those programs enforce. Most rugs, freezes, and operational mistakes on Solana trace back to one of these fields being misunderstood. ...
This is Part 6 of the Solana Program Lifecycle series. In Part 5 we covered the upgrade authority lifecycle, from a single keypair through Squads multisig and SPL Governance to the irreversible --final flag. Now we step back and look at the whole pipeline: how a program moves from a file on your laptop to live bytecode on mainnet. The short answer: it is more than solana program deploy. The deploy command is the last step, not the whole thing. Developers who skip straight to mainnet tend to discover this when a partial buffer upload stalls at 3 AM, or when a CPI that worked perfectly in local testing silently fails because the account it needed never existed outside mainnet. ...
This is Part 5 of the Solana Program Lifecycle series. In Part 4 we walked through the deploy and upgrade flows: the Buffer account, the chunked writes, and the activation step that copies bytecode into the ProgramData account. Every upgrade instruction checks one thing before it proceeds: who is allowed to do this. That one thing is the upgrade_authority_address field: 33 bytes in the ProgramData account that control who can replace the program’s bytecode. This post traces the full lifecycle of that field, from the keypair that deployed the program to the irreversible --final flag that writes None and freezes the program forever. ...