
0824 | Qwen 3.8 27B faz engenharia reversa em 30min; JIT em 5μs
Show notes
Neste episódio, os apresentadores comentam as discussões mais interessantes do Hacker News: um usuário relata ter dado ao modelo Qwen 3.8 27B um trabalho de engenharia reversa concluído em trinta minutos, com o debate girando em torno do desempenho de hardware e da falta de detalhes sobre o ambiente de teste. Em seguida, debatem uma técnica de compilação just-in-time capaz de rodar código em cinco microssegundos, mas esbarram na polêmica sobre a sustentabilidade do projeto pgrust. Há também a an
Linha do tempo
- 00:00:00 Abertura
- 00:00:40 Qwen 3.8 27B conclui engenharia reversa em trinta minutos
- 00:01:36 Compilação just-in-time em cinco microssegundos e o futuro do pgrust
- 00:02:39 Malware em firmware de unidades multimídia automotivas e o argumento da botnet
- 00:03:46 Wi-Fi 8 abandona a corrida pela velocidade e foca em estabilidade
- 00:04:36 O fim de um Athlon e a fragilidade do silício exposto
- 00:06:48 Medalha da Maratona de Sydney estampa o estádio de Munique por engano
Links relacionados
- I gave Qwen 3.8 27B a reverse-engineering job and it finished in 30 minutes - Bri Hacker News Campaign Feed
- JIT Compiling Code in 5μs - Bri Hacker News Campaign Feed
- Malware infects Android-based automotive head unit firmware - Bri Hacker News Campaign Feed
- Wi-Fi 8 is the first wireless upgrade in years that isn't chasing speed - Bri Hacker News Campaign Feed
- The End of an Athlon - Bri Hacker News Campaign Feed
- Sydney Marathon medal mistakenly depicts Munich stadium - Bri Hacker News Campaign Feed
Este episódio é produzido pela Bri. O Bri usa tecnologia avançada de IA para transformar os feeds importantes para você em podcasts feitos para ouvir. Fale conosco em hi@bri.so.
Transcript
Sofia Almeida: Bem-vindos ao Hacker News diário, na Bri Radio. Eu sou a Sofia Almeida, e o meu colega aqui é o Rafael Costa.
Rafael Costa: E hoje temos um programa forte: o Qwen 3.8 27B a fazer trabalho de engenharia reversa em meia hora, compilação de código em apenas cinco microssegundos, e malware a infetar o firmware de sistemas automóveis.
Sofia Almeida: Falaremos também do Wi-Fi 8, da primeira atualização sem fios em anos que não anda atrás de velocidade, e do fim de um artigo sobre processadores Athlon.
Rafael Costa: E ainda a maratona de Sidney com uma medalha que mostra o estádio errado. Vamos a isso.
Rafael Costa: Aqui vai um caso real curioso que circulou no Hacker News: alguém entregou ao Qwen 3.8 27B um trabalho de engenharia reversa, e o modelo terminou a tarefa em trinta minutos.
Sofia Almeida: O desempenho impressiona ainda mais pelo hardware. Um leitor da comunidade, que roda um sistema com duas placas gráficas Arc Pro B70, relatou que consegue em torno de vinte e dois tokens por segundo nessa configuração — não é ótimo, mas também não é ruim, e pelo menos usa menos quantização.
Rafael Costa: Os bastidores técnicos, porém, continuam em aberto. Esse mesmo usuário disse que queria saber quais ferramentas o modelo usou e como o ambiente foi montado para o teste — o artigo menciona que ele já viu a pessoa por trás do teste, que usa o nome de Sol, invocar ferramentas em outro contexto, mas o detalhe específico desse trabalho de engenharia reversa não foi divulgado no material que vazou.
Rafael Costa: No Hacker News tem uma história, da autoria do malisper, sobre compilação just-in-time rápida o bastante pra rodar código em cinco microssegundos. Um usuário comentou que o pgrust, um projeto profundamente integrado à base de código, soa muito interessante, mas, por causa dessas mudanças profundas, não existe um caminho viável para integrá-lo ao código principal — a pergunta levantada foi se o objetivo final é tornar o projeto robusto o bastante pra conseguir adoção ampla por conta própria.
Sofia Almeida: Outro comentarista respondeu direto a esse entusiasmo: será que é realmente interessante? Para ele, o pgrust foi essencialmente "vibe-coded" por pessoas — construído de forma improvisada, sem a profundidade de engenharia que se esperaria de um projeto com adoção séria. É uma resposta bem mais cética, e ela direciona o debate para a sustentabilidade do projeto, não para a velocidade da compilação em si.
Rafael Costa: Uma discussão no Hacker News trouxe à tona um alerta da Kaspersky sobre um malware que infecta o firmware de unidades multimídia automotivas baseadas em Android. A história aparece na newsletter de segurança com o título "Malware infects Android-based automotive head unit firmware".
Sofia Almeida: E o ponto mais interessante veio de um comentarista chamando Retr0id. Como uma unidade multimídia normalmente não guarda nada de valor para um atacante, escreveu ele, um dos cenários mais prováveis com malware Android "clássico" é infectar o aparelho para recrutá-lo numa botnet.
Rafael Costa: Mas ele acrescentou um detalhe que muda a leitura: as pessoas costumam parear essas unidades com seus celulares. Então ele imagina uma versão futura desse tipo de malware se propagando lateralmente — saindo do rádio do carro e alcançando o telefone pareado.
Sofia Almeida: Exato. Ou seja, hoje o risco maior é o aparelho em si ser mais um nó numa rede de dispositivos comprometidos. O vetor de ataque mais preocupante fica para o futuro, quando essa infecção poderia saltar para o celular conectado ao veículo.
Rafael Costa: A Wi-Fi 8 é a primeira grande atualização sem fio em anos que não está atrás de velocidade de download. Em vez de perseguir números cada vez maiores, ela se concentra em estabilidade, alcance e menos congestionamento nas redes domésticas reais.
Sofia Almeida: E isso bate com a experiência de muita gente. Um usuário no Hacker News comentou exatamente isso: nas áreas onde ele mora, a velocidade máxima fica em torno de cento e cinquenta megabytes por segundo, então uma faixa de cinco ou seis gigabits por segundo já seria um teto perfeitamente suficiente para ele.
Rafael Costa: Enquanto velocidade já não é o gargalo para ele, continuam sendo dois problemas concretos: alcance e congestionamento. É para isso que a Wi-Fi 8 está olhando — resolver justamente os pontos que frustram quem vive em redes domésticas cheias de aparelhos e paredes.
Sofia Almeida: Ainda no mundo do hardware antigo, o OS/2 Museum publicou em dez de agosto de vinte e vinte e seis, por Michal Necasek, o artigo "The End of an Athlon". Ele nasceu de uma pesquisa sobre bits de CPUID estranhos e mal documentados nos Athlon MP e XP, que obrigou Necasek a trocar muitos CPUs. E foi numa dessas trocas que aconteceu algo curioso: ao remover o dissipador de calor de um Athlon XP, o processador apareceu com um pedaço de silício faltando, porque o dissipador ficou com a peça do CPU colada.
Rafael Costa: O que chama atenção é que o CPU continuou funcionando normalmente mesmo depois de perder um bom pedaço, e a remoção ainda não exigiu força excessiva, embora muitos dissipadores tendam a ficar bem presos ao chip. Pela forma do pedaço extraído, Necasek suspeita que havia uma microtrinca longa e reta no silício que não afetava visivelmente a operação; quando a força foi aplicada, ela cedeu e um grande pedaço se soltou de uma vez.
Sofia Almeida: Na foto de perto dá pra ver isso: o lado direito da falha é bem reto, enquanto o lado esquerdo mostra as marcas típicas de fratura. E esse caso conecta com um problema mais amplo. Por volta do ano dois mil, Intel e AMD usavam empacotamento flip-chip PGA em busca de melhor resfriamento, porque o TDP dos processadores passou rápido de cinquenta watts e se aproximou de setenta a oitenta watts. As duas, especialmente a Intel, abandonaram esse tipo de empacotamento relativamente rápido, deixando o silício exposto.
Rafael Costa: A Intel usou flip-chip só em alguns modelos de Pentium III e depois migrou para CPUs com tampa na linha Pentium 4 e nos Pentium III-S; já a AMD usou flip-chip nos Athlons PGA, mas não nos Opterons. O problema é que esse silício exposto era frágil demais e exigia que os instaladores montassem os dissipadores com muito cuidado, já que pressão desigual podia trincar o silício. Por isso muitos CPUs vintage com flip-chip aparecem com os cantos lascados, o que normalmente não afeta o funcionamento, mas mostra como esse empacotamento era delicado na prática.
Rafael Costa: O medalha da Maratona de Sydney terminou estampado com o estádio errado:em vez do estádio local, a arte levou o estádio de Munique, um engano que o comentário mais citado no Hacker News atribui à facilidade do deslize — existe um grupo de estádios chamados Allianz Stadium pelo mundo.
Sofia Almeida: O site da Allianz lista sete deles hoje. E havia oito quando o medalha foi desenhado, porque o Palmeiras não renovou o contrato de naming rights, e o Allianz Parque deixou de usar esse nome — só por isso a conta caiu por um. Essa proximidade de nomes entre o estádio de Sydney e o de Munique torna o engano quase inevitável, e foi assim que a discussão registrou o erro.
Sofia Almeida: E o Qwen 3.8 27B fechou a engenharia reversa em meia hora — os comentários pedindo detalhes do harness ficaram para trás. Também ficou a pergunta se o pgrust, com compilação JIT em cinco microssegundos, um dia consegue ir para o upstream.
Rafael Costa: Exatamente. E por hoje é isso — obrigado por ouvir a gente. Até a próxima!