diff --git a/src/content/posts/en/gnu-and-the-free-software-story.mdx b/src/content/posts/en/gnu-and-the-free-software-story.mdx deleted file mode 100644 index 32872b5..0000000 --- a/src/content/posts/en/gnu-and-the-free-software-story.mdx +++ /dev/null @@ -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. diff --git a/src/content/posts/en/hello-world.mdx b/src/content/posts/en/hello-world.mdx deleted file mode 100644 index 72f3f08..0000000 --- a/src/content/posts/en/hello-world.mdx +++ /dev/null @@ -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. diff --git a/src/content/posts/en/how-cpus-execute-instructions.mdx b/src/content/posts/en/how-cpus-execute-instructions.mdx deleted file mode 100644 index 6366029..0000000 --- a/src/content/posts/en/how-cpus-execute-instructions.mdx +++ /dev/null @@ -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. - - - 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. - - -## 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. diff --git a/src/content/posts/en/why-i-like-knowing-how-things-work.mdx b/src/content/posts/en/why-i-like-knowing-how-things-work.mdx deleted file mode 100644 index 20d0695..0000000 --- a/src/content/posts/en/why-i-like-knowing-how-things-work.mdx +++ /dev/null @@ -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. - - - 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. - - -## 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. diff --git a/src/content/posts/pt/gnu-and-the-free-software-story.mdx b/src/content/posts/pt/gnu-and-the-free-software-story.mdx deleted file mode 100644 index 7201663..0000000 --- a/src/content/posts/pt/gnu-and-the-free-software-story.mdx +++ /dev/null @@ -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. diff --git a/src/content/posts/pt/hello-world.mdx b/src/content/posts/pt/hello-world.mdx deleted file mode 100644 index f9c3900..0000000 --- a/src/content/posts/pt/hello-world.mdx +++ /dev/null @@ -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. diff --git a/src/content/posts/pt/how-cpus-execute-instructions.mdx b/src/content/posts/pt/how-cpus-execute-instructions.mdx deleted file mode 100644 index d288ef5..0000000 --- a/src/content/posts/pt/how-cpus-execute-instructions.mdx +++ /dev/null @@ -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. - - - 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. - - -## 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. diff --git a/src/content/posts/pt/why-i-like-knowing-how-things-work.mdx b/src/content/posts/pt/why-i-like-knowing-how-things-work.mdx deleted file mode 100644 index d17492e..0000000 --- a/src/content/posts/pt/why-i-like-knowing-how-things-work.mdx +++ /dev/null @@ -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. - - - 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. - - -## 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.