<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Open-Source on /var/log/janio</title><link>https://devops.sarmento.org/tags/open-source/</link><description>Recent content in Open-Source on /var/log/janio</description><generator>Hugo</generator><language>pt-BR</language><lastBuildDate>Sat, 18 Apr 2026 13:11:00 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/tags/open-source/index.xml" rel="self" type="application/rss+xml"/><item><title>Hugin on steroids: tags, links e edição numa só TUI</title><link>https://devops.sarmento.org/posts/hugin-on-steroids-unificando-tags-links-e-edicao-numa-so-tui/</link><pubDate>Sat, 18 Apr 2026 13:13:00 +0000</pubDate><guid>https://devops.sarmento.org/posts/hugin-on-steroids-unificando-tags-links-e-edicao-numa-so-tui/</guid><description>&lt;p&gt;No &lt;a href="https://devops.sarmento.org/post/hugin-tags-e-resumos-para-hugo-com-ia/"&gt;post sobre o Hugin&lt;/a&gt; apresentei a ferramenta que uso para gerar tags e resumos nos meus blogs Hugo. Duas semanas depois, no &lt;a href="https://devops.sarmento.org/post/munin-links-internos-para-hugo-com-ia/"&gt;post sobre o Munin&lt;/a&gt;, mostrei o irmão dele: um segundo programa que descobre e insere links internos entre posts usando embeddings e LLM.&lt;/p&gt;
&lt;p&gt;Os dois funcionavam bem. Separados, funcionavam bem.&lt;/p&gt;
&lt;h2 id="o-problema-de-ter-dois-programas"&gt;O problema de ter dois programas&lt;/h2&gt;
&lt;p&gt;Na teoria, dividir responsabilidades entre ferramentas é uma boa prática. Na prática, o fluxo para processar um post novo era assim: abrir o Hugin, navegar até o post, gerar tags, gerar resumo, fechar o Hugin. Abrir o Munin, esperar o modelo de embeddings carregar, navegar até o mesmo post, verificar links existentes, gerar sugestões de links, aplicar. Se precisasse corrigir um typo no título que só apareceu depois de olhar o post no Hugin, fechar tudo e abrir o Pages CMS ou o vim.&lt;/p&gt;</description></item><item><title>Munin: links internos para Hugo com IA</title><link>https://devops.sarmento.org/posts/munin-links-internos-para-hugo-com-ia/</link><pubDate>Fri, 17 Apr 2026 10:49:00 +0000</pubDate><guid>https://devops.sarmento.org/posts/munin-links-internos-para-hugo-com-ia/</guid><description>&lt;p&gt;No &lt;a href="https://devops.sarmento.org/post/hugin-tags-e-resumos-para-hugo-com-ia/"&gt;post sobre o Hugin&lt;/a&gt; contei como resolvi o problema de tags e resumos no meu blog Hugo. Mas tinha outro problema, menos óbvio e mais chato: links internos. Aqueles links que conectam um post a outro, que ajudam o leitor a navegar pelo conteúdo relacionado, e que o Google adora ver num site bem estruturado.&lt;/p&gt;
&lt;p&gt;O problema é que ninguém linka nada. Você escreve um post sobre systemd timers, outro sobre cron, outro sobre launchd — e nenhum dos três menciona os outros. São ilhas de conteúdo que poderiam estar conectadas. A solução óbvia é reler cada post, lembrar quais outros existem, e ir inserindo links manualmente. Com 30 posts, é viável. Com 400, é insano.&lt;/p&gt;</description></item><item><title>Expondo serviços do homelab na internet com Cloudflare Tunnel</title><link>https://devops.sarmento.org/posts/expondo-servicos-do-homelab-na-internet-com-cloudflare-tunnel/</link><pubDate>Fri, 27 Mar 2026 18:24:00 +0000</pubDate><guid>https://devops.sarmento.org/posts/expondo-servicos-do-homelab-na-internet-com-cloudflare-tunnel/</guid><description>&lt;p&gt;No &lt;a href="https://devops.sarmento.org/posts/ssh-atras-de-nat-ssh-jcom-resolve/"&gt;post anterior&lt;/a&gt;, mostrei como o SSH-J.com resolve um problema específico: acessar via SSH uma máquina que está atrás de NAT, sem abrir portas no roteador e sem depender de IP público. O túnel reverso funciona bem para sessões interativas e transferência de arquivos, e o SSH-J.com como jump host torna tudo trivial de configurar. Para SSH, continua sendo a solução mais simples que conheço.&lt;/p&gt;
&lt;p&gt;Mas SSH é só uma peça do quebra-cabeça. Quem mantém um homelab — mesmo que seja só um mini PC embaixo da mesa ou um Raspberry Pi no canto da sala — inevitavelmente acaba rodando serviços web: um leitor de RSS, um dashboard de monitoramento, um Gitea, um Jellyfin, um &lt;a href="https://devops.sarmento.org/posts/immich-suas-fotos-seu-servidor-suas-regras/"&gt;Immich&lt;/a&gt;. Esses serviços escutam em portas HTTP locais e funcionam perfeitamente enquanto você está na mesma rede. O problema aparece quando você quer acessá-los de fora — do escritório, do celular no ônibus, de qualquer lugar que não seja a sua rede local.&lt;/p&gt;</description></item><item><title>Immich: suas fotos, seu servidor, suas regras</title><link>https://devops.sarmento.org/posts/immich-suas-fotos-seu-servidor-suas-regras/</link><pubDate>Wed, 25 Mar 2026 07:18:00 +0000</pubDate><guid>https://devops.sarmento.org/posts/immich-suas-fotos-seu-servidor-suas-regras/</guid><description>&lt;p&gt;Existe um momento em que todo mundo para e pensa sobre onde estão as suas fotos. Geralmente acontece quando o Google manda aquele email simpático avisando que o armazenamento gratuito acabou — e que por apenas alguns reais por mês você pode continuar guardando suas memórias no servidor deles. É um empurrãozinho gentil na direção de uma assinatura mensal que, somada ao longo de anos, custa mais do que um HD externo de vários terabytes. Mas o preço em dinheiro é só a parte mais óbvia da equação. Existe um custo mais sutil em deixar todas as suas fotos, vídeos e memórias pessoais nas mãos de uma empresa que lucra com dados — e é sobre esse custo que vale a pena conversar antes de falar de qualquer ferramenta.&lt;/p&gt;</description></item></channel></rss>