Nitrux 5.1.0 cria uma barreira: HCVL valida hardware e mira performance

O Nitrux 5.1.0 oficializa uma virada que os desenvolvedores já vinham sinalizando desde o 5.0: esta distro quer ser uma “track weapon”, feita para um cenário específico, e não um carro de passeio para qualquer rua. A mudança central é a introdução da HCVL, que passa a validar hardware e o alinhamento entre GPU e imagem ISO, além do salto de foco em performance com kernel 6.18.2 e novos schedulers padrão.

É uma postura direta, sem desculpas. Para quem pediu suporte legado, raiz mutável e workflows que “quebram” a integridade do modelo, a resposta do projeto segue a mesma: não.

Entenda em 90 segundos

O Nitrux é uma distro com ênfase em design, atualizações atômicas e fluxos de trabalho containerizados, mirando performance nativa em hardware moderno. O projeto também reforça o conceito de immutable root, como pilar para consistência e previsibilidade.

O que muda agora é a barreira de entrada. Em vez de apenas listar requisitos, o Nitrux 5.1.0 passa a validá-los ativamente e remove suporte a caminhos considerados “peso morto” de retrocompatibilidade, para reduzir expectativas quebradas e aumentar a precisão do ambiente suportado.

HCVL: a barreira de entrada técnica

A grande peça desta versão é a HCVL (Hardware Compatibility Validation Layer), descrita como um framework para garantir que o Nitrux rode em um ambiente previsível e suportável, reduzindo ambiguidades com validações em quatro frentes.

Primeiro, há validação de capacidade de CPU. Se o processador não suportar o conjunto de instruções exigido, o sistema interrompe cedo o boot e explica o motivo. A ideia é evitar “quebras sutis” que aparecem só depois.

Segundo, a HCVL verifica o alinhamento entre GPU e variante de ISO, conferindo se a stack gráfica corresponde à imagem escolhida (Mesa ou NVIDIA). Se houver incompatibilidade, o sistema avisa antes da sessão gráfica, o que melhora diagnósticos e reduz falhas confusas.

Terceiro, existe consciência de ambiente e recursos. A HCVL detecta virtualização e sistemas com poucos recursos e comunica claramente os requisitos de compatibilidade. Aqui o ponto não é “rodar de qualquer jeito”, e sim deixar explícito quando o resultado não representa o alvo do Nitrux.

Quarto, há clareza de workflow e consistência do modelo do sistema. A HCVL intercepta fluxos não suportados no host, como gerenciadores de pacotes legados ou binários sem gestão, e explica alternativas, com o objetivo de preservar integridade e confiabilidade.

Deep dive: kernel, schedulers e performance

O Nitrux 5.1.0 adota o kernel Linux 6.18.2 com patches do CachyOS. As duas ISOs passam a usar o mesmo kernel, e o projeto afirma que não usará mais o kernel Liquorix.

A parte “sem desculpas” aparece também no agendamento. O SCX agora é o scheduler padrão de processos, com um serviço no OpenRC capaz de ajustar o SCX dinamicamente dependendo de energia (AC) ou bateria.

No lado de I/O, o Nitrux coloca o ADIOS como scheduler padrão. A adição inclui o utilitário adiosctl e regras udev para uso do ADIOS em dispositivos rotacionais, não rotacionais e não virtuais, mirando baixa latência em storage moderno (blk-mq).

Para plataformas recentes, há foco explícito em otimizações de CPU. O sistema adiciona um serviço para habilitar o AMD 3D V-Cache Optimizer em sistemas suportados, com um requisito importante: a placa-mãe precisa permitir ajustes via AMD CBS, e é essencial configurar “CPPC” ou “CPPC Dynamic Preferred Cores” como DRIVER na BIOS, para que o sistema operacional controle preferências de núcleos via o dispositivo do otimizador.

No desktop e no gaming, o Nitrux também ajusta o GameMode para usar heurísticas que fixam e estacionam cores em processadores AMD com 3D V-Cache e em CPUs Intel com P/E cores. Não há promessa de FPS; a mensagem é de alinhamento agressivo do sistema para o perfil de hardware e workload alvo.

Segurança e ferramentas (Maui Apps)

A mudança de firewall é um marco prático. O Nitrux passa a usar Firewalld como firewall padrão, substituindo o UFW. Para tornar isso mais “pronto para uso”, entra o Cinderward, uma GUI Wayland-friendly e init-agnostic baseada em MauiKit para gerir regras do Firewalld sem depender do CLI no dia a dia.

Na mesma linha, o projeto adiciona o Wirecloak, cliente WireGuard com GUI em MauiKit, desenhado para integrar bem com o modelo de raiz imutável (immutable root filesystem). A ideia aqui é oferecer um caminho consistente para VPN sem “gambiarras” no sistema-base.

Em políticas de autenticação, o Nitrux afirma ter alinhado PAM e libpwquality às diretrizes da NIST SP 800-63B Revision 4. O texto é explícito: sai a ênfase em complexidade forçada e rotação de senha a cada 90 dias, e entra o foco em comprimento e entropia, por entender que regras antigas induzem padrões previsíveis no mundo real. O release também cita configuração de PAM hardened.

No Bluetooth, o projeto detalha uma bateria de hardening no Bluez: resolução de RPA no kernel para dificultar rastreamento, bloqueio de pareamento “Just Works” sem confirmação do usuário, exigência de modo SC (rejeitando métodos legados), ajustes de varredura, timeouts para reduzir superfície de ataque e mudanças de perfil para evitar quedas em codecs de baixa qualidade.

Além disso, há um endurecimento de rede e sistema: bloqueio centralizado de protocolos antigos ou específicos de servidor (DCCP, SCTP, RDS, TIPC), limites de recursos com teto de 30.000 processos por usuário, permissões de prioridade em tempo real e memory lock para o grupo de áudio, e ajustes de compatibilidade de recursos para Proton (Esync/Fsync) sem exaustão.

O que foi removido (e por que importa)

A lista de remoções ajuda a entender a filosofia de “limites rígidos”. O Nitrux remove suporte a Legacy BIOS e, com isso, também remove a capacidade do GRUB de bootar em hardware BIOS legado. O argumento é temporal e pragmático: UEFI se tornou padrão por volta de 2011-2012, e a era de CPUs AVX2 (2013+) já veio acompanhada de placas-mãe consumer com UEFI.

Também saem UFW e Plasma Firewall. No caso do Plasma Firewall, o motivo citado é a dependência de systemd para funcionalidade completa, o que conflita com escolhas do Nitrux. Outras remoções incluem SwayOSD, seatd, tini, nwg-displays e scripts SysV não utilizados, com a observação de que o Nitrux gerencia resolução e monitores externos automaticamente via Hyprscreend.

Atualizações relevantes de base e ecossistema

O release atualiza componentes de desktop e stack: Hyprland/Hypr utilities 0.52.2, KDE Frameworks 6.20.0, Qt 6.9.2, PipeWire 1.4.9, Flatpak 1.16.1 e Crystal Dock 2.16. Há também mudanças de UX (Waybar em layout “island” flutuante, ajustes em Hyprlock, Wofi com geometria arredondada) e correções funcionais (Calamares, Wofi, Wlogout, Grimshot, XWayland com autologin, e uma nota sobre stutter de áudio Bluetooth com Wi-Fi ativo em firmware recente para Realtek RTL8852CE).

Em rede, o Nitrux atualiza o NetworkManager para usar dnscrypt-proxy por padrão, adiciona dispatcher para ajustar relays dinamicamente, força ignorar DNS via DHCP, desabilita dhcpcd no NetworkManager para evitar DNS leaks e impõe preferência por 5 GHz, além de desligar background scanning.

O projeto também destaca melhorias internas em ferramentas como NX AppHub (CLI e daemon 1.0.0) e o Nitrux Update Tool System 2.2.7, incluindo travas para impedir múltiplas instâncias (flock), sequências de reboot com Magic SysRq para integridade de dados e validações para evitar restauração em discos errados quando há labels duplicadas.

Mini-glossário

• HCVL: camada de validação que checa CPU, alinhamento GPU/ISO (Mesa vs NVIDIA), ambiente (virtualização/recursos) e workflows suportados, interrompendo cedo quando o ambiente foge do alvo.
• CachyOS patches: conjunto de patches aplicados ao kernel do Nitrux 5.1.0, com foco em otimização e performance.
• SCX: scheduler de processos configurado como padrão no Nitrux 5.1.0, com ajuste dinâmico conforme energia (AC/bateria).
• ADIOS: scheduler de I/O no bloco (blk-mq) adotado como padrão, com adiosctl e regras udev.
• Immutable root: modelo de raiz imutável, usado para previsibilidade, integridade e atualizações atômicas.
• NIST SP 800-63B Rev 4: diretriz citada para políticas de senha, favorecendo comprimento e entropia, e abandonando rotação forçada de 90 dias e complexidade artificial.