Danilo Falcão da Silva — DevOps Blog

About

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.

Find me

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.

I know the pitch. I still do not care.

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.

I am treating this as a rumor. You should too.

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.

I use Zsh with Oh My Zsh.

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.

Firefox is my choice.

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.

Here’s the test I use for any deployment tooling:

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.

On April 1, 2026, that deal got noticeably worse.

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.