BR-Linux.org

Via James Benett chega a notícia de que a Oracle – que investe milhões para convencer seus clientes a usarem IA – também proíbe contribuições baseadas em LLM para um de seus principais projetos open source: o OpenJDK.

A política em vigor, aprovada pela governança interna, não deixa a menor dúvida:

As contribuições na comunidade OpenJDK não poderão incluir conteúdo gerado, parcial ou totalmente, por LLMs, diffusion ou sistemas similares de deep-learning. O conteúdo, neste contexto, inclui, entre outros, código-fonte, texto e imagens em repositórios git do OpenJDK, pull requests no GitHub, mensagens de e-mail, páginas wiki e chamados do JBS.

Essa política ainda é a versão preliminar, enquanto a Oracle, no seu papel de patrocinadora corporativa da Comunidade OpenJDK, elabora uma política mais completa limitando o uso de ferramentas de IA generativa nas contribuições ao OpenJDK.

Referência: James Bennett: "I just learned that Oracle, wh…" - Infosec Exchange

Via @grahamperrin@bsd.cafe chegou a informação de que as notícias sobre o fim do código GPL na base do FreeBSD foram precipitadas: ainda há alguns fragmentos (sob licença dupla) em drivers.

O Fossforce tem mais detalhes, incluindo a referência sobre qual o driver da Qualcomm que ainda afasta do FreeBSD o atestado de ausência de código GPL na sua base.

Referência: VISITE O DECORADO: "@grahamperrin interessante!" - Arram, senta lá, Cloud!

Leia também: FreeBSD 16 conclui com sucesso a remoção de todo o código GPL do seu sistema-base.

A família de compiladores GCC se une à lista de projetos que decidiram rejeitar contribuições significativas (no sentido de direitos autorais) derivadas de IA/LLM, com exceções específicas: alterações triviais, e casos de teste.

Pelas novas regras, o GCC passa a recusar quaisquer contribuições que incluam material protegido por direitos autorais (ou seja, código significativo) e produzido por um LLMs ou baseado em resultados gerados por LLMs.

Essa definição abrange não só código copiado diretamente de ferramentas como ChatGPT, Gemini ou GitHub Copilot, mas também quaisquer versões desse código posteriormente editadas ou reescritas por uma pessoa, caso a contribuição final ainda seja baseada no material gerado pelo sistema.

Referência: GCC Adopts Policy Rejecting Significant AI-Generated Code

Enquanto torcemos para que os desenvolvedores do Debian escolham a opção obviamente correta, o projeto abriu a discussão de uma Resolução Geral sobre "Uso de LLM no Debian", já em andamento.

No momento há 4 alternativas identificadas, cada uma com detalhamento e argumentação:

• Proposta A - Proibir expressamente quaisquer contribuições para o Debian escritas com o uso ou assistência de LLMs ou outras ferramentas de IA generativa.
• Proposta B - Permitir contribuições assistidas por IA.
• Proposta C - Rejeitar LLMs ("IA" generativa) tanto quanto for viável
• Proposta D - Aceitar contribuições de IA para trabalhos específicos do Debian

A página da Resolução Geral traz o detalhamento, inclusive quanto a minúcias que fazem diferença profunda na interpretação – por exemplo, sobre como cada proposta se aplica a código upstream, ou seja, recebido de outros projetos.

Referência: General Resolution: LLM usage in Debian

O projeto Ubuntu tem uma pendência mapeada desde 2005 para deixar de distribuir o arquivo /etc/debian_version, que é recebido do Debian que fornece os pacotes e, na prática, apenas indica a versão de desenvolvimento do Debian Sid da qual os pacotes chegaram.

O grande problema prático de manter esse artefato histórico no /etc é que, embora esse arquivo não seja indicado como fonte para identificar qual o nome e versão da distribuição que está em uso, há softwares e ferramentas que o usam assim, e acabam trabalhando com informações imprecisas ou mesmo erradas.

Agora, 21 anos depois dessa percepção, o desenvolvedor Benjamin Drung planeja resolver a questão definitivamente, por meio da remoção.

Vale lembrar: a fonte boa para obter as informações sobre distribuição e versão é o arquivo /etc/os-release, ou alternativamente o comando 'lsb_release -a'.

Olhei no servidor mais próximo rodando Ubuntu por aqui, que está rodando um LTS do Ubuntu 22.04, e seu /etc/debian_version indica 'bookworm/sid' (corretamente, mas também erroneamente).

Referência: Ubuntu Linux Looking To Get Rid Of /etc/debian_version Historical Artifact - Phoronix

Em uma votação que durou 14 dias, os integrantes do Codeberg decidiram, por 358 a 144 votos, que seus repositórios não aceitarão mais hospedar projetos criados via vibe coding.

Embora muitas vezes bem intencionado, compartilhar o resultado de um prompt e chamá-lo de “software gratuito” não torna o mundo um lugar melhor. O Codeberg não é e não quer ser um lugar para despejar software gerado dessa forma, de uso único, que ninguém mais irá olhar.

(...) Para nós, parece ridículo ver projetos com um único desenvolvedor, e praticamente nenhum usuário, consumindo tanto ou até mais recursos do que alguns dos maiores projetos comunitários no Codeberg, que operam frugalmente com CI/CD e recursos de armazenamento. Não acreditamos que seja razoável que Codeberg invista o precioso dinheiro de doações, na hospedagem de grandes projetos fantasmas. (...)

Eles também decidiram que sua posição oficial é :

não utilizar o código ou dados de projetos e usuários para treinar ferramentas de “Inteligência Artificial”, como Large Language Models (LLMs), cujo objetivo é criar saídas modeladas a partir das entradas que recebem como treinamento. Como associação, acreditamos que estas tecnologias são incompatíveis com a criação e manutenção responsável de software livre e de código aberto.

Referência: Protecting our FLOSS commons from LLMs — Codeberg News

O simpático Jellyfin é uma das boas alternativas¹ ao Plex para quem quer hospedar sua própria coleção de filmes, séries, músicas e mais, mas passa por uma crise cada vez mais comum.

Liderar projetos desenvolvidos comunitariamente envolve bastante stress e cobrança, e demanda apoio e renovação que frequentemente ficam ausentes. No caso do Jellyfin, o stress acumulado levou ao recente aviso dos mantenedores centrais, de que estão largando os tacos.

Poderia ser pior: a saída deles é amigável, e eles estão contribuindo na transição. Mas a situação é indesejada para qualquer projeto: mantenedores exaustos, como se pode verificar no relato do (agora ex-) líder do projeto:

Para mim, pessoalmente, era hora de mudar. Eu simplesmente não conseguia mais emtregar o esforço que a função exigia e, portanto, não estava desempenhando minhas funções em um grau aceitável, enfrentando grave esgotamento e riscos para minha saúde mental. Era hora de se afastar.

Desejamos uma transição tranquila e continuidade do sucesso ao projeto e, principalmente, aos mantenedores, que já deram sua contribuição e merecem reconhecimento e acolhimento.

Referência: Plex's Open Source Alternative Jellyfin is Having a Leadership Crisis

A nova falha grave do WordPress, que noticiamos no final de semana, já está sendo explorada ativamente, e tem potencial para ser um longo pesadelo coletivo.

Isso porque a falha permite a qualquer pessoa executar comandos no servidor rodando o WordPress com a falha, sem precisar autenticar - e há literalmente centenas de milhões de sites com WordPress na Internet.

Muitos deles serão atualizados, mas muitos outros não serão, e os bots que identificam e comprometem os servidores vulneráveis já começaram a ser detectados no sábado - mesmo dia em que publiquei o post aqui no BR-Linux.

As versões afetadas são o WordPress 6.9.0 a 6.9.4, 7.0.0 e 7.0.1. Se você tem uma dessas, o ideal é fazer o upgrade imediato para 7.0.2 (lançado na sexta-feira para corrigir o bug) ou o 6.9.5

Referência: WP2Shell WordPress Vulnerabilities Exploited in the Wild - SecurityWeek

A oportunidade para o Linux no desktop, representada pela transição recente do Windows 10 para o Windows 11, ganhou mais força com a distópica escassez de RAM, que agora faz a Microsoft fingir que seu novo sistema roda bem em laptops com só 8GB de RAM.

Claro que usuários motivados conseguem rodar esse pesado sistema com até menos, dependendo do que forem fazer. Mas a empresa passou muito tempo mirando em uma configuração mínima de 16GB, mas agora que RAM passou a ter preço de ouro, mudou o discurso, e passou a dizer que um laptop de 8GB com Windows 11 será “ótimo para uso diário, como navegação, streaming, trabalhos escolares e aplicativos de produtividade.”

O site The Verge resolveu testar a afirmação, e a conclusão foi: trava demais. Ou, como diz o título do artigo, “Nem a Microsoft conseguiu rodar bem o Windows 11 em 8GB de RAM”.

Eles fizeram o teste no novo Surface Laptop, da própria Microsoft, em sua configuração oficial com 8GB de RAM. E aqui está o resumo da qualidade da experiência:

O Surface Laptop travava desse jeito, por alguns segundos, várias vezes ao dia, mesmo quando eu achava que não estava forçando muito. Tive esses congelamentos temporários enquanto trabalhava em alguns arquivos no Google Docs – sem nenhuma chamada do Teams em execução ou qualquer transmissão em segundo plano. Em média, são apenas algumas vezes por dia, mas ainda é muito frequente.

Definitivamente, quando a experiência de usuário é melhor com outro sistema operacional, rodando em um computador de 3 ou 4 anos atrás, do que com o sistema operacional mais recente, no laptop mais recente, há uma oportunidade no mercado a ser aproveitada por quem não fornece esse sistema mais recente.

Referência: Even Microsoft couldn’t make Windows 11 work well on 8GB of RAM | The Verge (ou via archive,ph)

A vulnerabilidade CVE-2026-42533 no NGINX pode permitir que um invasor remoto e não autenticado sobrecarregue um buffer, levando a uma negação de serviço (DoS) e, teoricamente, à possibilidade de execução remota de código.

A falha está presente em mais de uma década de versões do NGINX, desde março de 2011, quando foi adicionado o recurso de expressões regulares na diretiva 'map'. É por isso que a lista de versões afetadas é enorme: 0.9.6 a 1.30.3, todas até 1.31.2, R33 a R36, e 37.0.0.1 a 37.0.0.2 (dependendo de qual série você usa). Produtos derivados, como NGINX Ingress Controller, Gateway Fabric, App Protect WAF e Instance Manager, também podem estar vulneráveis.

As versões com a correção são: 1.30.4, 1.31.3, R36 Patch 7 e 37.0.3.1.

Mas atenção: como a falha é dependente da configuração, é possível que um servidor que roda uma versão afetada não esteja exposto à vulnerabilidade (o que não é razão para adiar a correção, naturalmente).

Referência: CVE-2026-42533: 15-Year-Old NGINX RCE Vulnerability Explained | The CyberSec Guru

Um desenvolvedor do GNOME Calendar reavivou a brasa de uma discussão de meses com o Linux Mint sobre pacotes desatualizados, links de suporte e marcas.

São frequentes os conflitos de interesse entre os desenvolvedores e os distribuidores de software, porque o que é conveniente para um dos lados muitas vezes é inoportuno para o outro.

É precisamente o caso: o Linux Mint obtém seus pacotes via Ubuntu LTS, e assim costumeiramente distribui versões antigas de aplicativos (como o GNOME Calendar), contendo bugs e problemas já corrigidos pelos desenvolvedores (em versões lançadas meses ou anos depois daquela).

Acontece que os usuários do Mint (com razão!) percebem essas falhas do aplicativo, e usam os links de contato da documentação dele para entrar em contato com os desenvolvedores, pedindo solução ou suporte, o que os onera longamente com esse atendimento, além de causar um dano desnecessário à sua imagem.

Segundo o relato do desenvolvedor em questão, isso acontece desproporcionalmente com os usuários do Mint, apesar de serem as mesmas versões empacotadas por outras distribuições (como o Ubuntu LTS).

O desenvolvedor agora classifica o Mint como uma distribuição "hostil", após meses de tratativas em que o Mint responde apenas com versões repaginadas da mesma afirmação: "a gente pega os pacotes do LTS da outra distribuição e temos nossos problemas". Os distribuidores do Mint estão, naturalmente, exercendo um direito dado pela licença, de distribuir qualquer versão que queiram, mesmo se isso onerar desmedidamente os desenvolvedores, que também tem outros problemas.

Claramente a comunicação não está funcionando, e o que havia de reserva de empatia nesse relacionamento também já acabou. Aguardaremos, portanto, os próximos capítulos.

Referência: Linux Mint and GNOME Calendar Clash Resurfaces Months Later

Quem já usou está convidado a comentar suas impressões!

Enviado por Marcelo Teixeira (lixoatomicoθprotonmail⸱com)

“Projetado para qualquer computador moderno e sistemas mais antigos com RAM limitada, sempre com arquitetura de 64 bits. Uma versão ideal para revitalizar hardware limitado, combater a obsolescência programada e proteger o meio ambiente. A fluidez e velocidade do sistema se devem ao baixo consumo de recursos dos ambientes desktop selecionados e otimizados.”

“Vendefoul Wolf Excalibur GNU/Linux é uma distribuição completa e gratuita disponível em todas as suas versões e ambientes desktop. Pronto para usar imediatamente (impressoras, Bluetooth, etc.) com consumo mínimo de recursos. Não inclui telemetria ou inteligência artificial integrada. Ele vem com uma seleção selecionada de software para ajudá-lo a ser produtivo desde o início em um ambiente intuitivo e personalizável. Perfeito para migrar de qualquer outro ecossistema.”

“Baseada no Devuan 6 (um fork do Debian 13), ela apresenta o kernel vendefoul personalizado, XLibre (um fork do Xorg) e OpenRC por padrão. SysV ou Runit são opcionais. Ideal para Live-USB ou uso persistente, bem como para instalações completas.”

Referência: vendefoul-wolf-linux.sourceforge.io