Postagem do administrador do lemmy dbzer0 traduzida:

Eu descobri isso depois de atualizar nossa instância ontem, o que também atualizou todos os frontends para suas versões mais recentes. Depois que fiz isso, o frontend do Tesseract parou de funcionar e eu notei imediatamente, já que é o meu principal há um bom tempo. Inicialmente achei que era uma incompatibilidade de versão de API, mas não, era muito pior.

Alguém apontou que o desenvolvedor do frontend adicionou uma blacklist explícita oculta e imutável, que inclui qualquer e todas as instâncias à esquerda de Kissinger. Existe um commit que também explica sua justificativa falaciosa especificamente sobre nossa instância, já que parece que estamos na lista de desafetos deles há mais tempo do que isso.

Esta instância e sua equipe administrativa encorajam política de identidade, pensamento de grupo, mentalidade de multidão e soluções extremistas para problemas da sociedade. Usuários que defendem violência não são moderados enquanto os administradores concordarem com o alvo. Cuidado e pensamento crítico são aconselhados ao interagir com esta instância ou seus usuários.

Quando você usa o tesseract para se conectar a uma dessas instâncias na blacklist, você simplesmente recebe uma mensagem informando que o Tesseract “é incompatível com essa instância”, o que leva a crer que é uma questão técnica, como uma incompatibilidade de API, em vez de o dev ser um covarde com opinião própria.

Não é engraçado como todo o software desenvolvido pela turbolibs, como Piefed e Tesseract, acaba trazendo mecanismos ocultos de controle por parte de desenvolvedores que acham que sabem melhor do que todo mundo? Que eles não só acham que merecem te dizer no que você deve pensar, mas que deveriam te manipular para pensar nisso? Não é engraçado como libs falam sobre como é ruim dar suporte ao lemmy por causa da ideologia dos devs por trás disso, e ainda assim o lemmy tem 0 opiniões como software? Isso faz pensar...

De qualquer forma, eu fiz um fork - como se faz - e desativei a blacklist, mas já que esse software é massivamente comprometido ideologicamente, duvido que eu mantenha esse frontend depois do Lemmy 1.0. Acho que vamos trazer o mlmym de volta agora que alguém está mantendo ele novamente.


EDIT: atualizei a tradução para uma de melhor qualidade

 

Mudanças

Esta versão reduz significativamente o uso de memória para o backend do Lemmy. Métricas em instâncias de produção mostram uma redução de até 10 vezes. Aqui você pode ver as estatísticas de algumas instâncias diferentes. Leia mais para uma explicação técnica abaixo. Observe que a alteração afeta apenas x86, não há diferença no ARM (ex. Raspberry Pi), veja aqui para detalhes.

lemmy.ml (uso geral da memória RAM, incluindo sistema operacional, Docker, PostgreSQL etc):

leminal.space (apenas recipiente de backend)

lemmy.world (recipientes de API de backend)

lemmy.world (federação de backend e tarefas agendadas)

Como foi possível uma melhoria tão grande? O uso de memória em idiomas como Rust ou C é gerenciado por um chamado alocador de memória. Ele solicita grandes pedaços de RAM do sistema operacional e fornece pedaços menores quando necessário no programa. Por exemplo, cada string (como títulos de postagem ou texto de marcação) requer pedaços de memória para armazená-los. Ao processar os dados são concluídos, a memória deve ser liberada e liberada ou reutilizada.

Até a versão 0.19.19 Lemmy usou o mimalloc alocador de memória, que é supostamente melhor do que o padrão glibc alocador. No entanto, uma postagem recente no blog aponta que mimalloc não joga bem com o tokio tempo de execução do async. sugere usar jemalloc em vez disso. Alterar alocadores de memória é muito simples em Rust, requer apenas uma única linha de código. Então, tentamos isso, implantamos a mudança no lemmy.ml e imediatamente se mostrou eficaz.

Instruções de atualização

Não há mudanças de ruptura com esta versão.

Siga as instruções de atualização para ansible ou docker.

Se você precisar de ajuda com a atualização, você pode perguntar em nosso fórum de suporte ou no Matrix Chat.

Obrigado a todos

Gostaríamos de agradecer aos nossos muitos colaboradores e usuários do Lemmy por codificar, traduzir, testar e ajudar a encontrar e corrigir bugs. Estamos felizes que muitas pessoas acham útil e agradável o suficiente para contribuir.

Apoio desenvolvimento

Nós (@dessalines e @nutomic) trabalhamos em tempo integral no Lemmy há mais de cinco anos. Isso é em grande parte graças ao apoio da NLnet Foundation, bem como doações de usuários individuais.

Se você gosta de usar o Lemmy, e quer ter certeza de que estaremos sempre disponíveis para trabalhar em tempo integral construindo-o, considere doar para apoiar seu desenvolvimento. Uma doação recorrente é a melhor maneira de garantir que softwares de código aberto como o Lemmy possam permanecer independentes e vivos, e nos ajude a aumentar nossa pequena cooperativa de desenvolvedores para oferecer suporte a mais desenvolvedores em tempo integral.

 

Hey, guys. @ryper@lemmy.ca brought to my attention that Valve already addressed the situation about the batteries for the steam deck LCD.

For those who are out of the loop, I posted this news article earlier today: https://www.gamingonlinux.com/2026/07/it-looks-like-ifixit-wont-be-getting-any-more-steam-deck-lcd-spare-parts/

Here's the most relevant bit from this article:

The Reddit story wasn’t necessarily false. Earlier today, iFixit CEO Kyle Wiens confirmed to The Verge that it had indeed heard that Valve would no longer make replacement batteries or screens for the original Steam Deck LCD.

But by afternoon, Valve and iFixit had already managed to change that. “They have hooked us up with a supplier, we’re working on it,” Wiens now tells me. And if Valve does decide to sunset the part in the future, iFixit says it’ll be ready to take up the torch by using an aftermarket supplier instead. “I want people to know we are going to find a way to get batteries for these things,” says Wiens.

view more: next ›