<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>/var/log/janio</title><link>https://devops.sarmento.org/en/</link><description>Recent content on /var/log/janio</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 26 May 2026 07:00:00 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/en/index.xml" rel="self" type="application/rss+xml"/><item><title>SOPS + age: Declarative, Secure Secrets Management Without GPG Headache</title><link>https://devops.sarmento.org/en/posts/sops-and-age-secrets-management-in-practice/</link><pubDate>Tue, 26 May 2026 07:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/sops-and-age-secrets-management-in-practice/</guid><description>&lt;p&gt;As I previously discussed in my post on &lt;a href="https://devops.sarmento.org/posts/secret-management-macos-linux/"&gt;secret management in macOS and Linux&lt;/a&gt;, the real challenge of managing keys and tokens isn&amp;rsquo;t the encryption itself, but reducing accidental leakage without turning the sysadmin&amp;rsquo;s daily routine into a bureaucratic nightmare. Over the last few years, however, a duo of tools has gained significant traction and completely changed this dynamic: &lt;strong&gt;Mozilla SOPS&lt;/strong&gt; and &lt;strong&gt;age&lt;/strong&gt;. Together, they enable a declarative, GitOps-friendly, and extremely secure approach with virtually zero friction. This post is a detailed look at how these tools work and how to integrate them practically into your daily workflow.&lt;/p&gt;</description></item><item><title>Secret Management on macOS and Linux: a Practical-Theoretical Approach</title><link>https://devops.sarmento.org/en/posts/secret-management-macos-linux/</link><pubDate>Sun, 17 May 2026 11:54:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/secret-management-macos-linux/</guid><description>&lt;p&gt;At some point in the life of almost every sysadmin, there comes a slightly uncomfortable realization: too many secrets are scattered across the environment.&lt;/p&gt;
&lt;p&gt;A password inside a &lt;code&gt;.env&lt;/code&gt; file here, a token buried in shell history there, a forgotten webhook inside a &lt;code&gt;docker-compose.yml&lt;/code&gt;, an API key hardcoded into a “temporary” script that somehow survived for two years in production. None of those things seem catastrophic individually. The problem is that infrastructure rarely collapses because of one gigantic mistake; most of the time, it collapses under the accumulated weight of dozens of tiny operational shortcuts.&lt;/p&gt;</description></item><item><title>Hugin on steroids: tags, links and editing in one TUI</title><link>https://devops.sarmento.org/en/posts/hugin-on-steroids-tags-links-and-editing-in-one-tui/</link><pubDate>Sat, 18 Apr 2026 13:13:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hugin-on-steroids-tags-links-and-editing-in-one-tui/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/"&gt;post about Hugin&lt;/a&gt; I introduced the tool I use to generate tags and summaries for my Hugo blogs. Two weeks later, in the &lt;a href="https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/"&gt;post about Munin&lt;/a&gt;, I showed its sibling: a second program that discovers and inserts internal links between posts using embeddings and an LLM.&lt;/p&gt;
&lt;p&gt;Both worked well. Separately, they worked well.&lt;/p&gt;
&lt;h2 id="the-problem-with-having-two-programs"&gt;The problem with having two programs&lt;/h2&gt;
&lt;p&gt;In theory, splitting responsibilities between tools is good practice. In practice, the workflow for processing a new post looked like this: open Hugin, navigate to the post, generate tags, generate summary, close Hugin. Open Munin, wait for the embedding model to load, navigate to the same post, check existing links, generate link suggestions, apply. If you needed to fix a typo in the title that only showed up after reviewing the post in Hugin, close everything and open Pages CMS or vim.&lt;/p&gt;</description></item><item><title>Hugin: tags and summaries for Hugo with AI</title><link>https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/</link><pubDate>Fri, 17 Apr 2026 11:06:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/</guid><description>&lt;p&gt;Anyone who maintains a &lt;a href="https://devops.sarmento.org/posts/why-leave-wordpress-and-what-to-build-instead-with-hugo-pages-cms-and-cloudflare/"&gt;static blog with Hugo&lt;/a&gt; knows there are two tasks nobody enjoys: classifying posts with tags and writing meta descriptions. These are the things you skip when publishing because the post is already done, the deploy is set up, and choosing between &amp;ldquo;selfhosted&amp;rdquo; and &amp;ldquo;self-hosted&amp;rdquo; isn&amp;rsquo;t exactly the best use of your time. The result is predictable: posts without tags, empty descriptions or ones copied from the first paragraph, and a taxonomy that hurts more than it helps.&lt;/p&gt;</description></item><item><title>Cleaning up old Snap revisions to free up space on Ubuntu</title><link>https://devops.sarmento.org/en/posts/cleaning-up-old-snap-revisions-to-free-up-space-on-ubuntu/</link><pubDate>Fri, 17 Apr 2026 11:05:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/cleaning-up-old-snap-revisions-to-free-up-space-on-ubuntu/</guid><description>&lt;p&gt;If you&amp;rsquo;ve been using Ubuntu for a while, you&amp;rsquo;ve probably noticed that the &lt;code&gt;/var/lib/snapd&lt;/code&gt; directory grows silently and steadily. The reason isn&amp;rsquo;t the Snap packages you&amp;rsquo;ve installed — it&amp;rsquo;s the old copies the system automatically keeps every time one of those packages is updated. On a system with dozens of snaps, it&amp;rsquo;s common to find 5, 8, or even more gigabytes occupied by revisions you&amp;rsquo;ll never use. This issue is especially troublesome on smaller partitions, SSDs with limited space, or VMs with tight disk capacity. The good news is that identifying and removing this excess takes just a few minutes, as long as you know where to look and what not to delete.&lt;/p&gt;</description></item><item><title>Monitoring Files and Folders on Linux with systemd path units (and inotifywait for those without root)</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</link><pubDate>Fri, 17 Apr 2026 11:05:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;previous post&lt;/a&gt;, macOS&amp;rsquo;s launchd watched files and directories with &lt;code&gt;WatchPaths&lt;/code&gt; to fire scripts automatically when something changed. The model is reactive — instead of running a backup every hour or a conversion every five minutes, the system watches the path on disk and only runs the job when it detects an actual modification. No polling, no waste, no vulnerability window between the change and the action.&lt;/p&gt;
&lt;p&gt;Linux has the same capability, but implemented differently and with more options. systemd offers path units — &lt;code&gt;.path&lt;/code&gt; files that monitor filesystem paths and automatically activate an associated service when the condition is met. It is the direct equivalent of launchd&amp;rsquo;s &lt;code&gt;WatchPaths&lt;/code&gt;, with the same declarative philosophy: you describe what to watch in a configuration file, the system handles the rest. For anyone working on servers or desktops with systemd, which at this point means practically every mainstream distribution, path units are the right tool.&lt;/p&gt;</description></item><item><title>Munin: internal links for Hugo with AI</title><link>https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/</link><pubDate>Fri, 17 Apr 2026 10:49:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/"&gt;post about Hugin&lt;/a&gt; I explained how I solved the tag and summary problem on my Hugo blog. But there was another problem, less obvious and more annoying: internal links. Those links that connect one post to another, help readers navigate related content, and that Google loves to see on a well-structured site.&lt;/p&gt;
&lt;p&gt;The truth is nobody links anything. You write a post about systemd timers, another about cron, another about launchd — and none of the three mentions the others. They&amp;rsquo;re content islands that could be connected. The obvious solution is to reread every post, remember which others exist, and manually insert links. With 30 posts, it&amp;rsquo;s doable. With 400, it&amp;rsquo;s insane.&lt;/p&gt;</description></item><item><title>From WordPress to Hugo: Theming Is Not What You Think</title><link>https://devops.sarmento.org/en/posts/from-wordpress-to-hugo-theming-is-not-what-you-think/</link><pubDate>Sat, 04 Apr 2026 15:20:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/from-wordpress-to-hugo-theming-is-not-what-you-think/</guid><description>&lt;p&gt;Anyone who has worked with WordPress long enough develops a strong intuition for what a theme is and what it does. That intuition serves you well within the ecosystem: it guides decisions about file structure, where to put logic, and how to extend functionality. The trouble starts when you move to Hugo and try to apply the same mental model. The vocabulary overlaps — templates, layouts, partials — but what those words mean in practice is radically different.&lt;/p&gt;</description></item><item><title>Automatically deleting emails in Apple Mail with AppleScript + launchd</title><link>https://devops.sarmento.org/en/posts/automatically-deleting-emails-in-apple-mail-with-applescript-and-launchd/</link><pubDate>Mon, 30 Mar 2026 20:24:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/automatically-deleting-emails-in-apple-mail-with-applescript-and-launchd/</guid><description>&lt;p&gt;My inbox is always full of notifications with subjects like &lt;code&gt;[Ticket ID: 12345] Ticket Update&lt;/code&gt;. They&amp;rsquo;re useful for a few hours and then become noise. These aren&amp;rsquo;t emails that need to be archived, replied to, or revisited, so they just end up taking up mental space.&lt;/p&gt;
&lt;p&gt;Deleting them manually is the kind of small task that never becomes a priority, but silently costs you in distraction. So I decided to treat it like any other recurring problem: automate it locally, without relying on external services, no &lt;em&gt;webhooks&lt;/em&gt;, and no integrations. The idea is to periodically run a script that moves to the trash any &lt;a href="https://devops.sarmento.org/experiencias-com-mensagens-subliminares/"&gt;messages&lt;/a&gt; whose subject matches a specific pattern and that are older than 48 hours.&lt;/p&gt;</description></item><item><title>Tailscale in the Homelab — Remote Access Without Opening Ports</title><link>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</link><pubDate>Sun, 29 Mar 2026 21:58:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</guid><description>&lt;p&gt;Anyone who runs a homelab — or even a single Raspberry Pi hosting services — eventually hits the same obstacle: how do you access those devices from outside the local network? The classic answer involves opening ports on the router, setting up port forwarding, dealing with dynamic IPs via DDNS, and hoping no bot discovers that SSH port exposed to the internet. It works, but the attack surface grows with every open port, and the maintenance becomes a silent headache that only shows up when something breaks.&lt;/p&gt;</description></item><item><title>Exposing homelab services to the internet with Cloudflare Tunnel</title><link>https://devops.sarmento.org/en/posts/exposing-homelab-services-to-the-internet-with-cloudflare-tunnel/</link><pubDate>Fri, 27 Mar 2026 18:24:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/exposing-homelab-services-to-the-internet-with-cloudflare-tunnel/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/ssh-behind-nat-ssh-jcom-solves-it/"&gt;previous post&lt;/a&gt;, I showed how SSH-J.com solves a specific problem: accessing a machine behind NAT via SSH, without opening ports on the router and without relying on a public IP. The reverse tunnel works well for interactive sessions and file transfers, and SSH-J.com as a jump host makes everything trivial to configure. For SSH, it remains the simplest solution I know.&lt;/p&gt;
&lt;p&gt;But SSH is just one piece of the puzzle. Anyone who maintains a homelab — even if it&amp;rsquo;s just a mini PC under the desk or a Raspberry Pi in the corner of the room — inevitably ends up running web services: an RSS reader, a monitoring dashboard, a Gitea, a Jellyfin, an &lt;a href="https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/"&gt;Immich&lt;/a&gt;. These services listen on local HTTP ports and work perfectly as long as you&amp;rsquo;re on the same network. The problem appears when you want to access them from outside — from the office, from your phone on the bus, from anywhere that isn&amp;rsquo;t your local network.&lt;/p&gt;</description></item><item><title>Automatically Converting Images to WEBP and AVIF</title><link>https://devops.sarmento.org/en/posts/automatically-converting-images-to-webp-and-avif/</link><pubDate>Thu, 26 Mar 2026 22:19:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/automatically-converting-images-to-webp-and-avif/</guid><description>&lt;p&gt;The two previous posts built the monitoring infrastructure — &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;&lt;code&gt;WatchPaths&lt;/code&gt; on macOS&lt;/a&gt;, &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/"&gt;systemd path units and &lt;code&gt;inotifywait&lt;/code&gt; on Linux&lt;/a&gt; — and promised the scripts would come later. The trigger is ready: launchd or systemd detects when something changes in a directory and fires a command. What is missing is the command itself.&lt;/p&gt;
&lt;p&gt;This post delivers the image conversion script that those triggers will fire. The goal is simple: PNGs and JPGs go into a folder, WEBP or AVIF come out. The originals are deleted or moved, depending on the configuration. The script detects which encoders are available on the machine and picks the best one among those installed, with a fallback chain that ensures it works even when the ideal tool is not present. If no compatible encoder is found, the script tells you what to install and from which package manager.&lt;/p&gt;</description></item><item><title>Monitoring Files and Folders with launchd: WatchPaths in Practice</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</link><pubDate>Thu, 26 Mar 2026 18:56:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/"&gt;previous post about launchd&lt;/a&gt;, scheduling worked by time: &lt;code&gt;StartCalendarInterval&lt;/code&gt; defined &amp;ldquo;every day at 7 AM&amp;rdquo; and the system took care of the rest, including recovering missed executions when the Mac was asleep. For periodic tasks like sending a daily briefing or running a maintenance script, that model works perfectly — it is the functional equivalent of cron, but integrated into the macOS lifecycle.&lt;/p&gt;
&lt;p&gt;But not every automation makes sense tied to a clock. Some tasks only need to happen when something changes. A backup that runs every hour is wasting 23 executions per day if the database was only modified once. An image conversion that runs every 5 minutes has nothing to convert most of the time, and when it finally does, up to 5 minutes have passed since the file appeared. The time-based model works, but it is polling disguised as scheduling — and polling is almost always the least elegant solution to any synchronization problem.&lt;/p&gt;</description></item><item><title>SSH Behind NAT? SSH-J.com Solves It.</title><link>https://devops.sarmento.org/en/posts/ssh-behind-nat-ssh-jcom-solves-it/</link><pubDate>Wed, 25 Mar 2026 22:26:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/ssh-behind-nat-ssh-jcom-solves-it/</guid><description>&lt;p&gt;You work remotely, have a server at home, a Raspberry Pi running services, or a machine at the office you need to reach every now and then. The scenario is common and the obvious solution is SSH — already installed, secure, and battle-tested for decades. The problem is that between your machine and the rest of the internet sits a router, a NAT, and possibly an ISP that does not give you a fixed public IP or blocks incoming ports. Suddenly, the most reliable protocol in system administration becomes unreachable from outside your local network.&lt;/p&gt;</description></item><item><title>Immich: Your Photos, Your Server, Your Rules</title><link>https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/</link><pubDate>Wed, 25 Mar 2026 07:18:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/</guid><description>&lt;p&gt;There comes a moment when everyone stops and thinks about where their photos are. It usually happens when Google sends that friendly email letting you know your free storage is full — and that for just a few dollars a month you can keep storing your memories on their servers. It is a gentle nudge toward a monthly subscription that, added up over years, costs more than a multi-terabyte external hard drive. But the monetary price is only the most obvious part of the equation. There is a more subtle cost to leaving all your photos, videos, and personal memories in the hands of a company that profits from data — and it is worth talking about that cost before discussing any tool.&lt;/p&gt;</description></item><item><title>The Dark Side of Free Website: Limits and Alternatives for Hugo + GitHub + Cloudflare Pages + Pages CMS</title><link>https://devops.sarmento.org/en/posts/o-lado-b-do-site-gratis-limites-e-alternativas-para-hugo-github-cloudflare-pages-pages-cms/</link><pubDate>Tue, 24 Mar 2026 10:45:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/o-lado-b-do-site-gratis-limites-e-alternativas-para-hugo-github-cloudflare-pages-pages-cms/</guid><description>&lt;p&gt;In a &lt;a href="https://devops.sarmento.org/en/posts/why-leave-wordpress-and-what-to-build-instead-with-hugo-pages-cms-and-cloudflare/"&gt;previous post&lt;/a&gt;, we put together a complete blog with Hugo, GitHub, Cloudflare Pages, and Pages CMS without spending a cent. The stack works, it is fast, and for most personal blogs it will keep working for a long time without asking anything in return. But &amp;ldquo;free&amp;rdquo; does not mean &amp;ldquo;without limits,&amp;rdquo; and understanding where the walls are before you hit them is the kind of thing that saves headaches down the road.&lt;/p&gt;</description></item><item><title>Scheduling Tasks on macOS with launchd: No cron, No Workarounds</title><link>https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/</link><pubDate>Mon, 23 Mar 2026 21:29:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/"&gt;previous post&lt;/a&gt; I showed how systemd timers replace cron on Debian and Ubuntu servers with concrete advantages: integrated logging, missed execution recovery, declarative dependencies, and resource control. The logic is compelling and the migration is straightforward — as long as you are on a system running systemd. But if your daily routine includes a Mac, it is a different story.&lt;/p&gt;
&lt;p&gt;macOS has its own scheduling system, predating systemd and built on a different philosophy. It is called &lt;a href="https://devops.sarmento.org/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;launchd&lt;/a&gt;, it has been around since Mac OS X Tiger in 2005, and it is responsible for practically everything that runs in the background on the system — from internal Apple services to that Spotify updater you never asked to install. Despite being the official and recommended way to schedule tasks on a Mac, launchd lives in a kind of blind spot: people coming from Linux tend to reach for cron out of reflex, and Mac users without a sysadmin background do not even know the option exists.&lt;/p&gt;</description></item><item><title>Systemd Timers: Time to Retire cron</title><link>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</link><pubDate>Mon, 23 Mar 2026 06:21:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</guid><description>&lt;p&gt;If you have been managing Debian or Ubuntu servers for any length of time, you probably have a comfort relationship with cron. One line in the crontab, five scheduling fields, and the path to a script — done. cron has worked this way since the 1970s, and that simplicity is exactly what kept it relevant for so long.&lt;/p&gt;
&lt;p&gt;The problem is that &amp;ldquo;it works&amp;rdquo; and &amp;ldquo;it works well in 2026&amp;rdquo; are different things. When a job fails silently at three in the morning, when you need to figure out which of twenty crontabs scattered across the system contains that one specific task, or when the server reboots and simply misses the execution that should have happened during downtime — those are the moments when cron shows it was designed for an era with different expectations around observability and resilience.&lt;/p&gt;</description></item><item><title>Comments on static sites with Isso — lightweight, self-hosted, and tracking-free</title><link>https://devops.sarmento.org/en/posts/comments-on-static-sites-with-isso-lightweight-self-hosted-and-tracking-free/</link><pubDate>Sat, 21 Mar 2026 00:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/comments-on-static-sites-with-isso-lightweight-self-hosted-and-tracking-free/</guid><description>&lt;p&gt;A static site has no backend. No database, no application server processing requests — and that&amp;rsquo;s exactly what makes it fast, cheap, and resilient. But that simplicity comes at a cost when you need anything that depends on persistent state, and comments are the most obvious case. In WordPress or Ghost, the commenting system is part of the application. In a site generated by Hugo, Jekyll, or Eleventy, that layer simply doesn&amp;rsquo;t exist.&lt;/p&gt;</description></item><item><title>Why leave WordPress — and what to build instead with Hugo, Pages CMS, and Cloudflare</title><link>https://devops.sarmento.org/en/posts/why-leave-wordpress-and-what-to-build-instead-with-hugo-pages-cms-and-cloudflare/</link><pubDate>Fri, 20 Mar 2026 00:10:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/why-leave-wordpress-and-what-to-build-instead-with-hugo-pages-cms-and-cloudflare/</guid><description>&lt;h2 id="why-leave-wordpress"&gt;Why leave WordPress&lt;/h2&gt;
&lt;h3 id="the-weight-of-running-a-dynamic-cms"&gt;The weight of running a dynamic CMS&lt;/h3&gt;
&lt;p&gt;WordPress is an extraordinary piece of software that powers nearly half the internet. That said, keeping a WordPress installation healthy is a job that never ends. Every visit to your site triggers a chain of events: the server receives the request, PHP wakes up, queries MySQL, assembles the page on the fly, and sends the HTML back to the browser. Multiply that by a hundred simultaneous visitors and you have a server sweating to deliver pages that, on most blogs, are exactly the same for everyone.&lt;/p&gt;</description></item><item><title>Hello, World!</title><link>https://devops.sarmento.org/en/posts/hello-world/</link><pubDate>Thu, 19 Mar 2026 01:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hello-world/</guid><description>&lt;p&gt;This is the English side of &lt;strong&gt;/var/log/janio&lt;/strong&gt; — a blog about Linux, macOS, self-hosting, homelab, and the small tools that make daily life in the terminal a little better.&lt;/p&gt;
&lt;p&gt;Most of the content lives on the Portuguese side for now. Posts will be translated or written directly in English as the blog grows. If you read Portuguese, there&amp;rsquo;s a lot more waiting for you on the other side of the language switcher.&lt;/p&gt;</description></item><item><title>About</title><link>https://devops.sarmento.org/en/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/about/</guid><description>&lt;p&gt;Janio Sarmento — sysadmin, 53, Brazilian working from home for the world. I manage Linux servers, LXC containers, email that doesn&amp;rsquo;t land in spam, and cats that won&amp;rsquo;t get off the keyboard.&lt;/p&gt;
&lt;p&gt;This blog documents the daily life of someone keeping infrastructure running, including the things that break (and how to fix them).&lt;/p&gt;</description></item></channel></rss>