<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Danilo Falcão da Silva</title><link>https://falcao.org/posts/</link><description>Recent content in Posts on Danilo Falcão da Silva</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 27 May 2026 01:07:05 -0300</lastBuildDate><atom:link href="https://falcao.org/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>The Shell That Finally Got Out of My Way</title><link>https://falcao.org/posts/the-shell-that-finally-got-out-of-my-way/</link><pubDate>Wed, 27 May 2026 01:07:05 -0300</pubDate><guid>https://falcao.org/posts/the-shell-that-finally-got-out-of-my-way/</guid><description>&lt;p>I use Zsh with Oh My Zsh.&lt;/p>
&lt;p>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.&lt;/p>
&lt;p>I switched because my daily workflow changed, and Bash stopped fitting that workflow.&lt;/p>
&lt;h2 id="the-bash-pain-point-that-finally-made-me-move">The Bash pain point that finally made me move&lt;/h2>
&lt;p>The biggest Bash pain point for me was history behavior across multiple terminals.&lt;/p></description></item><item><title>Firefox Won My Daily Workflow</title><link>https://falcao.org/posts/firefox-won-my-daily-workflow/</link><pubDate>Wed, 27 May 2026 01:04:45 -0300</pubDate><guid>https://falcao.org/posts/firefox-won-my-daily-workflow/</guid><description>&lt;p>Firefox is my choice.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>NewRelic vs Datadog in 2026: My Opinionated Choice</title><link>https://falcao.org/posts/newrelic-vs-datadog-in-2026-opinionated-choice/</link><pubDate>Tue, 26 May 2026 18:17:06 -0300</pubDate><guid>https://falcao.org/posts/newrelic-vs-datadog-in-2026-opinionated-choice/</guid><description>&lt;p>I’ll make this simple up front: I love New Relic for APM. I also love what Datadog built as an integrated operational platform.&lt;/p>
&lt;p>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.&lt;/p>
&lt;p>But the right answer depends on team shape, telemetry habits, and how much operational burden you are willing to carry.&lt;/p></description></item><item><title>Codex CLI From a DevOps Lens: Fast, Guardrailed, and Worth Piloting</title><link>https://falcao.org/posts/codex-cli-devops-opinionated-review/</link><pubDate>Tue, 26 May 2026 00:05:54 -0300</pubDate><guid>https://falcao.org/posts/codex-cli-devops-opinionated-review/</guid><description>&lt;p>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?&lt;/p>
&lt;p>My conclusion is clear: Codex CLI is already good enough to pilot seriously, but it is not my daily driver yet.&lt;/p></description></item><item><title>Btrfs vs ZFS on Linux in 2026: Practical Winner, Technical Winner</title><link>https://falcao.org/posts/btrfs-vs-zfs-linux-2026/</link><pubDate>Mon, 25 May 2026 19:56:00 -0300</pubDate><guid>https://falcao.org/posts/btrfs-vs-zfs-linux-2026/</guid><description>&lt;p>Btrfs is king on Linux. Not because it&amp;rsquo;s technically superior to ZFS in
every dimension — it isn&amp;rsquo;t — but because it ships in the kernel, installs
without friction, and integrates with every major distro&amp;rsquo;s tooling out of
the box. In 2026, if you format a fresh Fedora, openSUSE, or Ubuntu
Desktop installation, you&amp;rsquo;re running Btrfs by default. ZFS requires you
to want it badly enough to fight the packaging.&lt;/p></description></item><item><title>Karpathy at Anthropic, the Pope at the Vatican, and the Internet Losing Its Mind</title><link>https://falcao.org/posts/karpathy-anthropic-pope-leo-what-is-real/</link><pubDate>Mon, 25 May 2026 18:05:00 -0300</pubDate><guid>https://falcao.org/posts/karpathy-anthropic-pope-leo-what-is-real/</guid><description>&lt;p>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.&lt;/p>
&lt;p>Let me untangle this.&lt;/p>
&lt;h2 id="what-actually-happened-the-karpathy-hire">What actually happened: the Karpathy hire&lt;/h2>
&lt;p>On May 19, 2026, Andrej Karpathy posted on X: &amp;ldquo;I&amp;rsquo;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&amp;amp;D.&amp;rdquo;&lt;/p></description></item><item><title>PostgreSQL Stopped Being 'Just SQL' a Long Time Ago</title><link>https://falcao.org/posts/postgresql-multi-model-data-platform/</link><pubDate>Mon, 25 May 2026 17:45:00 -0300</pubDate><guid>https://falcao.org/posts/postgresql-multi-model-data-platform/</guid><description>&lt;p>Every few years someone publishes a blog post titled something like
&amp;ldquo;PostgreSQL: The Everything Database&amp;rdquo; and the comments fill with people
saying &amp;ldquo;well, obviously.&amp;rdquo; The thing is, it wasn&amp;rsquo;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&amp;rsquo;t used MongoDB yet.&lt;/p></description></item><item><title>The Kubernetes Operator's Batman Utility Belt: Day-2 Tools That Actually Earn Their Keep</title><link>https://falcao.org/posts/batman-belt-kubernetes-tools/</link><pubDate>Mon, 25 May 2026 14:35:00 -0300</pubDate><guid>https://falcao.org/posts/batman-belt-kubernetes-tools/</guid><description>&lt;p>&lt;code>kubectl&lt;/code> 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 &lt;code>kubectl&lt;/code> 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.&lt;/p>
&lt;p>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&amp;rsquo;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&amp;rsquo;re still maintained, still solve real problems, and still faster
than the &lt;code>kubectl&lt;/code> incantation you&amp;rsquo;d otherwise be typing.&lt;/p></description></item><item><title>SLA, SLO, SLI, and Error Budgets: A DevOps Reality Check</title><link>https://falcao.org/posts/sla-slo-sli-error-budget-devops-practical-guide/</link><pubDate>Sun, 24 May 2026 22:50:00 -0300</pubDate><guid>https://falcao.org/posts/sla-slo-sli-error-budget-devops-practical-guide/</guid><description>&lt;p>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.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>Anthropic's Third-Party Claude Crackdown: How It Hit OpenCode, Zed, and the Wider Tooling Ecosystem</title><link>https://falcao.org/posts/anthropic-claude-access-crackdown-ecosystem-fallout/</link><pubDate>Sun, 24 May 2026 22:00:00 -0300</pubDate><guid>https://falcao.org/posts/anthropic-claude-access-crackdown-ecosystem-fallout/</guid><description>&lt;p>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:
&lt;em>&amp;ldquo;This credential is only authorized for use with Claude Code and
cannot be used for other API requests.&amp;rdquo;&lt;/em>&lt;/p></description></item><item><title>tmux vs GNU Screen — why I moved on after twenty years</title><link>https://falcao.org/posts/tmux-vs-gnu-screen/</link><pubDate>Sun, 24 May 2026 22:00:00 -0300</pubDate><guid>https://falcao.org/posts/tmux-vs-gnu-screen/</guid><description>&lt;p>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.&lt;/p>
&lt;p>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.&lt;/p></description></item><item><title>GPT-5.3-Codex: A Late Review (And Why I'm Paying Attention Now)</title><link>https://falcao.org/posts/openai-codex-5-3-late-review/</link><pubDate>Sun, 24 May 2026 21:00:00 -0300</pubDate><guid>https://falcao.org/posts/openai-codex-5-3-late-review/</guid><description>&lt;p>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.&lt;/p></description></item><item><title>AI Bug Reports: The Real Vulnerability Is That We Weren't Looking Hard Enough</title><link>https://falcao.org/posts/ai-bug-discovery-revolution/</link><pubDate>Sat, 23 May 2026 10:00:00 -0300</pubDate><guid>https://falcao.org/posts/ai-bug-discovery-revolution/</guid><description>&lt;p>On May 18, 2026, Linus Torvalds called the Linux kernel security mailing list &lt;strong>&amp;ldquo;almost entirely unmanageable.&amp;rdquo;&lt;/strong> The reason: a flood of AI-generated bug reports. The reaction was predictable — ban AI, blame researchers, declare the tools aren&amp;rsquo;t ready.&lt;/p>
&lt;p>I &lt;a href="https://falcao.org/posts/ai-bug-reports-open-source/">wrote about the maintenance crisis last week&lt;/a> and I think that framing misses the deeper story. The problem is not that AI is generating too many reports. &lt;strong>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.&lt;/strong>&lt;/p></description></item><item><title>Replacing Snyk with Open Source: SAST, DAST and SCA in 2026</title><link>https://falcao.org/posts/open-source-sast-dast-sca-2026/</link><pubDate>Fri, 22 May 2026 10:00:00 -0300</pubDate><guid>https://falcao.org/posts/open-source-sast-dast-sca-2026/</guid><description>&lt;p>I don&amp;rsquo;t pay for Snyk. Not because it&amp;rsquo;s bad — it&amp;rsquo;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&amp;rsquo;t been worth roughly &lt;strong>$600 per developer per year&lt;/strong> to close.
On a team of fifteen engineers, that&amp;rsquo;s the price of a small EC2
fleet you actually need.&lt;/p>
&lt;p>This post is about the open-source security tooling I actually wire
into pipelines: &lt;strong>Trivy&lt;/strong> for containers, dependencies and IaC,
&lt;strong>Semgrep&lt;/strong> for application code, &lt;strong>Nuclei&lt;/strong> and &lt;strong>OWASP ZAP&lt;/strong> for
the live app, and a few honourable mentions. It&amp;rsquo;s not an exhaustive
catalogue. It&amp;rsquo;s the stack I keep coming back to.&lt;/p></description></item><item><title>Ansible, Puppet, Chef and SaltStack: Why Ansible Is Still My Default in 2026</title><link>https://falcao.org/posts/ansible-puppet-chef-saltstack-2026/</link><pubDate>Fri, 22 May 2026 09:00:00 -0300</pubDate><guid>https://falcao.org/posts/ansible-puppet-chef-saltstack-2026/</guid><description>&lt;p>There are four names that come up when you ask how to manage
configuration at scale. I&amp;rsquo;ve used all four, in production, over the
last fifteen years. The answer to &amp;ldquo;which one&amp;rdquo; is not the one that
wins benchmarks — it&amp;rsquo;s the one that matches how your team thinks
about change.&lt;/p>
&lt;p>The shortlist hasn&amp;rsquo;t changed since the early 2010s: &lt;strong>Ansible&lt;/strong>,
&lt;strong>Puppet&lt;/strong>, &lt;strong>Chef&lt;/strong>, &lt;strong>SaltStack&lt;/strong>. The ownership has changed. The
licences have changed. The community gravity has very much changed.
Ansible sits at &lt;strong>31.94%&lt;/strong> 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 &lt;strong>12.41%&lt;/strong>, Chef around
&lt;strong>6.70%&lt;/strong>, and Salt has fallen out of the top-tier mindshare entirely
even though the codebase is still actively developed under Broadcom.&lt;/p></description></item><item><title>Terraform, OpenTofu and Pulumi: Why I Still Run Terraform in 2026</title><link>https://falcao.org/posts/terraform-opentofu-pulumi-2026/</link><pubDate>Thu, 21 May 2026 23:00:00 -0300</pubDate><guid>https://falcao.org/posts/terraform-opentofu-pulumi-2026/</guid><description>&lt;p>Infrastructure as Code stopped being a single-answer question a couple
of years ago. Terraform went &lt;strong>BSL&lt;/strong> in August 2023, &lt;strong>OpenTofu&lt;/strong> forked
under MPL, &lt;strong>Pulumi&lt;/strong> kept arguing that infrastructure should be real
code in real languages, and IBM closed the &lt;strong>$6.4B HashiCorp
acquisition&lt;/strong> in February 2025. Three legitimate tools, three different
bets on who owns the abstraction.&lt;/p>
&lt;p>I still run &lt;strong>Terraform&lt;/strong>. For everything.&lt;/p>
&lt;p>This post is the honest version of why. I&amp;rsquo;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
&lt;strong>OpenTofu&lt;/strong> or &lt;strong>Pulumi&lt;/strong> in front of production traffic. Most of what
follows about those two is research, not muscle memory — and I&amp;rsquo;ll flag
that as I go.&lt;/p></description></item><item><title>AWS Lambda Still Matters in 2026: Glue, Burst, and Honest Trade-offs</title><link>https://falcao.org/posts/aws-lambda-still-matters/</link><pubDate>Thu, 21 May 2026 18:00:00 -0300</pubDate><guid>https://falcao.org/posts/aws-lambda-still-matters/</guid><description>&lt;p>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. &lt;strong>AWS Lambda&lt;/strong> 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.&lt;/p></description></item><item><title>The Kubernetes Ingress Landscape in 2026: Nginx Isn't the Center Anymore</title><link>https://falcao.org/posts/kubernetes-ingress-landscape-2026/</link><pubDate>Thu, 21 May 2026 17:50:00 -0300</pubDate><guid>https://falcao.org/posts/kubernetes-ingress-landscape-2026/</guid><description>&lt;p>For about a decade, &amp;ldquo;Kubernetes ingress&amp;rdquo; effectively meant one thing:
&lt;strong>&lt;code>ingress-nginx&lt;/code>&lt;/strong>, the community-maintained controller that wrapped
the Nginx engine behind the Kubernetes &lt;code>Ingress&lt;/code> resource. It was
fine. It was the default everyone reached for. It was also,
quietly, the wrong long-term shape for the problem.&lt;/p>
&lt;p>That era ended in 2026. The community &lt;code>ingress-nginx&lt;/code> project
&lt;strong>reached end-of-life in March 2026&lt;/strong>. The &lt;strong>Kubernetes Gateway
API&lt;/strong>, which graduated to GA on the v1.2 line, is now the
forward-looking standard. &lt;strong>Envoy Gateway&lt;/strong> is the CNCF reference
implementation. &lt;strong>Cilium&lt;/strong> does L7 routing in eBPF without a
sidecar or an extra proxy. &lt;strong>RKE2&lt;/strong> flipped to &lt;strong>Traefik&lt;/strong> by
default in v1.36 and removes &lt;code>ingress-nginx&lt;/code> entirely in v1.37.&lt;/p></description></item><item><title>Notion vs Obsidian: Local-First Sounds Great Until You Have to Sync It</title><link>https://falcao.org/posts/notion-vs-obsidian/</link><pubDate>Thu, 21 May 2026 07:00:00 -0300</pubDate><guid>https://falcao.org/posts/notion-vs-obsidian/</guid><description>&lt;p>I configure infrastructure for a living. Containers, reverse proxies,
NFS mounts, certificate renewals, sync layers between machines —
that&amp;rsquo;s most days. The last thing I want when I open my personal
note-taking app is &lt;strong>another sync layer to babysit.&lt;/strong> That, more than
anything else, is why I picked Notion over Obsidian.&lt;/p>
&lt;p>This is the honest read on &lt;strong>Notion vs Obsidian&lt;/strong> for one person, one
phone, one Linux desktop, and the occasional browser tab on someone
else&amp;rsquo;s machine. The headline: &lt;strong>Obsidian is the purer architecture
and the wrong fit for me. Notion is the lazy architecture that does
the right thing without asking.&lt;/strong> For a personal knowledge base, lazy
wins.&lt;/p></description></item><item><title>Where to Hide Kubernetes Secrets: AWS, Azure, GCP, and On-Prem Compared</title><link>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</link><pubDate>Wed, 20 May 2026 22:25:00 -0300</pubDate><guid>https://falcao.org/posts/kubernetes-secrets-aws-azure-gcp-onprem/</guid><description>&lt;p>The Kubernetes &lt;code>Secret&lt;/code> object is a YAML manifest with a base64-encoded
value in it. That&amp;rsquo;s the entire encryption story. Anyone with &lt;code>get&lt;/code>
permission on the namespace can read every credential the workload
holds. &lt;strong>Base64 is not encryption.&lt;/strong> It is barely obfuscation.&lt;/p>
&lt;p>Teams discover this the wrong way — usually during a security
review, occasionally during an incident — and the next question is
always the same: &lt;em>so where do the real secrets live?&lt;/em>&lt;/p></description></item><item><title>Age Verification Laws Are Coming for Your OS. Linux Doesn't Care.</title><link>https://falcao.org/posts/age-verification-linux-immunity/</link><pubDate>Wed, 20 May 2026 21:40:00 -0300</pubDate><guid>https://falcao.org/posts/age-verification-linux-immunity/</guid><description>&lt;p>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 &lt;strong>operating system&lt;/strong>, and that is where the story gets
interesting for anyone who cares about how Linux is built.&lt;/p>
&lt;p>Nine US states put age-verification laws in force during 2025 alone:
&lt;strong>South Carolina&lt;/strong> (Jan 1), &lt;strong>Florida&lt;/strong> (Jan 1), &lt;strong>Tennessee&lt;/strong>
(Jan 13), &lt;strong>Georgia&lt;/strong> (Jul 1), &lt;strong>Wyoming&lt;/strong> (Jul 1), &lt;strong>North Dakota&lt;/strong>
(Aug 1), &lt;strong>Arizona&lt;/strong> (Sep 26), &lt;strong>Ohio&lt;/strong> (Sep 30), and &lt;strong>Missouri&lt;/strong>
(Nov 30). Roughly half the country now mandates some form of age
gate for adult content, social media, or both.&lt;/p></description></item><item><title>Rancher vs Lens: A Platform and a Dashboard, Not the Same Thing</title><link>https://falcao.org/posts/rancher-platform-vs-lens/</link><pubDate>Wed, 20 May 2026 21:15:00 -0300</pubDate><guid>https://falcao.org/posts/rancher-platform-vs-lens/</guid><description>&lt;p>You&amp;rsquo;ll see this comparison on r/kubernetes every couple of months,
phrased as if it&amp;rsquo;s a real choice: &lt;strong>Rancher or Lens?&lt;/strong> The framing is
wrong. They occupy different layers of the stack. Asking which one
&amp;ldquo;wins&amp;rdquo; is like asking whether VS Code beats Kubernetes.&lt;/p>
&lt;p>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&amp;rsquo;t, and which one earns a place
in a serious on-prem setup.&lt;/p></description></item><item><title>eBPF Is Eating Kubernetes' iptables Plumbing</title><link>https://falcao.org/posts/ebpf-eating-kubernetes-iptables/</link><pubDate>Wed, 20 May 2026 19:30:00 -0300</pubDate><guid>https://falcao.org/posts/ebpf-eating-kubernetes-iptables/</guid><description>&lt;p>For most of Kubernetes&amp;rsquo; life, the cluster data path has been a tower of
&lt;strong>iptables&lt;/strong> rules. Pod-to-service routing, NAT, network policy, even
the way &lt;code>kube-proxy&lt;/code> programs a Service IP — all of it expressed as
netfilter chains evaluated linearly on every packet. It worked. It
also aged badly.&lt;/p>
&lt;p>In 2026, the answer the ecosystem has converged on is &lt;strong>eBPF&lt;/strong>, and the
project doing most of the convergence is &lt;strong>Cilium&lt;/strong>. The shift is
no longer aspirational: kube-proxy itself shipped an &lt;strong>nftables mode&lt;/strong>
that is expected to go &lt;strong>GA in Kubernetes 1.33&lt;/strong>, the old &lt;strong>IPVS
backend is deprecated as of v1.35&lt;/strong>, 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.&lt;/p></description></item><item><title>Caddy, Nginx, Traefik: Picking a Reverse Proxy in 2026</title><link>https://falcao.org/posts/caddy-nginx-traefik-2026/</link><pubDate>Wed, 20 May 2026 17:35:00 -0300</pubDate><guid>https://falcao.org/posts/caddy-nginx-traefik-2026/</guid><description>&lt;p>There is a kind of infrastructure question that never really gets
settled, just re-litigated every couple of years as the surrounding
ecosystem moves. &lt;strong>&amp;ldquo;Which reverse proxy?&amp;rdquo;&lt;/strong> is one of those questions.&lt;/p>
&lt;p>The shortlist hasn&amp;rsquo;t changed much: &lt;strong>Caddy&lt;/strong>, &lt;strong>Nginx&lt;/strong>, &lt;strong>Traefik&lt;/strong>.
The context around them has changed a lot. The community &lt;code>ingress-nginx&lt;/code>
project reached end-of-life in &lt;strong>March 2026&lt;/strong>. &lt;strong>RKE2 v1.36&lt;/strong> flipped
to &lt;strong>Traefik&lt;/strong> as the default ingress. Caddy quietly shipped &lt;strong>2.11&lt;/strong>
with better health-checking and ECH rotation. Nginx is on &lt;strong>1.31
mainline / 1.30.1 stable&lt;/strong> and treats HTTP/3 as a first-class but
still-evolving feature.&lt;/p></description></item><item><title>Hermes Agent vs OpenClaw: Why I Run Hermes Every Day</title><link>https://falcao.org/posts/hermes-agent-vs-openclaw/</link><pubDate>Wed, 20 May 2026 14:30:00 -0300</pubDate><guid>https://falcao.org/posts/hermes-agent-vs-openclaw/</guid><description>&lt;p>There are two open-source autonomous agents in 2026 worth a serious
DevOps engineer&amp;rsquo;s time, and they have made &lt;strong>opposite architectural
bets&lt;/strong>. 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&amp;rsquo;t.&lt;/p>
&lt;p>The headline: &lt;strong>agent-first beats gateway-first when the work rewards
familiarity.&lt;/strong> Most infrastructure work does. The rest of this post is
the why.&lt;/p></description></item><item><title>AI Bug Reports Are Drowning Open Source — And the Fix Isn't 'Stop Using AI'</title><link>https://falcao.org/posts/ai-bug-reports-open-source/</link><pubDate>Wed, 20 May 2026 10:00:00 -0300</pubDate><guid>https://falcao.org/posts/ai-bug-reports-open-source/</guid><description>&lt;p>On May 18, 2026, Linus Torvalds said the Linux kernel security mailing
list had become &lt;strong>&amp;ldquo;almost entirely unmanageable&amp;rdquo;&lt;/strong> because of duplicate
AI-generated bug reports. Two months earlier, longtime stable
maintainer &lt;strong>Willy Tarreau&lt;/strong> had already shared the numbers: a list
that received two to three reports per week in 2024 was getting
&lt;strong>five to ten reports per day&lt;/strong> by March 2026. In January, &lt;strong>Daniel
Stenberg shut down the curl bug bounty&lt;/strong> 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.&lt;/p></description></item><item><title>KDE Plasma 6.7 Is Coming June 16th — And I Cannot Wait</title><link>https://falcao.org/posts/kde-plasma-6-7-whats-coming/</link><pubDate>Wed, 20 May 2026 09:30:00 -0300</pubDate><guid>https://falcao.org/posts/kde-plasma-6-7-whats-coming/</guid><description>&lt;p>KDE shipped the &lt;strong>Plasma 6.7 Beta&lt;/strong> on May 14, 2026. The final release
lands on &lt;strong>June 16&lt;/strong>. I&amp;rsquo;m still on Plasma 6.6.5 — the stable that
shipped in Fedora 44 — and I&amp;rsquo;m going to stay there until 6.7 hits
Fedora&amp;rsquo;s repos. But I have been reading every announcement, every
&amp;ldquo;This Week in Plasma&amp;rdquo; post, and every release-note dump KDE has been
putting out, and I want to say this clearly:&lt;/p></description></item><item><title>My Home Media Server: A Raspberry Pi 4 for Compute, a Synology NAS for Storage</title><link>https://falcao.org/posts/media-server-pi4-synology/</link><pubDate>Tue, 19 May 2026 14:30:00 -0300</pubDate><guid>https://falcao.org/posts/media-server-pi4-synology/</guid><description>&lt;p>My home media server is a &lt;strong>Raspberry Pi 4&lt;/strong> named &lt;strong>uther&lt;/strong>. It runs
Plex, the entire *arr stack, qBittorrent, a request manager, a reverse
proxy, &lt;strong>Vaultwarden&lt;/strong> 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 &lt;strong>Synology NAS&lt;/strong> sitting on the same shelf doing nothing but
being a quiet, reliable hard drive over NFS.&lt;/p></description></item><item><title>NVIDIA on Fedora KDE Wayland in 2026: Field Report from an RTX 5070</title><link>https://falcao.org/posts/nvidia-fedora-kde-wayland/</link><pubDate>Tue, 19 May 2026 14:00:00 -0300</pubDate><guid>https://falcao.org/posts/nvidia-fedora-kde-wayland/</guid><description>&lt;p>NVIDIA on Linux has been a punchline for so long that &amp;ldquo;just buy AMD&amp;rdquo; was
the standard advice in every Linux subreddit thread. In 2026, on
&lt;strong>Fedora 44&lt;/strong> with &lt;strong>KDE Plasma 6.6 on Wayland&lt;/strong>, running an &lt;strong>RTX 5070
(Blackwell)&lt;/strong> with the &lt;strong>595 driver branch&lt;/strong>, I want to say something
different:&lt;/p>
&lt;p>&lt;strong>It&amp;rsquo;s fine. It&amp;rsquo;s actually fine.&lt;/strong>&lt;/p>
&lt;p>Not &amp;ldquo;fine if you don&amp;rsquo;t use Wayland.&amp;rdquo; Not &amp;ldquo;fine if you stick to X11.&amp;rdquo;
&lt;em>Fine, full stop.&lt;/em> This is the short, honest report of how I run it.&lt;/p></description></item><item><title>GitOps with Argo CD: The Reconciliation Loop That Survives 3 a.m.</title><link>https://falcao.org/posts/gitops-argocd/</link><pubDate>Tue, 19 May 2026 13:30:00 -0300</pubDate><guid>https://falcao.org/posts/gitops-argocd/</guid><description>&lt;p>Here&amp;rsquo;s the test I use for any deployment tooling:&lt;/p>
&lt;p>&lt;strong>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 &lt;em>thinks&lt;/em> is true, what&amp;rsquo;s &lt;em>actually&lt;/em>
true, and what changed in the last twelve hours. The faster you can
answer those three questions, the better the tooling.&lt;/strong>&lt;/p>
&lt;p>The right GitOps stack collapses all three questions into one
dashboard. The wrong one has you SSH-hopping between five servers
running &lt;code>kubectl rollout history&lt;/code> against unlabeled deployments. I&amp;rsquo;ve
done both. I&amp;rsquo;m writing this post about the former.&lt;/p></description></item><item><title>Helm 4 Made Me Stop Looking for an Alternative</title><link>https://falcao.org/posts/helm-4/</link><pubDate>Tue, 19 May 2026 13:00:00 -0300</pubDate><guid>https://falcao.org/posts/helm-4/</guid><description>&lt;p>Helm has been the punchline of Kubernetes packaging for about as long
as Kubernetes has been called Kubernetes. Helm 2 had &lt;strong>Tiller&lt;/strong>, an
in-cluster component running as cluster-admin that read every chart&amp;rsquo;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 &lt;strong>six years&lt;/strong>.&lt;/p></description></item><item><title>RKE2 Deserves Some Love: Why It's My On-Prem Kubernetes Pick</title><link>https://falcao.org/posts/rke2-on-prem-kubernetes/</link><pubDate>Tue, 19 May 2026 12:30:00 -0300</pubDate><guid>https://falcao.org/posts/rke2-on-prem-kubernetes/</guid><description>&lt;p>Most of the Kubernetes conversation in 2026 happens around managed
services — &lt;strong>EKS&lt;/strong>, &lt;strong>GKE&lt;/strong>, &lt;strong>AKS&lt;/strong> — and most of the rest happens
around &lt;strong>K3s&lt;/strong> for edge and homelab. Somewhere in the middle, on the
hardware that lives in a rack in a datacenter you can drive to,
there&amp;rsquo;s a Kubernetes story that nobody talks about loudly enough.&lt;/p>
&lt;p>That story is &lt;strong>RKE2&lt;/strong> — the Rancher Kubernetes Engine 2, SUSE&amp;rsquo;s
hardened, security-focused, single-binary distribution designed for
on-premises production. I&amp;rsquo;ve been running it for two years across
two different employers and one home lab, and it&amp;rsquo;s the rare piece of
infrastructure that gets more impressive the longer you live with it.&lt;/p></description></item><item><title>Why I Left Ubuntu Desktop — and Picked Debian Over Ubuntu Server</title><link>https://falcao.org/posts/leaving-ubuntu-desktop/</link><pubDate>Tue, 19 May 2026 12:00:00 -0300</pubDate><guid>https://falcao.org/posts/leaving-ubuntu-desktop/</guid><description>&lt;p>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 &amp;ldquo;what
Linux should a sane person install?&amp;rdquo;&lt;/p>
&lt;p>I don&amp;rsquo;t run it on my desktop anymore. I don&amp;rsquo;t run &lt;strong>Ubuntu Server&lt;/strong>
either — though that&amp;rsquo;s a personal-taste call and not a knock on the
product, which is still a perfectly good distribution that I&amp;rsquo;d
happily recommend to most people. &lt;strong>Ubuntu has split in half&lt;/strong>: the
server side is still strong, the desktop side has gone somewhere I&amp;rsquo;m
not willing to follow, and the two halves deserve very different
treatment. Especially because we just got &lt;strong>Ubuntu 26.04 LTS
&amp;ldquo;Resolute Raccoon&amp;rdquo;&lt;/strong> on April 23, and the headlines are mostly
cheerful about features that don&amp;rsquo;t fix the things that actually
drove me away.&lt;/p></description></item><item><title>NetBird: The Self-Hosted Mesh VPN I Wanted Tailscale to Be</title><link>https://falcao.org/posts/netbird-mesh-vpn/</link><pubDate>Tue, 19 May 2026 11:30:00 -0300</pubDate><guid>https://falcao.org/posts/netbird-mesh-vpn/</guid><description>&lt;p>I have been carrying a quiet grudge about &lt;strong>Tailscale&lt;/strong> for two years.
The product is excellent. The clients are polished. The &amp;ldquo;log in with
Google and you have a mesh in 60 seconds&amp;rdquo; 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 &lt;strong>closed source and hosted exclusively by
Tailscale&lt;/strong>. You can run &lt;strong>Headscale&lt;/strong> to reimplement it open-source,
but you&amp;rsquo;re still bringing along Tailscale&amp;rsquo;s proprietary clients on
most platforms.&lt;/p></description></item><item><title>Claude Code, opencode, Cursor: My Daily Driver and My Plan B</title><link>https://falcao.org/posts/claude-code-opencode-cursor/</link><pubDate>Tue, 19 May 2026 11:00:00 -0300</pubDate><guid>https://falcao.org/posts/claude-code-opencode-cursor/</guid><description>&lt;p>I&amp;rsquo;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.&lt;/p>
&lt;p>This is my honest read on &lt;strong>Cursor&lt;/strong>, &lt;strong>Claude Code&lt;/strong>, and
&lt;strong>opencode&lt;/strong>. The headline:
&lt;strong>Claude Code is my daily driver. opencode is my Plan B. Cursor is
not what I reach for.&lt;/strong> Here&amp;rsquo;s why.&lt;/p></description></item><item><title>Distrobox, Toolbx, and the 'What Would You Give and What Would You Keep' Question</title><link>https://falcao.org/posts/distrobox-toolbx-podman-docker/</link><pubDate>Tue, 19 May 2026 10:30:00 -0300</pubDate><guid>https://falcao.org/posts/distrobox-toolbx-podman-docker/</guid><description>&lt;blockquote>
&lt;p>&lt;em>&amp;ldquo;What would you give and what would you keep?&amp;rdquo;&lt;/em>
— &lt;strong>Mase&lt;/strong>, &lt;em>From Scratch&lt;/em> (Double Up, 1999)&lt;/p>
&lt;/blockquote>
&lt;p>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 &lt;em>be&lt;/em> 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&amp;rsquo;re
making a series of small, ugly trade-offs. &lt;strong>What would you give up
from your bare-metal workflow, and what would you keep?&lt;/strong>&lt;/p></description></item><item><title>Steam Machine 2026: Round Two, and This Time It Runs KDE</title><link>https://falcao.org/posts/steam-machine-2026/</link><pubDate>Tue, 19 May 2026 09:00:00 -0300</pubDate><guid>https://falcao.org/posts/steam-machine-2026/</guid><description>&lt;p>The first &lt;strong>Steam Machine&lt;/strong> 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&amp;rsquo;t try to spin it. They went away, built the
&lt;strong>Steam Deck&lt;/strong>, built &lt;strong>Proton&lt;/strong> into something that actually works,
and waited.&lt;/p></description></item><item><title>Zed 1.0: When 'Fast Editor' Finally Stops Being a Marketing Line</title><link>https://falcao.org/posts/zed-1-0/</link><pubDate>Mon, 18 May 2026 21:00:00 -0300</pubDate><guid>https://falcao.org/posts/zed-1-0/</guid><description>&lt;p>I have a complicated relationship with code editors. I used &lt;code>vim&lt;/code> for
fifteen years out of stubbornness, switched to &lt;strong>VS Code&lt;/strong> 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.&lt;/p>
&lt;p>&lt;strong>Zed 1.0 shipped at the end of April 2026.&lt;/strong> I&amp;rsquo;ve been running it as
my daily driver for the two weeks since, and I&amp;rsquo;m writing this post in
it. Here&amp;rsquo;s where I&amp;rsquo;ve actually landed, including the things I think the
typical Zed review under-sells.&lt;/p></description></item><item><title>Hetzner Isn't the Cheap Default Anymore — And the AI Boom Is Why</title><link>https://falcao.org/posts/hetzner-not-cheap-anymore/</link><pubDate>Mon, 18 May 2026 20:30:00 -0300</pubDate><guid>https://falcao.org/posts/hetzner-not-cheap-anymore/</guid><description>&lt;p>I&amp;rsquo;ve been running personal infrastructure on &lt;strong>Hetzner&lt;/strong> for the better
part of a decade. Cloud VMs for side projects. A couple of dedicated
boxes for the things I didn&amp;rsquo;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.&lt;/p>
&lt;p>&lt;strong>On April 1, 2026, that deal got noticeably worse.&lt;/strong>&lt;/p></description></item><item><title>Musk vs. OpenAI Ends on a Technicality — and the Questions Everyone Wanted Answered Are Still Open</title><link>https://falcao.org/posts/musk-openai-verdict/</link><pubDate>Mon, 18 May 2026 19:30:00 -0300</pubDate><guid>https://falcao.org/posts/musk-openai-verdict/</guid><description>&lt;p>A nine-person jury in the Northern District of California took &lt;strong>less
than two hours&lt;/strong> today to unanimously dismiss every claim in Elon
Musk&amp;rsquo;s lawsuit against Sam Altman, Greg Brockman, OpenAI, and
Microsoft. Musk had sought up to &lt;strong>$134 billion in disgorgement&lt;/strong>, the
removal of Altman and Brockman from OpenAI&amp;rsquo;s leadership, and the
unwinding of OpenAI&amp;rsquo;s October 2025 conversion into an $852-billion
public benefit corporation.&lt;/p>
&lt;p>He got none of it. The technicality matters more than the headline.&lt;/p></description></item><item><title>Ollama in 2026: The Boring Choice for Open-Source LLMs (And Why That's the Whole Point)</title><link>https://falcao.org/posts/ollama-the-boring-standard/</link><pubDate>Mon, 18 May 2026 17:30:00 -0300</pubDate><guid>https://falcao.org/posts/ollama-the-boring-standard/</guid><description>&lt;p>There&amp;rsquo;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,
&lt;strong>Ollama is doing it for open-source language models.&lt;/strong>&lt;/p>
&lt;p>You install one binary. You type &lt;code>ollama pull &amp;lt;model&amp;gt;&lt;/code>. You type
&lt;code>ollama run &amp;lt;model&amp;gt;&lt;/code>. Your application talks to &lt;code>localhost:11434&lt;/code> over an
OpenAI-compatible HTTP API. That&amp;rsquo;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.&lt;/p></description></item><item><title>Fedora 44: A KDE-Heavy, DevOps-Tinted First Look</title><link>https://falcao.org/posts/fedora-44-first-look/</link><pubDate>Mon, 18 May 2026 15:30:00 -0300</pubDate><guid>https://falcao.org/posts/fedora-44-first-look/</guid><description>&lt;p>Fedora Linux 44 shipped on April 28, 2026, two weeks behind its original
date after a late-cycle batch of blockers. I&amp;rsquo;ve been running it on my KDE
daily-driver for a couple of weeks now. It&amp;rsquo;s the kind of release that
doesn&amp;rsquo;t scream — no single tentpole feature — but if you spend your day
on Linux, the cumulative effect is real. Here&amp;rsquo;s what stood out to me,
with a bias toward what I actually noticed.&lt;/p></description></item></channel></rss>