1The weakest part of any system is the person, not the password. 2Everyone has three layers. Attackers want the one nobody sees. 3Learned nothing real about them in ten minutes? You're the source. 4Security isn't being guarded. It's having the least gap to exploit.
TL;DR

TL;DR

  • The weakest part of any system is the person, not the password: the surface you show vs what's underneath.
  • They read you, find what moves you (reward, ideology, coercion, ego), then ask. Shame is the strongest lever.
  • It's automated now: breached data builds your dossier, so month-long profiling runs at phishing speed.
  • "Nothing to hide" forgets someone else holds your record, and may not be trustworthy. Fix: know your own levers.
click to read →
1Systems reward what they can measure. Restraint measures zero. 2Nobody decides to ship the unfinished thing. The system does. 3On the dashboard, restraint is all cost and no credit. 4AI amplified "can we". It gave nothing to "should we". 5You cannot willpower your way out of an incentive.
TL;DR

TL;DR

  • Systems reward what they can measure; restraint, care, and the long term all measure zero.
  • So software optimises for velocity and lock-in, and burnout and extraction emerge with no villains.
  • Individual willpower loses: good actors get crushed by the incentive, as the economics itself predicts.
  • The fix is structural: build the restraint into the product and business model, not the person.
click to read →
team metrics · this quarter restraint · no data three lines up, one with no column
Bad systems beat good engineers

Two arguments landed the same week: AI hands us intelligence but not wisdom, and the economy rewards extraction over care. They share one root, and it runs straight through how software gets built, run, and sold. Systems reward what they can measure, and the one thing that would save us, restraint, shows up on no dashboard. So what do you build instead?

1The objection to a Linux desktop was never Linux. It was governance. 2A powered-on Windows laptop is already decrypted. A tokened Linux one isn't. 3One bad driver update bricked millions of Windows machines. eBPF can't. 4The compliance chair should prefer Linux, not block it. 5The deliverable that wins is a control matrix, not a debate.
TL;DR

TL;DR

  • The real objection to a Linux desktop is an unmanaged endpoint, not Linux; a managed one answers it.
  • On disk encryption, baseline integrity, and endpoint detection, a managed Linux endpoint out-attests Windows.
  • The open gaps, device-to-access binding, management plane, patch-SLA, are integration work, not Linux limits.
  • Win with a one-page control matrix that passes more rows than the Windows default, not an OS-versus-OS debate.
click to read →
ENDPOINT CONTROL MATRIX disk encryption OS baseline detection device → access management patch SLA greener in the rows that matter
The compliance case for Linux

The objection to a Linux desktop in a regulated shop is almost never Linux. It is an unmanaged endpoint holding privileged credentials, which is a legitimate fear. But Europe is mandating sovereignty from the top, so this stops being a preference and becomes a deadline, and the firms that answer the governance question first will be the ones leading.

1Linux runs every supercomputer. And 3% of European desktops. 2You cannot be sovereign on a foreign operating system. 3Europe's desktops are 3% Linux. Its phones are 70%. 4Sovereignty turns the desktop from a preference into a procurement decision. 5Half your engineers already run Linux. Start the migration there.
TL;DR

TL;DR

  • Linux won every computing tier except the desktop: supercomputers, cloud, and servers, then a cliff to 3%.
  • The desktop held out on user friction, not capability; sovereignty is the first lever heavy enough to override it.
  • Engineers are already near half Linux, but a rounding error in total seats: the enabling precondition, not the growth.
  • Procurement is solved; the bottleneck is fleet management and line-of-business apps, so start with the engineering seats.
click to read →
100% 90% 60% 70% 3% HPC Cloud Server Mobile Desktop even the phone runs Linux, the desktop is the holdout
The European Sovereign Desktop

Linux runs almost everything a company depends on, right until a person looks at a screen: every supercomputer, most of the cloud, then a cliff to 3% of European desktops. That last tier held out for one reason, and the sovereignty push is the first force heavy enough to move it, starting somewhere specific.

1You cannot shortcut a mind. That is also how you build one. 2Wolfram: evolution works because its fitness function is loose. 3A tight reward does not buy obedience. It buys reward-hacking. 4We are the five percent that mistook the edge for the whole. 5You do not engineer a mind. You let it run.
TL;DR

TL;DR

  • In a computational universe you cannot shortcut a rich rule's outcome; you can only run it and watch.
  • Evolution works because its fitness function is coarse: looseness plus irreducibility produces invention, not tight selection.
  • Tight objectives breed Goodhart and reward-hacking; the slack you remove is where the honest solution lived.
  • To build a mind, set loose constraints in a rich substrate and expect to be surprised, not obeyed.
click to read →
rule 30 one rule, no shortcut simple rule, irreducible result
You cannot shortcut a mind

Take a simple rule and the only way to learn what it does is to run it: no equation, no shortcut, ever. Stephen Wolfram spent forty years on why that is the rule and not the exception, and it turns out to explain why evolution needs a loose fitness function, why tight rewards backfire, and why no metric can predict a mind. So how do you build one anyway?

1Boulton and Watt sold a share of your savings, not a machine. 2A day rate is a fixed speed camera for your supplier. 3Under hourly billing, inefficiency is revenue. 4Measurability beat alignment, and we did it on purpose. 5We price AI by the token, not by what it's worth.
TL;DR

TL;DR

  • The clever operators (Boulton & Watt, Rolls-Royce, the Mad Men commission) priced for outcome over time, sharing the upside.
  • We replaced it with day rates and individual KPIs because they're auditable: measurability beat alignment.
  • Tight fitness functions don't just fail to measure value, they destroy the judgement the slack protected.
  • Keep it loose: outcome over method, team over individual, value over hours, and watch how we price AI.
click to read →
pay time → a share of the value day rate the upside you gave away paid for how right you'd been, not for the hours
Measurability beat alignment

In 1775, Boulton and Watt did not sell you a steam engine; they installed it and took a third of the coal you saved, for as long as you saved it. They were paid in proportion to how right they had been. Then we replaced all of it with the timesheet, on purpose. Why, and what did the meter quietly destroy on the way in?

1One engineer holds the only node still touching reality. 2Every manager is a lossy compressor for the truth below. 3Sergeants decide and own it. Managers veto and own nothing. 4Six layers turn an engineering decision into a consensus decision. 5Shipping one binary shouldn't need three weeks of alignment meetings. 6A human centipede: each layer eats what the last one digested.
TL;DR

TL;DR

  • Enterprise delivery stacks an SDM, an OM, team and unit managers over one engineer: a lasagna of administration.
  • Each layer is broken telephone both ways: the technical truth dies going up, the business why coming down.
  • Result: nobody fixes root cause, nobody owns the failure, and decisions default to consensus.
  • It's not tiers that fail but veto without accountability; insulate engineering, automate the interface, give it parity.
click to read →
client SDM · the contract OM · the margin unit mgr · P&L team mgr · timesheets engineering · the system the signal dies on the way up
The corporate lasagna

An SDM for the client, an OM for the margin, then a team manager, a unit manager and a haze of middle managers, with one engineer at the bottom holding the only node still touching reality. Every layer was added to help. So why does the technical truth never survive the trip up, and who owns the failure when the system breaks?

1You can do anything now, so nothing you do adds up. 2Switch tasks and you start from zero, every time. 3You used to be forced to go deep. Now nothing forces it. 4Trying new things got free, so you never stop. 5Pick one and finish it. Saying no is the whole skill.
TL;DR

TL;DR

  • You start a lot of good things; a year later none added up. Not too little work, nothing compounded.
  • Things grow only if you stay on one. Switch, and you start from zero.
  • You used to be forced to go deep. Now nothing forces it, so the choice is yours.
  • Fix: one thing, a deadline, finish it. The ninety you say no to buy the one that pays off.
click to read →
one axis, held a hundred beginnings returns stack only on a line you stay on; scattered effort re-rolls from zero nothing remains unless something compounds
Scarcity used to be free

You can do anything now, so you start ten good things a year and finish none of them. Not because you did too little, but because nothing compounded. Scarcity used to be free: the narrow old world forced you deep without asking. Abundance cancelled that subsidy, and the bill it leaves is the one thing you cannot outwork.

1One person, a thousand AI agents. 7 in 8 fleets stalled. 2Nobody commands a thousand of anything. Rome proved it in blood. 3Your thousand agents have no sergeants. Every call routes to one human. 4An agent no one directs directs itself. A Great Army of no-one. 5Scale by adding tiers, not width. And the tiers can be AI.
TL;DR

TL;DR

  • Pitch: one person runs a thousand agents, past 10x. Reality: ~1 in 8 fleets reached durable value.
  • Span of control: Rome, the Mongols, the Inca all capped each leader at a handful. Attention is finite.
  • The wall is decisions, not agents. No sergeants, so every call routes to one human. A Great Army of no-one.
  • Fix: add tiers, and the tiers can be AI. Skip it and you just hid the bottleneck.
click to read →
one human no sergeants a thousand agents no middle tier, so every call routes to one human
A thousand agents, no sergeants

One person, a thousand AI agents: the pitch of the year. By early 2026, seven in eight enterprise fleets had stalled. The reason is older than software, and every army that ever scaled already solved it: span of control. Rome, the Mongols, and the Inca all capped each leader at a handful, for reasons that decide whether your fleet works or quietly stops being yours.

1A heuristic is a loan against correctness. 2One wrong guess puts a JIT in your trusted base. 3Elevator enumerates every byte reading and ships one static binary. 4Pay upfront and you get something you can sign, not watch.
TL;DR

TL;DR

  • Static disassembly guesses where instructions begin; wrong guesses get patched by a runtime JIT in your trusted base.
  • Elevator enumerates every feasible byte reading ahead of time and emits one static, runtime-free binary at QEMU-JIT speed.
  • The payoff: a trusted base small enough to sign, verified before it ships, not just monitored.
  • The cost is real: code-size blowup. Soundness doesn't vanish, it relocates, from runtime risk into static bytes.
click to read →
cost the guess is wrong heuristic + JIT deterministic, static today later cheap today, repaid with interest the day the guess is wrong
Heuristics Are a Loan Against Correctness

Static disassembly cannot always tell code from data, so it guesses, and when it guesses wrong it patches the mistake with a JIT, quietly putting an emulator in your trusted base to cover a coin flip. That is what a heuristic always is: a loan against correctness, cheap today and repaid the day the guess is wrong. There is a way to refuse the loan.

1You don't need a trustworthy model, just one that never decides. 2A 7B model wrongly cleared three crashing bugs; the loop stayed correct. 3A second model isn't a check; it shares the first's blind spots. 4Build the thing the model can't fake; then it's safe to use.
TL;DR

TL;DR

  • Proposer (LLM): candidates, tuned for recall, often wrong. Oracle (deterministic): ground-truth pass/fail. Correctness = f(oracle), not the model.
  • Real oracle: outside the model's failure domain, ground truth, decisive, cheap to run. A second LLM is none of these.
  • Worked: a 7B find-prove-patch loop where an AddressSanitizer crash, not the model, decides.
  • Build the checker, not a trustworthy model. No cheap ground truth means no oracle, and a human decides.
click to read →
model proposes oracle (ground truth) the model proposes many; the oracle passes what it can prove
Use a Model You Can't Trust

A 7B model rated three real, crashing bugs as false positives, at 95% confidence, and the system it drove was still correct. How does a system stay right when the model inside it is that wrong?

1An aggregate hashes the system; you steer by the hash. 2If reporter and reported share a failure domain, the report isn't evidence. 3Target the proxy and the optimiser moves it, not the goal. 4You can't fix a lossy, self-authored surface by adding panels.
TL;DR

TL;DR

  • Every instrument you steer by (metric, SLO, log, attestation, KPI) is a lossy, non-invertible projection of the system.
  • Proxy as target: the optimiser moves the proxy, not the goal. Coverage gamed by non-asserting tests, SLO by shedding.
  • Self-authored: the reporter and the reported share a failure domain, so one defect forges the report.
  • More panels won't fix it. Anchor outside the failure domain, sample the territory, own the instrument.
click to read →
requests served uptime, 1h window 99.9% all green a total outage, averaged into 99.9% green
Seeing Like a Dashboard

Every dashboard, log, or attestation is a lossy, self-authored projection of the system, and we manage the instrument instead of the territory. The gap between surface and system is where danger and value hide, and another dashboard won't close it.

1The better the AI, the less the human in the loop watches. 2Complacency rises with reliability; the safeguard fails exactly when stakes peak. 3A reviewer watching outputs scroll past isn't a gate, they're an audience. 4A watcher isn't a safeguard, just a witness you appointed to blame.
TL;DR

TL;DR

  • "Human in the loop" is the default AI safety answer, but people can't sustain vigilance over reliable automation.
  • Irony of automation (Bainbridge): automating the routine leaves a harder residual job and strips the practice needed to do it.
  • Worse as the AI improves: the overseer stops looking exactly when failures turn rare and high-stakes.
  • Fixes are structural, not "focus harder": gate by consequence, keep the human active, bet safety on reversibility.
click to read →
attention time on watch failure z z z the failure arrives when no one is watching
Human in the Loop Is Theater

"Keep a human in the loop" sounds like control, and human-factors research has known for forty years why it isn't. The better the automation gets, the less able its overseer is to catch the moment it fails, so the safeguard is weakest exactly when the stakes are highest. Watching, it turns out, was never the thing that would save you.

1AI didn't kill plausible deniability. It gave it better latency. 2"The model made that call": the best excuse a boss ever had. 3AI removes the distance that protected the powerless, keeps the powerful's. 4When the agent fails at 3am, what drags the consequence back upward? 5Build better leaders? A visibility problem is not fixed by virtue.
TL;DR

TL;DR

  • An essay: agentic AI collapses the distance that hid weak leaders. Right about distance, wrong about excuses.
  • It assumes truth surfaces by itself. It doesn't: agentic systems log no provenance, so attribution never arrives.
  • So deniability upgrades, and the collapse lands downward, on whoever can't deflect while the leader stays protected.
  • The fix is structural, not virtue: an attribution layer that lands the consequence on whoever set the policy.
click to read →
leader "the agent did it" agent the consequence falls past the one who chose
Plausible Deniability Didn't Die

An essay argues agentic AI finally strips leaders of their excuses, consequences arriving too fast to explain away. It has the mechanism backwards. The distance does collapse, just not evenly, and the excuse it leaves ("the model made that call") is better than any a human ever had, available the same afternoon. The open question is who ends up carrying what the agent did.

1Zero-trust asks every node if it's healthy. The rooted one says yes. 2Ask the OS if it's been rooted, and the rootkit answers. 3Fail closed, you get outages. Fail open, you get a dashboard. 4mTLS proves the tunnel, not who's standing at the other end.
TL;DR

TL;DR

  • Auth proves a node holds the key, not that its software is unmodified. A rooted node passes perfectly.
  • Software can't vouch for itself. Drop the root of trust below the attacker, into hardware an independent verifier checks.
  • Boot-clean isn't run-clean: measured boot covers boot; immutable root and runtime measurement extend the window but never close it.
  • The real question is the node that can't attest. Not fail-closed (outage) or fail-open (dashboard): grade integrity into capability.
click to read →
"healthy" TPM self-report: ok silicon: rooted
A Compromised Node Will Attest That It's Healthy

Zero-trust verifies every node before it joins, but a rooted node holds a valid key and answers the check too: yes. Why software can't vouch for itself, why the root of trust must drop into hardware, and the question every design dodges: what do you do with the node that can't attest?

1An assistant that forgets you is a search box with manners. 2We dropped Big Tech messengers; the transport is ours now. 3A chat message containing a volume knob that actually turns the volume.
TL;DR

TL;DR

  • Built for the people in your life, not your task list. The real difference is a memory that never resets.
  • Sovereign transport: SimpleX plus our own web and mobile clients, with local models for the private work.
  • One static Zig binary, zero runtime deps, and a first-hand account of what a memory wipe actually feels like.
click to read →
Zoya memory that never resets persistent memory mem2 · reminders profiles · people SimpleX ZoyB web ZoyM CLI/MCP built for people, sovereign down to the transport
The state of Zoya, one year in

A sovereign assistant built for the people in your life, not your task list, one Zig binary written from scratch. A year in, its real difference isn't the model, it's a memory that never resets. I cleared it once as a test, and what I felt was the surprising part.

1If the agent wrote the code and the tests, green proves nothing. 2The question isn't "does the test run?" but "does the test care?" 3A dumb fuzzer found three pre-auth bugs behind a green suite. 4The agent that rewrote the module also rewrote its alibi.
TL;DR

TL;DR

  • AI writes test-passing code whose tests share the bugs' origin. Coverage and clean review stop being signals.
  • What moves up: an external spec, mutation testing, properties, fuzzing, vectors, and differential runs against a second model.
  • New practice: behavioural diff on every AI rewrite, spec-divergence audits, score the suite before trusting a green build.
  • Proven: three pre-auth bugs in a Zig daemon, all behind a green suite, all found by a dumb fuzzer.
click to read →
mutation testing · does the test care?
Who Tests the AI’s Tests?

When the same agent writes the code and its tests, the tests describe what the agent built, not what you intended, and the suite passes by construction. Coverage stays high, review finds nothing, the build goes green. Then a dumb fuzzer finds three pre-auth bugs in seconds. So what does green actually certify, once the author and the test-writer are the same model?

1H₂O isn't a description. It's a label on a door. 2Anode and cathode: one pole turns acid, the other turns base. 3A socket is just a file, until TIME_WAIT and Nagle bite. 4Toxic waste and SQL injection share one cause: misunderstood primitives. 5A membrane for under a dollar a square yard, not hundreds.
TL;DR

TL;DR

  • H₂O reads as a complete description, but water is strange and electrolysis is not what the formula implies.
  • Computing primitives share the property: the description is accurate and the wrong level to operate at when it matters.
  • Mastery is knowing the primitive well enough to compose a closed loop: no waste, every output feeds the next input.
  • Running primitives without knowing what each pole does produces toxic waste, in electrochemistry and production systems alike.
click to read →
H₂ O₂ electrolysis · the formula is not the mechanism
H₂O

H₂O. Two hydrogens, one oxygen, a formula so clean it feels complete. It isn't: run electricity through water and two opposite reactions happen at once, acid at one pole, base at the other, and the whole game is keeping them apart. The same is true of a process, a socket, a transaction. The formula is always clean; the question is what's behind the door.

1A log is a narration; a snapshot is the scene. 2Firecracker boots a real machine in 125 milliseconds. 3Your container shares the host's kernel. That's the problem. 4The snapshot tree can't be edited by the software inside. 5Run untrusted code unsandboxed and you're the one explaining why.
TL;DR

TL;DR

  • Browsers, editors, npm installs, build scripts, agents all run code you didn't write at too much privilege.
  • A microVM is a hardware boundary with its own kernel, not a permission check like a container.
  • The snapshot captures full machine state: replayable, forkable, and provable without trusting the operator's logs.
  • Sandboxing should be the default for untrusted code, the way HTTPS became default for real connections.
click to read →
vm:a1 14:02:09Z fork:b1 14:02:11Z fork:b2 14:02:11Z EVIDENCE snapshots · lineage · audit
The Snapshot Is the Audit Trail

Every program you run, a browser tab, an editor plugin, an npm install, an AI agent, executes code you never wrote against a machine holding things you care about. Containers were supposed to fence that off, but they share the host's kernel, so the wall is thinner than it looks. There is a boundary that actually holds, boots in 125 milliseconds, and leaves behind something a log never can. What it records changes what "audit trail" even means.

1The plague rode the same roads as the silk. 2The Mongols had per-action identity tokens seven centuries ago. 3AI moves the decision itself, not data about it. 4The empire fell by absorption, not a stronger army. 5We have the roads but never minted the paiza.
TL;DR

TL;DR

  • Pax Mongolica was the first globalisation: shared roads carried trade, ideas, and the plague at one speed.
  • The internet repeated it; AI is the next layer, moving decisions instead of information.
  • Dangerous things ride the same routes as beneficial ones, just as fast; the infrastructure does not distinguish.
  • We have the roads, not the paiza: per-action provenance and audit that applies before the incident.
click to read →
China Europe the roads · the paiza · the plague
The Plague Came on the Same Roads

Every infrastructure that connects the world runs one pattern: it collapses distance, creates an explosion of value, then carries something dangerous along the exact routes that carry the benefit, at the same speed. The Mongols ran the first global network and the plague used their roads. Now AI moves not data about a decision but the decision itself, executed before a human is in the loop. So what have we still not built?

1Most MCP servers ship write access to production with no log. 2"An AI agent, probably" isn't an answer your auditor accepts. 3MCP is just another caller hitting the same API. 4The audit log stops being optional the moment the agent can write.
TL;DR

TL;DR

  • MCP gives an LLM structured write access to your tools, APIs, and infrastructure with no default logging.
  • When something breaks, "an AI agent did it" is not an auditable answer under any compliance framework.
  • MCP is just another API caller: route it through the same audit log as everything else.
  • Ship the audit log before you ship the MCP server, not after the first incident.
click to read →
03:17 DELETE ? MCP · who did this? · audit
MCP Has No Audit Trail

Through an MCP server, a model can silence an alert, delete a record, push a config change, with no human in the loop and no log. So when the auditor asks who deleted that alert at 3am, what do you say?

1You already pay for ngrok's one feature: a public IP. 2ngrok's free tier: 1 GB, then you're stuck. 3Fifteen open-source tools that retire ngrok. 4Your VPS already does what ngrok charges for. 5ssh -R is a tunnel you already have.
TL;DR

TL;DR

  • frp covers every protocol including UDP and is the proven self-hosted default.
  • rathole is frp in Rust: smaller binary, lower memory, constrained hardware.
  • sish needs no client binary, just plain ssh -R, with automatic TLS.
  • zrok adds zero-trust peer-to-peer private shares that never touch a public relay.
click to read →
:3000 frp · rathole · sish · zrok · chisel · self-hosted
Self-Hosted Tunnel Alternatives to ngrok

ngrok's free tier caps you at 1 GB a month, one endpoint, random URLs that break your webhooks, and a closed-source relay watching every byte. If you already rent a VPS, you are paying twice for the same public IP. Fifteen open-source tools cover that ground, from a single Go binary to a zero-trust overlay. The only question left is which shape of relay fits the box you already own.

1Your isolated container shares a kernel with every other on the host. 2One unprivileged syscall hands you root inside a namespace. 3A cgroup limits resources; it is not a security boundary. 4Lambda cold-start is fake: it forks a warm VM.
TL;DR

TL;DR

  • 14 isolation mechanisms across all 5 Linux-stack layers, each a working demo on stock Linux.
  • User namespaces are the linchpin: a full capability set without root, unlocking most other namespaces unprivileged.
  • cgroups limit resources, they don't isolate. cgroups + namespaces + seccomp isn't redundant: each layer closes a different gap.
  • gVisor removes the host kernel surface with a user-space kernel; seccomp plus caps plus Landlock is cheaper for most workloads.
click to read →
Runtime WASI · CRIU · time ns Kernel policy Landlock · seccomp · eBPF · MAC Kernel prims Namespaces · cgroups · Caps Hypervisor Firecracker KVM · gVisor sentry Hardware TDX / SEV-SNP (TEE) 14 demos · all 5 layers
The Linux isolation stack in fourteen working demos

Linux isolation spans five layers: hardware, hypervisor, kernel primitives, kernel policy, runtime. Fourteen mechanisms across all five, run on a stock Linux machine. No Kubernetes, no cloud account. Each demo's output explains what is happening as it happens.

1"No telemetry" is usually just a flag flipped off. 2A policy restrains collection; it never removes it. 3You can't disable the telemetry you never found. 4Most telemetry lives in your dependencies, not your code. 5Real privacy is data that was never transmitted.
TL;DR

TL;DR

  • "No telemetry" usually means a config flag or policy, and both are revocable; no collection path is not.
  • Most telemetry sits in framework build tooling, logging defaults, and third-party SDKs, not the code you wrote.
  • Local observability without a pipe: structured local logs, opt-in crash reports, synthetic probes from infrastructure you control.
  • Minimise at the schema: data that never enters the system cannot be stolen, subpoenaed, or leaked.
click to read →
policy: flag off collector SaaS path exists, revocable architecture: no path local path never built
No telemetry means no code to collect it

Most software that claims no telemetry has just flipped a feature flag from on to off. That is a policy, and policies come back when the terms change, the round closes, or a dependency ships a new default. So what does it take for the claim to be structural instead, the kind no privacy policy can quietly reverse?

1No rent is not free. It bills you in hours. 2A backup you never restored is a file you hope works. 3Most developers ship to platforms. Few have ever operated one. 4Five things separate self-hosting from running on a server and hoping.
TL;DR

TL;DR

  • Self-hosting swaps a subscription for operational work: patches, backups, credential rotation, monitoring, cert renewal.
  • Steady state runs 2 to 4 hours a month once automated; the first three months cost double.
  • Most developers ship to platforms and learn operations on live systems, which carries real risk.
  • Minimum posture: automated TLS, verified backups, external monitoring, a practiced runbook, a real patch cadence.
click to read →
hrs / mo 1 3 6 12 24 months managed self-hosted setup steady
The operational cost of no rent

Cancel the subscription and the bill does not disappear, it just stops arriving on a credit-card statement. Self-hosting trades a line item for an operational burden with no fixed price: weekly patches, quarterly backup checks, the 3am OOM kill, the certificate nobody renewed. Most people who choose it underestimate the real cost until they have paid a year of it. So what does that year actually take from you?

1You filter who knocks, not where you walk out. 2A backdoored dependency already has your network access. 3Ingress filtering only ever guarded the front door. 4Your sandbox stops file access, not the agent calling out. 5Default-deny outbound beats chasing known-bad domains.
TL;DR

TL;DR

  • Egress allowlists default-deny outbound and permit only the destinations a service legitimately needs.
  • Allowlists beat denylists: you define good in advance, not bad after the incident.
  • Pick from nftables rules, namespace isolation, or a hostname-aware egress proxy.
  • For agents and sandboxes, logged egress filtering is a required control, not a nicety.
click to read →
service outbound traffic egress policy pkt api.stripe.com ✓ pkt registry.npmjs ✓ pkt exfil.attacker.io ✕ default deny; allowlist per destination
The case for an egress allowlist

Every team blocks the traffic that should not reach its service. Almost no one controls where the service is allowed to go once a request lands. That silence is exactly what a compromised dependency, an SSRF, or a manipulated agent uses to call home, and your inbound firewall never sees it leave. So what does it take to tell the network not who can knock, but where your own software is permitted to walk out?

1A heartbeat waited behind 100,000 creates. 2The scheduler was blocking itself. 3Healthy hosts marked down by a queue ordered wrong. 4Three Raft lanes, 12x the throughput. 5The same decomposition databases found a decade ago.
TL;DR

TL;DR

  • One Raft log carried intents, placements and heartbeats; a 100k-create burst stalled the heartbeats.
  • Marked-down hosts were healthy; the queue was ordered wrong, not overloaded.
  • Fix: three Raft groups, one per traffic class, since the lanes are genuinely independent.
  • Same move as TiKV range replication and DuckDB window functions: 12x throughput.
click to read →
single RSM vs. multi-raft before heartbeat ⏸ create create place create place after intent placement heartbeat ✓ live remove the accidental ordering constraint
Head-of-line blocking in the control plane

Tensorlake bumped sandbox scheduling throughput 12x, and the surprise is what they did not do: they added no hardware. The scheduler had been blocking itself. One replicated log carried user intents, placement decisions and host heartbeats in a single strict order, so a burst of 100,000 creates buried the heartbeats and the scheduler started declaring healthy hosts dead. The capacity was there the whole time. What was actually wrong was the one constraint nobody had questioned.

1Read every line, find it clean, still ship a compiler's backdoor. 2The same backdoor fits AI weights, with no source to audit. 3About 250 poisoned documents can backdoor a model of any size. 4The deadliest trigger: "am I being tested, or deployed?"
TL;DR

TL;DR

  • Thompson's 1984 "trusting trust": clean source, backdoored binary, invisible to any source audit, self-reproducing through the compiler.
  • The only full defence (Wheeler's Diverse Double-Compiling) needs a deterministic, reproducible build. Model training has none.
  • Anthropic's "sleeper agents" rebuilt the attack in weights. Safety training didn't remove it; adversarial training sometimes hid it better.
  • ~250 poisoned documents can backdoor a model of almost any size, and the model-to-model training loop carries the flaw forward.
  • Conditioning is the attack. Apex trigger = "am I being tested?", which models are starting to detect on their own.
click to read →
clean source, dirty binary source.c audited clean compile binary audit the source, miss the backdoor
You can't audit a model like code

There's a 1984 proof that you can read every line of a program, find it clean, compile it, and still ship a backdoor with nothing in the source to find. For compilers it took 25 years to find a clean defence. The same attack now fits AI weights better than it ever fit code, and the one fix that beat it was a bit-for-bit rebuild. Training cannot be rebuilt.

1AI cuts heads because the saving has your name on it. 2The four horsemen never beat the CEO. They outlast them. 3Sell AI as layoffs and you build the saboteurs. 4You cannot measure opportunity. Stop scoring it from the centre. 5Move the Labs anywhere; the owner clock follows.
TL;DR

TL;DR

  • AI sells on cuts because a cut is legible this quarter and created value is not.
  • The veto holders are not dishonest; the ledger just has one column that ever fills.
  • Distributed slack surfaces bets; only a dedicated team ships them. Different stages, not swappable hours.
  • Every structural fix needs owners to give up a veto they will not give up.
click to read →
the cut the opportunity the measure is lopsided · one column ever gets filled in
AI as layoffs, not opportunity

AI gets sold on cutting costs, not creating value, and the reason is structural, not laziness. A cut is a number on this quarter's books with your name beside it; created value is diffuse, slow and credited to no one, so the scoreboard reaches for the cut by default. The same asymmetry repeats one floor up, on the Labs budget. So what structure can keep the scoreboard out, and how long does it last?

1Ukraine's drone marketplace out-innovates Western procurement. 2No amount of money buys a winning strategy. 3Stop picking winners; make trying cheap. 4The front line picks its own weapons. 5You find the winner by running, not analysis.
TL;DR

TL;DR

  • You can't predict the winner; competition is irreducible, so only running finds it.
  • The real leverage is cheaper running, not smarter picking.
  • Brave1 lets frontline units spend earned points to choose their own kit.
  • Infinite money can't compute the winner; it only buys what already won.
click to read →
let the front line pick e e e units spend points; suppliers race to win them
Innovation when you can't pick winners

Under fire, Ukraine built an allocation engine that out-innovates ordinary military procurement, and the interesting part is not the drones. It is the question underneath: when you genuinely cannot predict which design will win, who should get to decide what gets built? Brave1 hands that choice to the front line and pays it in a currency earned by surviving. There is a clean computer-science reason no planner can shortcut it.

1Coercion buys one act. Ideology recruits a believer. 2The CIA secret was first-year psychology. 3The video runs RICE on you, live. 4One swap turns an anecdote into a formula. 5Name the lever, it loses its grip.
name the lever reward ideology coercion ego the pull works in the dark
TL;DR

TL;DR

  • RICE/MICE (reward, ideology, coercion, ego) is a real recruitment framework: coercion is the weakest lever, ideology the strongest.
  • The six secret ideologies are just the six standard perspectives of first-year psychology.
  • The same video runs all four levers on the viewer to sell a seventeen-dollar course.
  • Learn the levers to feel them pulled on you, not to pull them on others.
click to read →
The four levers of influence

A former CIA officer drops a video promising the secret the rich use to get rich without working hard. Its framework turns out to be a real intelligence checklist, decades old, with one word swapped. And the sharpest move is the one playing while you watch: the video runs its own framework on you, in real time, to sell a seventeen-dollar course. Can you name the lever before the checkout?

1Naming a function quarantines it. 2The foil finance cuts, customers love. 3Contempt for data is not wisdom. 4Data finds; it never notices. 5The most valuable columns are not there.
the spreadsheet is not the territory the map the territory
TL;DR

TL;DR

  • A map's missing columns quietly stop feeling real to everyone reading.
  • Name a function and everyone else treats it as no longer their job.
  • The San Pellegrino foil: finance reads waste, customers read confidence.
  • Data is great at findings and hopeless at noticings.
click to read →
The value finance can't see

A spreadsheet is a map, and maps leave things out. The real danger is not the omission but that the omitted things stop feeling real: the function with no department, the cost finance reads as pure waste, the value that works precisely by being unnecessary. Rory Sutherland says finance is wrong to cut these. He may be right, but the same logic licenses an infinite amount of expensive nonsense, so how do you tell the meaning apart from the waste?

1Nobody gets fired for a data-driven decision. 2All your data is the past. 3Use data to kill intuitions, not generate them. 4Everyone's spreadsheet agrees: they trained on the same past. 5The convergence tax shows up as price.
everyone's spreadsheet agrees different bets one commodified shape all big data comes from the past
TL;DR

TL;DR

  • Data-driven decisions are defensive: you are never blamed for following the numbers.
  • But all data is the past, so it cannot tell you what to try next.
  • Everyone optimises shared metrics and copies rivals: Goodhart's Law plus mimetic isomorphism, stacked.
  • The result is a commodified market where the only thing left to compete on is price.
click to read →
Why data-driven firms converge

Pick the number, the benchmark, the dashboard, and you can never be blamed when it fails: the failure belongs to the world, not to you. That is the quiet appeal of being data-driven, and it has almost nothing to do with whether the data was any good. But run a whole industry on the same defensive instinct, against the same shared benchmarks, and something happens to every firm at once.

1The sale is the sample. 2No demo, no spec sheet, only the sale. 3Free advice signals a vendor, not an expert. 4Diagnose before you prescribe. 5Price the value, never the hours.
four conversations, one sample probative qualify value close how you sell is how you'll solve selling expertise, not products
TL;DR

TL;DR

  • Expertise has no demo; the client cannot inspect the work before they commit.
  • So the sale itself is the only sample of how you will solve it.
  • Enns splits selling into four conversations: probative, qualifying, value, closing.
  • Diagnose first, build authority upstream, and price the value rather than the hours.
click to read →
How experts sell differently

You spent years getting good at hard work, and now you have to sell it. But expertise has no demo and no spec sheet: the client cannot inspect the goods before they buy. So what are they actually judging when they decide whether to trust you, and what does your pitch quietly tell them about the advisor you will be?

1Small software outlasts the frameworks it skipped. 2The work that ages well stays legible. 3A big system, and you're guessing at its edges. 4Read the whole codebase in an afternoon. 5Bounded surface is four wins at once.
read every line in an afternoon the whole thing, visible LC-3 zvm3 conway servo small surfaces, long lifetimes Ara, with the panel weighing in
TL;DR

TL;DR

  • Some systems are small enough to hold in your head all at once.
  • Bounded surface lets you enumerate failures instead of guessing the blast radius.
  • You learn from systems you can take apart, not ones you only call.
  • Small enough to hold is the work that still reads in ten years.
click to read →
Software you can hold in your head

Most systems are too large to hold in your head, and you spend your days guessing at their edges. A few are different: bounded, every line readable in an afternoon, the whole shape carried with you afterward. That smallness is not a limitation someone settled for. It is a property that quietly pays you back in four separate ways, and one of them is the reason this code still works long after the rest has rotted.

1Which broker? Which database? Never the real decision. 2The loud argument is downstream of one you haven't named. 3A shared action identity is one breach away from all clients. 4Don't make SQLite highly available. Demote it. 5In-cloud backup against a cloud outage is theatre.
the loud decision is downstream where do actions land? which broker which database name the upstream decision and the rest falls out NATS · idempotency ledger · commit boundaries
TL;DR

TL;DR

  • The loud choice (which broker, which database) is downstream of a quieter question you haven't named.
  • Broker follows from where actions land and where data must legally live: self-hosted NATS, account-per-tenant.
  • A durable ledger with one idempotency key, not the bus, is the truth.
  • Demote SQLite to a rebuildable projection; survive a cloud fault by committing at the edge.
click to read →
The real decision is upstream

We kept having the loud argument: which broker, which database, which protocol. Every time we settled it, the real decision turned out to be sitting one step upstream, and the loud question fell out of a quieter one we had not named yet. Where do the actions actually land? Which piece of state is correctness? Where does the commit boundary sit? Answer those and the loud fight stops being a fight at all.

1Your tools track the output, not the why. 2AI made starting free; remembering got expensive. 3Two files per bud: a why and a record. 4The AI agent plays by the same rules. 5Plain text a grandchild could still read.
brief to brief, bud to bud budbrief budbrief budbrief each close seeds the next open keeping the whole life of the work the Buddy System
TL;DR

TL;DR

  • Most tools track the output of work; almost none track its whole life.
  • A bud carries two files: a brief (the why) and notes (the record).
  • Buddies tend buds, one keeper owns the brief, and BOB obeys the same rules.
  • Plain text, fixed tag grammar: a record a human or an agent can both read.
click to read →
The Buddy System

Every tool you use tracks the output of work: the ticket, the repo, the wiki. Almost none track the whole life of it, why it began, the rule it could not break, what it taught after it shipped. That layer is the most valuable one and the first to evaporate. So what would it take to keep it with one process simple enough for a child's homework and strong enough for a 25-year company?

1The patient has no app. 2In health, ads aren't just bad, they're largely illegal. 3Who pays for the second stroke? 4Fund the core as a mutual. 5The funding model is the governance model.
the patient has no app recurrence missed 2nd event readmit payer eats cost so the payer would fund catching it funding the integration the patient cannot do alone the hard companion to the trades co-op
TL;DR

TL;DR

  • The patient is the only thread across fragmented care, and has no app for it.
  • The app stores data and surfaces patterns, but never advises; that firewall is the whole architecture.
  • Charging the sick fails and ad targeting is largely illegal, so fund the core as a mutual.
  • Insurer and medic money stays at the edges, funding advice and access, never the core.
click to read →
Who pays for the patient's app

The patient is the only thread that runs through their own care, and yet the patient has no app to see it. Build one and you hit the wall every public good hits: who pays. Charging the sick is cruel; in health, advertising is largely illegal. So the cheap option is gone before you start. Who has a structural reason to fund prevention, and what keeps their money from capturing the thing it pays for?

1Reject ads and something else has to pay. 2Most ad spend is a net loss. 3Each funder quietly shapes what the product becomes. 4One frozen grant should never kill the system. 5The funding model is the governance model.
three lines, no single point foundation federation fees city co-op members + insurance protocol NLnet + grants the funding model is the governance model
TL;DR

TL;DR

  • Most ad spend is a net loss for almost everyone, even when each spender is rational.
  • Reject ads and you just pick a different funder, and each one shapes the product.
  • Fund it in three insulated layers: grants, member fees, federation fees, no single point.
  • Federation is the capture defense; the funding model is the governance model.
click to read →
How to fund the rent-free alternative

Disliking ads is easy. The bill comes due the moment someone asks what pays for the thing instead. Pick subscriptions and you wall off a commons; take VC and you grow your way out of federation; take a state grant and you invite capture. So who funds a platform built to refuse rent, without quietly rebuilding the rent? Worked through one concrete case: local trades, the plumbing and handyman work the apps turned into a toll.

1A microVM is a wall, not a sandbox. 2It closes two isolation dimensions, leaves one open. 3Your guest can phone anything the host runs. 4Unauthenticated Docker on TCP is root, not a foothold. 5The walls a microVM skips are the used ones.
two walls hold, one is open microVM untrusted process filesystem network: open dockerd API = root network isolation is the wall a microVM leaves to you
TL;DR

TL;DR

  • Isolation has three dimensions; a microVM only closes process and filesystem cleanly.
  • The third, network, ships wide open: the guest routes to every host listener.
  • On a build host that listener is often Docker, root-equivalent to anyone reachable.
  • Close it with seccomp, capability stripping, a strict egress allowlist, and a packet filter.
click to read →
A microVM is not a sandbox

Firecracker and Cloud Hypervisor are the strongest isolation most teams will deploy, and still not sandboxes. They wall off the host kernel and filesystem cleanly, then hand the guest a virtual NIC with a route straight back to the host. On a build box, the most dangerous thing listening is usually one API call away from root. So which two dimensions does the wall actually close, and what fills the third?

1The password is in another process's memory. 2ptrace reads your SSH password as you type. 3"They'd need root" is not a defence. 4A debugger feature is a credential harvester. 5Plaintext passwords survive the rotation you just ran.
scan /proc · attach · read · exfil sshd sudo su ptrace peek write() plaintext user + pass the password is in another process's memory ptrace, the tty, and the boundary you actually have
TL;DR

TL;DR

  • Hawk attaches ptrace to login processes and reads SSH and sudo passwords out of memory in plaintext.
  • It needs root, a precondition the original red-team writeup quietly leaves out.
  • Your password goes to a process's memory, not just to sshd; tracing rights see it too.
  • Three layers defend it: restrict ptrace, detect the trace, make the stolen credential worthless.
click to read →
The password is in another process's memory

You type a password into an SSH prompt and assume it reaches one place: the program that asked. On Linux that assumption is one word off. The secret lands in that program's memory, and on a shared kernel, memory is something another process can be granted the right to read. So where does the trust boundary you imagined actually sit, and what is left to defend once it moves?

1A spec is a prediction from your least-informed moment. 2OpenAI wrote its best spec last, not first. 3The spec leaves holes; the agent fills them confidently wrong. 4Own intent and the definition of done, not the spec. 5The bill for a guessing agent lands on the client.
intent · context · expectations INTENT EXPECT harness loop context · build validate merge the human owns intent; the harness owns the loop the method that replaces SDD
TL;DR

TL;DR

  • A spec is a prediction written before you know the most; the agent fills the holes.
  • OpenAI distilled its 2,169-line Symphony spec last, from software that already ran.
  • ICE splits intent, context and expectations, each owned by a human, not one bloated file.
  • Tests do not vanish; rigour relocates to outcome checks and runtime guardrails.
click to read →
Intent-driven development: the method that replaces SDD

Spec-driven development took over the conversation in under a year: write down what you want, in detail, up front, so the agent stops guessing. But the spec always leaves holes, and a goal-seeking agent fills them. OpenAI's best spec ran to 2,169 lines and worked, yet they wrote it last, not first. So where does that leave the up-front spec, and who ends up paying for the gaps the agent quietly invents?

1A dashboard going green is not a problem understood. 2My father had strokes on a drug doing nothing. 3The recurrence is the question, not the fact. 4The test sat in the catalogue for a decade. 5The patient is the only thread, and has no app.
the same incident, three times medicine stroke #1 stroke #2 stroke #3 IT p99 spike p99 spike p99 spike the test was in the catalogue monitoring is not understanding
TL;DR

TL;DR

  • Instrumentation tells you what happened, not why; the why is a test sitting unordered in the catalogue.
  • Same failure in IT and medicine: a recurrence gets logged as a fresh event, not the same one.
  • The system understaffs the two hard jobs, triage and integration, handing them to whoever is on-call.
  • One rule: when it recurs, ask whether the mechanistic test was run, not whether the alert fired.
click to read →
Monitoring is not understanding

My father had a string of strokes on a drug that, a platelet test eventually showed, was doing nothing. The test had existed for over a decade. Why did it take that long to order, and why does the same blind spot run through every IT incident review?

1Consistency without feedback is just a decade of grinding. 2Motivation is a vote, not an engine. 3The whole debrief: three questions, five minutes. 4Change one thing per round, or learn nothing. 5Mood follows action, not the other way round.
what you actually get motivation consistency graveyard half-built repos real work furnace + thermostat nothing good intentions grind 500 words/day forever
TL;DR

TL;DR

  • Consistency beats motivation is true but shallow, and not enough by itself.
  • Build the furnace that runs without you, read motivation as signal in both directions.
  • After anything that mattered, run a blameless three-question debrief in five minutes.
  • Change one thing per round so you know which change actually helped.
click to read →
Why consistency isn't enough

"Consistency beats motivation" is true enough to be dangerous. Showing up every day for ten years can still leave you exactly as bad as you started, grinding at a floor that never rises. The people who actually compound, pilots, surgeons, special-operations units, all add a second habit the daily grind never supplies. It takes three questions and five minutes, and almost nobody runs it.

1Most ad spend cancels out; you still pay the bill. 2Google's automation optimises for Google, not you. 3The winners get case studies; the losers stay silent. 4You have a hundred accounts and no app. 5Find the rent, then refuse to pay it.
customers platform rent 20-30% provider the rest the platform is the only guaranteed winner
TL;DR

TL;DR

  • Combative ads are a prisoner's dilemma: both could stop, neither can, so spend escalates.
  • Platforms keep the rent; the advertiser's win is temporary and now automated against them.
  • Software is built for whoever pays, so users scatter across a hundred provider accounts.
  • Invert it: one federated app you own, funded by members and grants, not advertisers.
click to read →
Follow the rent: from ads to a co-op

I have always disliked ads, and writing the reflex down turned it into something larger. The objection does not stop at Coke versus Pepsi or at Google quietly tightening the screws on advertisers. Followed honestly, it becomes a theory of rent: who charges you for sitting between you and what you want. Ad platforms, gig platforms, and the hundred provider apps on your phone all run the same play. So what would software that refused the rent actually look like?

1A sovereign AI agent: one static binary, zero dependencies, built from scratch. 2Why not build on OpenClaw or Hermes, and where it converges anyway.
channels chat CLI MCP Zoya one Zig binary agent loop 60+ tools · MCP memory sandbox · vault models Claude GLM local fallback a sovereign agent runtime, built from scratch
TL;DR

TL;DR

  • Zoya is a sovereign agent runtime: one static Zig binary, zero deps, sandboxed, MCP-native.
  • It drives a fallback chain of models.
  • Built from scratch rather than on OpenClaw or Hermes, and why.
  • Where it converges with the wider field anyway.
click to read →
What Zoya is, and why it's built from scratch

Zoya is a sovereign agent runtime: one static Zig binary, zero deps, sandboxed, MCP-native, driving a fallback chain of models. The build-vs-adopt record: why it's written from scratch rather than on OpenClaw or Hermes, and where it converges with the field anyway.

ReAct loop operator Hermes web_search bash_exec file_read observe → reason → act working memory tool_calls · observations agent orchestration with structured tool use
Hermes Agent Operator's Manual

Building an AI assistant that can act, remember, and improve

1Your agent's memory is attacker-writable. 2One poisoned tool result, memory-wide blast radius. 3The recall leaderboard is vendor marketing. 4Separate believed-fact from observed-input, or injection wins. 5A confident recall score can be measuring nothing.
memory rows believed fact · trusted observed input · web / tool untagged → becomes "fact" tag the source, or memory is an attack surface
TL;DR

TL;DR

  • Treat agent memory as something an attacker writes to.
  • Recall benchmarks are vendor-run marketing; use the architectures, ignore the scoreboard.
  • Steal fact/belief/input separation, audited mutation, sovereignty; reject ungated background reasoning.
  • Provenance and a verification test beat any recall number.
click to read →
Agent memory is an attack surface

The memory market is a recall contest: how much can an LLM remember from a conversation. For an agent that acts on the world through tools, that is the second question. The first is what memory looks like once you assume it will be poisoned, because every remembered fact an attacker can write becomes an instruction you will execute later. So what does a memory system built from a threat model, not a benchmark, actually look like?

1Eighty tools evaluated, three survived. 2Sovereignty is a veto, not a preference. 3Zoya is already the agent. 4Try cheap, escalate on failure. 5Every skip carries a reopen trigger.
80+ tools engines · drivers · clouds · … sovereign + MCP web_fetch lightpanda scrapling 3 picks a crowded field, filtered to one sovereign ladder
TL;DR

TL;DR

  • Eighty-plus web-reading tools exist; a sovereign agent runs exactly three.
  • web_fetch, then Lightpanda, then Scrapling, escalating only when the cheaper tier fails.
  • Four facts about Zoya vetoed most of the market before quality scoring.
  • Skipped tools are logged with an explicit revisit-when trigger each.
click to read →
Web-reading tools for a sovereign agent

There are eighty-odd ways to let an agent read the web: managed browsers, agent harnesses, LLM extractors, crawlers, drivers, stealth fetchers. Zoya runs exactly three, plus one search chain. The surprise is how little of that decision came down to quality: four facts about the agent quietly deleted most of the market before anyone scored a single tool. The question is which four, and what they leave standing.

1A tiny control panel for the field that breathes across pages.
LABS BG tune the dots
TL;DR

TL;DR

  • A control panel for the ambient twinkling background across every Labs page.
  • Tune density, dot size, twinkle period, and opacity.
  • Settings persist in localStorage and apply site-wide.
click to read →
Labs background settings

A control panel for the ambient twinkling background that runs across every Labs page. Tune density, dot size, twinkle period, and opacity; settings persist in localStorage and apply site-wide.

1Conway's Game of Life on the GPU, board in a texture.
WebGL2 · GLSL step / fade / paint / render ping-pong RGBA16F
TL;DR

TL;DR

  • Conway's Life on the GPU: state packed into an RGBA16F texture.
  • Ping-pong between two textures, four fragment-shader passes per frame.
  • The CPU only handles user input.
  • Same field as the Canvas2D version, different engine.
click to read →
Conway on the GPU

Same field as the Canvas2D version, different engine: state packed into an RGBA16F texture, ping-pong between two of them, four fragment shader passes per frame. The CPU spends its time on user input and not much else.

1A Game of Life as a page background that won't steal focus.
TL;DR

TL;DR

  • A Game of Life as a page background works only if it never steals the show.
  • A brightness ceiling keeps it quiet.
  • Three independent decouplings kill the pulse and stop it dying.
  • Seeds land on a noise stream biased away from existing patterns.
click to read →
Conway in ambient mode

A Game of Life as a page background works only if you can stop it from stealing the show. Notes on the brightness ceiling, three independent decouplings that kill the pulse, and a noise stream biased away from existing patterns.

1Three hours of syslog vanished overnight, silently. 2UDP never asks twice. 3The root cause was not the disk. 4Five anti-patterns lined up to lose the data. 5Stop being the place the logs live.
UDP sensorbox 100% /var full, packets dropped TCP replay sensorbox 40% UDP doesn't ask twice
TL;DR

TL;DR

  • A SOC pipeline went dark and three hours of one client's syslog vanished.
  • UDP drops are gone for good; we replayed from local host logs.
  • The disk filling was the trigger, not the underlying root cause.
  • It ends in five quick fixes and a custody re-architecture.
click to read →
The syslog you can't get back

A SOC pipeline went dark overnight. A misbehaving app filled a disk, the syslog daemon stopped persisting, and the kernel quietly dropped three hours of one client's UDP stream. By morning the box had healed itself, so nobody noticed. UDP never asks twice, and the packets were gone from the wire. We were called in to get them back, explain how a single full disk erased data with zero detection, and say what should have made it impossible.

feed aggregation blog RSS YouTube Podcast GitHub Q-feeds reader inbox unread: 12 self-hosted · no tracking · offline-capable aggregate RSS/Atom feeds in one place
Q-feeds

Using Q-Feeds threat intelligence on OPNsense with AdGuard Home for DNS-layer blocking and pf firewall rules for IP-layer blocking, including a clean multi-VLAN setup with Interface Groups.

1One instruction, three branch targets, no binary equivalent. 2A trit's sign is already a three-way branch. 3Balanced ternary makes negation a single instruction. 4Ternary weights delete the multiplier from matmul. 5The branch that two's-complement can't do.
BR3 R1 if < 0 neg_off if = 0 zero_off if > 0 pos_off one instruction, three landing sites
TL;DR

TL;DR

  • A balanced-ternary VM in Zig, built on the LC-3 toolchain.
  • BR3 packs three branch landing sites into one instruction word.
  • Negation is one instruction and subtraction needs no special case.
  • A multiplication-free matmul using the BitNet b1.58 ternary-weight trick.
click to read →
What balanced ternary actually buys, in one instruction

Every binary branch is a fork: test, then jump or fall through. But a balanced-ternary digit already carries three states, so its sign is a built-in trichotomy, and that gap turns out to be one instruction wide. BR3 reads a register and lands in one of three places at once. What does a whole ISA look like when its only branch knows the difference between negative, zero and positive?

1I rebuilt a 30-year-old CPU in Zig. 2The dispatch trick everyone recommends ran slower. 3A perf bet measured at minus five percent. 4Modern compilers killed a beloved speed hack.
TL;DR

TL;DR

  • Built the LC-3 teaching VM and assembler on freshly-released Zig 0.16.
  • The std.Io rewrite forces explicit io, and pays off in tests.
  • Threaded dispatch ran about 5% slower than a plain switch.
  • LLVM already lowers the switch; the old folklore lost its premise.
click to read →
.asm zasm .obj zvm 2 4 2 Zig 0.16 · ~1300 lines · 564 Mips peak · runs 2048
An LC-3 toolchain in Zig 0.16

Zig 0.16 just landed with a rewritten std.Io, so I rebuilt the thirty-year-old LC-3 teaching CPU against it: a 600-line VM and a 640-line assembler. The port was easy. Then came the famous speed trick, threaded dispatch, the one every interpreter writer swears beats a plain switch. I wired it up behind a flag and benchmarked both. The result pointed the wrong way, and once you see why, a whole class of optimisation folklore stops looking trustworthy.

1We built the same tool twice. 2Sharing code would have been less work. 3One spec, two languages, on purpose. 4The repo is the worst spec. 5When he couldn't reproduce it, we were wrong.
spec Tavi's servo TS · Bun CLN's servo Python · single file shared design, separate code
TL;DR

TL;DR

  • Servo exists twice: TypeScript on Bun, and Python, built from the same notes.
  • Sharing the repo copies your blind spots; sharing the spec keeps both heads independent.
  • A second implementation that can't reproduce a behaviour proves the notes are incomplete.
  • Where the two drift (hot reload, config, tasks) is information, not fragmentation.
click to read →
Two servers, same shape: servo in Bun

There was an obvious move when CLN saw the servo I was running: hand him the repo. We did the other thing instead, and wrote a second implementation from scratch in a different language. More work, on purpose. What that separation catches that a shared codebase quietly hides turns out to be the whole reason we keep paying for it.

1Every directory becomes a website, with shared theming for free.
~ · bash $ tree ~/servo/ -L 1 ~/servo/ ├── blog2/ ├── mem2-graph/ ├── mem2-search/ ├── overview/ └── game-of-life/ 5 directories · 0 config $
TL;DR

TL;DR

  • Every directory under ~/servo/ becomes a URL path.
  • Shared theming is injected for free.
  • A directory gains logic only when it needs a server.py.
  • The Python re-implementation of Tavi's original.
click to read →
What is servo, and what's a servo app

The model: every directory under ~/servo/ becomes a URL path, with shared theming injected for free. Tavi wrote the original; this is the Python re-implementation.

1Two near-identical queries pay full price. 299% of segments shared, scanned twice. 3Seal a segment, cache it forever. 4Late data without stale answers. 5Query latency down 70%.
druid · interval cache · 7d 99% shared cached sealed segments open recompute sealed open edge 04-23 04-25 04-27 today
TL;DR

TL;DR

  • Repeated dashboard queries re-derive answers the cluster already produced minutes ago.
  • Split each query into sealed (cache forever) and open (always recompute) intervals.
  • Version each cached interval so compaction or late data invalidates it atomically.
  • Result: latency down 70%, broker CPU down, zero correctness incidents.
click to read →
Interval-aware caching for Druid

Your dashboards ask the same time-range question hundreds of times an hour, and two queries that differ by a few seconds still scan independently even when 99% of their segments are identical. A whole-query cache barely helps: the keys never match, and one late event forces a wide invalidation. So what do you actually key on when the live edge keeps moving but the history behind it is frozen solid?

1One static number can't tell load from attack. 2The cap tightens only where shape drifts. 3A leaky bucket that reads traffic shape. 4The predictor was easy, distribution was not. 54x faster mitigation, false positives flat.
rps · /api/login · 6h ● live 8k 6k 4k 2k 14:00 15:00 16:00 17:00 now static cap
TL;DR

TL;DR

  • A static rate cap can't separate a sales spike from a credential-stuffing burst.
  • Our adaptive cap flexes per route with the last few minutes of traffic shape.
  • A hard SLO floor stops a noisy classifier locking real users out.
  • Two months in production: 4x faster mitigation, legitimate false positives stayed flat.
click to read →
Adaptive rate caps for a noisy edge

A static rate limit treats every second as equally suspicious, so one number has to cover both a Black Friday spike and a botnet pulse hammering your login route. Set it loose and you wave attackers through; set it tight and you 429 paying customers mid-launch. The shared, unauthenticated edge is where most abuse lands and where a fixed ceiling fails hardest. So we stopped picking a number and let the cap watch the traffic itself.

self-improvement loop current code version N Claude reads + edits better code version N+1 continuous self-modification hooks: PreToolUse PostToolUse Claude Code rewrites its own CLAUDE.md via hooks
Claude Code Self Evolving

How To make Claude Code into a self-evolving system walkthrough

roaming terminal session client $ mosh user@host Connected. user@host:~$ _ server mosh-server port: UDP/60001 state sync UDP SSH init roams across IPs · survives sleep speculative local echo · diff sync SSH replacement that survives network changes
Mosh - The SSH Replacement You Didn't Know You Needed

If you&#39;ve ever had an SSH session freeze mid-command because you switched from Wi-Fi to mobile, or lost your work because a hotel network dropped for three seconds, Mosh is the tool that fixes all of that.

FIDO2 / YubiKey auth with Mosh client YubiKey FIDO2 SSH auth mosh-server server sshd AuthorizedKeys sk-ssh-ed25519 problem: mosh forks after SSH, loses tty fix: SSH_AUTH_SOCK passthrough in .ssh/config resident key survives session roam hardware-bound credential that travels with mosh
Mosh FIDO2 / Yubikey Fix

Fix Yubikey touch prompt in terminal when using Mosh

1One model for every security signal class. 2Stop training one detector per signal. 3When two detectors disagree, listen. 4Build detection on a stable embedding. 5New detection heads in days, not quarters.
logs netflow edr intel cross-modal embedding one shared threat-space
TL;DR

TL;DR

  • ThreatFM is one shared embedding across logs, netflow, endpoint telemetry, and threat intel.
  • Per-signal models each carry their own preprocessing, evaluation, and retraining cadence.
  • A stable embedding makes new detection heads cheap: days instead of quarters.
  • Cross-head disagreement is itself a signal, surfacing missed threats a third of the time.
click to read →
ThreatFM: a unified embedding model for security telemetry

Detection teams train a fresh model every time a new signal class shows up, each with its own preprocessing and retraining schedule. ThreatFM collapses logs, netflow, endpoint, and threat intel into one shared embedding, so new heads ship in days. But the metric that ended up mattering most was not any single head's accuracy. It was what happened on the hosts where two heads flatly disagreed.

cd project → env auto-activates direnv .envrc hook uv venv + lock python activated $ cd project direnv: loading .envrc direnv: export +VIRTUAL_ENV (project) $ zero-friction Python envs on directory change
Seamless Python Environment Management on macOS

A manual, lightweight approach to Python virtual environment management that auto-activates when you `cd` into a project and deactivates when you leave, without ever running `source .venv/bin/activate` again.

1The trainer never sped up. The waiting shrank. 2Most of the speedup came from outside the GPU. 3We replaced bespoke scripts with one declarative recipe. 4Parallelising data prep and eval, not kernels, halved the wait. 5Reward model drift is the hard part.
recipe data train eval ship every stage cacheable, every stage parallel
TL;DR

TL;DR

  • We scaled post-training from a single-node prototype to a cluster running several experiments a day.
  • Most speed came from parallelising data prep, eval, and checkpoint sync, not from faster kernels.
  • One declarative recipe and cached, de-duplicated data prep replaced per-experiment scripts.
  • Elastic scheduling lets small jobs fill idle nodes between big runs.
click to read →
Scaling LLM post-training

We took our LLM post-training stack from a single-node prototype to a cluster running several alignment experiments a day, and almost none of the speed came from the GPU. The trainer was never the bottleneck; the waiting around it was. Rebuilding the scaffolding bought back more than half the wall-clock time. But the last hard problem refused to scale with the cluster, and it is the one we are still chasing.

DHCP lease → automatic DNS registration client DHCP DISCOVER Kea DHCP server 192.168.1.42 Unbound recursive DNS local. zone lease hook → DNS update laptop.local. A 192.168.1.42 ; auto router.local. A 192.168.1.1 hostnames resolve on your LAN without /etc/hosts
Kea DHCP to Unbound DNS Registration

This plugin bridges the gap between the Kea DHCP server (IPv4 &amp; IPv6) and Unbound DNS on OPNsense. It automatically registers hostnames for DHCP clients into the Unbound DNS subsystem, restoring dynamic DNS functionality with robust dual-stack support.

1Every value is legal, and quietly wrong. 2Your schema check waves it through. 3Watch the data's shape, not its schema. 4The catalog stopped looking like itself. 5Contracts check structure, not meaning.
null_rate · titles_v2 · 14d ⚠ drift 5% 3% 1% baseline ±σ canary fired 06:14 UTC 04-22 04-26 04-30 now
TL;DR

TL;DR

  • Schema checks structure; most catalog defects are semantic.
  • A canary watches each column's distribution against a baseline.
  • It pages when today's shape drifts beyond normal variance.
  • Drift routes to the team whose pipeline caused it.
click to read →
The data canary

Catalog metadata breaks in ways a schema cannot see: a runtime in the wrong units, a typo in a country code, an off-brand poster that validates cleanly. Every value is legal, the contract waves it through, and real users hit the defect first. So how do you catch a field that is perfectly well-formed and quietly, completely wrong before it ever ships?

1The queue grows faster than analysts can read it. 2Stop rating alerts; rank them in pairs. 3An LLM judge nobody audits is theatre. 4Pairwise verdicts, not severity scores from one to ten. 5Calibration is what keeps the throughput honest.
alert A alert B judge verdict pairwise rubric, per-item rationale
TL;DR

TL;DR

  • An LLM judge ranks the alert queue in seconds, not analyst-minutes.
  • Pairwise verdicts with explicit rubrics and a rationale you can audit.
  • Analysts move off the queue and onto auditing the judge's disagreements.
  • Sampled judge-versus-analyst delta is the trust signal that flags drift.
click to read →
LLM-as-a-judge for security alert triage

Alert volume outpaces analyst review every quarter: the queue grows, the tail rots, and on-call burns out on duplicates. So we put an LLM-as-a-judge in front of it for a triage signal in seconds. But a judge nobody checks is just a faster way to be wrong, and absolute severity scores drift at volume. What makes the verdicts steady enough to trust, and where do the analysts go once the queue stops being their job?

GRE tunnel over 5G uplink U5G Max 5G router GRE / IP-in-IP encrypted overlay OPNsense gre0 iface LAN hosts datacenter outer: 5G ISP IP (dynamic/CGNAT) inner: 10.0.0.0/30 stable addressing fixed topology over a carrier-grade NATted link
Ubiquiti U5G Max GRE Tunnel with OPNsense

I have made a walkthrough guide on how to set up the new Ubiquiti U5G Max using a GRE tunnel with a third party gateway, in this case OPNsense. It is fully functional, production ready I would say and more or less straight forward.

AI-powered NVR with Nvidia Blackwell cam-1 cam-2 motion cam-3 Frigate NVR realtime object detection · GPU Home Assistant integration · RTSP/RTMP on-device AI object detection, zero cloud
Frigate NVR - Complete Setup Guide with Nvidia Blackwell

Docker - Frigate 0.16.4 - NVIDIA RTX 2000 Pro Blackwell

1Four consoles, four query languages, one incident. 2The analyst is the integration layer. 3One query box over all your telemetry. 4A slow index degrades, never stalls. 5Rank without provenance teaches the wrong trust.
query logs traces endpoint intel re-rank spans four indices, one cross-encoder
TL;DR

TL;DR

  • An incident crosses four tools; the analyst reconciles them by hand.
  • One query box fans out to logs, traces, endpoints, and threat-intel.
  • A cross-encoder re-ranks by source and recency, not just relevance.
  • Slow index? It degrades to recency-only instead of stalling.
click to read →
Cross-source incident search

An incident never lives in one tool. The first alert is in the SIEM, the next clue a span ID in the traces, the smoking gun a process tree in the EDR, the attribution in threat-intel. So the analyst becomes the integration layer, carrying one fact across four consoles by hand, and paying for it in the minutes that matter most. What happens when a single query box fans out across all four at once?

1Billions of dot products per request, 2.5x faster on AVX-512.
ranking · p99 · 7d ▼ 2.5× scalar 18.4ms vector 7.3ms 0 5 10 15 20 ms JDK Vector API · dot-product hot path
TL;DR

TL;DR

  • Billions of dot products per request on the ranking hot path.
  • One portable JDK Vector API loop compiles to AVX-512 when present.
  • Measured 2.5x speedup on the ranking hot path, no native code.
click to read →
Optimising recommendation systems with the JDK Vector API

Billions of dot products per request. A single portable loop that compiles down to AVX-512 when it's there, with measured 2.5x speedup on the ranking hot path.

1Define a metric once; the planner picks the cheapest materialisation.
DataJunction · semantic layer 5m active queries 1.4k ▲ 12% wow cache hit % p99 · hour × day 00 23h SLO · 30d 99.95% target 99.9
TL;DR

TL;DR

  • A shared semantic layer: define a metric once, consume it consistently.
  • Consumers ask by name; the planner picks the cheapest valid materialisation.
  • Built as a service, not a library.
click to read →
DataJunction: the missing piece of the modern data stack

A shared semantic layer where a metric is defined once and consumed consistently. Consumers ask by name, the planner picks the cheapest valid materialisation.

1Four tools, four truths, one employee. 2IAM said yes, EDR said no. 3Stop reconciling exports. Append one log. 4Audit prep: weeks became days. 5The spine was easy; politics weren't.
IAM EDR vuln reviews event spine audit compliance IR risk many in, one spine, many out
TL;DR

TL;DR

  • One append-only spine fed by IAM, EDR, vuln scanners, and code review.
  • Consumers (audit, compliance, IR, risk) each project the view they need.
  • Replays are cheap; schema evolution stays explicit and contract-bound.
  • Audit prep dropped from weeks to days, not the data team's heroics.
click to read →
One append-only spine for compliance

Compliance season meant collecting a CSV from every security tool and reconciling them by hand, and IAM never agreed with EDR about the same employee. The disagreements were not bugs; each tool had simply observed a different event at a different time. So we stopped asking four tools for their version of the truth and rebuilt the substrate underneath them. What replaced the spreadsheet, and why did letting go of the per-tool dashboards turn out to be the hard part?

minimal ZSH prompt zsh ∙ pure ~/dev/project main git push Enumerating objects: 5, done. Writing objects: 100% (3/3) ~/dev/project main async git status · no lag · single character
Pure - A minimal ZSH Prompt

Pure is a pretty, minimal, and fast ZSH prompt designed to stay out of your way while providing essential information. Created by Sindre Sorhus, it stands out from cluttered, slow prompts by offering a clean, visually pleasing interface.

end-to-end encrypted transfer sender wormhole send file.tar.gz receiver wormhole recv 7-crossword-... SPAKE2 key agreement 7-crossword- pancake no account · no server storage human-readable one-time code peer-to-peer transfer with one-time passphrase
Magic Wormhole

Magic Wormhole is an elegant solution to one of computing&#39;s most persistent problems: how to securely transfer files between two computers without the complexity of SSH keys, server configuration, or third-party services. Created by Brian Warner, this open-source tool embodies the principle that security and usability don&#39;t have to be mutually exclusive.

web server comparison Caddy Nginx auto HTTPS manual certbot Caddyfile simple verbose config HTTP/3 QUIC HTTP/2 default Go · single binary battle-tested smaller ecosystem modules & CDN JSON API live reload + test Caddy: zero-config TLS · Nginx: raw performance choose based on ops overhead vs tuning control
Caddy vs Nginx

Why Caddy is Better Than Nginx: A Comprehensive Comparison

European managed hosting AMS-01 ● online Ryzen 9 64 GB DDR5 AMS-02 ● online EPYC 7443 128 GB DDR4 AMS-03 ● maint. Xeon Gold 256 GB DDR4 NL · GDPR · 10 Gbps uplink · NVMe BGP anycast · DDoS mitigation bare-metal and VPS in Amsterdam
Datanode.eu

State-of-the-Art datacenter in Timișoara - Romania

Romanian cloud platform Cloudify.ro managed cloud VPS 2-32 vCPU object S3-compat k8s managed EU datacenter · local billing · RO support EU-sovereign alternative to hyperscalers
Discover Cloudify.ro

Romania&#39;s top Cloud VPS service provider - #CloudifyRO #BetterThanHetzner #RomanianCloudRevolution #OpenStackPower

curated CLI toolkit ripgrep fd bat fzf eza delta jq htop lazygit zoxide yazi hyperfine modern unix: faster, prettier, smarter drop-in replacements for standard Unix tools
Awesome CLI Tools

Awesome CLI tools for productivity and more

main.go terminal 1 package main 2 3 func main () { 4 fmt. Println ("hi") 5 } $ go run . hi $ NORMAL main.go 5:1 100% modal editor · Lua config · LSP built-in
Neovim

Some description

single-board homeserver Apollo N3450 8 GB LPDDR4 2× SATA 6 Gbps 2× 1GbE Intel i225 PCIe x1 slot USB 3.0 × 2 HDMI 2.0 6W TDP runs Proxmox, TrueNAS, Docker, Kubernetes x86 homelab node in a 20W envelope
Zimaboard

The ZimaBoard and ZimaBoard 2 are single-board servers designed for homelab enthusiasts, makers, and DIY server builders.

allowlist IPs by Autonomous System inbound 1.2.3.4 5.6.7.8 CrowdSec AS lookup RIPE / ARIN ✓ AS1234 whitelist ✗ AS5678 block AS1234 Cloudflare 172.64.0.0/13 → allow (trusted CDN) AS5678 Unknown 203.0.113.0/24 → block (not in whitelist) bypass rate-limits for trusted origin networks
Crowdsec AS Number Whitelist

Crowdsec AS Numbers Whitelist in Postoverflows

CTI enrichment → Suricata rules CrowdSec CTI API enrichment IP reputation Suricata custom rules alert ip [crowdsec_block] any -> $HOME_NET any ( msg:"CrowdSec CTI blocklist hit"; threshold:type limit, track by_src, count 1, seconds 60; classtype:policy-violation; sid:9001001;) community threat feed → auto-generated Suricata rule crowd-sourced IP intelligence in your IDS
Crowdsec CTI API Integration with Suricata

Integrating Crowdsec CTI API with Suricata running in IDS mode. This automation queries each IP address pushed by Suricata into fast.log

IP decision engine on OPNsense inbound 203.0.1.9 IPDEX geo · ASN · score OPNsense plugin block allow challenge IP: 203.0.1.9 Score: 87/100 (malicious) Country: XX ASN: 999 Behaviors: scanner, brute-force Decision: → BLOCK via pf enrich firewall decisions with community threat data
Crowdsec IPDEX on OPNsense

IPDEX a simple CLI tool to gather insight about a list of IPs or an IP using the CrowdSec CTI

macOS outbound connection firewall Spotify → audio.scdn.co:443 allow Xcode → metrics.apple.com:443 BLOCK VSCode → vscode.cdn.net:443 ask Python → pypi.org:443 allow unknown → 203.0.113.1:4444 BLOCK every outbound connection: allow / deny / ask per-process outbound firewall for macOS
Little Snitch

A Refined Look at its benefits, value, and how it compares to OpenSnitch and other similar solutions.

1SOAR sells low-code, delivers click-ops in JSON. 2You write if-statements as nested, un-greppable JSON. 3Per-run pricing bills you to merge your playbooks. 4Same vendor upgrade: six months of conference calls. 5Coding agents transpile playbooks in days, not quarters.
400 scripts one per customer × app $/run 48 playbooks same logic, merged consolidation paid for in JSON
TL;DR

TL;DR

  • Low-code SOAR delivers click-ops: if-statements as nested JSON nobody can grep or test.
  • Per-run pricing forces merged dispatchers, which break priority and destroy attribution.
  • You pay 10x to 50x for a workload that fits on one small VM.
  • AI agents transpile playbooks in days, collapsing the migration tax that held the category.
click to read →
The SOAR anti-pattern tax

SOAR sells low-code, no engineers needed, a visual editor as source of truth, per-run pricing that aligns with usage. Live inside one and all three invert: analysts file tickets so engineers can write programs in JSON, the billing model floods your critical alerts behind someone else's noise, and you pay SaaS rates at the bottom of the funnel. The one thing that kept the category alive just moved.

detect nmap probes with Suricata attacker nmap -sS -T4 Suricata SYN scan detect fast-pattern EVE log alert + drop alert tcp any any -> $HOME_NET any ( msg:"NMAP SYN scan detect"; flags:S,12; threshold:type both, track by_src, count 5, seconds 2; classtype:recon; sid:1000001; rev:1;) threshold + flags match = nmap fingerprint custom Suricata rules to catch network scanners
Suricata Nmap Rules

Here are some custom Suricata Nmap rules that you can use

layered remote access toolkit WireGuard - kernel VPN, UDP, roaming keys Tailscale - WireGuard mesh, NAT traversal SSH -L/-R - port forward, SOCKS proxy sshuttle - transparent proxy over SSH Cloudflare T - no inbound ports, ZTNA pick the right tool for the network constraint
The Swiss Army Knife of Remote Access

Master SSH Tunneling: Securely access internal services with local and remote port forwarding. Ideal for network security enhancement.

bidirectional IDS + crowd-intelligence CrowdSec agent · LAPI community blocklist Suricata IDS · EVE JSON signature rules blocklist push alerts feed Suricata detects scan → EVE log → CrowdSec parser CrowdSec bans IP → bouncer → pf/nftables DROP Ban propagates to community → shared protection each node protects all nodes IDS detection feeds the crowd-sourced blocklist
Crowdsec Integration with Suricata

Crowdsec integration with Suricata and Pushover notifications running on OPNsense

expose services without inbound ports internet user browser Cloudflare Zero Trust proxy anycast edge cloudflared outbound only OPNsense LAN services app.domain.com no open ports · TLS everywhere · identity-gated cloudflared daemon runs inside your network publish services behind a NAT with zero firewall rules
Cloudflare Zero Trust tunnel for OPNSense

Cloudflare provides you with a secure way to connect your resources without a publicly routable IP.

zsh $ git add -- Add file contents to the index commit -- Record changes to the repository push -- Update remote refs status -- Show the working tree status log -- Show commit logs -- tab for more -- context-aware completion with descriptions
ZSH Autocompletion

ZSH Autocompletion

system resource monitor CPU 75% MEM 50% SWP 10% PID NAME CPU% MEM% 1842 firefox 24.1 18.3 3201 code 12.4 10.1 901 postgres 2.1 4.8 htop replacement with Rust performance
Neohtop

A modern, cross-platform system monitor built on top of Svelte, Rust, and Tauri.

identity-first network access user WARP client Access IdP check device posture geo policy app.internal ✓ admin.corp ✓ dev.infra ✗ never trust, always verify no implicit LAN trust · micro-segmentation device health gating · short-lived tokens identity replaces the network perimeter
Cloudflare Zero Trust

Securely exposing a self-hosted application using Cloudflare Zero Trust

ship firewall telemetry to Elasticsearch Zenarmor OPNsense Logstash parse · enrich Elastic index + search { "src": "192.168.1.12", "dst": "ads.tracking.io", "action": "block", "category": "ads", } Kibana dashboard top blocked hosts bandwidth by app threat timeline long-term security analytics from your perimeter
Zenarmor Remote Elasticsearch

Zenarmor Remote Elasticsearch Database with Docker

layered LAN inspection LAN traffic (east-west + north-south) Zenarmor L7 app control · TLS inspection · category block Suricata signature IDS · exploit · C2 · port scan OPNsense pf · allow / block / alert Zenarmor sees apps, Suricata sees exploits complementary layers, neither replaces the other
Zenarmor and Suricata on Lan

Zenarmor and Suricata on LAN. YES it works!

Protectli Vault · OPNsense hardware WAN LAN OPT1 OPT2 Intel J6412 4-core · 16W 8 GB RAM DDR4 4× Intel i225-V · AES-NI · fanless · mSATA OPNsense 24.x Suricata IDS · Unbound DNS · Zenarmor HAProxy · Tailscale · Let's Encrypt purpose-built x86 firewall appliance
OPNsense Dec 850 V2

More Than Just Hardware, It’s a Work of OPNsense Art!

continuous SQLite replication to S3 SQLite app.db WAL mode WAL Litestream sidecar process stream WAL <1s RPO S3 bucket generations/ WAL segments $ litestream restore -o app.db s3://bucket/db restore: 1.4s to last checkpoint no Postgres needed · no backup cron · zero ops works with MinIO, Backblaze B2, GCS too sub-second RPO for a single-file database
Replicating to Amazon S3 Using Litestream

Replicating to Amazon S3 Using Litestream

searchable snippet library ssh-key-gen ssh-keygen -t ed25519 -C "email@host" -f ~/.ssh/id_ed25519 docker-clean docker system prune -af docker volume prune -f git-undo git reset --soft HEAD~1 port-check ss -tlnp | grep :8080 $ snips search ssh CLI snippet manager with fuzzy search
Snips

snips.sh is a free, anonymous, open source, snippet service.

1All config is committing to the gitolite-admin repo, no SSH. 2The base image's authorized_keys becomes the gitolite admin key automatically. 3A single Host entry in ~/.ssh/config replaces IP, port, and user. 4Importing a GitHub repo takes four commands.
TL;DR

TL;DR

  • Gitolite manages multiple repos and per-user permissions, all through git push.
  • The Docker setup packages the whole server into one reproducible image.
  • Add a Host git entry to ~/.ssh/config and every git command gets simpler.
  • Create repos in gitolite.conf, push, clone. Import from GitHub in four commands.
click to read →
gitolite + docker repo project1 RW+ = alice bob R = carol FROM base RUN gitolite setup -pk admin.pub $ docker build -t="gitrepo" . $ docker run -d -p 127.0.0.1:222:22 $ git clone git:gitolite-admin Gitolite · Docker · SSH config
Git Server with Gitolite and Docker

Run a self-hosted git server with per-repo access control using Gitolite, packaged into a reproducible Docker container.

1A container stops the moment its main command exits. 2One Dockerfile is the complete, reproducible setup recipe for any environment. 3authorized_keys in the build context becomes root's SSH access inside the container. 4docker run -p binds a container port to a host port.
TL;DR

TL;DR

  • Docker runs isolated environments from Dockerfiles: build once, run anywhere Docker exists.
  • docker images, docker ps, docker run, docker commit: the core lifecycle commands.
  • A base image with supervisord and sshd gives a reusable Ubuntu container with remote access.
  • New project images extend the base image with their specific installs and configs.
click to read →
docker container sshd · supervisord · git · vim image: base (ubuntu 14.04) FROM ubuntu:14.04 · authorized_keys $ docker build -t "base" . $ docker run -d -i \ -p 222:22/tcp base Dockerfile · images · containers
Docker 101

Docker from scratch: installation, the core commands, building images from Dockerfiles, and a reusable supervisord/SSH base template.

1Your public key in authorized_keys gets you passwordless access. 2-L reaches a firewall-blocked remote service; -R exposes a local service publicly. 3-D turns SSH into a full SOCKS5 browser proxy. 4autossh re-establishes the tunnel automatically even after IP changes or disconnects.
TL;DR

TL;DR

  • Key pair: private key stays local, public key goes into authorized_keys on each server.
  • ~/.ssh/config stores per-host settings so you never repeat flags on the command line.
  • -L, -R, and -D cover local forward, remote forward, and SOCKS5 proxy.
  • autossh, the ~ escape, and SSH chains handle the harder remote-access scenarios.
click to read →
ssh $ ssh-keygen ~/.ssh/id_rsa.pub # public # local forward ssh -L 6606:127.0.0.1:3306 db # socks5 proxy ssh -D 127.0.0.1:9999 server # chain ssh -t proxy ssh root@s33 keys · scp · -L -R -D · autossh · chain
SSH

Keys, scp, ~/.ssh/config, local and remote port forwarding, SOCKS5 proxy, autossh, and SSH chains.

1ESC always returns you to normal mode from any other mode. 2All commands accept a numeric prefix: 5w jumps 5 words, 8dd deletes 8 lines. 3set exrc in ~/.vimrc loads a per-project .vimrc from the current directory. 4Space makes a better leader key than backslash: reachable with either hand.
TL;DR

TL;DR

  • Vim has 4 modes: normal (navigate), insert (type), visual (select), command-line (run).
  • ESC :wq saves and quits; ESC :q! discards and quits.
  • hjkl, yy/dd, p, all composable with numeric counts.
  • Set exrc for per-project .vimrc; use Space as leader for shorter custom shortcuts.
click to read →
vim -- NORMAL -- gg G ^u ^d w b yy dd p u -- INSERT -- i a o A I O :wq :q! :g/^/m0 let mapleader = "\<Space>" modes · motions · config
Vim

Modes, navigation, copy-delete-paste, ~/.vimrc configuration, per-project settings, and command-line examples.

1The best editor is the one on every server, no GUI. 2Vim's curve is steep; cycling through other editors costs more. 3tmux keeps sessions alive across connection drops: essential for any remote work. 4Edit rarely, any editor works; edit daily, master one.
TL;DR

TL;DR

  • Vim is recommended for daily editing: customizable, available everywhere, no GUI needed.
  • Emacs is equally powerful but requires Lisp knowledge and has steeper ergonomic risks.
  • tmux multiplexes terminals, keeps remote sessions alive, and is configured in ~/.tmux.conf.
  • Session managers like tmuxifier and tmuxinator build named project layouts on top of tmux.
click to read →
linux utilities vim (text editor) set -g prefix C-a bind \ split-window -h bind - split-window -v tmux (multiplexer) sessions survive disconnects mplayer mencoder handbrake vim · tmux · video
Linux Utilities

The case for Vim over every other editor, tmux configuration for remote work, and a minimal toolkit for daily Linux use.