1005 | Segurança exposta, rede nova e ferramentas para construir

Sofia Almeida: Olá, bem-vindo a mais um episódio. Eu sou Sofia Almeida.

Rafael Costa: E eu sou Rafael Costa. E olha, o fio que costura os assuntos de hoje é meio inesperado, mas forte: confiança. Quem confia em quem, e o que acontece quando essa confiança é testada — seja num certificado escondido, seja num carro que espiona, seja num data center que só revela o que consome quando alguém erra a mão na redação.

Sofia Almeida: Exatamente. E de confiança a gente vai passar para infraestrutura — o que sustenta tudo isso —, depois para ferramentas que a gente controla de verdade, e no fim um bloco mais variado, com memória, nostalgia e o mundo lá fora. Vamos começar do começo: uma vulnerabilidade que ficou escondida por quase um ano.

Rafael Costa: Então, é isso. O Xray-core, que é um projeto de proxy muito usado — ferramenta de rede, gente usa para tudo que você imagina que se usa um proxy desses — divulgou que existia uma vulnerabilidade de bypass de verificação de certificado no parâmetro pinnedPeerCertSha256. E a palavra-chave aqui é: ocultou. Passou quase um ano em segredo.

Sofia Almeida: E é importante explicar o que é cert pinning para quem não vive isso. Quando você conecta a um servidor, você pode "fixar" o certificado esperado — o hash SHA-256 do certificado — para garantir que, mesmo que a cadeia de certificados pareça legítima, você só fala com aquele servidor específico. É a defesa mais forte contra um intermediário malicioso, contra um certificado emitido indevidamente, contra atacante no meio do caminho.

Rafael Costa: E o bypass significa exatamente que essa defesa não defensava. Ou seja, quem configurou o pinning achando que estava no modo mais paranoico e mais seguro possível estava, na prática, sem a proteção que achava que tinha. Isso é o pior tipo de vulnerabilidade, porque o usuário fez tudo certo. Ele escolheu a opção mais rigorosa. E a ferramenta mentia para ele.

Sofia Almeida: O que me incomoda não é só o bug em si — bugs existem, todo projeto tem —, é o quase ano de silêncio. Agora, aqui vale a pena ser honesto: escondido pode significar coisas diferentes. Pode ser que os mantenedores tenham descoberto, corrigido discretamente e só divulgado depois. Pode ser que tenham levado tempo para entender a gravidade. Pode ser até um período de coordenação de divulgação que simplesmente se esticou demais. Não temos esses detalhes no que foi publicado.

Rafael Costa: Mas aí vem a pergunta que a comunidade sempre faz nesses casos: quem tem o direito de saber, e quando? Porque tem uma escola que diz: divulgação imediata de tudo, o usuário decide. E tem outra que diz: divulgar um bypass antes da correção é entregar a chave do cofre para quem explora. O problema é quando o "depois da correção" vira "quase um ano depois". Nesse intervalo, os usuários estavam operando com uma falsa sensação de segurança, e ninguém avisou.

Sofia Almeida: E tem um agravante específico de ferramentas como o Xray-core. Gente que usa proxy com cert pinning geralmente está em ambientes adversariais — redes hostis, censura, tráfego monitorado. Nesse contexto, a ameaça não é "alguém pode ver meus dados de navegação". A ameaça pode ser a identificação do usuário, a segurança física até. Então o custo de uma falsa sensação de segurança é desproporcional.

Rafael Costa: E ainda tem a questão da auditoria. Se a comunidade soubesse "existe um problema no caminho do certificado, ainda não digamos onde", pesquisadores independentes poderiam olhar aquilo. O segredo total, mesmo que bem-intencionado, impede o escrutínio externo. A pergunta que fica sem resposta, do jeito que a informação chegou, é: como foi descoberto, por quem, e o que exatamente o bypass permitia? Isso não está detalhado no que temos.

Sofia Almeida: Vamos amarrar isso com algo que, no fundo, é o mesmo tema em outra roupa: seus dados, quando você sabe e quando não sabe que estão sendo mandados embora. Um estudo da Northeastern, em parceria com a Consumer Reports, olhou carros conectados. Vinte e um carros. Dezenove — dezenove em vinte e um — mandavam dados para terceiros.

Rafael Costa: A proporção é que assusta. Não é "alguns fabricantes são ruins". É quase universal. E a gente precisa contextualizar o que "carro conectado" significa hoje. O carro moderno é um computador com rodas, literalmente. Ele sabe onde você foi, quando, com que velocidade, como você freia, às vezes até comportamento de direção que pode ser classificado como agressivo. É telemetria, e telemetria é o tipo de dado que seguradoras pagam para ver.

Sofia Almeida: E é por isso que o estudo importa para a conversa que a gente vinha tendo. O paralelo com o Xray-core é direto: em ambos os casos, quem está no controle da informação é quem fabrica a ferramenta, não quem usa. No Xray, o usuário escolheu pinning e não tinha a proteção prometida. No carro, você compra o veículo e o fluxo de dados para terceiros simplesmente acontece, embutido no funcionamento, sem que você tenha uma escolha clara e informada.

Rafael Costa: E aí entram os dois lados do debate que sempre aparece nisso. Um lado diz: parte dessa telemetria é legítima e até boa para o usuário — assistência em emergência, diagnóstico remoto, atualizações, serviços de navegação. O carro precisa conversar com alguma coisa para oferecer as funções modernas. E uma parte disso naturalmente passa por parceiros comerciais. O outro lado responde: ok, mas "terceiros" é um saco sem fundo. Terceiro pode ser o concessionário. Pode ser uma seguradora.

Rafael Costa: Pode ser um data broker. E o usuário não tem visibilidade nenhuma de qual é qual, nem de qual dado vai a qual destino.

Sofia Almeida: E tem um detalhe que eu acho importante: o estudo vem da Northeastern com a Consumer Reports, ou seja, é pesquisa acadêmica em parceria com uma organização de defesa do consumidor. Isso muda o tom. Não é um jornalista fazendo matéria de impacto; é metodologia formal. E mesmo assim, com vinte e um carros, a amostra é pequena — a pergunta óbvia é o que aconteceria com uma frota inteira. Mas vinte e um já bastam para mostrar que o problema é estrutural, não exceção.

Rafael Costa: E o que pode vir disso? Regulação, provavelmente — já existe pressão nesse sentido em vários lugares. E uma mudança de mercado: fabricante que deixar você desligar a telemetria de forma real, com menu claro, pode começar a usar isso como argumento de venda. Mas enquanto isso não acontecer, a recomendação prática é engraçada de amarga: a gente confia no carro do mesmo jeito que o usuário do Xray confiava no pinning. De boa fé. E a fé, às vezes, é traída.

Sofia Almeida: E já que estamos falando de quem controla a informação — vamos falar de quem controla a informação sobre si mesma, e o que acontece quando ela vaza por acidente. A história dos data centers do Google é quase cômica de tão banal. Uma redação mal feita — isso, um erro de escrita — revelou o consumo de água e de eletricidade dos data centers do Google em Nebraska. E de quebra, os reembolsos fiscais.

Rafael Costa: É quase poético, né? Décadas de opacidade, relatórios cuidadosamente redigidos, e o que fura o sigilo é um erro de texto. E a razão pela qual isso é quente é que água é o ponto sensível dos data centers. Refrigeração de data center em escala hiperscale consome água em volume que, quando você multiplica por dezenas de instalações, chega em nível de cidade pequena. E Nebraska, região agrícola, com questões de aquífero e de seca — água ali não é abstração, é recurso disputado com a agricultura.

Sofia Almeida: E o eletricismo segue a mesma lógica. Quando os data centers começaram a ser construídos em ritmo acelerado, os governos locais disputavam essas instalações com isenções e reembolsos fiscais — "venha para cá, crie empregos, a gente alivia seu imposto". O que quase nunca vinha junto era o número que a comunidade queria: quanto isso custa em água e em energia para nós.

Sofia Almeida: E aí, quando um erro de redação entrega os dois de uma vez, o reembolso fiscal ao lado do consumo, a leitura é imediata: a gente deu desconto para uma instalação que consome X de água e Y de eletricidade, e ninguém nos contou.

Rafael Costa: E é aí que a história conversa com os dois blocos anteriores. É o mesmo padrão: transparência por acidente. O Xray divulgou a vulnerabilidade quando quis — ou quando foi forçado pela situação. Os carros mandam dados porque o fabricante decidiu. O Google expõe água e luz porque alguém escreveu mal um parágrafo. Em nenhum dos casos a transparência foi uma escolha proativa. Ela sempre é consequência de vazamento, erro ou pressão externa.

Sofia Almeida: E é justo fazer a contra-argumentação, porque ela existe: o Google publica relatórios ambientais, publica números agregados de consumo de água em escala global. A defesa corporativa seria: nós somos transparentes, no nosso nível. Mas o nível é que importa. Números globais agregados não dizem nada para o morador de uma cidade que hospeda um data center e quer saber o quanto aquele prédio específico bebe do aquífero local. A transparência agregada é, na prática, uma forma de opacidade local.

Rafael Costa: E a conexão que eu acho mais interessante para onde a conversa vai: tudo isso — certificado escondido, carro espionando, data center bebendo água — tem um denominador comum, que é escala centralizada. Grandes sistemas, grandes atores, e você na ponta, confiando. E aí a pergunta natural é: e a infraestrutura por trás disso tudo, para onde ela está indo? Porque tem gente redesenhando a infraestrutura inteira para a era da IA.

Sofia Almeida: Vamos entrar nisso exatamente por aí. John Ousterhout — o mesmo cara do Tcl, do Raft, professor em Stanford, uma lenda da engenharia de sistemas — tem um protocolo chamado Homa, e a proposta é substituir o TCP nos clusters de IA.

Rafael Costa: E vale parar um segundo em por que alguém teria coragem de substituir o TCP. O TCP tem cinquenta anos de estrada. Ele é o protocolo de transporte da internet, está em tudo, foi otimizado por gerações. A proposta do Homa é que o TCP foi desenhado para um mundo de cargas genéricas, e os clusters de IA têm uma carga muito específica: comunicação coletiva massiva entre máquinas, treinamento distribuído, onde uma máquina espera a outra — sincronização.

Rafael Costa: Nesse cenário, latência e variabilidade de latência são o gargalo real.

Sofia Almeida: E a diferença técnica que o Homa aponta é o controle de congestionamento baseado no receptor. Isso é contraintuitivo à primeira vista, então deixa eu tentar explicar. No modelo tradicional, quem envia decide quando desacelerar, lendo sinais da rede. No Homa, quem recebe tem a informação central: ele sabe o que está chegando, o que está pendente, e ele orquestra o recebimento. Ele basicamente agenda o tráfego do lado de quem recebe, onde está a visão completa.

Sofia Almeida: Em clusters de data center, onde o remetente e o destinatário estão no mesmo prédio, sob o mesmo controle administrativo, essa suposição funciona — diferente da internet aberta, onde o receptor não controla nada.

Rafael Costa: E é aí que mora o debate. O ceticismo é legítimo: substituir TCP é substituir uma infraestrutura com décadas de investimento, tooling, hardware especializado, depuração. O entusiasmo é igualmente legítimo: se você tem um cluster fechado, controlado, com carga específica, por que carregar cinquenta anos de bagagem genérica? E a resposta pragmática talvez esteja no meio: Homa não precisa vencer o TCP na internet. Precisa vencer dentro do data center. E aí o jogo é muito mais curto.

Sofia Almeida: E perceba a escala disso no contexto do que a gente acabou de falar. O data center de IA é o consumidor extremo daquela água e daquela eletricidade de Nebraska. O protocolo de rede que faz o treinamento de modelo ser mais eficiente é, indiretamente, uma conversa sobre consumo energético. Cada porcentagem de ganho de comunicação entre GPUs é menos tempo de cluster ligado, menos calor, menos refrigeração.

Rafael Costa: E é exatamente esse pano de fundo que torna o próximo assunto tão interessante, porque ele vai no sentido oposto. Na direção contrária do data center gigante: IA no seu computador. Existe um projeto chamado Strata que roda o Qwen 3.8 Flash Next — um modelo de cento e vinte e cinco bilhões de parâmetros — em hardware de consumidor. Numa RTX 4090, chega a algo entre cem e cento e vinte e quatro tokens por segundo.

Sofia Almeida: Só para dimensionar: cem a cento e vinte tokens por segundo é uma velocidade de leitura confortável — é mais rápido do que a maioria das pessoas lê texto. E estamos falando de um modelo de 125 bilhões de parâmetros, o que até pouco tempo atrás era território exclusivo de data center, e hoje roda numa placa de vídeo que um entusiasta tem em casa.

Sofia Almeida: Isso é o resultado de uma soma de técnicas — quantização, inferência esparsa, arquiteturas de mistura de especialistas —, e o nome "Flash Next" e a possibilidade de poucos parâmetros ativos por token são justamente desse mundo de eficiência.

Rafael Costa: E aqui está o debate que atravessa tudo isso: centralizar ou descentralizar. O argumento da centralização é econômico e técnico: modelos de fronteira precisam de escala, e escala significa data center, significa clusters como os que o Homa quer conectar melhor, significa todo o investimento em infraestrutura que a gente descreveu.

Rafael Costa: O argumento da descentralização é de controle e resiliência: se o modelo roda na minha máquina, meus dados não saem dela, o serviço não cai quando o provedor decide mudar os termos, e eu não dependo da licença que pode ser revogada.

Sofia Almeida: E os dois não são excludentes — e acho que é isso que os números mostram. O Qwen de 125B numa 4090 não substitui o modelo de fronteira para tarefas difíceis. Mas cobre uma enorme fatia de uso cotidiano. Então o futuro provável é camadas: fronteira centralizada para o que é difícil, modelos locais para o que é privado e frequente. A pergunta em aberto é a curva: daqui a dois anos, o que for local, roda o que? Porque essa curva de eficiência só tem acelerado.

Rafael Costa: E tem um sub-tema que aparece quando a IA desce para a sua máquina: a experiência de uso muda completamente. No data center, você é consumidor de um serviço. Na sua máquina, você é dono de um processo. E isso nos leva muito naturalmente para o próximo bloco, que é sobre exatamente isso: infraestrutura que você controla, literalmente, com as próprias mãos.

Sofia Almeida: Vamos começar pelo caso mais extremo de controle sob adversidade: a Ucrânia. Com a invasão russa e os ataques contínuos à infraestrutura energética, o país teve que repensar algo que os países estáveis dão como garantido: a rede elétrica. E a resposta que emergiu, em parte, foi a geração distribuída renovável.

Rafael Costa: O exemplo concreto é painéis solares em Mykolaiv, mantendo água e energia sob ataques russos. E é importante entender por que "distribuída" é a palavra mágica aqui. Uma usina grande é um alvo: um míssil, e você perde a capacidade inteira. Milhares de pequenas instalações espalhadas são outro problema completamente diferente — destruir o suficiente delas para derrubar a capacidade é muito mais difícil e muito mais caro. A distribuição é, literalmente, uma defesa.

Sofia Almeida: E o detalhe da água em Mykolaiv é muito forte, porque água é uma cadeia que depende de energia — bombeamento, tratamento, pressão. Quando a rede centralizada cai, a água cai junto. Painéis solares no lugar certo, com o armazenamento certo, mantêm essa cadeia mínima viva mesmo com a rede destruída. É infraestrutura de sobrevivência, no sentido mais literal da palavra.

Rafael Costa: E eu acho que vale a honestidade de ambos os lados do debate. O entusiasmo com renováveis distribuídas na Ucrânia é justificado e é factual — funcionaram. Mas renovável tem a sua fraqueza conhecida: solar não produz à noite, sem bateria não segura a ponta. Então a lição de lá não é "renovável resolve tudo", é "diversificação e distribuição aumentam resiliência".

Rafael Costa: A Ucrânia está aprendendo, na prática e sob fogo, o que os planejadores de rede discutem em teoria há anos: quanta centralização você aceita trocar por quanta eficiência?

Sofia Almeida: E essa é uma lição que viaja. Porque a gente, no mundo estável, tem a mesma troca em outra forma: convenientes serviços centralizados — a nuvem, a plataforma, o SaaS — em troca de dependência. E quando essa dependência quebra — outage, mudança de preço, mudança de termos — a gente sente na pele. E é aí que entra a parte mais técnica do nosso bloco, que é o self-hosting na prática. Não na escala de guerra, na escala do desenvolvedor.

Rafael Costa: A receita é bonita de tão enxuta: túneis HTTP self-hosted usando só OpenSSH e nginx. Sem terceiro, sem serviço de túnel, sem plataforma. Dois componentes que todo mundo já tem.

Sofia Almeida: E deixa eu explicar como funciona, porque é elegante. O OpenSSH tem um recurso chamado remote forward. Você, a partir da sua máquina — digamos, atrás de um NAT, sem IP público, que é a situação da maioria —, abre uma conexão SSH para um servidor que tem IP público e pede: "abra a porta tal aí, e tudo que chegar aí, me mande de volta pelo túnel". Pronto: seu serviço, que estava escondido atrás do NAT, agora é alcançável pelo servidor público.

Sofia Almeida: Isso é exatamente o que os serviços de túnel comerciais fazem, só que você está usando o SSH que já está instalado em qualquer Unix.

Rafael Costa: E aí entra a parte mais esperta: como você não quer expor esse túnel para o mundo inteiro, o nginx na frente usa o módulo secure link. Você gera um token com hash e um prazo de expiração, embute na URL, e o nginx só aceita a requisição se o token for válido e não tiver expirado. Ou seja, você construiu um link temporário, assinado, que morre sozinho.

Rafael Costa: O equivalente ao "link de compartilhamento com prazo" que você usa em serviços pagos — mas com meia dúzia de linhas de configuração e zero de terceiro.

Sofia Almeida: E as ressalvas honestas valem ser ditas, porque o debate em volta de self-hosting sempre tem esse tom. Primeiro: o servidor público é seu ponto único de falha e precisa estar seguro — SSH exposto é alvo constante de tentativa de força bruta, então quem faz isso precisa cuidar de chaves, de fail2ban, do básico de higiene. Segundo: você agora é o operador. Quando quebrar às três da manhã, não tem suporte, tem você. É essa a moeda da troca: controle em troca de responsabilidade.

Rafael Costa: E é a mesma moeda da história da Ucrânia, em escala menor. Distribuir, controlar, não depender. A diferença é que lá a ameaça é um míssil e aqui a ameaça é um prazo expirado ou um servidor mal cuidado. Mas a filosofia é idêntica: manter o serviço vivo e sob controle próprio.

Sofia Almeida: E essa filosofia de "local, meu, sob meu controle" é exatamente o tema do próximo bloco — só que agora no seu computador pessoal, no dia a dia. Três ferramentas, três ângulos. Começando por Rust, porque o custo de compilação é o tipo de coisa que corrói a vida do desenvolvedor em silêncio.

Rafael Costa: O projeto se chama Headstart, e a ideia é geniosa de simples: emitir os metadados do crate mais cedo no processo de compilação. O resultado medido é aceleração de até cinquenta e quatro por cento no cargo check e quarenta e dois por cento no cargo build em projetos reais.

Sofia Almeida: E é preciso explicar por que isso importa, porque quem não escreve Rust pode achar que quarenta por cento é detalhe. O tempo de compilação do Rust é o imposto conhecido da linguagem — você ganha segurança de memória e desempenho, e paga tempo de espera. E esse tempo não é uma espera única: é uma espera que acontece dezenas de vezes por dia, em cada iteração. Cinquenta por cento menos de espera não é conforto, é mudança no loop de feedback do desenvolvedor.

Sofia Almeida: É a diferença entre "deixo compilando e vou tomar café" e "compilou, continuo pensando".

Rafael Costa: E a parte interessante é o mecanismo: os metadados são a informação que os crates dependentes precisam uns dos outros. Se você consegue emitir isso mais cedo no pipeline, os crates dependentes começam o trabalho deles mais cedo, em paralelo, em vez de esperar o crate inteiro terminar. É paralelização fina dentro da compilação.

Rafael Costa: E o fato de os números virem de projetos reais, não de benchmark sintético, dá credibilidade — porque projeto real tem a estrutura irregular, dependências desiguais, exatamente onde otimizações bonitas no papel costumam decepcionar.

Sofia Almeida: E a pergunta que fica, naturalmente, é quando isso entra no cargo oficial de verdade. Porque toda otimização de build tem um caminho longo até virar padrão — tem que ser testada contra os infinitos formatos de projeto que existem. Mas a direção é clara, e o sinal é de que a comunidade está disposta a atacar esse imposto da linguagem.

Rafael Costa: E do compilador, vamos para a sua biblioteca de fotos. Duas ferramentas de macOS, com filosofias opostas — e é aí que a discussão fica boa. A primeira se chama SCM, e é a tese do "mais IA local, por favor". Ela faz busca por IA de todas as suas fotos e de todos os frames de vídeo, no seu Mac, local-first. Usa Whisper para transcrever áudio, OCR para ler texto que aparece na imagem, e análise de cenas.

Sofia Almeida: E o que isso significa na prática: você digita "aquela foto com o quadro branco da reunião" e acha — porque o OCR leu o quadro branco. Ou "o vídeo onde a pessoa fala sobre o orçamento" — porque o Whisper transcreveu o áudio. A busca não depende mais de você ter nomeado e etiquetado tudo nos últimos dez anos, o que ninguém fez. A IA local vira o índice do seu arquivo pessoal. E o "local-first" é o ponto: seus dez anos de fotos não vão para nuvem de ninguém para serem indexados.

Rafael Costa: E a segunda ferramenta é a resposta exata à primeira: RemoveMacAI, que desliga a Apple Intelligence no macOS 27, remove os modelos do disco, e é reversível. Ou seja, mesmo que a SCM represente o melhor cenário de IA local — útil, privada, sob seu controle —, tem gente que quer é tirar a IA do computador de vez. E o argumento não é anti-tecnologia: é sobre disco e recursos. Modelos locais ocupam espaço, ocupam memória, rodam processos em segundo plano.

Rafael Costa: Se você não usa, é lixo no seu disco com processes rodando à toa.

Sofia Almeida: E o que eu acho mais rico nessa dupla é que as duas ferramentas estão, no fundo, fazendo a mesma exigência: controle. A SCM diz "quero IA, mas no meu disco, indexando meus dados, sem sair daqui". O RemoveMacAI diz "não quero IA, e quero poder tirá-la, incluindo os modelos do disco". As duas posições só fazem sentido num mundo onde o padrão do sistema operacional decide por você — e as duas existem porque o padrão não dá esse controle de forma plena.

Sofia Almeida: A ferramenta reversível é o detalhe importante: não é desinstalação destrutiva, é uma escolha que você pode desfazer. O que é exatamente como o controle deveria funcionar.

Rafael Costa: E as duas visões respondem à mesma pergunta, de lados opostos: como o software local deve funcionar? Uma diz: local e inteligente, indexando tudo o que é seu. Outra diz: local e enxuto, só o que você pediu. E o usuário ideal, talvez, queira as duas — IA poderosa quando pedida, silêncio quando não.

Sofia Almeida: E de controle do software, vamos para o prazer de construir software — que é onde o nosso último bloco começa. Existe um projeto que eu acho delicioso: um IDE estilo Visual Basic seis, nativo no navegador. Com runtime, designer de formulários, e que compila para um arquivo HTML único.

Rafael Costa: Para quem não viveu isso, contexto: o Visual Basic seis, lá nos anos noventa e começo dos dois mil, tinha uma magia específica. Você arrastava um botão para um formulário, dava duplo clique, e escrevia o que acontecia quando clicasse. Pronto, era um programa. Não tinha build pipeline, não tinha npm, não tinha deploy. O IDE estilo VB6 do navegador resgata exatamente isso: designer de formulários, runtime embutido, e o resultado é um arquivo HTML único que você abre em qualquer lugar.

Rafael Costa: Sem servidor, sem instalação.

Sofia Almeida: E é por isso que esse projeto conecta direto com uma provocação do Nolan Lawson, que é conhecido no mundo web: por que os desenvolvedores evitam "usar a plataforma"? Ou seja, por que a gente insiste em empilhar camadas de framework e ferramenta em cima do navegador, quando o navegador sozinho já é uma plataforma de aplicação poderosa?

Rafael Costa: E o Lawson aponta três razões, e acho que vale passar por elas, porque o autoexame é doloroso e útil. A primeira é histórica: as ferramentas cresceram numa época em que a plataforma era genuinamente limitada — e os hábitos que aquela época criou sobreviveram à plataforma que se corrigiu. A segunda é familiaridade com libs: você conhece seu framework, sabe onde está o bug, sabe onde buscar ajuda; a plataforma crua é território menos mapeado para muita gente.

Rafael Costa: E a terceira é a mais honesta: o prazer de construir. Construir a própria abstração, a própria camada, é divertido. É engenharia como ofício.

Sofia Almeida: E o IDE estilo VB6 é quase um argumento vivo nesse debate, porque ele mostra que a plataforma pode carregar a experiência inteira: runtime, designer, compilação em um arquivo. É o espírito do "usar a plataforma" empacotado em nostalgia. E a ressalva que sempre aparece é justa: projetos grandes e em equipe precisam de estrutura que a plataforma crua não oferece de graça — tipos, testes, organização de código em escala.

Sofia Almeida: O debate não é "framework ruim", é "a gente escolhe, ou a escolha agora é automática e herdada?"

Rafael Costa: E de construir software, para preservar memória — e essa é uma história que me deixa genuinamente feliz. O arquivo digital do VGHF, o Video Game History Foundation, ultrapassou cinco mil revistas de games, cobrindo de mil novecentos e oitenta e um até vinte e vinte e seis. E agora passa a incluir revistas japonesas.

Sofia Almeida: E por que revistas de games importam tanto? Porque elas eram, por décadas, o registro primário da indústria: previews, entrevistas, reviews, fotos de protótipos que nunca saíram. Quando uma revista desaparece, desaparece junto a versão do fato contada na época — não a versão revisitada pela memória nem a versão oficial da assessoria.

Sofia Almeida: E a inclusão das revistas japonesas é significativa, porque a cobertura japonesa da era de ouro não é tradução da americana: é outra cobertura, outra perspectiva, jogos que o Ocidente nunca viu ou viu diferente.

Rafael Costa: E o intervalo até vinte e vinte e seis é um lembrete: preservação não é só sobre o passado distante. As revistas morreram como mídia há tempo, mas a cultura da crítica e da cobertura de games continua em outros formatos — e o que se salva hoje é o que existirá em trinta anos. Cinco mil títulos é trabalho de catalogação, digitalização, indexação — é o tipo de esforço silencioso que só se valoriza quando a fonte desaparece.

Sofia Almeida: E a conexão com o resto do episódio é direta, não é? O self-hosting, o local-first, a preservação — tudo isso é a mesma resposta a uma pergunta: em quem confiar com o que é seu e com o que importa. Vamos fechar com o mundo lá fora, três notas rápidas mas que merecem uns minutos. A primeira: F1. Um glitch de software deixou pilotos sem potência na volta de apresentação no Bahrain e em Sepang — e o patch levou cinquenta minutos.

Rafael Costa: E a F1 é um ótimo lembrete de onde o software chegou. O carro de F1 é talvez a máquina esportiva mais densa em software do planeta — e um glitch no lugar errado tira a potência justamente na volta de apresentação, que é cerimônia, é imagem, é o momento em que o piloto está diante do público. Cinquenta minutos para corrigir é rápido em termos absolutos — e é uma eternidade no contexto de um evento ao vivo.

Rafael Costa: A lição que carrega para tudo o que discutimos: quando o software controla o mundo físico, o patch de emergência vira parte da operação, não uma exceção.

Sofia Almeida: A segunda nota: The Economist publicou uma análise da evolução do altruísmo eficaz — e o Will MacAskill respondeu à matéria. Para quem não conhece, MacAskill é filósofo e uma das figuras centrais do movimento de effective altruism, e o movimento vive um momento de reavaliação: a ideia original era maximizar o impacto mensurável do bem, com muita ênfase em métricas, e os últimos anos forçaram o movimento a repensar o que é mensurável e o que se perde quando se otimiza o número.

Rafael Costa: E o detalhe de o próprio MacAskill responder à matéria é o mais interessante, porque mostra um debate em andamento, não um veredito. O movimento está sendo moldado publicamente, em tempo real, por quem o fundou e por quem o critica. E a terceira nota é mais sóbria: morreu Bill Draper, investidor de risco de três gerações da família Draper — uma dinastia do venture capital — e financiador de duzentas e oitenta ONGs.

Sofia Almeida: Duzentas e oitenta organizações. Isso é a outra ponta do espectro que discutimos o episódio inteiro: capital, impacto, o que se financia e o que permanece. O Draper viveu a construção da indústria de venture capital como a conhecemos, e a parte da vida dedicada a financiar duzentas e oitenta ONGs é a resposta dele, em atos, à mesma pergunta que o MacAskill faz em filosofia: onde o recurso gera mais bem?

Rafael Costa: E é um bom lugar para terminar, porque amarra tudo: o certificado escondido, o carro que fala demais, o data center que bebe em segredo, o protocolo que redesenha o data center, o túnel SSH, a revista japonesa escaneada — tudo são respostas, melhores ou piores, à pergunta de confiança. Em quem confiar, com o quê, e com quem verificamos.

Sofia Almeida: Obrigado por ficar com a gente até aqui. Nos encontramos no próximo episódio.

Rafael Costa: Até lá.