O Rsync 3.5 acaba de ser lançado , e o arquivo NEWS da versão o descreve como um “lançamento extraordinário”, associado ao volume de problemas de segurança. Os 33 problemas de segurança foram localizados após uma auditoria focada no tratamento de paths, em questões associadas ao uso do rsync como daemon, e outros aspectos descritos na documentação.
A versão inclui a correção para vários CVEs, indicando prioridade para a instalação do upgrade.
Enviado por Renato Yamane, a partir de uma thread no Github
O Euro-Office foi lançado em 27/Março/2026, com a sua primeira versão em 9/Junho/2026. A iniciativa parecia muito boa: mais transparência, maior colaboração, menor dependência da influência Russa, sendo uma provável alternativa ao Microsoft O365.
A intenção era de lançar um patch a cada 2 semanas, porém como pode ser visto na edição do primeiro comentário, as datas nunca são cumpridas, ficando reduzido a uma versão inicial com o número da versão ainda errada.
A página inicial do projeto lista 12 empresas como colaboradoras, porém nas minhas tentativas de contato com essas empresas, aparentemente elas só emprestaram o nome para ser incluído na lista, sem colaborar com o desenvolvimento ou com suporte financeiro.
Arregalei os olhos incrédulo quando uma das empresas me respondeu que a colaboração que eles dão ao projeto é basicamente um suporte moral: "...We wish the project success, and plan to use it in our products..."
Aparentemente, há apenas UMA empresa por trás desse fork, que nasceu dizendo que a intenção era de melhorar a transparência do projeto, dentre outros maravilhosos argumentos, porém na minha percepção, tudo leva a crer que o fork foi lançado aproveitando a crise geo-política global e esperando que centenas de desenvolvedores abraçassem a causa, porém ninguém apareceu.
Será que a única empresa por trás desse projeto dará conta de continuar o desenvolvimento de uma suíte de escritório com quase 2 décadas de desenvolvimento (https://en.wikipedia.org/wiki/OnlyOffice)?
Será que uma empresa que diz que a triagem dos "issues" seja feita em 48h, mas nem o próprio desenvolvedor que criou essa regra é capaz de seguir a própria regra, terá condições de dar sequência ao desenvolvimento desse projeto?
No momento é gratuito e disponível para Android e Windows – mas está planejada a inclusão no GitHub e adoção de desenvolvimento aberto.
Enviado por Júlia Zuchini (θifspjcr)
O Papuguinho é 100% gratuito, feito para auxiliar profissionais e famílias, e conta com atualizações constantes.
Um sistema 100% gratuito de Comunicação Aumentativa e Alternativa (CAA), o Papuguinho, foi desenvolvido por estudantes do Instituto Federal de São Paulo – Campus Jacareí (que atualmente conta com o apoio de outras instituições, como o Instituto de Ciência e Tecnologia da Unifesp - Campus São José dos Campos e a Unesp) para o público neurodivergente como um todo, incluindo crianças com Transtorno do Espectro Autista (TEA) e pessoas com dificuldades de fala e interação. Isso é possível porque a CAA é um conjunto de ferramentas e estratégias que visa auxiliar pessoas com dificuldades de comunicação a expressar necessidades, pensamentos e sentimentos. O sistema também foi pensado e desenvolvido para atender tanto a profissionais da área quanto a famílias, o que torna o uso acessível a todos.
O Papuguinho foi criado para atender às necessidades reais de crianças com TEA e fortalece as conexões entre pais, cuidadores e crianças por meio de uma comunicação mais clara. O sistema funciona com pranchas visuais: uma interface intuitiva que permite às crianças formarem frases faladas ao tocar em ícones coloridos. Ainda é possível adaptar as pranchas às necessidades individuais com temas customizáveis.
Durante o processo de desenvolvimento, todas as etapas contaram com pesquisas, estudos e fundamentos. A prova está na própria escolha do nome e das cores usadas: após as pesquisas, ficou evidente a preferência por tons como azul e verde, além da relação com a natureza. O nome remete ao papagaio, ave conhecida por reproduzir sons, e, da mesma forma, o Papuguinho dá voz às crianças, com o objetivo de ser um companheiro fiel que ajuda na expressão e na comunicação do dia a dia.
Inicialmente, o aplicativo foi desenvolvido no FlutterFlow em busca de agilidade. Agora, porém, está sendo programado tradicionalmente — mantendo o Flutter — para permitir ajustes mais precisos no código e lançamentos multiplataforma, utilizando o Firebase como banco de dados. Futuramente, o projeto disponibilizará o código-fonte no GitHub, onde aceitará contribuições da comunidade.
Atualmente, o Papuguinho está disponível no site e para download no Android (via Play Store) e Windows (via Microsoft Store), com versões planejadas para macOS, iOS e Linux.
Sou o desenvolvedor do Nexus Shell, um cliente SSH proprietário e nativo para macOS, criado em SwiftUI para administrar servidores Linux a partir de Macs com Apple Silicon. A versão 1.6.9 reúne terminal com abas, gerenciamento de arquivos via SFTP, chaves SSH, controles para contêineres Docker, monitoramento somente leitura de servidor e rede, além de registros de sessão criptografados localmente. O aplicativo requer macOS 14.2 ou posterior; o uso pessoal e não comercial do SSH básico é gratuito, e o cadastro inclui sete dias de avaliação Pro.
A proposta é manter uma ferramenta visualmente integrada ao macOS, simples para o trabalho diário e sem acumular recursos desnecessários. A versão Pro custa US$ 12,88 em pagamento único. Há também um TestFlight público para a futura versão da Mac App Store. O Nexus Shell não é software livre nem um cliente Linux: ele é uma ferramenta para usuários de Mac que administram máquinas Linux e outros servidores por SSH. A página oficial contém downloads assinados, requisitos, política de privacidade e o histórico completo de versões.
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.
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.
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.
Enviado por André Machado (andremachado⸱socialθoutlook⸱com)
O produtor de conteúdo Slackjeff teve sua casa assaltada e todos os seus equipamentos de trabalho subtraídos. Ele pede ajuda com doações através de uma chave Pix, divulgado no seu canal, pelo link abaixo.
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.
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).
Enviado por Marcelo Teixeira (lixoatomicoθprotonmail⸱com)
Mais uma distribuição com Arch+Hyprland? Acho que não. Lindíssima! Mas... Pesada...
https://mainstreamos.org/
“Mainstream OS – Arch, acessível. Hyprland, em casa. - Arch sob o capô, Hyprland na superfície e o polimento do macOS na parte superior - um desktop aberto, que parece perfeito, seja seu primeiro Linux ou o décimo. Nada precisa de terminal; nada não pode ser desfeito.”
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.
O simpático Jellyfin é uma das boas alternativas1 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.
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
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.
software, seguranca, administracao
Comentar |
Link para compartilhar
Por Augusto Campos |
13/08/2026
