removed example posts written by claude

src/content/posts/en/gnu-and-the-free-software-story.mdx

@@ -1,30 +0,0 @@
----
-title: "GNU, Linux, and the fight that built modern software"
-description: "A short history of the GNU project, Linus Torvalds' kernel, and the free/open source split that still shapes software today."
-pubDate: 2026-05-30
-tags: ["open-source", "history"]
----
-
-Most of the software you rely on daily — the languages, the servers, half the tools in a typical terminal — traces back to a decision Richard Stallman made in 1983: to walk away from a proprietary printer driver dispute at MIT and start building a completely free replacement for Unix, from scratch. He called it GNU — "GNU's Not Unix," a recursive acronym, because that's the kind of joke that programmer culture loves.
-
-## The GNU project
-
-The GNU project's goal was total: a free operating system, kernel included, with every tool a Unix user would expect — a compiler, an editor, a shell, coreutils — released under licenses that guaranteed the freedom to run, study, modify, and share the software. That last part became the Free Software Foundation and the GPL, a license explicitly designed to keep derivative works free too — what Stallman called "copyleft."
-
-By the early 1990s, GNU had built almost everything: GCC, Emacs, Bash, binutils, glibc. Almost everything except a kernel. The GNU Hurd, its intended kernel, was ambitious in design and slow to mature.
-
-## Enter Linux
-
-In 1991, a Finnish student named Linus Torvalds posted a now-famous, deliberately modest message to a Usenet newsgroup: he was writing a "free operating system (just a hobby, won't be big and professional like gnu)" for 386(486) AT clones. That hobby project was a kernel — Linux.
-
-Linux filled exactly the gap GNU had left open. Combined with the GNU userland, you got a complete, free operating system: technically "GNU/Linux," though most people just say "Linux." The naming debate itself became a small piece of open source folklore — a genuine disagreement about credit and framing that's still occasionally relitigated on mailing lists today.
-
-Torvalds' contribution didn't stop at the kernel. In 2005, frustrated with existing tools for the scale and pace of kernel development, he wrote Git in about ten days. A distributed version control system built specifically to handle a project with thousands of contributors and no single point of trust. It's hard to overstate how much of today's software workflow — pull requests, forks, the entire GitHub/GitLab ecosystem — sits on top of a tool built to solve one very specific, very large-scale problem.
-
-## Why the history matters
-
-It's easy to use `git commit`, install a package with `apt`, or compile something with `gcc` without ever thinking about where they came from. But the free software movement wasn't inevitable — it was a specific, sometimes contentious set of choices about licensing, collaboration, and what "ownership" of software should even mean.
-
-The split between "free software" (Stallman's ethical framing, about user freedom) and "open source" (a later, more pragmatic framing coined partly to be palatable to business) is still a live philosophical distinction, not just semantics. Understanding it explains a lot about why different projects choose the licenses they do, and why some communities care so much about it.
-
-I find this history genuinely useful, not just interesting — it's a reminder that the tools we treat as neutral infrastructure were built by people making deliberate, sometimes idealistic bets. Worth knowing before you take them for granted.

src/content/posts/en/hello-world.mdx

@@ -1,22 +0,0 @@
----
-title: "Hello, world"
-description: "A short note on why this blog exists and what I plan to write about here."
-pubDate: 2026-01-12
-tags: ["meta", "blogging"]
----
-
-I finally sat down and built this thing. Not because the world needed another blog, but because I kept having half-formed thoughts about code, systems, and the history of the tools I use every day — and nowhere to put them.
-
-So: hello. I'm Gabe. This is going to be a small, mostly technical corner of the internet where I write things down so I understand them better, and maybe so future-me (or you) can come back to them later.
-
-## What to expect
-
-A few recurring themes, roughly in order of how often I think about them:
-
-- **How things work under the hood** — CPUs, compilers, operating systems, the kind of stuff that's easy to use and hard to explain.
-- **Open source history** — the people and decisions that shaped the software we take for granted.
-- **Whatever I'm learning at PUCRS** that seems worth writing about properly instead of just leaving in a notebook.
-
-I write in English and Portuguese, since both are useful to me and hopefully to whoever reads this. Every post has both versions — use the language switch in the header to move between them.
-
-No comment section, no newsletter, no tracking scripts I didn't write myself. Just posts. Let's see where this goes.

src/content/posts/en/how-cpus-execute-instructions.mdx

@@ -1,41 +0,0 @@
----
-title: "How a CPU actually executes an instruction"
-description: "Fetch, decode, execute: a plain-language walk through what your processor does billions of times per second."
-pubDate: 2026-03-18
-tags: ["computer-science", "systems"]
----
-
-import ObservationCard from '../../../components/ObservationCard';
-
-When people say a CPU "runs code," what actually happens is a lot more mechanical — and a lot more satisfying to understand — than that phrase suggests. There's no magic. Just a very fast, very disciplined loop.
-
-## The loop: fetch, decode, execute
-
-At the bottom of almost everything your computer does is a cycle that repeats, conceptually, forever:
-
-1. **Fetch** — the CPU reads the next instruction from memory, at the address stored in the program counter (PC).
-2. **Decode** — control logic figures out what the instruction actually means: which operation, which registers, which addressing mode.
-3. **Execute** — the ALU (or another functional unit) performs the operation — an addition, a memory load, a branch.
-4. **Write back** — the result, if any, is stored somewhere: a register, or memory.
-5. The program counter updates, and the loop starts again.
-
-<ObservationCard title="Observation">
-  This is the textbook five-stage model (sometimes just three: fetch, decode, execute). Real
-  processors pipeline these stages so multiple instructions are in flight at once, and modern
-  chips go much further with out-of-order execution and speculation — but the mental model above
-  still holds for reasoning about correctness.
-</ObservationCard>
-
-## Why this matters even if you never write assembly
-
-You don't need to write machine code to benefit from understanding this loop. It explains, among other things:
-
-- Why branches (`if`, loops) are relatively expensive — the CPU has to figure out where to fetch from next, and a wrong guess (misprediction) means throwing away speculative work.
-- Why cache misses hurt so much — the fetch and memory-access stages stall waiting on DRAM, which is glacially slow compared to a clock cycle.
-- Why "the compiler optimized it away" is a real thing — the compiler is generating the instruction stream this loop consumes, and it's free to pick a completely different sequence as long as observable behavior matches.
-
-## Under the hood is not a black box
-
-The instruction set architecture (ISA) — x86-64, ARM, RISC-V — is the contract between software and hardware: a fixed vocabulary of operations the fetch/decode/execute loop knows how to handle. Everything above that — your language, your framework, your favorite abstraction — eventually compiles or interprets down into that vocabulary.
-
-Knowing this doesn't make you write faster code by itself. But it makes the rest of the stack stop feeling like magic, and that's usually where I start when I want to actually understand a system instead of just using it.

src/content/posts/en/why-i-like-knowing-how-things-work.mdx

@@ -1,28 +0,0 @@
----
-title: "Why I insist on knowing how things work"
-description: "On the habit of digging past the abstraction, and why it's worth the extra time."
-pubDate: 2026-08-25
-tags: ["learning", "philosophy"]
----
-
-import ObservationCard from '../../../components/ObservationCard';
-
-There's a moment that happens fairly often when I'm learning something new: a tool, a library, a framework works, I get the result I wanted, and I still don't feel done. Something in me needs to know *why* it worked before I can move on.
-
-This is slower. I'll admit that up front. You can ship things faster by treating a library as a black box, calling the documented function, and trusting it. Most of the time that's the correct engineering tradeoff, and I do it too when a deadline demands it.
-
-But left to my own devices, I go the other way. If a build tool does something unexpected, I'd rather read its source for ten minutes than paste the error into a search bar. If a language feature feels like magic, I want to know what it actually compiles or desugars to.
-
-<ObservationCard title="Observation">
-  This isn't really about distrust of abstractions — abstractions are how any of this scales at
-  all. It's that an abstraction I understand is one I can safely break when I need to, and one I
-  understand *badly* is where the weirdest, hardest-to-debug problems tend to live.
-</ObservationCard>
-
-## Where this comes from
-
-I'm studying computer science at PUCRS, and if there's one thing the coursework reinforces, it's that almost every "advanced" tool is built from a small number of ideas repeated and combined: state machines, trees, graphs, the fetch-decode-execute loop, layers of indirection stacked on layers of indirection. Once you've actually implemented a toy version of something — a shell, a tiny compiler, a basic scheduler — the "real" version stops looking like magic and starts looking like an engineering decision you can evaluate.
-
-That's part of why I find open source history so interesting too: it's the same instinct applied to systems instead of code. Knowing *why* GNU exists, or why Git was built the way it was, changes how I read a commit history or a mailing list thread. The tool stops being a given and becomes a decision someone made, for reasons, under constraints — which is exactly the kind of thing I want to understand before I trust it completely.
-
-I don't think this is a virtue in some abstract sense. It's just a very specific, very particular way of working that happens to suit me, and this blog is mostly a record of the digging.

src/content/posts/pt/gnu-and-the-free-software-story.mdx

@@ -1,30 +0,0 @@
----
-title: "GNU, Linux e a disputa que construiu o software moderno"
-description: "Uma breve história do projeto GNU, do kernel do Linus Torvalds e da divisão entre software livre e open source que ainda molda o software hoje."
-pubDate: 2026-05-30
-tags: ["open-source", "history"]
----
-
-Boa parte do software que usamos todo dia — as linguagens, os servidores, metade das ferramentas de um terminal comum — remonta a uma decisão que Richard Stallman tomou em 1983: abandonar uma disputa sobre um driver de impressora proprietário no MIT e começar a construir, do zero, uma substituta completamente livre para o Unix. Ele chamou isso de GNU — "GNU's Not Unix", um acrônimo recursivo, porque esse é exatamente o tipo de piada que a cultura da programação adora.
-
-## O projeto GNU
-
-O objetivo do projeto GNU era total: um sistema operacional livre, kernel incluído, com todas as ferramentas que um usuário Unix esperaria — compilador, editor, shell, coreutils — lançadas sob licenças que garantissem a liberdade de rodar, estudar, modificar e compartilhar o software. Essa última parte deu origem à Free Software Foundation e à GPL, uma licença desenhada explicitamente para manter livres também os trabalhos derivados — o que Stallman chamou de "copyleft".
-
-No início dos anos 1990, o GNU já tinha construído quase tudo: GCC, Emacs, Bash, binutils, glibc. Quase tudo, menos um kernel. O GNU Hurd, o kernel planejado, era ambicioso em design e lento para amadurecer.
-
-## Entra o Linux
-
-Em 1991, um estudante finlandês chamado Linus Torvalds postou uma mensagem hoje famosa, deliberadamente modesta, em um newsgroup da Usenet: ele estava escrevendo um "sistema operacional livre (só um hobby, não vai ser grande e profissional como o gnu)" para clones AT 386(486). Esse projeto de hobby era um kernel — o Linux.
-
-O Linux preencheu exatamente a lacuna que o GNU tinha deixado aberta. Combinado com o userland do GNU, você tinha um sistema operacional livre e completo: tecnicamente "GNU/Linux", embora a maioria das pessoas diga só "Linux". O próprio debate sobre o nome virou um pequeno pedaço do folclore do open source — uma discordância genuína sobre crédito e enquadramento que volta a ser discutida em listas de e-mail até hoje.
-
-A contribuição de Torvalds não parou no kernel. Em 2005, frustrado com as ferramentas existentes para a escala e o ritmo do desenvolvimento do kernel, ele escreveu o Git em cerca de dez dias. Um sistema de controle de versão distribuído, construído especificamente para lidar com um projeto com milhares de colaboradores e nenhum ponto único de confiança. É difícil superestimar o quanto do fluxo de trabalho de software de hoje — pull requests, forks, todo o ecossistema GitHub/GitLab — está construído em cima de uma ferramenta feita para resolver um problema bem específico e de grande escala.
-
-## Por que essa história importa
-
-É fácil usar `git commit`, instalar um pacote com `apt` ou compilar algo com `gcc` sem nunca pensar de onde essas coisas vieram. Mas o movimento do software livre não era inevitável — foi um conjunto específico, às vezes controverso, de escolhas sobre licenciamento, colaboração e o que "propriedade" de software deveria sequer significar.
-
-A divisão entre "software livre" (o enquadramento ético de Stallman, sobre a liberdade do usuário) e "open source" (um enquadramento posterior, mais pragmático, cunhado em parte para ser palatável ao mundo dos negócios) ainda é uma distinção filosófica viva, não só semântica. Entender isso explica bastante sobre por que projetos diferentes escolhem as licenças que escolhem, e por que algumas comunidades se importam tanto com isso.
-
-Acho essa história genuinamente útil, não só interessante — ela é um lembrete de que as ferramentas que tratamos como infraestrutura neutra foram construídas por pessoas fazendo apostas deliberadas, às vezes idealistas. Vale a pena conhecer antes de tomar isso como garantido.

src/content/posts/pt/hello-world.mdx

@@ -1,22 +0,0 @@
----
-title: "Olá, mundo"
-description: "Uma nota curta sobre por que este blog existe e sobre o que pretendo escrever aqui."
-pubDate: 2026-01-12
-tags: ["meta", "blogging"]
----
-
-Finalmente me sentei e construí isso. Não porque o mundo precisasse de mais um blog, mas porque eu vivia tendo pensamentos pela metade sobre código, sistemas e a história das ferramentas que uso todo dia — e não tinha onde colocá-los.
-
-Então: olá. Eu sou o Gabe. Este vai ser um cantinho pequeno e majoritariamente técnico da internet, onde escrevo as coisas para entendê-las melhor, e talvez para que o meu eu do futuro (ou você) possa voltar a elas depois.
-
-## O que esperar
-
-Alguns temas recorrentes, mais ou menos na ordem em que penso sobre eles:
-
-- **Como as coisas funcionam por baixo dos panos** — CPUs, compiladores, sistemas operacionais, esse tipo de coisa que é fácil de usar e difícil de explicar.
-- **História do open source** — as pessoas e decisões que moldaram o software que hoje consideramos garantido.
-- **O que eu estiver aprendendo na PUCRS** que pareça valer a pena escrever com calma, em vez de deixar só num caderno.
-
-Escrevo em português e em inglês, já que os dois são úteis pra mim e, espero, para quem estiver lendo. Todo post tem as duas versões — use o botão de idioma no cabeçalho para alternar entre elas.
-
-Sem seção de comentários, sem newsletter, sem script de rastreamento que eu mesmo não tenha escrito. Só posts. Vamos ver até onde isso vai.

src/content/posts/pt/how-cpus-execute-instructions.mdx

@@ -1,41 +0,0 @@
----
-title: "Como uma CPU de fato executa uma instrução"
-description: "Busca, decodificação, execução: um passeio em linguagem simples pelo que o seu processador faz bilhões de vezes por segundo."
-pubDate: 2026-03-18
-tags: ["computer-science", "systems"]
----
-
-import ObservationCard from '../../../components/ObservationCard';
-
-Quando dizem que uma CPU "executa código", o que de fato acontece é bem mais mecânico — e bem mais satisfatório de entender — do que essa frase sugere. Não há mágica nenhuma. Só um loop muito rápido e muito disciplinado.
-
-## O loop: busca, decodificação, execução
-
-Na base de quase tudo que o seu computador faz existe um ciclo que se repete, conceitualmente, para sempre:
-
-1. **Busca (fetch)** — a CPU lê a próxima instrução da memória, no endereço guardado no contador de programa (PC).
-2. **Decodificação (decode)** — a lógica de controle descobre o que a instrução realmente significa: qual operação, quais registradores, qual modo de endereçamento.
-3. **Execução (execute)** — a ALU (ou outra unidade funcional) realiza a operação — uma soma, uma leitura de memória, um desvio.
-4. **Write back** — o resultado, se houver, é armazenado em algum lugar: um registrador ou a memória.
-5. O contador de programa é atualizado, e o loop recomeça.
-
-<ObservationCard title="Observação">
-  Esse é o modelo clássico de cinco estágios (às vezes reduzido a três: busca, decodificação,
-  execução). Processadores reais fazem pipeline desses estágios, de forma que várias instruções
-  estejam "em voo" ao mesmo tempo, e chips modernos vão muito além disso com execução fora de
-  ordem e especulação — mas o modelo mental acima ainda serve para raciocinar sobre corretude.
-</ObservationCard>
-
-## Por que isso importa mesmo que você nunca escreva assembly
-
-Você não precisa escrever código de máquina para se beneficiar de entender esse loop. Ele explica, entre outras coisas:
-
-- Por que desvios (`if`, laços) são relativamente caros — a CPU precisa descobrir de onde buscar a próxima instrução, e um chute errado (misprediction) significa descartar trabalho especulativo.
-- Por que cache miss dói tanto — os estágios de busca e acesso à memória ficam parados esperando a DRAM, que é absurdamente lenta comparada a um ciclo de clock.
-- Por que "o compilador otimizou isso e sumiu" é uma coisa real — o compilador está gerando o fluxo de instruções que esse loop consome, e é livre para escolher uma sequência completamente diferente desde que o comportamento observável seja o mesmo.
-
-## Por baixo dos panos não é uma caixa-preta
-
-A arquitetura do conjunto de instruções (ISA) — x86-64, ARM, RISC-V — é o contrato entre software e hardware: um vocabulário fixo de operações que o loop de busca/decodificação/execução sabe tratar. Tudo o que vem acima disso — sua linguagem, seu framework, sua abstração favorita — eventualmente compila ou é interpretado até chegar nesse vocabulário.
-
-Saber disso não faz você escrever código mais rápido por si só. Mas faz o resto da pilha parar de parecer mágica, e é geralmente por aí que eu começo quando quero de fato entender um sistema em vez de apenas usá-lo.

src/content/posts/pt/why-i-like-knowing-how-things-work.mdx

@@ -1,29 +0,0 @@
----
-title: "Por que eu insisto em entender como as coisas funcionam"
-description: "Sobre o hábito de cavar além da abstração, e por que vale a pena o tempo extra."
-pubDate: 2026-08-25
-tags: ["learning", "philosophy"]
----
-
-import ObservationCard from '../../../components/ObservationCard';
-
-Há um momento que acontece com bastante frequência quando estou aprendendo algo novo: uma ferramenta, uma biblioteca, um framework funciona, eu consigo o resultado que queria, e mesmo assim não me sinto satisfeito. Alguma coisa em mim precisa entender *por que* aquilo funcionou antes de eu conseguir seguir em frente.
-
-Isso é mais lento. Admito isso de cara. Dá pra entregar coisas mais rápido tratando uma biblioteca como uma caixa-preta, chamando a função documentada e confiando nela. Na maior parte do tempo essa é a decisão de engenharia correta, e eu também faço isso quando um prazo exige.
-
-Mas, por conta própria, eu vou pelo caminho contrário. Se uma ferramenta de build faz algo inesperado, prefiro ler o código-fonte dela por dez minutos a colar o erro numa busca. Se um recurso de uma linguagem parece mágica, eu quero saber para o que ele realmente compila ou se desdobra.
-
-<ObservationCard title="Observação">
-  Isso não é bem sobre desconfiar de abstrações — abstrações são o motivo de qualquer coisa
-  escalar. É que uma abstração que eu entendo é uma que eu posso quebrar com segurança quando
-  preciso, e uma que eu entendo *mal* costuma ser onde moram os problemas mais estranhos e mais
-  difíceis de debugar.
-</ObservationCard>
-
-## De onde isso vem
-
-Estou cursando ciência da computação na PUCRS, e se tem uma coisa que as disciplinas reforçam, é que quase toda ferramenta "avançada" é construída a partir de um pequeno número de ideias repetidas e combinadas: máquinas de estado, árvores, grafos, o loop de busca-decodificação-execução, camadas de indireção empilhadas sobre camadas de indireção. Depois que você de fato implementa uma versão de brinquedo de alguma coisa — um shell, um compilador minúsculo, um escalonador básico — a versão "de verdade" para de parecer mágica e passa a parecer uma decisão de engenharia que você consegue avaliar.
-
-Essa é parte do motivo pelo qual também acho a história do open source tão interessante: é o mesmo instinto aplicado a sistemas em vez de código. Saber *por que* o GNU existe, ou por que o Git foi construído do jeito que foi, muda como eu leio um histórico de commits ou uma thread de lista de e-mail. A ferramenta deixa de ser um dado e passa a ser uma decisão que alguém tomou, por motivos, sob restrições — que é exatamente o tipo de coisa que eu quero entender antes de confiar completamente nela.
-
-Não acho que isso seja uma virtude em algum sentido abstrato. É só um jeito bem específico e bem particular de trabalhar que combina comigo, e este blog é basicamente um registro dessa cavada.