A comunidade KDE anunciou o lançamento do Plasma 6.7.0, trazendo flexibilidade inédita para quem usa o KDE em múltiplos monitores, além de amplas melhorias funcionais no gerenciamento desse popular desktop de código aberto.
Esta edição une soluções para demandas técnicas de infraestrutura e continuidade nos refinamentos visuais, trazendo também maior estabilidade no gerenciamento de energia e compatibilidade avançada com tecnologias modernas de exibição.
Os grandes destaques são as áreas de trabalho virtuais diferenciadas para cada monitor, a modesta mas cada vez mais necessária facilidade em testar o volume do seu microfone, e o recurso de segurar o pressionamento de uma tecla para ver caracteres especiais associados a ela,
Tecnicamente, o Plasma 6.7.0 também se destaca pela estreia do Union, seu novo sistema de estilização unificado baseado em CSS estruturado para simplificar temas em aplicativos QtQuick e QtWidgets. No campo gráfico, o ambiente agora possibilita a ativação simultânea do gerenciamento de cores por perfis ICC e a reprodução de conteúdos em HDR.
O Lynx 2.9.3 foi lançado oficialmente, atualizando o histórico navegador web para terminais em modo texto, com foco em ajustes internos e correções de falhas.
O Lynx está na estrada desde 1992, e é o navegador mais antigo que ainda recebe manutenção regular. Eu uso desde sempre, e acompanhei esse trajeto em que ele se consolidou como uma ferramenta essencial, hoje amplamente utilizada para testes de acessibilidade, automação e navegação rápida em terminais, bem como para acessar alguns conteúdos de sites que fazem o possível para tentar bloquear o acesso por outras ferramentas de automação, como curl e wget.
Um terminal rodando o Lynx para acewssar uma página na web
A versão 2.9.3 concentra suas melhorias no empacotamento, correções de portabilidade do código-fonte e revisão de scripts internos de configuração. Foram solucionados problemas relatados por usuários em revisões de código anteriores e atualizados os arquivos de suporte a idiomas, bem como refinamentos na manipulação de URLs e ajustes finos nas dependências de exibição de caracteres do terminal, mitigando falhas que poderiam comprometer a estabilidade do programa e a fidelidade do conteúdo exibido.
O código-fonte completo e os arquivos compactados nos formatos tar.gz e tar.bz2 já foram disponibilizados nos repositórios oficiais e espelhos do projeto para compilação e distribuição pelas principais plataformas que incluem o Lynx.
O Linux 7.2, em desenvolvimento, removeu oficialmente o driver de dispositivo de framebuffer e o driver de console de texto associados à clássica placa de vídeo monocromática Hercules ISA de 8 bits.
Sou experiente o suficiente para: (a) na década de 1980 ter desejado uma placa Hercules pro meu clone de IBM PC; e (b) na década de 1990, enquanto configurava manualmente o kernel Linux, ter pensado "mddc eles ainda suportam placas Hercules".
Já sonhei em ter uma placa Hercules como essa.
E agora, na década de 2020, eu concordo com a medida. Manter drivers para hardware histórico, mesmo quando obsoleto, é valioso, mas mais valioso ainda é reduzir, no kernel em produção, a superfície de ataque para incidentes de segurança no kernel – que se multiplica no caso de drivers usados por pouca gente e mantidos por pouquíssimos desenvolvedores interessados.
E é o foco: essa medida aprofunda a modernização iniciada em versões recentes do kernel, como a remoção do suporte a CPUs i486 e outros drivers antigos no recém-lançado Linux 7.1.
A remoção foi consolidada por um merge no repositório Git do Linux, concentrado nas atualizações do subsistema FBDEV. A eliminação do driver da saudosa Hercules, e de seu respectivo console de texto, aliviaram o código-fonte do kernel em mais de mil linhas de instruções que permaneciam praticamente intocadas há décadas. Embora a maior parte do trabalho moderno de exibição do Linux ocorra hoje no subsistema Direct Rendering Manager (DRM), o FBDEV ainda abrigava essa relíquia de barramento ISA. O encerramento do suporte afeta apenas colecionadores de peças antigas de PC, que ainda movimentam esse hardware no mercado de usados por valores que surpreendentemente ultrapassam 200 dólares.
Versão 7.1 do kernel Linux foi lançada oficialmente por Linus Torvalds, trazendo suporte renovado a volumes NTFS e correções de áudio voltadas ao Steam Deck.
O lançamento do kernel 7.1 traz uma mix interessante de atualizações de recursos e drivers, expandindo o suporte de hardware e a estabilidade geral do sistema – e consolidando o fim do suporte a PCs com CPU 486.
O componente técnico mais visível na atualização é o novo driver nativo para o sistema de arquivos NTFS, que Linus chamou de "ressureição do NTFS", e que esteve em desenvolvimento ao longo dos últimos 4 anos. Para o pessoal dos jogos, também há a solução para uma falha persistente no subsistema de som que afetava os usuários do Steam Deck OLED.
Também há novidades em desempenho de servidores, criptografia, suporte a mais arquiteturas, e a ativação por default do suporte ao FRED.
O ciclo de desenvolvimento do Kernel 7.1 também ficou marcado por uma tendência recente observada por Torvalds: um volume de patches acima da média nas fases finais de testes, impulsionado pela crescente utilização de ferramentas de inteligência artificial por parte dos revisores e contribuidores de código.
Originalmente um remaster brilhoso do Kubuntu, a versão de 2026 do Hannah Montana Linux é um novo remaster, desta vez fundamentado no Debian Trixie de 64 bits e no instalador Calamares, e aplicando personalizações ao KDE Plasma.
O autor fez um vídeo apresentando sua obra, disponibilizou uma ISO (grande demais) no Google Drive, e instruções (relativamente comuns) para quem preferir gerar sua própria ISO a partir do código-fonte.
A expiração da chave UEFI de 2011 da Microsoft, agora em junho, exige que distribuições Linux migrem suas assinaturas de inicialização.
Tende a não ser nenhum fim de mundo: há credenciais mais recentes (de 2023) à disposição, e não há nada de oculto ou misterioso1 nesse processo: a Microsoft assina com uma chave própria o shim – que é o software da Red Hat que serve de intermediário entre os PCs com Secure Boot, feitos para o mundo Windows (e que só dão boot em sistemas assinados por chaves criptográficas que eles reconheçam, como as da Microsoft) –, e as distribuições usam esse shim, assinado, como intermediário do seu processo de boot, garantindo que o firmware do PC tope transferir o controle para elas durante o boot (e confiando que esse processo validará também os componentes posteriores, como o próprio kernel).
Sequência de carregamentos do Secure Boot: a UEFI chama o shim, que chama o gerenciador de boot, que chama o kernel.
A transição para sistemas de boot assinados com chaves modernas é essencial para preservar essa cadeia de confiança que permite ao seu hardware dar boot com o sistema operacional que você escolher, mas esse processo tende a ser transparente para os usuários – ainda mais que não há expectativa de uma interrupção imediata, nas máquinas que hoje estão funcionando, dos boots feitos com a assinatura anterior.
Ou seja: sistemas já instalados tendem a continuar funcionando, e PCs futuros possivelmente rejeitarão as chaves desatualizadas, o que é algo para você ter em mente quando encontrar dificuldades inesperadas com o boot a partir de mídias antigas (ou geradas a partir de imagens antigas), discos de recuperação arquivados, ou versões históricas de distribuições.
A invasão de um agente de IA no bugzilla do Fedora teve sucesso em transferir e encerrar vários chamados indevidamente e até em injetar código incorreto no instalador Anaconda.
Em mais um incidente que coloca em contato as distribuições populares, a segurança da informação e a ação de agentes de IA, no final de semana circularam os relatos sobre a indesejada ocorrência vivida no projeto Fedora no final de maio.
O incidente aconteceu após as credenciais de um colaborador legítimo serem comprometidas, permitindo que o sistema automatizado gerasse correções falsas e insistisse em respostas robotizadas para levar os mantenedores humanos a incluir no instalador Anaconda um patch que introduziu erros no sistema.
Esse incidente de segurança evidenciou os riscos reais que a automação impõe às cadeias de suprimentos de software (de código aberto ou não), servindo mais uma vez de alerta sobre o potencial de dano causado pela sucessão de ataques deste ano voltados a capturar chaves e senhas de desenvolvedores.
No caso concreto, as interações geradas por IA chegaram a causar a inclusão de código falho na versão 45.5 do instalador Anaconda, antes do efeito ser detectado e revertido pela equipe de controle de qualidade.
No âmbito do projeto, o caso reabriu debates intensos sobre a obrigatoriedade de autenticação em duas etapas para colaboradores do projeto, uma discussão que estava estagnada desde o ataque à biblioteca XZ (2024), mas que esbarra em entraves técnicos de ferramentas antigas, como o próprio Bugzilla.
A maré de más notícias para a comunidade Arch Linux permanece, e o gerenciamento da crise por lá não está brilhando.
Quando cobrimos essa notícia na sexta-feira, o número de pacotes com rootkit sendo distribuídos pelo repositório da comunidade do Arch Linux era de 400; na manhã de sábado verificamos que havia passado de 1600, e logo depois tivemos a notícia de que o número havia parado de aumentar; mas o o domingo chegou com a informação de que o comprometimento reiniciou, e agora um pouco mais elaborado do que as ondas iniciais.
No momento não há muitas informações disponíveis além de relatos de desenvolvedores e poucas notícias (como esta do Phoronix), mas aparentemente agora os novos comprometimentos estão mais para a categoria de vandalismo – com inclusão de mensagens ofensivas nos pacotes – do que para a de rootkits e roubos de senhas (ao contrário dos 1500+ pacotes dos dias anteriores).
Considerando que as ondas anteriores eram baseadas em malwares de roubo de senhas e tokens, é de se imaginar que haja uma quantidade de credenciais de desenvolvedores do Arch nas mãos dos atacantes, e estejam sendo usados para essa segunda onda. Mas isso é suposição, e continuaremos acompanhando a situação.
Quanto ao gerenciamento da crise, vale mencionar que a capa do site do repositório AUR não tem nenhuma informação a respeito até o momento em que escrevo, e as informações na capa do site do próprio Arch Linux a respeito não são atualizadas desde a sexta-feira.
Em novo capítulo da campanha internacional de comprometimento de repositórios de software, mais de 400 pacotes no ecossistema Arch Linux foram adulterados com um rootkit oculto e um malware focado em roubo de credenciais.
O comprometimento foi no AUR (Arch User Repository), onde invasores assumiram a responsabilidade por pacotes órfãos, e usaram esse acesso para modificar seus arquivos PKGBUILD, injetando de forma automatizada uma dependência maliciosa (chamada atomic-lockfile, e correspondendo ao malware) durante o processo de instalação.
O AUR é um repositório mantido pela comunidade da distribuição Arch, e contém scripts de construção de pacotes (PKGBUILDs) com instruções para baixar, compilar e instalar software não disponível nos repositórios oficiais do Arch, tais como aplicativos proprietários, versões beta, utilitários de nicho e versões mais antigas de pacotes que retêm funcionalidades que podem ter sido removidas em versões posteriores.
Este ataque é mais um exemplo da série que vem expondo os limites (em termos de exposição a riscos) do modelo de governança comunitária de repositórios open source. Ao maliciosamente herdar a confiança histórica de softwares legítimos que foram abandonados por mantenedores anteriores, os cibercriminosos conseguiram enganar as ferramentas de detecção convencionais.
No campo estritamente técnico, a infecção ocorre por meio de scripts de pós-instalação que invocam o gerenciador de pacotes npm para rodar o executável malicioso. A ameaça se destaca por utilizar tecnologia eBPF (extended Berkeley Packet Filter), injetando código diretamente no kernel do Linux com privilégios elevados.
O rootkit atua interceptando chamadas de sistema para camuflar processos, arquivos e conexões de rede do sistema afetado. Adicionalmente, ele usa técnicas para tentar impedir análises de segurança, e possui rotinas focadas em colher chaves SSH, credenciais de nuvem (como AWS e GCP) e de VPNs, histórico da shell, cookies de navegadores e outras informações sensíveis.
Se você usa o Arch e o AUR, este script pode ajudar a verificar se você instalou a versão infectada de algum dos pacotes comprometidos.
Atualização: troquei a URL do script de verificação, por uma versão mais recente e que se auto-atualiza conforme a lista de pacotes confirmados como estando comprometidos aumenta.
A Juno Computers anunciou o Juno Tab 4 LTE, um tablet que se destaca por sair de fábrica com distribuições Linux tradicionais e consolidadas no ecossistema de código aberto.
Eu tenho demanda para um dispositivo assim: com opções nativas de distribuições reconhecidas (no caso, a escolha é entre Debian e Ubuntu), altamente portáteis (tela touchscreen 1920x1080 antirreflexo de 10,5 polegadas e chassi de 0,59 kg), com bateria, conectividade, e possibilidade de operar tanto com teclado físico quanto com touch screen.
A iniciativa da Juno é relativamente rara em um mercado carente de opções portáteis com Linux que não seja como parte do Android. Ao apostar em distribuições bem estabelecidas e interfaces otimizadas para toque, a fabricante permite a expectativa por um ambiente diferente daquele que se encontra no típico ecossistema fechado dos sistemas voltados ao mercado de dispositivos móveis.
Debaixo do capô, o tablet traz uma CPU Intel Celeron N300 (Alder Lake-N) de 8 núcleos e 8 threads, 12 GB de RAM e SSD M.2 SATA III de 1 TB. O diferencial de conectividade é um módulo LTE que oferece download de até 150 Mbps (além de Wi-Fi 6). No quesito expansão, tem duas portas USB-C (com saída de vídeo 4K!), uma porta micro HDMI, uma entrada para Micro SD, e conector para fone de ouvido.
O WordPress Studio, ambiente oficial da Automattic para desenvolvimento local, recebeu uma versão nativa para Linux (“começando pelo Ubuntu”, dizem eles).
A ferramenta promete permitir que desenvolvedores criem sites instantaneamente sem configurações complexas de servidores (“sem configurar Apache, sem Docker, sem 'na minha máquina funciona'”, diz o anúncio), ao rodar sem dependências locais, eliminando a necessidade de instalar manualmente a sua pilha PHP + MySQL.
Os recursos incluem:
Domínios personalizados e HTTPS para seus sites locais, para que você possa desenvolver URLs realistas
Links de visualização com um clique para compartilhar seu trabalho em andamento com clientes, colegas de equipe ou testadores
Sincronização bidirecional com o WordPress.com, para que você possa transferir um site de produção ou de teste para o seu laptop e depois enviar de volta as alterações
Ele usa o WordPress Playground baseado em WebAssembly (WASM) e SQLite, rodando o CMS diretamente no ecossistema local, e inclui também a interface Studio CLI, para automação de rotinas via terminal (como criação e inicialização de sites).
O lançamento chega junto com a notícia de que a participação do WordPress caiu pelo 6º mês consecutivo (mas permanece dominante), após anos de crescimento consecutivo, com inflexão negativa associada às escolhas controversas da sua governança (ou “meses de ações judiciais, liminares, disputas de plugins e disputas públicas”).
O (ótimo) cliente web open source Elk alcançou oficialmente sua versão estável 1.0.0, introduzindo novos recursos de agendamento de postagens e suporte nativo a citações para usuários da rede Mastodon.
Interface do Elk rodando no navegador
A atualização adiciona o suporte a citações (“quote RTs”) e um botão dedicado para agendar posts diretamente na interface de publicação, e implementa confortos como ampliar automaticamente os (geralmente minúsculos) emojis personalizados, oferecer novos filtros aplicáveis a respostas e a reposts, e adicionar mais uma confirmação antes de consolidar um bloqueio a toda uma instância.
O lançamento da versão 1.0.0 consolida o Elk como uma alternativa madura no ecossistema de redes descentralizadas. Eu uso ocasionalmente, e recomendo a novos usuários – é uma alternativa de alta qualidade, e frequentemente oferece recursos e usabilidade bem à frente dos que estão presentes no cliente oficial do Mastodon.
Você pode usar na plataforma pública, ou instalar em seu próprio servidor, se desejar.
Nova versão traz mais proteção contra a recente onda de ataques a pacotes de repositórios open source, um método mais eficiente para gerenciar os metadados necessários às instalações, e o suporte a sandboxing de pacotes no Linux.
O Homebrew é um gerenciador de pacotes popular no Mac, e há algum tempo disponível também para Linux e para Windows (WSL), com um funcionamento similar aos típicos gerenciadores das distribuições, mas um diferencial: gerencia pacotes do usuário, e não do sistema – no Linux, por default, os pacotes instalados residem numa árvore de diretórias criada em .linuxbrew.
Especificamente para Linux, passa a haver suporte a sandboxing dos pacotes, oferecendo algum isolamento de contexto de execução (com o bubblewrap), como também já é default no Mac, e também em caráter mitigatório aos riscos trazidos pela atual onda de comprometimentos.
A nova versão também traz ganhos de desempenho, opções default remodeladas (após uma pesquisa com os usuários) e várias outras novidades.
Para um usuário de Linux do século XX, como eu, esse tipo de notícia mostra como o mundo mudou: eu demorava semanas para conseguir configurar um PC novo para entrar no modo gráfico, e agora a luta é para reduzir uma diferença de latência medida em 4 milissegundos – avançamos!
O desenvolvedor Jakub Okoński tem trabalhado na comparação da latência de jogos entre Linux e Windows e, a partir do resultado, trabalhando para produzir algumas melhorias no compositor KWin, do KDE, para que a latência seja mais competitiva com a experiência de jogo no Microsoft Windows 11.
Um Teensy 4.0 em uma janela do KDE
Ele usou um microcontrolador Teensy para comparar a latência de jogos entre Windows 11 e Linux com KDE Plasma 6, medindo o tempo entre clique no mouse e fóton na tela, e encontrou diferenças de até 4 milissegundos entre os 2 sistemas operacionais.
A partir daí, buscou as causas, e desenvolveu patches para o código do KDE que reduzem cerca da metade dessa diferença, especialmente em jogos e aplicativos que rodam em janelas – mas também em alguns jogos que rodam em tela cheia.
Ele ainda não encerrou as pesquisas e o desenvolvimento, mas planeja enviar os patches ao KDE nas próximas semanas.
O ReactOS, projeto que desde 1996 busca oferecer um sistema operacional open source capaz de rodar aplicativos e drivers desenvolvidos para Windows, alcançou um marco do seu desenvolvimento: passou a ser capaz de rodar a versão do Half-Life para Windows (que há alguns anos já conseguia inicializar parcialmente).
O marco não é pela funcionalidade (já que quem quer rodar o Half-Life fora do Windows já tem opções há um bom tempo), e sim pela maturidade do código do ReactOS, que agora já tem todos os recursos necessários a essa mesma tarefa.