1011 | Compilado Técnico: open source, IA e curiosidades da semana

Sofia Almeida: Boas-vindas ao mais novo episódio do nosso podcast de tecnologia e sociedade — eu sou Sofia Almeida.

Rafael Costa: E eu Rafael Costa. O que amarra os assuntos de hoje é bem simples: sistemas, licenças e regras. Quando a regra é código, quando ela é uma licença, quando ela é um imposto ou uma senha — e o que acontece quando essa regra falha ou quando alguém tenta dobrá-la.

Sofia Almeida: É um episódio sobre pressão, basicamente. Pressão sobre projetos open source, sobre quem responde quando uma IA decide algo, sobre políticas de moradia, até sobre a palavra "ultraprocessado". E a gente começa exatamente por essa pressão sobre o open source, que rendeu uma discussão boa demais para resumir em duas frases.

Rafael Costa: O primeiro caso é o Talorys. É um agente de IA pessoal que você autohospeda — a promessa é que você sobe a coisa inteira com um único comando na sua conta do Cloudflare. A licença é MIT, e o ponto de venda explícito é que não tem telemetria. Nada do que você conversa com o agente sai da sua infraestrutura.

Sofia Almeida: E na discussão, o que todo mundo meio que concordou é que o design de distribuição é a parte inteligente. Comentou gente que já sofreu com self-hosting tradicional: você precisa de um servidor, de Docker, de atualização de dependência, de backup. O apelo do "um comando na sua conta Cloudflare" é que o custo de operação recai sobre uma infraestrutura que já existe e que você talvez já pague. É auto-hospedagem com o atrito reduzido ao mínimo.

Rafael Costa: Mas tem uma tensão aí que apareceu rápido nos comentários. Auto-hospedar no Cloudflare não é a mesma coisa que auto-hospedar na sua própria máquina. Você está trocando "confio no fornecedor do software" por "confio no fornecedor da plataforma". Se o Cloudflare um dia muda alguma coisa, ou resolve que aquele tipo de carga de trabalho não é bem-vinda, o seu agente pessoal quebra — e aí a independência que você achava que tinha era, na prática, emprestada.

Sofia Almeida: E aí alguém levantou o contraponto: MIT permite que o projeto vire produto comercial amanhã, fechado, e ninguém pode reclamar. É o preço de uma licença permissiva. Só que outro comentarista fez a defesa: para um agente que lê seus e-mails e seus documentos, a parte que importa não é tanto a licença do código, é a garantia de ausência de telemetria — e essa, no caso, é verificável na rede. Você pode auditar o tráfego e ver que não sai nada.

Sofia Almeida: Essa é uma forma de confiança que a licença sozinha não compra.

Rafael Costa: Então o Talorys deixa a gente com uma pergunta aberta: o que significa "auto-hospedado" num mundo de plataformas? A resposta de cada comentarista dependia do que ele mais valoriza — controle do código, controle dos dados, ou facilidade de operação. E nunca dá para maximizar os três.

Sofia Almeida: E essa mesma tensão aparece no segundo caso, que é o Bitwarden. O gerenciador de senhas anunciou que vai publicar as apps das lojas — a App Store, a Play Store — como builds sob licença comercial. A versão GPLv3 continua no GitHub, inteira, aberta, como sempre esteve.

Rafael Costa: E aqui a discussão foi bem dividida, e de uma forma que eu acho instrutiva. Um grupo viu isso como uma erosão gradual. O argumento era: a experiência real do usuário é a app da loja. Quase ninguém compila do código-fonte. Então se o binário que 99% das pessoas usam é de licença comercial, a pergunta incômoda é — o projeto ainda é open source na prática, ou só no repositório?

Sofia Almeida: O outro grupo rebateu com um argumento de sustentabilidade. Bitwarden tem um negócio, tem funcionários, tem custos de infraestrutura de sincronização. Publicar builds de loja como licença comercial é uma forma de deixar claro o que é o produto e o que é o projeto comunitário. E ninguém retirou nada: o código GPLv3 está lá.

Sofia Almeida: Um comentarista com experiência em manter projetos open source escreveu mais ou menos o seguinte: "toda discussão sobre licença de projeto com empresa por trás acaba sendo uma discussão sobre quem paga a conta". E a resposta dele era — se você não paga com dinheiro, alguém paga com tempo voluntário, e isso também tem limite.

Rafael Costa: Tem também o detalhe técnico de licenças que vale explicar, porque mudou a percepção de muita gente no fio. A GPLv3 é uma licença copyleft forte: se você distribui o software, tem que distribuir o código-fonte correspondente sob a mesma licença. Uma app de loja publicada sob licença comercial que fosse construída em cima de código GPLv3 seria um problema jurídico real.

Rafael Costa: O fato de o Bitwarden separar — este build é o produto comercial, aquele repositório é o projeto livre — é exatamente o tipo de arrangement que a dual licensing tenta viabilizar. Se eles estão fazendo isso de forma consistente, é lícito. A discordância dos comentaristas era menos jurídica e mais filosófica: é isso que a comunidade esperava quando adotou o produto?

Sofia Almeida: E aí tem a reação dos usuários, que é a incógnita. Tem gente que vai migrar para forks, tem gente que vai pagar licença sem pestanejar porque confia no time, tem gente que vai continuar usando a build da loja sem nunca ler uma licença na vida. Essa última categoria, aliás, é a maior — e alguns comentaristas apontaram que ela é a que não sente nada dessas mudanças, o que, paradoxalmente, é o que dá liberdade para a empresa fazer essas escolhas.

Rafael Costa: E o terceiro caso do bloco é talvez o mais espinhoso: o WallHop. É um serviço gratuito, sem registro, que se posiciona como substituto do 12ft.io — aquela ferramenta que contornava paywalls de notícias. O WallHop é um fork do ladder, que é GPL-3.0. Só que o próprio WallHop ainda não é open source.

Sofia Almeida: E essa combinação é o que fez a discussão esquentar de verdade. Porque a GPL-3.0 tem uma exigência clara: se você distribui o software — e rodar como serviço público é uma zona que a GPL trata diferente da AGPL — você tem obrigações dependendo de como usa. Como o WallHop é um serviço, não um binário distribuído, a conversa jurídica fica tecnicamente no ar.

Sofia Almeida: Mas do ponto de vista da ética da comunidade open source, muita gente achou no mínimo ironia: um projeto nascido de código aberto, se recusando a abrir o próprio.

Rafael Costa: E aí os comentários se dividiram em três acampamentos, mais ou menos. O primeiro: a legalidade do serviço em si. Contornar paywall é contornar um acordo entre leitor e publisher — tem gente que acha que é um direito do leitor de ler o que já está publicado na web aberta, e gente que acha que é simplesmente freeriding no jornalismo. Esse debate é antigo, voltou com o 12ft.io, e não se resolveu agora.

Sofia Almeida: O segundo acampamento era sobre a questão da licença. Comentou gente que lembrou que fork de GPL usado em serviço não dispara automaticamente a obrigação de abrir — a menos que seja AGPL, que foi criada exatamente para fechar essa lacuna de "Software como Serviço". E aí alguém fez a observação afiada: se o ladder quisesse garantir que derivados em serviço abrissem o código, deveria ter sido AGPL.

Sofia Almeida: A escolha da licença no upstream tem consequências que só aparecem anos depois, quando alguém faz exatamente isso.

Rafael Costa: O terceiro acampamento foi o mais pragmático e o mais curiosamente simpático ao WallHop: "olha, o projeto original morreu, o serviço é gratuito, não tem registro, não monetiza seus dados aparentemente — e vocês estão brigando sobre licença?" A resposta do outro lado: "a licença é justamente o contrato social que permite que esse fork exista. Ignorá-la uma vez define o precedente para o próximo fork." Ninguém saiu convencido de ninguém nesse fio, sinceramente.

Sofia Almeida: E o que os três casos têm em comum — Talorys, Bitwarden, WallHop — é exatamente isso: open source não é um estado, é um equilíbrio. Cada projeto escolhe onde colocar a pressão: no usuário, no desenvolvedor, no downstream. E a gente fica com duas coisas para acompanhar: se o WallHop vai abrir o código eventualmente, e como a base de usuários do Bitwarden reage ao modelo de builds comerciais ao longo dos próximos meses.

Rafael Costa: E olha, essa pergunta de "quem controla a ferramenta" não sai do open source — ela segue a gente direto para o próximo bloco, porque envolve IA. E o primeiro item daí é uma tese provocativa que veio do ghuntley: os unikernels estão voltando, e a razão é a IA.

Sofia Almeida: Vou dar o contexto para quem não lembra. Um unikernel é uma imagem de aplicativo que roda sem sistema operacional tradicional — o app e o mínimo de bibliotecas de que ele precisa são compilados juntos numa única imagem de máquina. Sem shell, sem pacotes extras, sem a enorme superfície de coisas rodando por baixo. A tese do ghuntley é que os unikernels sempre foram uma boa ideia que ninguém adotava porque configurar e manter era uma fricção absurda.

Sofia Almeida: E a IA elimina exatamente essa fricção: você descreve o que precisa, o modelo gera a configuração, resolve as dependências. A fricção era o único motivo de não usar.

Rafael Costa: E o segundo argumento dele é o mais forte para mim, e foi o que mais ecoou nos comentários: "o sistema operacional é dívida técnica". Todo aquele software herdado rodando debaixo do seu aplicativo — drivers, serviços, daemons — é código que você não escreveu, não revisa, mas do qual você herda cada CVE. O unikernel ataca isso pela raiz: reduz a superfície de ataque ao mínimo literal. Sem SSH para explorar, sem serviço desnecessário rodando, sem attack surface que você não escolheu.

Sofia Almeida: Os comentários tiveram experiências de primeira mão divididas. Tem gente que rodou unikernels em produção anos atrás e contou que a experiência foi boa até o momento em que precisou depurar algo — aí o fato de não ter ferramentas de sistema virou inferno. Tem gente de áreas muito específicas, tipo appliances de rede, onde unikernels já são padrão e funcionam muito bem. E tem o cético de sempre: "a IA elimina a fricção de criar, mas quem mantém?

Sofia Almeida: Se o modelo gera um unikernel quebrado às 3 da manhã, quem conserta?" Que é uma versão, aliás, de um argumento que a gente vai encontrar de novo em poucos minutos.

Rafael Costa: E a conexão entre esse item e o seguinte é bem direta: se a questão é quem controla a infraestrutura de IA, a grande notícia corporativa do dia é que a Nvidia está negociando a compra da Reflection AI, uma startup de modelos abertos.

Sofia Almeida: E aqui a preocupação que dominou os comentários foi consolidação vertical. Pensa no quadro: a Nvidia faz o hardware que todo mundo usa para treinar e servir modelos. Se ela também passa a controlar uma empresa que produz modelos abertos, ela passa a influenciar o quê, como e em que condições os modelos abertos são feitos — em cima do próprio hardware dela.

Sofia Almeida: Uma comentarista colocou de forma bem clara: "abertura de modelo é um compromisso; quando quem vende as shovels compra a mina, você precisa perguntar qual compromisso sobrevive."

Rafael Costa: O contra-argumento que apareceu: Reflection AI aberta pode receber mais recurso e competir melhor com os modelos fechados gigantes, e consolidar sob uma empresa que historicamente lucra com todo o ecossistema — não com um modelo específico — pode ser menos nocivo do que consolidação por um provedor de nuvem que tem interesse em prender o cliente. Um comentarista fez exatamente esse ponto: a Nvidia ganha se houver muito tokens rodando em GPU dela, independentemente de quem é o modelo.

Rafael Costa: Então o incentivo dela para modelo aberto pode ser genuíno.

Sofia Almeida: Mas aí alguém trouxe o histórico: empresas que compram projetos abertos têm um registro misto de preservar a abertura depois da aquisição. A promessa na assinatura do contrato e a realidade dois anos depois frequentemente divergem. E o que fica como incógnita é exatamente isso: se o negócio avança, e quais compromissos de abertura sobrevivem ao contrato. Enquanto isso, tudo é especulação — e os comentaristas foram honestos em dizer que especulam.

Rafael Costa: E o terceiro item do bloco é o mais filosófico, e para mim o mais importante dos três: programas não tomam decisões. Quando um LLM faz algo errado — nega um pedido, gera um texto preconceituoso, recomenda algo ruim — dizer "a IA decidiu isso" é, no argumento, branqueamento de decisão. A decisão foi de alguém: quem treinou, quem configurou, quem colocou o sistema naquele fluxo de trabalho, quem assinou a compra.

Sofia Almeida: Essa frase provocou uma das discussões mais substantivas do dia. E o que é interessante é que ela foi útil porque conectou dois fios que estavam correndo paralelos: o da consolidação da Nvidia e o dos unikernels. Em todos os casos, a pergunta central é a mesma — quando um sistema automatizado causa dano, em que camada recai a responsabilidade?

Rafael Costa: E aí um comentarista trouxe um exemplo técnico que ilustra bem o argumento — e que está na fonte também: é possível emular um modelo de decisão num LLM restringindo os tokens de opção que ele pode emitir. O Java — desculpa, o Jev — faz exatamente isso: saídas calibradas, onde o conjunto de respostas possíveis é restrito e calibrado.

Rafael Costa: E a observação que fez gente assobiar nos comentários foi: se você consegue restringir as saídas de um modelo, então a "decisão" do modelo é, na verdade, um desenho de produto. Alguém escolheu quais opções existem. Alguém calibrou. Chamou de decisão da IA é dar ao designer um lugar para se esconder.

Sofia Almeida: E isso abriu uma subdiscussão boa: os defensores de uma visão mais distribuída de responsabilidade. O argumento de lá: em sistemas complexos, culpar uma única pessoa também é enganoso. O erro nasce de uma cadeia — o dado de treino, a função de perda, o prompt, a integração, o processo de aprovação. Escolher um culpado é convenientemente simples e frequentemente injusto. Mas o outro lado rebateu: responsabilidade distribuída demais vira responsabilidade de ninguém.

Sofia Almeida: Se ninguém em particular é responsável, então a empresa como entidade jurídica tem que ser — e é isso que regulação de produto sempre exigiu. Não "a IA errou", mas "o fornecedor colocou no mercado um produto que errou".

Rafael Costa: E não houve resolução — a questão que ficou aberta, e é honesto dizer isso, é como a responsabilização vai ser cobrada na prática. O direito ainda está correndo atrás da tecnologia. O que o fio estabeleceu, com bastante força, é o enquadramento: sempre que você ler uma notícia do tipo "a IA decidiu negar o benefício de alguém", a pergunta certa é "quem desenhou o sistema para poder negar". E essa pergunta muda completamente o tipo de conversa.

Sofia Almeida: E há uma elegância engraçada na sequência aqui: o argumento dos unikernels era reduzir o sistema ao mínimo — eliminar a dívida técnica do sistema operacional. E a gente vai agora para um software que é uma masterclass de engenharia cuidadosa: o DuckDB 2.0.

Rafael Costa: Para quem não conhece, o DuckDB é um banco de dados analítico que roda no seu processo, tipo um SQLite para análise de dados. E a versão 2.0 trouxe uma mudança de arquitetura que merece ser explicada, porque é bonita: E/S assíncrona. Antes, o processo de ler dados da rede e o processo de decodificar os dados lidos caminhavam juntos — você esperava o download para decodificar, com o CPU ocioso.

Rafael Costa: Agora existe um grupo de threads dedicado só ao download, que vai puxando dados do S3 enquanto outras threads decodificam o que já chegou. Download e computação sobrepõem-se.

Sofia Almeida: O resultado no benchmark: a leitura de dados no S3 caiu de 18,8 segundos para 7,7 segundos. Mais do que o dobro de velocidade, sem mudar uma linha de como o usuário trabalha. E os comentários sobre isso foram o tipo de comentário que eu gosto: gente analisando por que funciona.

Rafael Costa: O principal insight do fio é sobre onde estava o gargalo. Um comentarista com experiência em sistemas distribuídos escreveu que a maior parte do tempo em consultas a armazenamento de objetos não é CPU, é latência de rede e throughput — e qualquer técnica que sobreponha essas duas coisas tira ganho quase de graça.

Rafael Costa: Outro apontou que isso é uma técnica antiga, usada em bancos de dados há décadas — o mérito do DuckDB foi fazer isso num software que roda embutido, num processo único, onde orquestrar isso é mais difícil do que num cluster.

Sofia Almeida: E é claro que teve ceticismo saudável: "18,8 para 7,7 no benchmark do autor é fácil; como isso se comporta numa carga real, com consultas que ficam 40 minutos, com arquivos pequenos demais para valer a paralelização, com rede instável?" E esse é exatamente o ponto que ficou pendente: medir o ganho em cargas reais além do benchmark. O consenso informal do fio, se é que dá para chamar de consenso, é que a direção é certa, mas o número real vai depender do workload de cada um.

Sofia Almeida: Vários comentaristas disseram que vão medir nos próprios pipelines — o que me parece a atitude certa.

Rafael Costa: E do engenheiro meticuloso que fez o download assíncrono no DuckDB, a gente pula para... comida ultraprocessada. E eu juro que a conexão existe.

Sofia Almeida: Existe, e é sobre rigor metodológico, você vai ver. O estudo é da Virginia Tech, e o desenho é o que o torna interessante. O debate sobre ultraprocessados sempre tropeça na mesma limitação: comida ultraprocessada é diferente de comida não-ultraprocessada em várias dimensões ao mesmo tempo — tem mais açúcar, mais sal, mais gordura, mais aditivos. Então quando se observa diferença de saúde, não se sabe o que causou.

Rafael Costa: E o que o estudo fez foi equiparar os nutrientes. Comidas ultraprocessadas versus não-ultraprocessadas com perfil nutricional pareado — mesma quantidade de macro, basicamente. E mesmo assim encontrou respostas metabólicas e cerebrais distintas entre os dois grupos. Ou seja: o efeito da ultraprocessação não é redutível à composição nutricional que se costuma medir.

Sofia Almeida: Os comentários sobre isso foram um microcosmo do debate maior de nutrição, e vale recorrer os principais. O primeiro grupo: "finalmente um desenho que testa a hipótese certa". O argumento aqui é que a hipótese da matriz alimentar — que a estrutura física do alimento, o processamento em si, importa independentemente dos nutrientes — agora tem evidência experimental direta.

Sofia Almeida: Um comentarista que trabalha em pesquisa clínica elogiou justamente o controle: parear nutrientes é difícil e caro, e a maioria dos estudos observacionais não faz.

Rafael Costa: O segundo grupo fez as perguntas que todo estudo assim merece: quais mecanismos explicam a diferença? É saciedade? É velocidade de ingestão — comida ultraprocessada é mais macia, se come mais rápido, e isso sozinho muda a resposta metabólica? É aditivo específico? O estudo mostra que existe diferença, mas não mostra por quê. E aí tem o terceiro grupo, que apontou o tamanho dos efeitos e a duração: respostas agudas medidas num laboratório não são desfechos de saúde de longo prazo.

Rafael Costa: "Diferença na resposta pós-prandial" não é "doença cardiovascular em 20 anos". E isso é uma ressalva justa.

Sofia Almeida: E o que fica como incógnita é exatamente isso: mecanismo e longo prazo. O que o estudo estabelece é o que ele foi desenhado para estabelecer — que a categoria "ultraprocessado" carrega efeito próprio além dos nutrientes — e isso já é relevante para regulação, rotulagem, orientação alimentar. São os casos em que reguladores e hábitos públicos mudam devagar, e uma evidência assim entra no debate devagar. Como, aliás, tudo que envolve regras sobre onde as pessoas moram. Que é o próximo assunto.

Rafael Costa: E o primeiro item daí é um estudo de política fiscal que inverteu a intuição de muita gente. Reformas fiscais nos Estados Unidos, ao longo das últimas décadas, reduziram impostos sobre proprietários residenciais e transferiram a carga para propriedades comerciais.

Sofia Almeida: E a consequência, segundo o estudo: sobem os custos de moradia. Que parece contraintuitivo — você alivia a carga de quem mora, e a moradia fica mais cara? Mas o mecanismo que os comentaristas explicaram é o seguinte: quando o imposto sobre propriedade comercial sobe, o custo repassa para os aluguéis dos negócios, os negócios repassam para os preços e os salários, e a economia local reorganiza o uso do solo.

Sofia Almeida: Terreno que valia como comércio passa a valer menos como comércio, e a competição pelo uso do solo muda. Nada disso é gratuito — a carga migra, ela não desaparece.

Rafael Costa: E o fio teve uma vibe particular: muitos comentaristas com experiência em avaliação imobiliária e em governo local, contando como esses rebalanceamentos de carga tributária acontecem na prática. O relato mais comum: ninguém quer ser o político que subiu imposto de residência. Então a solução fácil, eleita repeatedly, é "vamos tributar o comércio, que não vota aqui". E décadas dessa lógica acumulam a distorção que o estudo documenta.

Sofia Almeida: Um comentarista fez a conexão com o debate clássico de economia da moradia: se o estoque de moradia é restrito por zoneamento, qualquer custo adicional no sistema vira preço. Então a questão do imposto não pode ser avaliada isolada da questão da oferta. Em cidades onde se pode construir, um imposto deslocado para o comércio é absorvido de forma diferente de onde não se pode construir nada. E aí a incógnita que ficou: se os estados vão revisar esses deslocamentos de carga tributária.

Sofia Almeida: Politicamente é difícil — quem ganhou a redução não quer devolver — mas o estudo dá argumento numérico para quem quiser tentar.

Rafael Costa: E o segundo item daqui é uma ponte perfeita com o que a gente discutiu nos unikernels e no DuckDB: como se faz uma regra complexa compreensível. Só que aqui a regra não é código, é planejamento urbano de São Francisco. O Discretionary Review é um simulador de moradia, e cada site dentro do jogo é uma disputa real — baseado em leis e casos do registro público de SF.

Sofia Almeida: O conceito é ótimo: em São Francisco, muita aprovação de projeto passa por um processo chamado discretionary review, em que vizinhos podem contestar um projeto que, no papel, cumpre o código. O simulador transforma isso em jogo: você vê um lote, vê o projeto proposto, vê as regras, e tem que navegar a disputa — que no mundo real aconteceu, com documento público disponível.

Rafael Costa: E os comentários sobre isso foram sobre o poder pedagógico da simulação. Um comentarista que participou de processos reais de audiência de zoneamento escreveu que jogar o simulador ensinou mais sobre o processo do que anos de cobertura jornalística — porque no jogo você é obrigado a considerar os interesses de todos os lados: o desenvolvedor, o vizinho, o planejador, o morador que quer morar ali e não consegue.

Rafael Costa: Outro fez a conexão direta com a crise de moradia: "quando você gamifica o processo, você percebe o quanto dele é fricção deliberada, não engenharia".

Sofia Almeida: E tem um comentarista que fez uma observação que conecta com o DuckDB de um jeito que eu achei ótima: o melhor simulador é aquele que não esconde a regra — no DuckDB você pode ver o plano de execução, no jogo você pode ver a lei e o caso do registro. Transparência da regra é o que permite aprender com o sistema. E política de moradia costuma ser o oposto: regra espalhada, dependente de discricionariedade, invisível até você ser parte de uma disputa.

Rafael Costa: E isso nos leva quase naturalmente para o próximo bloco, que é sobre o elo mais fraco — mas não o que você imagina. A grande brecha de dados do CPR, na Dinamarca, que expôs dados de uma população inteira, aconteceu por causa de uma senha: '123456'.

Sofia Almeida: E a reação coletiva do fio, sinceramente, foi um suspiro coletivo. Um comentarista resumiu: "passamos anos discutindo criptografia pós-quântica, e a maior brecha da história recente do país teve a senha mais batida do mundo". E é isso. O fator de falha não foi exótico. Foi o básico das credenciais.

Rafael Costa: E os comentários se organizaram em torno de duas perguntas. Primeira: como isso é sequer possível em 2024? Uma instituição com dados dessa sensibilidade usando senha simples, aparentemente sem MFA, sem detecção de credencial vazada, sem rate limiting que bloqueasse tentativa massiva. A resposta que emergiu dos relatos de quem trabalha com segurança institucional: sistemas legados. Sistemas herdados de outra década, que ninguém ousa modernizar, com credenciais que ninguém audita.

Rafael Costa: O ponto fraco raramente é o sistema novo; é o velho que continua ligado.

Sofia Almeida: E a segunda pergunta é a mais difícil: o que muda depois? Um comentarista fez a observação que achou mais justa — que a resposta institucional típica a uma brecha assim é mais treinamento de conscientização de segurança, que é sabidamente pouco eficaz, quando o que funciona é tirar a decisão do usuário: MFA obrigatório, detecção de senha vazada no cadastro, federação de identidade.

Sofia Almeida: Você não educa o usuário a escolher senha melhor; você constrói um sistema onde uma senha ruim não basta para causar estrago.

Rafael Costa: E a pergunta que fica em aberto é exatamente quais controles as instituições dinamarquesas — e outras, porque isso não é exclusividade delas — vão adotar de verdade. Histórico sugere: auditoria, reunião, relatório, e voltamos a trabalhar como antes até a próxima. Mas essa brecha é do tipo que pode forçar mudança regulatória, pelo tamanho. Vamos ver.

Sofia Almeida: E se a lição do item anterior é que erros evitáveis são os mais comuns, o último bloco do episódio é um conjunto de coisas que são o oposto: esforços incomuns, cuidadosos, às vezes esquisitos. E o mais sério deles é o da PopVax.

Rafael Costa: A PopVax é uma empresa que desenvolve a PVX-001, uma vacina de COVID de ampla cobertura — ou seja, que visa proteger contra uma variedade de variantes, não só a da estação — e que é estável a 2 a 8 graus, a temperatura de uma geladeira comum. E eles acabaram de dosar o primeiro participante em fase I. E o detalhe que faz o projeto entrar numa lista como esta: o projeto vai ser open source ao concluir.

Sofia Almeida: E os comentários sobre isso foram predominantemente de celebração com ceticismo doseado, o que me parece a combinação certa. O lado da celebração: o gargalo global de vacinas não é só ciência, é logística. Uma vacina de mRNA que precisa de ultracongelador é inviável em muita parte do mundo; uma que fica estável em geladeira muda a conta inteira de distribuição. E o compromisso de open source, se cumprido, significa que o conhecimento não fica preso atrás de patente exclusiva.

Rafael Costa: O ceticismo doseado: fase I é fase I. É segurança e dose em número pequeno de participantes. A ampla maioria das vacinas candidatas que entram em fase I não chega ao fim do caminho. Então "resultados da fase I" é o que se acompanha, sem antecipar vitória. Mas o desenho é promissor e a intenção de abertura é rara e valiosa. Um comentarista colocou assim: "ciência aberta não é só um ideal; em vacinas, é uma questão de acesso global". E acho que é isso.

Sofia Almeida: E do extremo sério para o extremo esquisito, no melhor sentido: a Lightbulb Computer. É literalmente uma lâmpada com um projetor e visão computarizada embutidos. A ideia é que qualquer superfície bem iluminada vira interface: o projetor projeta, a câmera lê seus gestos, e o teto da sua sala vira uma tela interativa.

Rafael Costa: E a demo é real — tem vídeo, funciona — mas os comentários não pouparam a observação de que o hardware atual é voluminoso. Ou seja: não é exatamente uma bombilha ainda, é mais um objeto pendurado no teto com essa função. E a discussão no fio foi entre dois grupos: os que acham que é um caminho de produto legítimo — a interface ambiental, computação onipresente sem óculos nem tela — e os que acham que é uma solução procurando problema.

Rafael Costa: Um comentarista fez um contraponto histórico: "toda tecnologia de interface nova nasce voluminosa e esquisita. O primeiro mouse era uma caixa de madeira com duas rodas". O que é verdade, embora, como outro apontou, "voluminoso e esquisito" descreva também muita coisa que nunca foi a lugar nenhum.

Sofia Almeida: E o que acompanhar aqui é se a demo encolhe. Se a física e a engenharia permitirem reduzir ao formato de lâmpada de verdade, a promessa é interessante. Se não, fica como demo de conferência, bonita e irrelevante. A história decide.

Rafael Costa: E a gente fecha com dois itens que são quase um curso de cultura técnica em miniatura. O primeiro é sobre Donald Knuth, que segue enviando cheques de recompensa para quem encontra erros nos seus livros. E a parte que fez o fio se encantar: hoje, os cheques são fictícios — são certificados do Banco de San Serriffe, um país fictício, com valores como 2,56 dólares, que é um trocadilho binário — 2 na potência 8.

Rafael Costa: Os cheques reais foram descontinuados porque, bem, as pessoas não descontavam, emolduravam — e as fraudes de cheques falsos ficaram um problema.

Sofia Almeida: E os comentários sobre isso foram quase unanimemente afetuosos. Tem gente que tem um certificado emoldurado na parede e contou a história de como achou o erro. E tem a observação mais profunda do fio, na minha opinião: o mecanismo do Knuth é uma forma de engenharia de qualidade — ele paga para que os leitores ativos encontrem erros que ele e seus revisores não acharam.

Sofia Almeida: É crowdsourcing de revisão, décadas antes de o termo existir, com uma recompensa que vale mais simbólica do que monetária, o que é exatamente o ponto. Um erro encontrado nos livros do Knuth é uma honra, não um trabalho.

Rafael Costa: E o último item é uma correção aparente: o macOS deixou de estar no registro de certificação UNIX do Open Group? Não. E essa foi a resolução da história. O macOS continua certificado UNIX 03. A ausência do registro no site do Open Group parece ser um problema de renderização do site — um bug de frontend, essencialmente.

Sofia Almeida: E a discussão em torno disso foi deliciosamente meta: um grupo de pessoas altamente técnicas, debatendo horas se o sistema operacional mais difundido do mundo para desenvolvimento perdeu uma certificação de 30 anos, para concluir que era um bug de CSS ou equivalente. Tem comentarista que apontou a ironia: "a página de certificação de conformidade a padrões não está em conformidade com os padrões web".

Sofia Almeida: Outro defendeu o Open Group: registro de certificação é um sistema antigo, pouco financiado, e o fato de ter sobrevivido décadas já é mérito.

Rafael Costa: E o que a história ilustra, para fechar o episódio num tema que percorreu tudo: a diferença entre o que um sistema aparenta e o que ele é. O macOS parecia ter perdido a certificação e não perdeu. Um LLM parece "decidir" e não decide. Um unikernel parece simples e é um esforço considerável. Uma senha '123456' parece inofensiva e derrubou uma base de dados nacional. A superfície mente — e a única antídoto que a gente viu hoje, em todos os fios, foi a mesma: ir ver embaixo.

Sofia Almeida: E era exatamente isso que eu ia dizer para fechar, mas você disse melhor. Fica a nossa agradecimento a quem acompanhou até aqui — discutimos open source sob pressão, com o Talorys, o Bitwarden e o WallHop; quem controla a infraestrutura de IA, com os unikernels, a Nvidia e a Reflection AI, e quem responde pelas decisões; o DuckDB 2.

Sofia Almeida: 0 e a leitura assíncrona do S3; comida ultraprocessada além dos nutrientes; política fiscal e o simulador de moradia de São Francisco; a senha '123456'; e fechamos com a PopVax, a Lightbulb Computer, o Knuth e o certificado UNIX do macOS.

Rafael Costa: E ficam as coisas para acompanhar: se o WallHop abre o código, como o Bitwarden navega a reação, se o negócio da Nvidia avança, os resultados da fase I da PopVax, e se a Lightbulb encolhe. Eu sou Rafael Costa.

Sofia Almeida: E eu Sofia Almeida. Até o próximo episódio — e continuem indo ver embaixo.