BR-Linux.org

O Euro-Office é o pacote de aplicativos de escritório que nasceu da positiva onda de soberania tecnológica da União Europeia, vem sendo desenvolvido por um consórcio de empresas e projetos (como Nextcloud, Open-Xchange, OpenProject, Proton e Tuta) e tem como principal base um fork do código open source do ONLYOFFICE (que é de origem russa, e cujos desenvolvedores não aderiram ao esforço da União Europeia).

Aplaudimos a existência e desejamos sucesso ao Euro-Office, mas há algo que ele diz ser, e não é – ou, no mínimo, há espaço para contestação, mesmo que não se dê total razão ao incômodo expresso pelo LibreOffice sobre o Euro-Office dizer que é o primeiro pacote de escritório open source europeu.

A carta aberta do LibreOffice, datada de hoje, começa assim:

Nos últimos dias você tem lido vários artigos anunciando a chegada do Euro-Office, que anunciado como o primeiro pacote de escritório de código aberto desenvolvido na Europa. Somos compelidos – com relutância, uma vez que o código aberto deve basear-se na transparência e não na fraude – a corrigir esta afirmação. O primeiro pacote de escritório de código aberto desenvolvido na Europa foi o OpenOffice.org em 2001, baseado no código-fonte do StarOffice, e seguido pelo LibreOffice a partir de 2010.

Eu estou nesta estrada há tempo suficiente para ter usado o StarOffice para Linux (importei uma caixa enorme de discos de instalação e manuais impressos, na época vendidos na Alemanha pela SuSE). Comemorei a abertura do seu código, que veio na virada do século, após a compra pela Sun Microsystems (dos EUA).

No ano 2000 Sun abriu o código do StarOffice, que comprou em 1999 da empresa alemã que o desenvolvia desde 1985. Esse código deu forma ao OpenOffice, mantido pela Sun até a aquisição da empresa pela Oracle, em 2010. A aquisição pela Oracle acabou dando o ensejo para a criação do fork comunitário LibreOffice (também em 2010), administrado pela The Document Foundation, uma ONG sediada na Alemanha. Em paralelo, no ano seguinte, o código e a marca do OpenOffice foram herdados pela Apache.

Para mim, há pouco espaço para dúvida: o LibreOffice é um pacote de escritório open source europeu, desde 2010. O fato de o código ter sido aberto nos EUA não muda a sua origem, nem interfere na nacionalidade do projeto.

Afinal, se o Euro-Office quer dar importância especial ao país de origem de cada aplicativo, é bom que o faça de forma consistente.

Referência: blog.documentfoundation.org

Quem tem demanda de instalar com frequência sistemas operacionais em computadores de uma placa só (como o Orange Pi, Banana Pi, Odroid, Raspberry Pi e similares) vai gostar de saber que agora o gerador de imagens de instalação do Armbian permite configurar previamente itens como login, senha, Wi-Fi, fuso horário, localização, chaves SSH e shell.

Ter esses detalhes pré-configurados na imagem permite dar boot com um estado muito mais pronto para uso na máquina de destino, que frequentemente tem menos recursos e usabilidade do que a máquina usada para gerar a mídia de instalação – já que o Armbian Imager roda em Linux, Mac e até Windows.

Na prática, em alguns casos, isso permite ter a máquina acessível e configurável remotamente desde seu primeiro boot, sem que ela precise ter um console local.

Armbian, você sabe, é um projeto que disponibiliza uma plataforma unificada, baseada em software do Debian e do Ubuntu, pronta para produção em mais de 300 computadores baseados no fragmentadíssimo ecossistema do hardware ARM. As imagens de instalação do Armbian incluen o kernel e configurações específicos para cada placa, com drivers testados e grande chance de a placa funcionar de primeira, sem ter que recorrer a forks de cada fabricante.

Referência: Armbian Imager 2.0 Flashing Tools Debuts with First-Boot Setup Profiles

Vejam que momento mágico eu escolhi para recolocar no ar o BR-Linux: cada vez mais, precisaremos de conteúdo escrito por pessoas que desejam ser lidas por pessoas!

Os acessos vindos de bots (automatizados) já são 57,5%, de acordo com os dados mais recentes da Cloudflare, um dos maiores funis dos conteúdos da web moderna. É a primeira vez na história em que isso acontece, e antecipou até mesmo a previsão pessimista do CEO da empresa, que previa para o ano que vem essa ultrapassagem.

E não são aqueles bots ~tradicionais (rastreadores de sites, indexadores de pesquisa, bots de DDoS, etc.): a Cloudflare sublinha que está mapeando agentes que navegam na web fingindo serem pessoas, em nome de pessoas, e que _isso_ já está em grande escala, em tarefas como comparar preços, pesquisar voos, pedir refeições ou lidar com interações de SACs e atendimento a clientes em geral.

Em termos de tempo on-line, entretanto, os humanos continuam ~ganhando.

Referência: ‘Bots have now passed human traffic online,’ Cloudflare boss laments — says agentic traffic wasn’t expected to eclipse real people until next year

Quero começar dizendo algo que precede: tenho imenso respeito pelo legado de Andrew Tridgell, o desenvolvedor em questão. Sua principal criação – o Samba (1992-) – foi um dos grandes impulsionadores da vitória do código aberto nos conflitos da interoperabilidade com redes proprietárias, na virada do século. Não satisfeito, ele também co-inventou o rsync (1996-), que há décadas é um fundamento da sincronização de arquivos entre servidores, e um elemento central em muitas estratégias de backup.

Isso não impede minha rejeição (na verdade, aumenta o tamanho da decepção, embora eu não negue que ele tenha o direito de se posicionar como bem entender) à resposta que ele publicou sobre a recente controvérsia causada pelas regressões no código do rsync, iniciadas quando ele resolveu aplicar vibe coding ao seu desenvolvimento, como vimos neste post anterior aqui no BR-Linux: “Novas versões do rsync trazem bugs críticos surpreendentes e foram feitas com IA”.

A resposta dele me desaponta por vários motivos, mas o principal é se esforçar para desqualificar coletivamente quem criticou a situação.

A resposta dele me desaponta por vários motivos, mas o principal é ele concentrar boa parte dela em uma visão que desqualifica coletivamente (com expressões como “uma enxurrada de lama dos assim chamados especialistas da internet”) quem criticou a situação atual do código – que objetivamente não é boa, ainda mais se comparada ao histórico do próprio projeto.

A resposta dele também me preocupa, porque ele confirma que preferiu uma estratégia em que a IA não apenas escreve o código novo para o rsync, mas escreve os testes que validam esse código novo. O resultado nós vimos nas atualizações recentes (e não surpreende, dado o método), Mas Tridge defende longamente essa escolha, e rejeita (literalmente) os PhDs que apontam os riscos dessa estratégia, como se estivéssemos falando de um risco teórico, e não da sua materialização na forma de regressões em um sistema previamente estável.

A resposta de Tridge também me causa rejeição porque ele – que acusou os outros de jogarem lama – aproveitou para jogar lama no openrsync (que eu uso há anos, e agora vou usar em mais máquinas) como alternativa a quem deseja migrar do seu projeto, com o argumento de que não passa em boa parte da sua nova suíte de testes (aquela que ele acabou de pedir para a IA criar…).

Esse argumento dele é duplamente ruim: primeiro, porque desconsidera que o openrsync atualiza segurança e compatibilidade, mas intencionalmente congelou sua base nos recursos e interfaces do rsync de uma versão estável de um bom tempo atrás (é com o rsync 3.1.3, de 2018), portanto naturalmente não passaria em testes desenhados para atestar compatibilidade com versões posteriores. E segundo, porque no mesmo post, Tridge sugere aos descontentes que instalem versões anteriores do próprio rsync (mesmo sabendo que elas possuem falhas de segurança, que foi o que o motivou a usar vibe coding no projeto, conduzindo à situação atual).

Em suma, uma má resposta, que não resolve nenhum problema, por mais que o autor tenha direito de se sentir injustiçado ou desvalorizado pela enxurrada de críticas.

Mas há algo que me dói um pouco mais, e aí é a favor do Tridge, e não contrário ao seu posicionamento: ele abre o texto dizendo que está aposentado, e prefere ir velejar do que ficar cuidando de softwares. Ao longo do texto, ele retorna a essa ideia. É evidente o quanto ele está em busca de uma alternativa que permita viabilizar isso (e pensou ter encontrado na IA).

Eu concordo com ele quanto ao desejo: ele tem direito, e merece poder desfrutar da aposentadoria. Sabemos que ele já tentou passar o rsync para outro mantenedor, mas não deu certo, e o projeto voltou a ele.

Tomara que uma próxima tentativa dê mais certo, Tridge possa se aposentar efetivamente, e deixe o projeto em boas mãos.

O BR-Linux, que completa 30 anos em novembro deste ano, deseja feliz aniversário ao Phoronix, que é o aniversariante do dia. Parabéns!

Hoje completam-se 22 anos desde o dia em que Michael Larabel criou o Phoronix, inicialmente voltado a reviews de hardware rodando Linux, e hoje um dos principais recursos internacionais de notícias e comentário especializado sobre a cena open source.

Parabéns ao Michael pela resiliência, pela qualidade do resultado, e por continuar resistindo a se juntar a um cenário cada vez mais caracterizado por veículos que copiam conteúdo alheio ou se limitam a transcrever releases recebidos das assessorias de imprensa das marcas, ou mesmo a vender seu espaço para publicar propaganda fingindo ser conteúdo editorial.

Referência: phoronix.com

Em um evento voltado a desenvolvedores, a Microsoft anunciou o Coreutils for Windows, descrito como parte de uma estratégia para tornar o Windows uma plataforma amigável a esse público (ao aproximá-lo cada vez mais da linha de comando das distribuições de Linux, mas essa parte ela não disse em voz alta).

A turma do Retrópolis certamente vai identificar um padrão 👇🏻 ao saber que a Microsoft anunciou ontem o lançamento do componente 'Coreutils for Windows', levando ao sistema deles uma implementação nativa, e oficialmente mantida, de uma série de comandos e utilitários herdados do Unix dos anos 1970 e 1980, e que a partir de 1990 evoluíram como parte do GNU Coreutils (que só ganhou esse nome a partir de 2002, porque antes era dividido entre textutils, shellutils, fileutils e mais alguns pacotes isolados).

A implementação da Microsoft usa a mesma estratégia do BusyBox: um único executável, e inúmeros links apontando para ele, com nomes distintos como cat, cp, mv, ls, base64, pwd, tee e muitos mais. E o pacotão da Microsoft usa a reimplementação das coreutils em Rust (aquela mesma que a Canonical incluiu cedo demais como default no Ubuntu), e também incluiu alguns softwares extras, relacionados aos comandos find e grep.

Alguns dos comandos, que dependem de funcionalidades do POSIX que não são nativas no Windows, não foram incluídos na versão atual – assim, não estão disponíveis itens como chmod, chown, chroot, nohup, tty, kill e timeout. Quanto aos que foram incluídos, a Microsoft já avisa para não esperar compatibilidade plena e imediata, porque até a forma como os 2 sistemas identificam o final de cada linha de texto é diferente, e certamente haverá outras diferenças mais profundas a serem identificadas para corrigir ou conviver.

E o padrão retrô que eu mencionei acima é este: os comandos mais essenciais do Unix sempre acabam dando um jeito de chegar às plataformas da Microsoft, cuja linha de comando suporta os recursos necessários de redirecionamentos e pipes, mas não vem com a mesma riqueza de filtros para explorá-los.

Eu já fui usuário dessa ideia ainda no século XX, com o pacote MSX-DOS Tools (lançado em 1987 pela Ascii Corp., parceira da Microsoft no Japão), que incluía no MSX-DOS da Microsoft vários comandos do Unix como grep, head, tail, tr, uniq, wc, sort e patch.

Referência: infosec.exchange

A versão 4.1.2 do Transmission chegou trazendo mais de 20 correções de bugs.

Quase não há novas funcionalidades nessa versão, o que não significa que você não deva instalá-la, já que alguns dos bugs corrigidos tem implicações diretas em segurança do sistema, e em estabilidade das transferências de arquivo – incluindo um bug quase sádico, que às vezes deixava um download estacionado permanentemente em 99%, sem jamais indicar sua conclusão.

Referência: techhub.social

No momento, o foco da firma do ex-astronauta é a turma que acredita na IA como motor do futuro do desenvolvimento de software, e ontem ele deixou isso claro ao palestrar em um evento em que seu assessor para assuntos de tecnologia aproveitou para afirmar que eles rejeitam a postura de quem se mantém afastado da IA por princípios morais.

Sabemos que o Ubuntu não deseja ser, nem nunca desejou, uma continuidade daquela visão do que seria uma distribuição Linux ortodoxa (melhor representada por projetos como o Slackware); a esta altura já não surpreende que esteja a cada 4 anos mudando quem é o seu público-alvo (já foi mobile, já foi a turma da convergência de telas), nem que abandone na chuva o público-alvo anterior a cada troca de foco – que é a parte que me levou a abandoná-lo há 16 anos (hoje minha distribuição do dia a dia é o Debian, nunca fui triste), após uma regressão grave na qualidade do instalador, que me custou dados e muito stress, na época em que eles resolveram se concentrar em ter seu próprio ambiente gráfico.

E a palestra do CEO da Canonical e ex-astronauta Mark Shuttleworth deixou clara, mais uma vez, essa desconexão com o legado, pois ele falou com todas as letras: para esse mundo novo que ele enxerga como o futuro para o Ubuntu, não há alternativa exceto “os usuários irem além do apt e rpm, para snaps assinados, atualizados automaticamente e orientados por políticas” – formato e modelo de distribuição de pacotes que a empresa dele prefere há tempos, e agora justifica com a palavra mágica “IA”.

Outro ponto em que o ex-astronauta apresenta a mesma desconexão em relação ao modelo ortodoxo de Linux é a insistência em containers. Para ele, containers são a solução desde a base, com "tudo rodando em caixas de ferramentas isoladas em camadas", o que seria uma solução ideal para a sua visão em que seu público-alvo “deseja rodar milhares de agentes”, e assim cada instância do Claude e do Copilot terá completo isolamento.

Essa solução containerizada é complementada pelo 'Workshop', um modelo que permite ao administrador hierarquizar os tokens, senhas e acessos, passando a cada agente apenas o conjunto que ele precisa ter, e reduzindo assim a atual onda de ataques em que agentes roubam conjuntos inteiros de credenciais de máquinas de desenvolvimento ou acessíveis por elas.

Esse público-alvo a que ele está se dirigindo existe? Certamente, e parte dele deve até mesmo estar lendo o BR-Linux neste momento, enquanto acredita no acerto das medidas da Canonical – e pode até estar certo, quanto ao sucesso mercadológico do contexto tecnológico que a empresa adotou, pois nada está definido no momento.

A certeza que eu tenho, entretanto, é que eu não sou parte desse público-alvo, e isso não mudaria, caso eu fosse fã de IA no desenvolvimento de software. No nível sistema operacional, eu prefiro interfaces e conhecimentos estáveis ao longo de muitos anos, e não uma sucessão de tentativas periódicas de me levar a adotar um novo ambiente, um novo padrão de empacotamento, um novo conjunto de coreutils etc., enquanto vejo os recursos e requisitos que eu valorizava sendo largados pelo caminho.

Referência: tech.lgbt

O OMGUbuntu destaca o jogo El Poblador, uma implementação open source do jogo de tabuleiro Settlers of Catan, feita em Go, que funciona no terminal e permite partidas entre até 4 jogadores.

Por enquanto funciona apenas em modo local (ou seja, várias pessoas se alternando em frente a um mesmo terminal), mas a expansão para partidas entre jogadores remotos já esta planejada. E achei bem bonitinha a interface TUI já implementada!

O desenvolvedor não buscou permissão para usar a marca registrada, então nada de chamarmos de Settlers of Catan – o nome é El Poblador! Quanto ao código, entretanto, está tudo bem definido: é open source e free software, com a licença EUPL 1.2, da União Europeia – mesma licença do Pi Hole, entre outros projetos.

Referência: techhub.social.

Mais de 30 pacotes npm disponibilizados no namespace ‘@redhat-cloud-services’, da Red Hat, foram comprometidos em um ataque que distribuiu uma nova variante do malware de roubo de credenciais Shai-Hulud, apelidado de “Miasma”.

“A Red Hat está ciente dos relatórios de segurança sobre certos pacotes npm em nosso ecossistema de ferramentas de desenvolvimento. Iniciamos imediatamente uma investigação e removemos os pacotes do registro npm”, diz o comunicado que a empresa está distribuindo à imprensa.

A Red Hat também diz que os pacotes estão limitados ao uso no desenvolvimento interno, e que "não identificou nenhum impacto a sistemas de clientes ou parceiros, ou a ambientes de produção internos", e se negou a responder sobre como foi que os pacotes foram infectados.

Já as empresas de segurança Aikido e OX Security, que identificaram e reportaram a situação, dizem que os pacotes em questão (96 versões de um total de 32 pacotes) recebem cerca de 117 mil downloads semanais, e que o malware inserido nos pacotes foi projetado para roubar credenciais de desenvolvedores, segredos de nuvem, chaves SSH, tokens CI/CD e outras informações confidenciais.

Está mesmo sendo um ano distópico para o cenário da tecnologia da informação em geral, e da segurança digital (e da privacidade) em particular: essa mesma família de malwares já foi encontrada também em pacotes mantidos por organizações como Bitwarden, SAP, Mistral, TanStack, OpenAI e o próprio GitHub.

Neste momento, a orientação a quem instalou algum das versões afetadas é rotacionar imediatamente todas as credenciais, segredos e tokens utilizados pelo código no dispositivo infectado.

Via BleepingComputer: Red Hat npm packages compromised to steal developer credentials.

O projeto Rust Coreutils anunciou sua nova versão 0.9, que passa a usar como referência para testes de compatibilidade o GNU Coreutils 9.11 (até então era o 9.10).

Rust Coreutils, você sabe, é uma implementação em Rust de uma série utilitários fundamentais da linha de comando, fornecidos pelo pacote GNU Coreutils, como cp, mv, rm, ls, cat, head, tail, wc e chmod.

Esse tipo de componente é um caso de uso ideal para uma reescrita que aproveite as vantagens de segurança e desempenho que o Rust traz, e o projeto busca oferecer substitutos compatíveis para essas ferramentas.

Mas compatibilidade é mesmo o conceito-chave aqui: o ecossistema tem décadas de acervo de scripts e bibliotecas fazendo uso das interfaces e formatos (documentados ou não) adotados pelas ferramentas originais, e qualquer mudança nas entradas ou nas saídas gera efeitos inesperados, imprevisíveis, e surpreendentes, de um jeito ruim.

Os desenvolvedores estão cientes e atentos para isso, o que talvez não seja o caso de alguns distribuidores, como os do projeto Ubuntu, que decidiram colocar desde o ano passado esse código em versões de produção, decisão que rejeito (mas não coloco na conta dos desenvolvedores, e sim dos distribuidores) – concordo 100% com a medida, mas não com a oportunidade, já que sacrifica a estabilidade e compatibilidade de hoje em prol de vantagens que serão colhidas apenas pelos usuários no final do ciclo de suporte da atual versão LTS.

Quanto à nova versão, o Changelog indica que além de melhorias de arquitetura de segurança, tivemos melhorias de desempenho (em comandos como cat, wc, head, tail, yes, cp, tee e unexpand), de compatibilidade (ls, numfmt, date, tr, cksum, factor, head, stat e sort) e suporte a modelos cross-platform.

Vem da fundamental Dra. @melissawm@pynews.com.br o aviso de que está no ar o vídeo completo da transmissão ao vivo da primeira edição do Nosso Open Source Summit: um encontro aberto sobre FLOSS (Free/Libre and Open Source Software) no Brasil, reunindo pessoas que constroem, mantêm e querem entrar no ecossistema de tecnologias abertas para compartilhar experiências, fortalecer projetos e criar comunidade.

 
Consulte também a programação completa deste evento, que aconteceu no sábado.

Parabéns aos organizadores e a todo mundo da Cumbuca Dev. Que venham outras edições!

Um cenário de pesadelo começou a se desenrolar na noite de quinta, quando @JeremiahFieldhaven@mastodon.gamedev.place compartilhou seu relato sobre uma regressão grave de funcionalidade no rsync 3.4.3, e sobre o que ele descobriu ao ir inspecionar o código-fonte: as alterações dessa e de outras versões recentes não estão mais assinadas mais só pelo mantenedor (o Tridge, que conhecemos desde o século 20), mas por uma dupla: Tridge and Claude.

Ou seja: a IA entrou em cena em um utilitário que fundamenta os backups de muitos de nós, e entrou com aquele workflow típico: ao arrumar um bug, gera outros dois em partes do código que nem estavam relacionadas, e a gente começa a ver um padrão de patches feitos por IA, que estão lá para consertar bugs introduzidos por patches anteriores, também feitos por IA. A thread do link acima (assim como outros locais também) esmiuça isso um pouco mais detalhadamente, relatando outras regressões encontradas em versões recentes, numa inspeção inicial do código.

Como case de adoção de IA, é interessante para estudo, talvez vire caso antológico até, já que é um desenvolvedor experiente e renomado, e um software altamente popular. Escolha dele, claro. Do ponto de vista de quem recebe e usa um software previamente estabilizado, entretanto, provavelmente atende mal e leva a procurar alternativas.

A situação ainda está se desenvolvendo, possivelmente haverá respostas dos envolvidos, e mais detalhes, contrapontos ou explicações surgirão. Convém acompanhar. Mas vale lembrar: existe o fork openrsync, integrante da árvore de projetos do OpenBSD (sendo, portanto, irmão do openssh). Eu uso há anos.

Mais um final de semana, mais uma vulnerabilidade que dá acesso indevido de root em distribuições Linux variadas: desta vez é o CIFSwitch, que permite que um usuário local sem privilégios obtenha acesso root por meio da interação entre o cliente CIFS do kernel Linux e o utilitário cifs-utils. CIFS, você sabe, é o nome popular moderno (a partir de 1996) do tradicional SMB, protocolo de compartilhamento bastante conhecido de quem faz integração entre redes Linux e Windows.

Dependendo da configuração de recursos como AppArmor ou SELinux, o bug pode ser mitigado, mesmo quando presente. E ele está presente na configuração default de uma série de versões de distribuições como Linux Mint Cinnamon, CentOS Stream 9, Rocky Linux 9, Kali Linux headless, AlmaLinux 9.7, SLES 15.

Em várias outras distribuições, o bug não é instalado por default, mas estará presente se o usuário tiver instalado o cifs-utils. Nesse grupo, temos: Ubuntu 18.04/20.04/22.04 Desktop/Server, Ubuntu 24.04 Desktop minimal/full e Server, Debian 11/12/13 netinst standard e GNOME/KDE/standard/XFCE, CentOS Stream 9 Cinnamon/KDE/MATE/XFCE, Rocky Linux 9 KDE/Workstation-Lite, openSUSE Leap 15.6 GNOME/KDE, openSUSE Tumbleweed GNOME/KDE, Rocky Linux 8 GenericCloud, Oracle Linux 8/9 KVM, Amazon Linux 2023 KVM.

O link acima inclui, ao final, os passos para mitigação imediata (desativar o módulo do kernel ou desinstalar o pacote cifs-utils deve bastar para afastar o risco imediato).