Relembrando os tempos dourados, deixo aqui no Viva O Linux, Um artigo onde veremos como libertar o seu AirPods para utilizá-lo na plataforma Linux com todos os recursos diferenciados deste hardware.

Quando você conecta um AirPods a um desktop Linux, normalmente ele funciona como “um fone Bluetooth qualquer”: áudio ok, mas boa parte dos recursos premium (ANC/Transparency, detecção de ouvido, bateria confiável, ajustes finos, etc.) fica presa ao ecossistema Apple. O LibrePods nasceu justamente para “libertar” esses recursos.

O que é o LibrePods

LibrePods é um projeto open source que desbloqueia recursos avançados dos AirPods em dispositivos não-Apple, trazendo de volta modos de ruído, transparência/adaptive, detecção de ouvido, status de bateria, modo “hearing aid”, personalizações e mais recursos que a Apple costuma expor só quando o fone “acha” que está conectado a iOS/macOS.

Para que serve (no Linux)

Na prática, no Linux ele serve como um painel/controle para o seu AirPods, com um app nativo (GUI) que expõe funções que normalmente não aparecem no stack Bluetooth padrão. O repositório mantém um app Linux dedicado e releases específicos.

Como ele funciona (visão técnica, sem magia)

O “pulo do gato” do LibrePods é que ele implementa (via engenharia reversa) partes do protocolo proprietário usado pelos AirPods para negociar recursos com dispositivos Apple. Em várias funções, a liberação depende de identificação do dispositivo host (ex.: fabricante/vendor), então o projeto também documenta mecanismos para o host “se apresentar” de forma compatível e o AirPods liberar telemetria e controles avançados. The Verge+1

Em outras palavras: não é “tweak de UI”; é protocolo + controle de estados (e, em alguns cenários, identificação do host) para acessar recursos que já existem no hardware do AirPods.

Vantagens para usuárias Linux

• Você usa o que pagou: ANC/Transparency/Adaptive e outros controles deixam de ficar “reféns” do iPhone/iPad/Mac.
• Status de bateria mais útil (incluindo case/earbuds, dependendo do modelo/estado do suporte).
• Experiência mais integrada: o projeto menciona melhorias de integração (ex.: expor bateria e atalhos de controle), e existe um app Linux com funcionalidades centrais.
• FOSS e auditável: por ser open source, dá para inspecionar/acompanhar evolução e limitar “apps caixa-preta” que só fazem polling genérico.

Observação importante de maturidade: o README do projeto sinaliza que o app Linux tem/teve uma fase “versão antiga” e que há trabalho em uma nova versão, então espere evolução rápida e possíveis arestas dependendo do seu modelo de AirPods e distro.

Requisitos no Linux

1) Hardware/stack Bluetooth

• Adaptador Bluetooth funcional no PC (interno ou dongle).
• BlueZ e serviços de Bluetooth ativos (padrão na maioria das distros desktop).

2) AirPods compatíveis

O projeto lista compatibilidades por modelo (alguns com suporte completo, outros parcial). Em geral, modelos mais recentes tendem a receber o “suporte cheio” primeiro.

Status	Device	Features
	AirPods Pro (2nd Gen)	Fully supported and tested
	AirPods Pro (3rd Gen)	Fully supported (except heartrate monitoring)
	AirPods Max	Fully supported (client shows unsupported features)
	Other AirPods models	Basic features (battery status, ear detection) should work

Dependências

Devemos garantir que o sistema de gerenciamento de audio e bluethooth esteja funcionando corretamento.

Qt6 packages

# For Arch Linux / EndeavourOS
sudo pacman -S qt6-base qt6-connectivity qt6-multimedia-ffmpeg qt6-multimedia

# For Debian
sudo apt-get install qt6-base-dev qt6-declarative-dev qt6-connectivity-dev qt6-multimedia-dev \
     qml6-module-qtquick-controls qml6-module-qtqml-workerscript qml6-module-qtquick-templates \
     qml6-module-qtquick-window qml6-module-qtquick-layouts

 # For Fedora
 sudo dnf install qt6-qtbase-devel qt6-qtconnectivity-devel \
     qt6-qtmultimedia-devel qt6-qtdeclarative-devel

 # For openSUSE
 sudo zypper install patterns-kde-devel_qt6

openSSL

# On Arch Linux / EndevaourOS, these are included in the OpenSSL package, so you might already have them installed.
sudo pacman -S openssl

# For Debian / Ubuntu
sudo apt-get install libssl-dev

# For Fedora
sudo dnf install openssl-devel

# For openSUSE
sudo zypper install openssl-devel

Libpulse e cmake

# On Arch Linux / EndevaourOS, these are included in the libpulse package, so you might already have them installed.
sudo pacman -S libpulse

# For Debian / Ubuntu
sudo apt-get install libpulse-dev

# For Fedora
sudo dnf install pulseaudio-libs-devel

# For openSUSE
sudo zypper install pulseaudio-qt-devel cmake libpulse-devel

Download, compilação e instalação.

Agora com todos requisitos instalado e cofigurado, efetue do download dos fontes com o comando git clone.

git clone https://github.com/kavishdevar/librepods

Após o download entra na pasta linux dentro da pasta librepods recém criada.

cd librepods/linux

Ao entrar na pasta, devemos criar a pasta build e os comandos cmake e make para efetuas a compilação.

mkdir build
cd build
cmake ..
make -j $(nproc)

Se tudo funcionou corretamente, teremos o binario librepods na pasta pronto para ser executado. Então basta digitar ./librepods e teremos uma tela como na figura a baixo e pronto! Boa liberdade.

Mais informações na página oficial do projeto. https://github.com/kavishdevar/librepods/

Introdução

O Intel® Linux NPU Driver vem se consolidando como a base de software para explorar o potencial das NPUs embarcadas nos Intel Core Ultra (Meteor Lake, Arrow Lake, Lunar Lake e afins). A versão 1.24.0 marcou um ponto importante dessa evolução: além de atualizar firmware e componentes internos, trouxe melhorias de desempenho, estabilidade e segurança que começaram a aparecer em tutoriais e notícias da comunidade Linux. Nessa release, a Intel atualizou o Level Zero, o compilador e o firmware, além de fazer ajustes no próprio utilitário de testes da UMD, sempre mantendo a compatibilidade com o driver de kernel “intel_vpu” (que ainda carrega o nome histórico de VPU, apesar do hardware ser uma NPU).

A versão 1.26.0, lançada em 26 novembro de 2025, chega como continuidade desse trabalho, mas já com um ecossistema bem mais maduro em torno do conceito de “AI PC”. Segundo o LinuxCompatible, o 1.26.0 foi validado em várias combinações de Intel Core Ultra + Ubuntu (22.04/24.04/24.10/25.04) com kernels recentes e firmwares específicos, mantendo o alinhamento com Level Zero 1.24.2, OpenVINO 2025.3 e um compilador NPU atualizado (npu_ud_2025_44_rc1). Isso significa que, ao instalar o linux-npu-driver a partir do código-fonte ou via pacotes, você está plugando sua máquina em uma stack validada para workloads de IA eficientes em energia, pensada para executar redes neurais diretamente na NPU sem sobrecarregar CPU ou GPU.

Stack de software do Intel® NPU Driver

O repositório intel/linux-npu-driver hospeda o driver de espaço de usuário para o dispositivo Intel® NPU, um acelerador de inferência embarcado nos Intel Core Ultra. No Linux, a pilha é dividida em duas grandes camadas:

1. Driver de kernel – o módulo intel_vpu (IVPU) já está integrado ao kernel e é responsável por expor o dispositivo como /dev/accel/accel0 (ou similar), gerenciar o firmware e integrar com a infraestrutura de DRM/accel.
2. Stack de user-space – é o foco deste projeto: bibliotecas de user mode driver (UMD), implementações de oneAPI Level Zero para a NPU, compilador de modelos (NPU compiler) e ferramentas de validação, como o npu-umd-test.

Do ponto de vista das aplicações, você normalmente não conversa diretamente com o driver: quem faz isso é o framework de IA. Ferramentas como o OpenVINO usam o plugin “NPU” e, por baixo dos panos, dependem dessa stack para compilar o modelo (via compilador NPU) e enviar comandos ao hardware usando Level Zero. É aqui que o driver entra como peça crítica: se a combinação driver + firmware + compilador + Level Zero não estiver correta, a aplicação não enxerga a NPU ou sofre quedas de desempenho. Releases como 1.24.0 e 1.26.0 alinham todas essas versões, garantindo que quando você compilar um modelo para NPU, o binário gerado seja compatível com o firmware embarcado e com a versão do driver instalada no sistema.

Compilando e instalando o linux-npu-driver a partir do código-fonte

Abaixo está o fluxo básico para compilar e instalar o driver a partir do repositório oficial:

git clone https://github.com/intel/linux-npu-driver
cd linux-npu-driver
git submodule update --init --recursive

cmake -B build -S . \
  -DENABLE_NPU_COMPILER_BUILD=ON \
  -DCMAKE_CXX_FLAGS="-fcf-protection=none" \
  -DCMAKE_C_FLAGS="-fcf-protection=none"

cmake --build build --parallel $(nproc)
sudo cmake --install build

Comentando passo a passo:

1. git clone
   Baixa o código-fonte da versão atual do driver, incluindo UMD, compilador, firmware e ferramentas.
2. git submodule update --init --recursive
   O projeto depende de vários submódulos (por exemplo, componentes como vpux_elf e partes do compilador). Esse comando garante que todo o código necessário seja trazido junto, o que é essencial para builds offline e para empacotamento em distribuições.
3. Comando cmake -B build -S . ...
   • Cria um diretório de build fora da árvore de fontes (build).
   • Ativa a construção do compilador NPU (ENABLE_NPU_COMPILER_BUILD=ON).
   • Desabilita o -fcf-protection nas flags C/C++, o que é útil em toolchains que não reconhecem essa opção (como alguns GCC empacotados em distros específicas).
   • Nessa etapa, o CMake verifica dependências, configura caminhos, escolhe opções de compilação e gera os arquivos de projeto/Makefiles.
4. cmake --build build --parallel $(nproc)
   Compila o projeto usando todos os núcleos disponíveis. Isso gera as bibliotecas de UMD, o compilador, os binários de teste e demais artefatos necessários.
5. sudo cmake --install build
   Instala os artefatos gerados nos prefixos configurados (tipicamente /usr ou /usr/local), registrando as libs, o compilador e as ferramentas como npu-umd-test no sistema.

Em ambientes de produção (ou empacotamento para distro), é comum encapsular esse fluxo em um spec de RPM, .deb ou snap, como fez a Canonical no intel-npu-driver snap.

Validando o driver com o comando npu-umd-test

Depois de instalar o driver, é fundamental validar se a NPU está realmente funcional. Para isso existe a aplicação de teste do user mode driver, hoje chamada npu-umd-test (o prefixo antigo era vpu-umd-test, renomeado nas versões mais recentes do driver).GitHub+1

Nos pacotes em snap (intel-npu-driver), a Canonical documenta um fluxo bem claro que vale como referência também para instalações manuais:GitHub

Garantir permissões de acesso ao dispositivo
A NPU costuma aparecer como /dev/accel/accel0 associado ao módulo intel_vpu. Antes de rodar o teste sem ser root, o usuário precisa estar no grupo render e o nó de dispositivo precisa ter permissões adequadas:

sudo usermod -a -G render $USER   # depois faça logout/login
sudo chown root:render /dev/accel/accel0
sudo chmod g+rw /dev/accel/accel0

Ver o help e opções disponíveis

Em instalações via snap, o binário é exposto como app do snap:

intel-npu-driver.npu-umd-test --help

Em uma instalação “pura” a partir do código-fonte, o binário normalmente estará em um diretório padrão de executáveis (por exemplo /usr/bin/npu-umd-test), então:

npu-umd-test --help

Executar a bateria de testes
O npu-umd-test roda um conjunto de testes que exercitam o Level Zero da NPU, o compilador e o fluxo de envio de comandos ao hardware. Na própria documentação do snap, eles mostram resultados típicos como “200/209 testes passando” em diversas combinações de kernel/Ubuntu, com alguns testes marcados como “skipped” por dependências opcionais (GPU, DMA heap, métricas de uso, etc.).

Entender o papel do npu-umd-test no seu fluxo

• Se todos (ou quase todos) os testes passam, significa que driver de kernel, firmware, UMD, Level Zero e compilador estão conversando corretamente.
• Se vários testes falham, é um indicativo de versão incompatível de firmware, kernel sem suporte ou configuração incorreta de permissões/dispositivos.
• Em ambientes de empacotamento (RPM, DEB, snap, flatpak), é comum usar o npu-umd-test como smoke test automatizado de pós-instalação.

Em resumo, o npu-umd-test é o seu “check-up” oficial da NPU: se ele está feliz, as chances de seu pipeline OpenVINO ou outro framework de IA rodar liso na NPU são muito maiores.

É com grande alegria que anuncio hoje o lançamento do DiraQ, uma distribuição Linux portátil baseada no openSUSE 15.6 — projetada especialmente para experimentação, ensino e pesquisa em computação quântica. O DiraQ roda diretamente de um pendrive, sem necessidade de modificar o disco rígido da máquina.

Por que o DiraQ existe?

A ideia do projeto nasceu da constatação de que muitos estudantes, pesquisadores e entusiastas de computação quântica esbarram em barreiras de infraestrutura: configurar ambientes complexos, instalar bibliotecas específicas, lidar com incompatibilidades etc. O DiraQ vem como uma alternativa prática e “plug-and-play”, permitindo que você inicie um ambiente completo para experimentação quântica em qualquer computador compatível, com apenas um pendrive.

Além disso, o DiraQ está intimamente ligado ao projeto LEONTI — o primeiro computador quântico fotônico de código aberto do Brasil atuando como seu sistema operacional oficial. Isso significa que o DiraQ vai além de ser “apenas mais uma distribuição” ele funciona como a ponte entre o hardware quântico fotônico e o mundo clássico de software.

Principais destaques

• Ambiente pré-configurado com bibliotecas e frameworks quânticos de ponta, como Cirq, PennyLane e Strawberry Fields.
• Robusto e portátil: basta gravar a imagem no pendrive e inicializar qualquer máquina compatível, sem tocar no restante do sistema operacional instalado.
• No futuro terá integração com API de alto nível para comunicação entre o DiraQ/LEONTI e aplicações externas, seja via Wi-Fi ou conexões físicas como USB.
• Licença aberta e espírito colaborativo: o projeto é pensado para que a comunidade participe, contribua e construa junto esse ecossistema.

Como começar a usar o DiraQ

1. Baixe a imagem ISO do DiraQ (versão atual: 1.0.0) — a página oficial oferece links diretos para download. openSUSE
2. Grave no pendrive (mínimo recomendado: 4 GB) usando ferramentas como Etcher (Windows/macOS) ou comandos como dd no Linux. openSUSE+1
3. Inicialize o computador pelo pendrive — em alguns casos pode ser necessário ajustar a ordem de boot ou ativar suporte USB no BIOS/UEFI. openSUSE+1
4. Explore o ambiente, execute simulações, escreva seus próprios circuitos ou integre com projetos quânticos.

Convite à comunidade: participe, colabore e compartilhe

O DiraQ foi idealizado por Wilson Fonseca e Alessandro “Cabelo” de Oliveira Faria, mas para que ele alcance seu verdadeiro potencial, é essencial que a comunidade científica, entusiastas e desenvolvedores façam parte.

Se você domina Python, quiser testar frameworks quânticos ou ajudar a documentar, tu tens um lugar garantido nesse projeto. Queremos tornar computação quântica mais acessível, e juntos podemos construir uma plataforma brasileira, aberta e robusta.

Você já ouviu falar em “cochilo com cafeína”? À primeira vista, pode parecer uma contradição: tomar café para dormir? No entanto, pesquisas recentes sugerem que essa combinação pode trazer benefícios reais à nossa atenção, clareza mental e combate à fadiga.

O mecanismo por trás da fadiga

Durante o dia, nosso cérebro acumula uma substância chamada adenosina, que se liga a receptores e induz a sensação de sono. Para nos mantermos alertas, a cafeína atua como um antagonista da adenosina: ela “ocupou” os receptores que a adenosina usaria, impedindo que ela cause aquele efeito de lentidão cerebral.

Já o cochilo tem um efeito restaurador, porque ele ajuda a “limpar” parte da adenosina acumulada. Ou seja: combinar café e soneca pode atacar a fadiga por dois caminhos complementares.

Por que a combinação pode funcionar?

A magia ocorre no timing: a cafeína leva cerca de 20 a 30 minutos para fazer efeito justamente o intervalo ideal de um cochilo “curto”. Se você dormir mais que esse tempo, pode entrar em sono profundo e acordar confuso. Portanto, a ideia é: tomar café e logo em seguida fazer um breve cochilo, para maximizar o alerta sem sobrecarga.

Pesquisas piloto já demonstraram que essa prática (200 mg de cafeína seguida de 30 minutos de soneca) pode:

• Reduzir a sensação de fadiga
• Melhorar o desempenho cognitivo

Limitações e precauções

Apesar do potencial, ainda há muitos “poréns”:

• Os estudos existentes são relativamente pequenos e feitos em ambientes controlados, com adultos jovens saudáveis, não abrangendo diferentes faixas etárias ou pessoas com distúrbios do sono.
• Há variações individuais: algumas pessoas têm maior sensibilidade à cafeína ou têm mais ou menos propensão a cochilar bem.
• A prática não substitui uma boa noite de sono: ela pode ser um “truque auxiliar”, mas não uma solução mágica para produtividade contínua.

Dicas para experimentar com segurança

Se quiser testar por conta própria, aqui vão algumas sugestões:

1. Dose moderada de cafeína não exagere para evitar efeitos colaterais.
2. Cochilo curto (até ~30 minutos) para evitar entrar no sono profundo.
3. Escolha o momento certo evite esse experimento perto da hora de dormir à noite.
4. Observe seus resultados veja se você realmente se sente mais alerta ou se ficou “mais grogue”.

Por décadas, a “Parede de von Neumann” travou o desempenho do PC: CPU e memória de um lado, GPU e sua própria memória do outro, ligados por um barramento (PCIe) que vira funil para dados. Com o anúncio conjunto de Intel e NVIDIA — unindo CPUs x86 e gráficos RTX em SoCs, com ligação CPUGPU via NVLink e memória unificada (UMA) — chega, enfim, o momento em que esse gargalo deixa de mandar na evolução do PC para IA e games. É a virada de chave que faltava.

O que mudou, exatamente?

Largura de banda e latência muito acima do PCIe: a Tom’s Hardware lembra que NVLink oferece até ~14× a largura de banda do PCIe, além de latencia menor — e a NVIDIA está abrindo o ecossistema por meio do programa NVLink Fusion, permitindo que CPUs de terceiros e aceleradores customizados pluguem-se na tecnologia NVLink Fusion.

Intel x NVIDIA, no mesmo pacote: as empresas anunciaram “Intel x86 RTX SoCs” — processadores x86 com chiplet RTX, integrados por NVLink em vez de PCIe convencional. O objetivo declarado é o mercado de PCs (notebooks finos e desktops compactos) e data centers com CPUs x86 customizadas para os aceleradores da NVIDIA.

Memória Unificada (UMA): CPU e GPU acessam o mesmo pool de memória, sem cópias redundantes. No design anterior (ex.: Kaby Lake-G de 2017), o elo era PCIe e a memória do lado GPU ficava “ilhada”; agora, o vínculo NVLink dá a ambos uma visão comum e coerente dos dados. Resultado: adeus ida-e-volta de buffers.

Por que isso mata (na prática) o gargalo de von Neumann?

O gargalo nasce quando processamento e memória ficam separados por um barramento estreito. Em IA e jogos modernos, os dados precisam fluir rápido entre CPU (lógica, simulação, IA clássica, orquestração) e GPU (ray tracing, rasterização, redes neurais). Com NVLink + UMA, o PC passa a se comportar como um “superchip”:

1. Mais largura de banda entre CPU e GPU (ordens de grandeza acima do PCIe),
2. Menos cópias e menos latência (dados vivem numa piscina comum),
3. Escalonamento mais previsível (o que antes era “transferência” vira “acesso compartilhado”).

Efeitos imediatos em IA

• Treino/inferência de modelos maiores em laptops compactos: com UMA, tensors e KV-cache deixam de pular entre memórias. O agendamento pode distribuir partes do grafo entre CPU e GPU sem o custo de “ir por PCIe”.
• Aceleração de pipelines multimodais: visão, linguagem, áudio podem compartilhar o mesmo espaço de endereçamento, reduzindo overhead de pré/pós-processamento.
• Data center x86 “by NVIDIA”: Intel fabricará CPUs x86 custom que, ao lado de GPUs NVIDIA, falam NVLink de ponta a ponta. Isso abre rota para clusters super poderoso.

Efeitos imediatos em games

• Streaming de dados e simulação mais coesa: física, IA de NPCs e lógica de jogo rodam na CPU com acesso direto a estruturas que a GPU renderiza sem maratonas de cópia. Pense em mundos maiores, streaming de assets mais fluido e shader compilation com menos soluços/gargalos.
• Ray tracing + upscalers com menos overhead: a ida-e-volta entre passes de render e redes neurais (DLSS/Frame Gen/denoisers) perde o “pedágio” do PCIe. O que era gargalo de interop, vira pipeline contínuo.

Por que agora?

Além dos SoCs para PCs, a NVIDIA oficializou o NVLink Fusion, programa que abre o NVLink para CPUs e aceleradores de terceiros, ampliando o uso o além de um único servidor e levando a arquitetura para escala de rack. É a normalização de um interconnect de altíssimo desempenho no mundo x86 — justamente onde o PCIe reinou sozinho por décadas.

O que isso exige do ecossistema

• Drivers maduros e toolchains: NVIDIA cuidará dos drivers de GPU; a Intel, do lado CPU. É uma lição aprendida após experiências passadas. Para devs, isso significa SDKs e runtimes que tratam CPU+GPU como um continuum (alocação unificada, sincronização fina, profiling sem “buracos”).
• Embalagem avançada (chiplets, 2.5D/3D, possivelmente HBM em variantes): quanto mais perto e mais “gorda” a ligação física, mais o PC se parece com um SoC heterogêneo de classe estação/servidor.

Calendário e realidade de mercado

A parceria está nos estágios iniciais; cronogramas e especificações ainda serão divulgados. Mesmo assim, o comprometimento é multigeracional, e a NVIDIA anunciou, em paralelo, a expansão de NVLink via Fusion. Tradução: o caminho está traçado — e ele aponta para CPUGPU sem funil.

Conclusão

Chamar de “fim do gargalo de von Neumann” não é exagero no contexto prático de IA e games no PC: NVLink + UMA entre Intel x86 e NVIDIA RTX extingue o principal pedágio que limitava a cooperação CPUGPU. O PC passa a operar como um sistema heterogêneo coeso, com banda e latência dignas de supercomputador, só que no seu colo e com um ecossistema inteiro (via NVLink Fusion) pronto para crescer além do PCIe. O futuro do PC é heterogêneo e a parede, enfim, rachou.

Fontes: Tom’s Hardware — anúncio dos Intel x86 RTX SoCs com NVLink e memória unificada, e apresentação do NVLink Fusion (banda até ~14× PCIe, abertura a CPUs/aceleradores de terceiros). Tom’s Hardware+1

Somos apaixonados pelo que fazemos. Cada linha de código carrega não apenas lógica, mas também dedicação, criatividade e horas de estudo. Temos uma sede insaciável por conhecimento. Curiosos por natureza, movidos por desafios, comemos informação no café da manhã e transformamos problemas complexos em soluções elegantes. Hoje é o nosso dia. O dia de quem transforma café em software, erros em aprendizado e ideias em inovação.

Feliz dia do programador para todos programadores aqui do Assunto Nerd.

#DiaDoProgramador #Programação #Tecnologia #OrgulhoDev #Desenvolvimento #Software #ApaixonadosPorCódigo

Na primeira semana de setembro de 2025, a comunidade JavaScript foi surpreendida com o que especialistas já estão chamando de o maior ataque à cadeia de suprimentos da história do ecossistema NPM. Pacotes extremamente populares — incluindo nomes como chalk, debug, color-convert, strip-ansi e supports-color — foram sequestrados por hackers, afetando diretamente bilhões de instalações semanais em projetos no mundo todo.

O Que Aconteceu?

Hackers realizaram um ataque de phishing direcionado a mantenedores de pacotes NPM. Eles enviaram e-mails falsos alegando serem da equipe oficial do NPM, solicitando uma “atualização obrigatória de 2FA”. A mensagem induzia os desenvolvedores a clicarem em um link malicioso hospedado no domínio falso npmjs.help, que imitava o portal legítimo npmjs.com.

Uma vez obtidas as credenciais, os invasores ganharam acesso total à conta do mantenedor e injetaram código malicioso em versões novas dos pacotes.

Como o Malware Funciona (Passo a Passo)

O código malicioso inserido nos pacotes compromete a segurança de aplicações web que utilizam carteiras de criptomoedas. A seguir, um resumo técnico do seu funcionamento:

1. Injeção no navegador

• O malware se infiltra diretamente no ambiente do navegador.
• Realiza hooks em funções centrais como fetch, XMLHttpRequest e APIs de carteiras (window.ethereum, Solana, etc.).
• Com isso, é capaz de interceptar tanto o tráfego web quanto a atividade de carteiras.

2. Monitoramento de dados sensíveis

• Escaneia respostas de rede e payloads de transações.
• Busca por padrões que correspondam a endereços de carteiras ou transferências de valor.
• Reconhece diversos formatos, incluindo Ethereum, Bitcoin, Solana, Tron, Litecoin e Bitcoin Cash.

3. Reescrita de destinos

• Substitui o endereço legítimo por um endereço controlado pelo atacante.
• Usa endereços com aparência semelhante (“lookalike”) para evitar levantar suspeitas.

4. Sequestro de transações antes da assinatura

• Altera parâmetros críticos de transações Ethereum e Solana (como destinatários, autorizações e permissões).
• Mesmo que a interface de usuário pareça correta, a transação assinada redireciona os fundos ao invasor.

5. Modo furtivo

• Caso detecte uma carteira ativa, evita alterações visíveis na interface para não levantar alertas.
• Mantém hooks silenciosos em segundo plano, prontos para capturar e modificar transações reais conforme necessário.

A investigação completa está sendo atualizada dinamicamente pela equipe da Aikido:
https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

Lista de Pacotes Afetados

Lições e Recomendações

1. Desconfie de e-mails solicitando ações urgentes, mesmo que pareçam legítimos.
2. Ative o 2FA com aplicativos confiáveis, como Authy ou Google Authenticator.
3. Audite os pacotes utilizados, especialmente os que foram atualizados recentemente.
4. Fixe dependências com lockfiles (package-lock.json, yarn.lock) e verificação de integridade.
5. Implemente repositórios internos (mirrors) para dependências críticas.
6. Use ferramentas de segurança contínua, como Snyk, Socket.dev, Aikido ou npm audit.

Conclusão

Esse ataque levanta um alerta vermelho sobre a fragilidade operacional, mesmo nos projetos mais populares. Uma única conta comprometida pode escalar rapidamente para bilhões de sistemas afetados — silenciosamente e de forma altamente sofisticada.

A segurança de sua aplicação não está apenas no seu código — mas também em tudo o que você importa via npm install.

Usuários que compraram placas da nova geração NVIDIA, como a GeForce RTX 5070 Ti, podem se deparar com o seguinte erro ao tentar rodar projetos com PyTorch e CUDA, como o Fooocus ou outras interfaces com IA generativa:

RuntimeError: CUDA error: no kernel image is available for execution on the device

Além disso, pode surgir o aviso:

UserWarning: NVIDIA GeForce RTX 5070 Ti with CUDA capability sm_120 is not compatible with the current PyTorch installation.

O erro indica que o PyTorch instalado não possui suporte à arquitetura SM da sua GPU. No caso da RTX 5070 Ti, trata-se de uma arquitetura nova (possivelmente Blackwell ou Lovelace Refresh), e o PyTorch está compilado apenas para arquiteturas anteriores (como SM_50 a SM_90).

Solução passo a passo

A solução é instalar uma versão nightly do PyTorch que já foi compilada com suporte às arquiteturas mais recentes e ao CUDA 12.8, exigido por GPUs mais novas.

1. Remova o PyTorch atual

pip uninstall torch torchvision torchaudio -y

2. Limpe o cache do pip (opcional, mas recomendado)

pip cache purge

3. Instale o PyTorch nightly com suporte ao CUDA 12.8

pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu128

4. Verifique a instalação

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

Saída esperada:

2.7.0.dev2025xxxx+cu128
12.8
True
NVIDIA GeForce RTX 5070 Ti

Se tudo estiver certo, o erro desaparecerá e você poderá usar a GPU corretamente no Fooocus, Stable Diffusion, LLMs, etc.

Dica extra

Se você estiver usando Pinokio, Fooocus, WebUI, InvokeAI ou outro frontend com interface gráfica para IA, garanta que ele esteja utilizando o ambiente Python com esse novo PyTorch instalado.

Referência oficial

A própria equipe do PyTorch mantém instruções atualizadas aqui

A DeepSeek tentou treinar o modelo R2 nos chips Ascend da Huawei para reduzir dependência da Nvidia, mas problemas técnicos persistentes travaram o projeto. O plano foi refeito: treino em Nvidia, inferência em Ascend. Resultado: adiamento do lançamento (previsto para maio) e um retrato honesto dos desafios de autonomia tecnológica na IA.

O que aconteceu?

O lançamento foi adiado; a expectativa de mercado é que o R2 chegue “nas próximas semanas”. Enquanto isso, vale lembrar: o R1 foi desenvolvido majoritariamente em Nvidia H20, hoje o chip mais popular na China.

A DeepSeek iniciou o treinamento do R2 em hardware Ascend (Huawei).

Segundo pessoas ouvidas pelo Financial Times, falhas recorrentes durante o treino inviabilizaram o cronograma, levando a empresa a migrar o treinamento para GPUs Nvidia e manter Ascend para a inferência.

A pressão de Pequim para priorizar tecnologia nacional encontrou um limite prático: quando “chegou a hora do treino pesado”, estabilidade e maturidade do stack fizeram diferença.

Por dentro do gargalo: treino ≠ inferência

Treinar um modelo de IA é como mandar alguém para anos de universidade:

• exige muito poder computacional de ponta a ponta (meses contínuos, clusters grandes, interconexão rápida);
• requer ecossistema de software estável (drivers, compiladores, kernels, bibliotecas, otimizadores, depuração);
• demanda resiliência operacional e financeira (quedas e inconsistências custam tempo e dinheiro).

A inferência, por sua vez, é “usar o diploma”: roda o modelo já treinado para responder perguntas. É pesada, mas menos sensível a arestas no stack.

A conclusão da DeepSeek: Ascend aguenta validação e inferência, mas a maratona do treinamento ainda cobra maturidade adicional.

A geopolítica no data center

• Os EUA restringiram exportações de chips avançados para a China; em julho, autorizaram a volta das vendas do H20 (com limitações).
• Pequim incentiva o setor a migrar para Ascend (autonomia estratégica), e ao mesmo tempo questiona o uso de chips dos EUA em projetos críticos.
• A linha Ascend está na lista negra dos EUA por alegações de uso de tecnologia americana restrita.
• Na prática, Nvidia segue dominante no treino de modelos de fronteira, enquanto o ecossistema Ascend cresce — com ênfase em inferência.

Por que isso importa

1. Risco tecnológico vs. prazo de mercado
   Apostar em um stack menos maduro pode estourar cronogramas. Para quem disputa janelas de lançamento, atraso custa mindshare e receita.
2. Custo total de propriedade (TCO)
   Treino instável gera restarts, retrabalho e subutilização de cluster, elevando o custo por token treinado.
3. Portabilidade de modelos
   Projetar pipelines para “train em A, infer em B” aumenta resiliência, mas também complexidade operacional (toolchains, formatos, kernels).
4. Sinal para o ecossistema
   O caso reforça a mensagem: hardware importa, mas software e tooling maduros são o verdadeiro fosso competitivo no treino de LLMs de grande porte.

Lições práticas para líderes técnicos

Antes de mudar do stack Nvidia para outro (ou de adotar um “duplo stack” treino/inferência), responda:

• Maturidade do ecossistema: drivers, kernels, compiladores, bibliotecas (atenção a regressões sob carga real de treino).
• Tooling e depuração: profiler, verificadores de precisão, diagnósticos de OOM, kernels customizados.
• Compatibilidade de frameworks: cobertura de operadores, suporte a paralelismo (tensor/pipeline/data), mixed precision, kernels otimizados.
• Interconexão e I/O: topologia do cluster, throughput de armazenamento (checkpointing frequente sem gargalo).
• Planos de rollback: como sair rápido de um stack se o MTBF sob treino longo for inaceitável?
• Estratégia híbrida: é viável treinar onde é mais estável e servir onde é mais econômico sem duplicar demais o esforço?

Para onde olhar nas próximas semanas

• Calendário do R2: se chega sem novos adiamentos, é sinal de que o treino em Nvidia estabilizou.
• Atualizações do stack Ascend: correções de estabilidade sob treino distribuído prolongado serão o termômetro da evolução.
• Movimentos de pares: ByteDance, Tencent e Alibaba continuam em H20; qualquer mudança ampla de rumo seria um indicador forte.

Conclusão

O adiamento do DeepSeek R2 não é apenas um tropeço operacional: é um estudo de caso sobre trade-offs entre autonomia tecnológica, maturidade de ecossistema e time-to-market. A mensagem é clara: para treinar modelos de ponta, o software conta tanto quanto o silício. Enquanto Ascend avança e conquista espaço em inferência, Nvidia preserva a dianteira onde a estabilidade extrema ainda decide — o treinamento.

Fonte:
https://www.tomshardware.com/tech-industry/artificial-intelligence/deepseek-reportedly-urged-by-chinese-authorities-to-train-new-model-on-huawei-hardware-after-multiple-failures-r2-training-to-switch-back-to-nvidia-hardware-while-ascend-gpus-handle-inference
https://br.investing.com/news/stock-market-news/deepseek-adia-lancamento-de-novo-modelo-de-ia-devido-a-problemas-com-chips-da-huawei-1648171