Hi, I’m Danilo Falcão da Silva — a Senior DevOps Engineer with 20+ years
of experience designing and operating infrastructure across on-premises and
cloud environments. I’m based in Belo Horizonte, Brazil.
My day-to-day is mostly Linux systems, containerization, CI/CD, and the kind
of glue that keeps large-scale distributed infrastructure honest. This blog
is where I write up the things I learn, fix, or kubectl delete and
never speak of again.
Grok 4.5 shipped this afternoon, July 8, 2026, and I am writing about it
the same day. That is not how I usually do these. The
GPT-5.3-Codex review
took me four months, and I opened it apologizing for the lateness. This
one I am writing while it is still warm, because I have been waiting for
it in a specific way and I want to get the reaction down before the
scoreboard arguments start.
Two weeks ago I watched a frontier model disappear out of a live session and learned about it from a fallback banner before I learned about it from the news. Fable 5 went dark on a Friday afternoon because the government told Anthropic to cut foreign-national access, and the only way to comply was to pull the model for everyone. The reflex it triggered was the on-call one, not the policy one: what broke, what’s my fallback, and how much of my work assumed the thing that just vanished.
Let me get the correction in before anyone sends it: this is not a
field report. I have not daily-driven Silverblue, Kinoite, Bluefin,
Bazzite, or Aurora, and I am not going to write as if I had. I have
read the docs, watched the model mature for years, and formed an
opinion from the outside. So when I say I do not care about immutable
Linux desktops, I am not reviewing them. I am telling you why a
technology I genuinely respect has never made me want to switch.
I did not move my main desktop back to Windows because Windows got good. I moved it back because the Fedora box on my desk kept hanging on resume, and a daily driver that needs a reboot ritual after lunch is not a daily driver. WSL carries the Linux side now — kubectl, Terraform, the VPN dance — and the host underneath it is Windows again. I wrote the long version of that desktop friction in my Fedora/NVIDIA field report; this post is about what I found waiting on the other side.
The headline version is too clean: Mythos broke into the NSA. That is almost certainly not what happened. The more interesting version is messier, caveated, and still astonishing.
Here is the chain the viral claim traveled down. Senator Mark Warner, vice chair of the Senate intelligence committee, said the NSA’s chief — Joshua Rudd — had told him that Anthropic’s Mythos model “broke into almost all of our classified systems, not in weeks, but in hours.” The Economist printed the quote. Then the journalist who reported it, Shashank Joshi, walked the edges back in public. He stood by the wording — he had accurately quoted Warner quoting the NSA chief — but said it would be a mistake to read it literally. It surely depended on using Mythos alongside other tools under very particular conditions. He had used the line to convey the model’s potency, and conceded it was a mistake not to have added caveats.
The pager goes off because the app is sick. You start the usual dance: open the traces, pull the logs, check the deploy timeline. Except the traces are thin, the logs are lagging by four minutes, and the dashboards that should be screaming are politely flat. For a second you wonder if the incident is actually over. It isn’t. Your telemetry pipeline is the thing that’s down, and it’s been quietly dropping spans since the memory pressure started — which is exactly when you needed it most.
If you have already fixed WSL2 networking twice this quarter, you read the Build 2026 headlines differently than everyone else. While the tech press argued about whether Microsoft just shipped “WSL 3,” you were the person who actually had to make Docker Desktop, a corporate VPN, and kubectl agree on DNS before standup. So when a wave of articles announced that a paravirtualized GPU/NPU future had arrived, my first question was not “is this exciting.” It was “does this change the thing that breaks on my machine.”
Cloudflare spent a week in April shipping things and then called
the result “Cloud 2.0 — the agentic cloud.” That is a big claim,
and my first reaction to big claims from infrastructure vendors is
to look for the part they are not putting in the headline. The
marketing was about agents. The interesting part is the compute
model underneath it, and almost nobody is talking about that.
The argument they are making is actually sound, which is rare. The
cloud we have was built for the smartphone era. One app serves many
users. You provision a fleet, you put it behind a load balancer,
you scale horizontally, and the whole shape assumes a many-to-one
relationship between users and processes. Agents break that shape.
An agent is one-to-one: one user, one agent, one task, often for
minutes at a stretch, holding state the whole time. That is a
genuinely different compute problem, and pretending it is just
“more web traffic” is how you end up with a bill that does not make
sense.
I did not start worrying about supply chain attacks because of
a new CVE. I started worrying the day I noticed where the
attackers were aiming. For twenty years the model was simple:
the internet is hostile, the server is the prize, and you put
a wall between the two. Firewalls, VPNs, bastion hosts, WAFs,
hardened images, least-privilege IAM on the cloud account. We
got good at defending the server.
DeepSeek V3.2 will sell you a million output tokens for forty-two cents.
Claude Opus will sell you the same million for seventy-five dollars.
That’s not a discount. That’s not even the same market. That’s roughly
170x, and once you’ve internalized that number, almost everything
else about the “China overtook the US in AI usage” story stops being
surprising. Developers are not philosophers. When the thing in front of
them is good enough and costs two orders of magnitude less, they route
the traffic and move on. The leaderboard drama is for the timeline. The
invoice is what actually moves workloads.
On June 17, 2026, Zhipu AI — the lab that ships under the Z.ai brand —
released GLM-5.2 under an MIT license. Open weights. Free to download,
free to fine-tune, free to run wherever you want. Within forty-eight
hours, my feeds had decided this was either the death of Anthropic, the
triumph of Chinese AI, or the most overhyped model of the year.
It is none of those things. It is something more interesting and more
boring at the same time: the first open-weights model that I can’t
dismiss as “good for an open model.” Let me walk through what’s actually
in the box, what the internet got right, and where it falls apart the
moment you put real work through it.
There’s a reflex in this industry that nobody questions anymore.
You have a few services to run. Maybe a handful of containers, a
couple of background workers, a cron job or two. And the very first
architecture decision — before anyone has asked what the workload
actually needs — is “so which Kubernetes are we using?”
Kubernetes is the default answer to a question most teams never
bothered to ask. Nomad is the question. Specifically: do you
actually need all of that?
My editor knew before the news did. I was mid-task on Friday afternoon, Claude Code humming along on Fable 5, when the session dropped a banner saying the model was unavailable and that it was falling back to Opus 4.8. My first reaction was not about AI policy. It was the reflex every on-call engineer has when a dependency stops answering: what broke, what is my fallback, and how much of my work assumes the thing now gone.
Every time I write about observability I end up at the same problem: the
telemetry already exists, what is missing is something that assembles it
into answers. Not another panel. Not a correlation query I have to write
by hand at 2 a.m. Something that knows what depends on what, notices
that latency climbed two minutes after the deploy, checks the runbook,
and tells me what the options are. AWS DevOps Agent is the most credible
attempt I have seen to build exactly that. My hesitation is not about
the idea. It is about what happens to the bill once teams start
depending on it.
For two years the answer to “where do I run a model that won’t fit on a
normal GPU” was the same boring answer: rent a cloud instance, watch the
meter, hope you remembered to shut it down. In 2026 there’s finally a
second answer that lives on your desk. Two of them, actually, and they
take opposite philosophical bets.
NVIDIA shrank a slice of its datacenter stack into a desktop and called
it DGX Spark — a GB10 Grace Blackwell superchip with 128GB of unified
memory and a literal petaFLOP of FP4 compute. AMD took the other road:
Ryzen AI Max+ 395, codename Strix Halo, a normal x86 APU that happens
to carry up to 128GB of unified memory and shows up in mini PCs you can
buy for roughly half the price.
Hermes Desktop exists now, and I think it’s phenomenal — and I want to be honest up front about why that sentence almost didn’t come from me.
I live in the terminal. I have a tmux layout I’ve been refining for years, a shell that finally gets out of my way, and muscle memory that turns most config edits into a few keystrokes. Hermes Agent has run from my terminal for months and it works. It reaches me over Telegram, it runs its loop, it learns my environment. The CLI was never a problem I needed solved.
The evidence is thin. A reference to gpt-5.6 appeared briefly in OpenAI’s Codex logs and disappeared. Polymarket consensus put the probability of a late-June release above eighty percent. No official benchmark, no spec sheet, no price card. The “Mythos-level” claim — that GPT-5.6 would be roughly equivalent to Anthropic’s Mythos family at a fraction of the cost — comes from community inference, not a press release.
Everybody who has run Kubernetes on their own hardware knows the
moment the demo ends. You stand up a cluster — RKE2,
K3s, kubeadm, whatever fits the rack — and stateless workloads behave
beautifully. Deployments roll, pods reschedule, the control plane
self-heals, and for about a week you feel like you’ve gotten away with
something. Then somebody needs a database. Or a registry. Or Postgres
for the internal app that the whole company quietly depends on. And
suddenly the question is no longer “can Kubernetes schedule this” but
“where does the data actually live, and what happens to it when a node
dies at 3 a.m.”
Open any infrastructure repository from the last five years and count
the file extensions. I did this recently on a platform I inherited, and
the answer was bleak in a familiar way: a handful of Go files, some
Dockerfiles, a couple of shell scripts, and then a sprawling continent
of .yaml. Cluster manifests. Helm values. CI pipelines. Argo
Applications. Alerting rules. Service definitions. Policy. The actual
program was a rounding error. The system was YAML.
There is a particular kind of meeting I have sat in too many times. A
team is frustrated with a tool. Something broke, or the config is ugly,
or a louder team down the hall is using something newer, and someone
says the words: “maybe we should just switch to X.” And everyone nods,
because switching feels like progress, and nobody in the room wants to
be the person defending the thing that’s annoying them today.
I did not start caring about MCP because of the protocol spec. I read
the spec, it is fine, it is JSON-RPC with some sensible primitives, and
on its own it would not have earned a post. I started caring about MCP
the day it changed what an agent is. Before tool access, an agent
generates text. You read the text, you decide, you act. After tool
access, the agent acts. It opens the pull request, it queries the
database, it restarts the container, it pages someone. The text was a
suggestion. The tool call is an operation.
It is 2:14 a.m. The page fires. Checkout error rate is up, the on-call channel is already three messages deep, and someone has dropped a link to a dashboard. I open it. Forty-two panels. Twelve of them are red, which tells me nothing, because nine of those twelve are red on a good day and nobody has touched the thresholds since 2022. I scroll. I find a latency graph that is clearly angry. It does not tell me why. It does not tell me what changed at 2:09. It does not tell me which of our seventeen downstream dependencies is the actual problem. It just confirms, in beautiful gradients, that we are having a bad night.
I do not use Go for everything, and I want to be honest about that.
My stack has a hierarchy. Shell handles most of what I do. Python takes over when shell gets too complex. Go is what I reach for when I am explicitly optimizing for performance. That last tier is what this post is about — when performance is the goal, Go is awesome in a specific, practical way.
I have been waiting years to write this sentence without rolling my eyes: hybrid Kubernetes on a major managed platform finally looks practical.
Not perfect. Not magical. Practical.
The new EKS Hybrid Nodes Gateway is the first AWS move in this space that feels like an operations feature, not a slide-deck feature. It directly targets one of the worst recurring pain points in hybrid Kubernetes: getting reliable traffic flow between cloud-side components and on-prem or edge pods without building a pile of bespoke routing logic that only two people on the team understand.
That one line summarizes a big shift in how I work every day. I did not switch because Bash is bad. I love Bash and respect it. Bash is stable, everywhere, script-friendly, and still the safest common denominator when I touch unknown Linux boxes.
I switched because my daily workflow changed, and Bash stopped fitting that workflow.
The Bash pain point that finally made me move
The biggest Bash pain point for me was history behavior across multiple terminals.
That sentence is boring, and that is exactly why I trust it. I have spent long stretches on Chrome, pure Chromium builds, and Brave. I keep coming back to Firefox. Not because it is perfect, not because it wins every benchmark, and not because I enjoy contrarian browser takes. I come back because it fits my real daily workflow better, with less policy friction and less account-management nonsense.
I’ll make this simple up front: I love New Relic for APM. I also love what Datadog built as an integrated operational platform.
If you only want a tribal answer, stop here: for app-centric teams with strong APM focus, New Relic still punches above its weight. For platform-heavy operations across infra, security, delivery, and incident flow, Datadog usually wins.
But the right answer depends on team shape, telemetry habits, and how much operational burden you are willing to carry.
I decided to test Codex CLI today because I have liked the quality I get from GPT-5.3-Codex enough to take it seriously in real work. I did not open it looking for a demo. I opened it with the same question I apply to any tool that can touch production-bound code: is this operationally trustworthy, or just impressive for fifteen minutes?
My conclusion is clear: Codex CLI is already good enough to pilot seriously, but it is not my daily driver yet.
Btrfs is king on Linux. Not because it’s technically superior to ZFS in
every dimension — it isn’t — but because it ships in the kernel, installs
without friction, and integrates with every major distro’s tooling out of
the box. In 2026, if you format a fresh Fedora, openSUSE, or Ubuntu
Desktop installation, you’re running Btrfs by default. ZFS requires you
to want it badly enough to fight the packaging.
Two things happened in the same week. Both of them involved Anthropic.
One was a major hire. The other was a Vatican press conference. Neither
was fake. But the internet managed to smash them together into something
that was, and now people are asking me if the Pope works at Anthropic.
Let me untangle this.
What actually happened: the Karpathy hire
On May 19, 2026, Andrej Karpathy posted on X: “I’ve joined Anthropic. I
think the next few years at the frontier of LLMs will be especially
formative. I am very excited to join the team here and get back to R&D.”
Every few years someone publishes a blog post titled something like
“PostgreSQL: The Everything Database” and the comments fill with people
saying “well, obviously.” The thing is, it wasn’t obvious. In 2010, if
you told a room full of engineers that the correct database for their
document store, their geospatial queries, their full-text search, and
their vector similarity lookups was the same 30-year-old relational
database, they would have politely suggested you hadn’t used MongoDB yet.
kubectl is the Swiss Army knife. Nobody disputes this. But Swiss
Army knives are terrible at most of the individual jobs they claim to
do, and kubectl is no different: it can tail logs, but only one pod
at a time. It can switch contexts, but with zero guardrails. It can
describe resources, but in a wall of YAML that buries the thing you
actually care about.
Day-2 operations — the part where the cluster is live, traffic is
flowing, and someone pages you at 2 a.m. — need sharper instruments.
What follows is the utility belt I’d recommend to any Kubernetes
operator building their toolkit in 2026. Not everything here is new.
Some of these tools have been around since 2018. The point is that
they’re still maintained, still solve real problems, and still faster
than the kubectl incantation you’d otherwise be typing.
Most teams get SLAs, SLOs, and SLIs wrong. Not because the concepts are hard, but because they treat them as compliance paperwork instead of operational tools. The result is dashboards nobody trusts, targets nobody chose deliberately, and on-call rotations that burn people out chasing noise.
This post is a field guide for teams that actually run production systems and want reliability engineering to work as an engineering discipline — not a slide deck exercise.
On January 9, 2026, at roughly 02:20 UTC, Anthropic flipped a switch
on their servers and broke thousands of developer workflows overnight.
No blog post, no advance notice, no migration path. Third-party coding
tools — OpenCode, Cline, RooCode, OpenClaw, and others — that had been
using Claude subscription OAuth tokens suddenly got a single error:
“This credential is only authorized for use with Claude Code and
cannot be used for other API requests.”
I ran GNU Screen for more than twenty years. It was one of the first tools I installed on every machine, right after vim and ssh. Screen kept long compilations alive through flaky connections, let me juggle IRC and tail logs on the same VT100, and never once lost a session I cared about. For a tool born in 1987, that is a remarkable track record.
About fifteen years ago I switched to tmux. It was not because Screen broke. It was because tmux made me faster at work I was already doing, and then it kept getting better while Screen stood still. I have not looked back.
This is a late review. GPT-5.3-Codex shipped on February 5, 2026, and
here I am almost four months later writing about it. I have no excuse
beyond the usual one — too many things to look at, not enough evenings.
But having spent the past few weeks reading benchmarks, watching demos,
and following what developers are actually saying about it, I want to be
honest: it is a good model. A genuinely good one.
On May 18, 2026, Linus Torvalds called the Linux kernel security mailing list “almost entirely unmanageable.” The reason: a flood of AI-generated bug reports. The reaction was predictable — ban AI, blame researchers, declare the tools aren’t ready.
I wrote about the maintenance crisis last week and I think that framing misses the deeper story. The problem is not that AI is generating too many reports. The problem is that the code was more broken than we thought, and for twenty years nobody had the tools to look at it properly.
I don’t pay for Snyk. Not because it’s bad — it’s a genuinely good
product — but because there is a free stack that catches the vast
majority of the same issues directly in CI, and the remaining gap
hasn’t been worth roughly $600 per developer per year to close.
On a team of fifteen engineers, that’s the price of a small EC2
fleet you actually need.
This post is about the open-source security tooling I actually wire
into pipelines: Trivy for containers, dependencies and IaC,
Semgrep for application code, Nuclei and OWASP ZAP for
the live app, and a few honourable mentions. It’s not an exhaustive
catalogue. It’s the stack I keep coming back to.
There are four names that come up when you ask how to manage
configuration at scale. I’ve used all four, in production, over the
last fifteen years. The answer to “which one” is not the one that
wins benchmarks — it’s the one that matches how your team thinks
about change.
The shortlist hasn’t changed since the early 2010s: Ansible,
Puppet, Chef, SaltStack. The ownership has changed. The
licences have changed. The community gravity has very much changed.
Ansible sits at 31.94% market share for new projects as of early
2026 and is, by a wide margin, the most-adopted tool for new
configuration-management work. Puppet holds 12.41%, Chef around
6.70%, and Salt has fallen out of the top-tier mindshare entirely
even though the codebase is still actively developed under Broadcom.
Infrastructure as Code stopped being a single-answer question a couple
of years ago. Terraform went BSL in August 2023, OpenTofu forked
under MPL, Pulumi kept arguing that infrastructure should be real
code in real languages, and IBM closed the $6.4B HashiCorp
acquisition in February 2025. Three legitimate tools, three different
bets on who owns the abstraction.
I still run Terraform. For everything.
This post is the honest version of why. I’ve read the OpenTofu release
notes, watched Pulumi talks, played with both on weekend projects, and
read more migration write-ups than I can remember. I have never put
OpenTofu or Pulumi in front of production traffic. Most of what
follows about those two is research, not muscle memory — and I’ll flag
that as I go.
I have spent most of my career running things that boot. Bare metal,
VMs, containers, Kubernetes — boxes that come up, hold state, and need
somebody to think about their lifecycle. AWS Lambda is the opposite
of that mental model, and for a long time I treated it the way a lot of
old-school infrastructure people treat it: useful for toy apps, fine for
a Slack bot, not a serious tool.
For about a decade, “Kubernetes ingress” effectively meant one thing:
ingress-nginx, the community-maintained controller that wrapped
the Nginx engine behind the Kubernetes Ingress resource. It was
fine. It was the default everyone reached for. It was also,
quietly, the wrong long-term shape for the problem.
That era ended in 2026. The community ingress-nginx project
reached end-of-life in March 2026. The Kubernetes Gateway
API, which graduated to GA on the v1.2 line, is now the
forward-looking standard. Envoy Gateway is the CNCF reference
implementation. Cilium does L7 routing in eBPF without a
sidecar or an extra proxy. RKE2 flipped to Traefik by
default in v1.36 and removes ingress-nginx entirely in v1.37.
I configure infrastructure for a living. Containers, reverse proxies,
NFS mounts, certificate renewals, sync layers between machines —
that’s most days. The last thing I want when I open my personal
note-taking app is another sync layer to babysit. That, more than
anything else, is why I picked Notion over Obsidian.
This is the honest read on Notion vs Obsidian for one person, one
phone, one Linux desktop, and the occasional browser tab on someone
else’s machine. The headline: Obsidian is the purer architecture
and the wrong fit for me. Notion is the lazy architecture that does
the right thing without asking. For a personal knowledge base, lazy
wins.
The Kubernetes Secret object is a YAML manifest with a base64-encoded
value in it. That’s the entire encryption story. Anyone with get
permission on the namespace can read every credential the workload
holds. Base64 is not encryption. It is barely obfuscation.
Teams discover this the wrong way — usually during a security
review, occasionally during an incident — and the next question is
always the same: so where do the real secrets live?
For most of 2025 the age-verification conversation was about porn
sites. By the end of the year it had moved up the stack. By 2026 it
is at the operating system, and that is where the story gets
interesting for anyone who cares about how Linux is built.
Nine US states put age-verification laws in force during 2025 alone:
South Carolina (Jan 1), Florida (Jan 1), Tennessee
(Jan 13), Georgia (Jul 1), Wyoming (Jul 1), North Dakota
(Aug 1), Arizona (Sep 26), Ohio (Sep 30), and Missouri
(Nov 30). Roughly half the country now mandates some form of age
gate for adult content, social media, or both.
You’ll see this comparison on r/kubernetes every couple of months,
phrased as if it’s a real choice: Rancher or Lens? The framing is
wrong. They occupy different layers of the stack. Asking which one
“wins” is like asking whether VS Code beats Kubernetes.
But the question keeps coming up — usually from someone who has Lens
installed, has heard about Rancher, and is trying to figure out
whether they should swap. So let me lay out what each one actually
is, where they overlap, where they don’t, and which one earns a place
in a serious on-prem setup.
For most of Kubernetes’ life, the cluster data path has been a tower of
iptables rules. Pod-to-service routing, NAT, network policy, even
the way kube-proxy programs a Service IP — all of it expressed as
netfilter chains evaluated linearly on every packet. It worked. It
also aged badly.
In 2026, the answer the ecosystem has converged on is eBPF, and the
project doing most of the convergence is Cilium. The shift is
no longer aspirational: kube-proxy itself shipped an nftables mode
that is expected to go GA in Kubernetes 1.33, the old IPVS
backend is deprecated as of v1.35, and the major managed Kubernetes
providers (EKS, GKE, AKS) all offer a Cilium-powered data plane as a
first-class option. Azure CNI Powered by Cilium is GA on K8s 1.33.
There is a kind of infrastructure question that never really gets
settled, just re-litigated every couple of years as the surrounding
ecosystem moves. “Which reverse proxy?” is one of those questions.
The shortlist hasn’t changed much: Caddy, Nginx, Traefik.
The context around them has changed a lot. The community ingress-nginx
project reached end-of-life in March 2026. RKE2 v1.36 flipped
to Traefik as the default ingress. Caddy quietly shipped 2.11
with better health-checking and ECH rotation. Nginx is on 1.31
mainline / 1.30.1 stable and treats HTTP/3 as a first-class but
still-evolving feature.
There are two open-source autonomous agents in 2026 worth a serious
DevOps engineer’s time, and they have made opposite architectural
bets. I tried both. I run Hermes Agent every day. This is the
analysis of why — not a both-sides post, not a head-to-head benchmark,
but a direct argument that one of these two architectures is right for
infrastructure work and the other one isn’t.
The headline: agent-first beats gateway-first when the work rewards
familiarity. Most infrastructure work does. The rest of this post is
the why.
On May 18, 2026, Linus Torvalds said the Linux kernel security mailing
list had become “almost entirely unmanageable” because of duplicate
AI-generated bug reports. Two months earlier, longtime stable
maintainer Willy Tarreau had already shared the numbers: a list
that received two to three reports per week in 2024 was getting
five to ten reports per day by March 2026. In January, Daniel
Stenberg shut down the curl bug bounty after the valid-report rate
on HackerOne dropped from above 15% to below 5%, with twenty
submissions in 21 days — seven of them in one 16-hour window — and
zero real vulnerabilities among them.
KDE shipped the Plasma 6.7 Beta on May 14, 2026. The final release
lands on June 16. I’m still on Plasma 6.6.5 — the stable that
shipped in Fedora 44 — and I’m going to stay there until 6.7 hits
Fedora’s repos. But I have been reading every announcement, every
“This Week in Plasma” post, and every release-note dump KDE has been
putting out, and I want to say this clearly:
My home media server is a Raspberry Pi 4 named uther. It runs
Plex, the entire *arr stack, qBittorrent, a request manager, a reverse
proxy, Vaultwarden as a password manager, and this very blog — all
in Docker Compose. It sips around five watts at idle, more like seven
during peak indexing, and the most expensive part of the whole setup is
a separate Synology NAS sitting on the same shelf doing nothing but
being a quiet, reliable hard drive over NFS.
NVIDIA on Linux has been a punchline for so long that “just buy AMD” was
the standard advice in every Linux subreddit thread. In 2026, on
Fedora 44 with KDE Plasma 6.6 on Wayland, running an RTX 5070
(Blackwell) with the 595 driver branch, I want to say something
different:
It’s fine. It’s actually fine.
Not “fine if you don’t use Wayland.” Not “fine if you stick to X11.”
Fine, full stop. This is the short, honest report of how I run it.
It is 3 a.m. on a Sunday. PagerDuty just woke you up. A production
service is degraded. You roll out of bed, open your laptop, and have
to figure out what the cluster thinks is true, what’s actually
true, and what changed in the last twelve hours. The faster you can
answer those three questions, the better the tooling.
The right GitOps stack collapses all three questions into one
dashboard. The wrong one has you SSH-hopping between five servers
running kubectl rollout history against unlabeled deployments. I’ve
done both. I’m writing this post about the former.
Helm has been the punchline of Kubernetes packaging for about as long
as Kubernetes has been called Kubernetes. Helm 2 had Tiller, an
in-cluster component running as cluster-admin that read every chart’s
YAML and applied it from inside the cluster — a security horror show
that drove half the community to invent its own deployment tooling
just to avoid it. Helm 3 finally killed Tiller in 2019 and went
client-side, which fixed the worst of it. And then Helm 3 sat there,
relatively unchanged, for six years.
Most of the Kubernetes conversation in 2026 happens around managed
services — EKS, GKE, AKS — and most of the rest happens
around K3s for edge and homelab. Somewhere in the middle, on the
hardware that lives in a rack in a datacenter you can drive to,
there’s a Kubernetes story that nobody talks about loudly enough.
That story is RKE2 — the Rancher Kubernetes Engine 2, SUSE’s
hardened, security-focused, single-binary distribution designed for
on-premises production. I’ve been running it for two years across
two different employers and one home lab, and it’s the rare piece of
infrastructure that gets more impressive the longer you live with it.
I ran Ubuntu on my workstation from Hardy Heron in 2008 to about
Jammy in 2022. Fifteen years. It was the first Linux I trusted on
servers I cared about, the first one that made hardware support feel
solved, and for a long stretch it was the obvious answer to “what
Linux should a sane person install?”
I don’t run it on my desktop anymore. I don’t run Ubuntu Server
either — though that’s a personal-taste call and not a knock on the
product, which is still a perfectly good distribution that I’d
happily recommend to most people. Ubuntu has split in half: the
server side is still strong, the desktop side has gone somewhere I’m
not willing to follow, and the two halves deserve very different
treatment. Especially because we just got Ubuntu 26.04 LTS
“Resolute Raccoon” on April 23, and the headlines are mostly
cheerful about features that don’t fix the things that actually
drove me away.
I have been carrying a quiet grudge about Tailscale for two years.
The product is excellent. The clients are polished. The “log in with
Google and you have a mesh in 60 seconds” experience is genuinely
magical. But the control plane — the part that decides which of your
machines can talk to which other machines, and where the keys for that
decision live — is closed source and hosted exclusively by
Tailscale. You can run Headscale to reimplement it open-source,
but you’re still bringing along Tailscale’s proprietary clients on
most platforms.
I’ve spent enough of the last six months working alongside an AI coding
agent that I now have actual opinions, in the way you only get from
shipping production code with a tool, not from reading benchmarks
about it. There are three names that dominate the conversation in
2026 and they represent three genuinely different bets about how
humans and language models should collaborate on code.
This is my honest read on Cursor, Claude Code, and
opencode. The headline:
Claude Code is my daily driver. opencode is my Plan B. Cursor is
not what I reach for. Here’s why.
“What would you give and what would you keep?”
— Mase, From Scratch (Double Up, 1999)
Mase asked it about rewinding your whole life and starting over. I ask
it every time someone on my team picks a development container stack. Because the
moment you decide to let a container be your workstation —
not just hold a service, but hold your editor, your shell, your
language toolchains, your AUR packages on top of a Fedora host — you’re
making a series of small, ugly trade-offs. What would you give up
from your bare-metal workflow, and what would you keep?
The first Steam Machine was a 2015 disaster. A confused, fragmented
launch of third-party boxes running an immature SteamOS 1, no AAA Linux
catalogue, no Proton, and a controller everyone politely pretended to
like. The whole effort quietly evaporated within a couple of years and
Valve, to its credit, didn’t try to spin it. They went away, built the
Steam Deck, built Proton into something that actually works,
and waited.
I have a complicated relationship with code editors. I used vim for
fifteen years out of stubbornness, switched to VS Code because the
ecosystem made it impossible not to, and have spent the last four years
quietly resenting it every time the laptop fans spin up because I opened
three monorepos and a markdown file.
Zed 1.0 shipped at the end of April 2026. I’ve been running it as
my daily driver for the two weeks since, and I’m writing this post in
it. Here’s where I’ve actually landed, including the things I think the
typical Zed review under-sells.
I’ve been running personal infrastructure on Hetzner for the better
part of a decade. Cloud VMs for side projects. A couple of dedicated
boxes for the things I didn’t want to babysit on AWS pricing. The
calculus was always the same: pay a third of what the hyperscalers
charge, manage it yourself, accept the lack of a managed-service safety
net. The deal was very, very good.
A nine-person jury in the Northern District of California took less
than two hours today to unanimously dismiss every claim in Elon
Musk’s lawsuit against Sam Altman, Greg Brockman, OpenAI, and
Microsoft. Musk had sought up to $134 billion in disgorgement, the
removal of Altman and Brockman from OpenAI’s leadership, and the
unwinding of OpenAI’s October 2025 conversion into an $852-billion
public benefit corporation.
He got none of it. The technicality matters more than the headline.
There’s a particular kind of project I love: the one that takes something
new and weird and turns it into something you barely have to think about.
Docker did this for containers. Hugo did it for static sites. In 2026,
Ollama is doing it for open-source language models.
You install one binary. You type ollama pull <model>. You type
ollama run <model>. Your application talks to localhost:11434 over an
OpenAI-compatible HTTP API. That’s the whole user manual. The fact that
this is now boring — that nobody has to argue about it on Hacker News
anymore — is the point of this post.
Fedora Linux 44 shipped on April 28, 2026, two weeks behind its original
date after a late-cycle batch of blockers. I’ve been running it on my KDE
daily-driver for a couple of weeks now. It’s the kind of release that
doesn’t scream — no single tentpole feature — but if you spend your day
on Linux, the cumulative effect is real. Here’s what stood out to me,
with a bias toward what I actually noticed.