"Distribuições de lançamento regular estão erradas"

“sistemas que mantém pacotes congelados e vão atualizando com patches de correções/segurança… (LTS da vida) mantém softwares frankenstein…”

“Não importa o quão habilidosos sejam os engenheiros, não importa quão grandes sejam os processos e os testes em torno de seu backport, fundamentalmente o resultado é uma combinação híbrida combinada de software antigo e novo que nunca foi originalmente planejado para trabalhar em conjunto.
No processo de tentar evitar riscos, os backports introduzem vetores totalmente novos para que os bugs apareçam.”

“Segurança e estabilidade não podem ser alcançadas ficando paradas.
Novos recursos não podem ser facilmente adicionados se as boas práticas de engenharia forem desencorajadas em nome de parecerem estáveis.
Em softwares tão complicados quanto uma distribuição Linux, muitas vezes, a maneira correta de fazer uma alteração requer uma quantidade significativa de alterações em toda a base de código.
Ou, em outras palavras, “para poder mudar qualquer coisa, você deve poder mudar TUDO” .”

"# Lançamentos regulares negligenciam os pontos fortes do código aberto

A lei de Linus declara que “dados suficientes olhos, todos os erros são superficiais”.
Acredito que essa seja uma verdade fundamental e um dos benefícios mais fortes do modelo de desenvolvimento de código aberto. Quanto mais pessoas envolvidas no trabalho, mais olhos olham para o código, melhor é o código, não apenas no sentido de “falta de bugs”, mas também no sentido de “vários recursos de trabalho”."

https://rootco.de/2020-02-10-regular-releases-are-wrong/

9 Curtidas

Nesse ponto que eu gosto da filosofia do gentoo, que é rolling release sem ser bleeding edge (mas também pode ser bleeding edge se o usuário tiver disposição).

2 Curtidas

Isso me lembrou das críticas que Jeremy Soller – engenheiro principal da System76 – teceu sobre o Ubuntu.

A política deles (Canonical/Ubuntu) se baseia em cumprir com vários requirimentos para que então seja permitido uma atualização, já nós realizamos atualizações de acordo com a necessidade dos nossos usuários, então se os usuários querem tal atualização, eles vão receber tal atualização rapidamente. Ubuntu vai trabalhar em cima de um programa fornecendo patches de correção e segurança, mas não funcionalidades e até mesmo alguns bugs ficam sem patches e no Debian Stable é muito pior.

O que nós estamos vendo é que o ciclo de lançamento (do Ubuntu), não é mais o modelo certo, porque o que nós estamos fazendo a cada lançamento é criar desculpas para mudanças na interface, essa é a única diferença que você vê. Eles se sentem confortável com isso porque assim eles são capazes de empurrar a nova versão. Eu quero criar um sistema operacional o mais perto da perfeição possível, mas mudanças importantes (no Ubuntu) não estão sendo mais feitas. Se tudo está perfeito em um nível, você precisa fazer mudanças nos outros níveis.

Eu particularmente concordo com esse ponto de vista, porque ao meu ver, um sistema que força os usuários a buscar meios alternativos devido a falta de comprometimento na hora de atender o usuário, não deve ser chamado de estável. Estabilidade para um sistema não significa e nem deve significar “aquilo que está desatualizado” ou “aquilo que é burocrático”.

2 Curtidas

OK. Mas como ter uma distribuição rolling-release sem que o usuário comum seja recomendado a verificar o fórum do seu sistema operacional a cada nova atualização para ver se nada corre o risco de quebrar?

opensuse tumbleweed, em teoria, é uma distro rolling release e que vc não precisa consultar uma página pra saber se vai dar ■■■■■

1 Curtida

Bem, é um outro ponto de vista sob o qual não tinha pensado ainda. O copo pode estar meio cheio ou meio vazio a depender do olhar.

1 Curtida

Essa é uma ótima questão, principalmente quando se trata de atualizações de versão de programas. Uma vez que o sistema está rodando com as configurações desejadas, uma atualização desse nível pode obrigar uma alteração dos arquivos de configuração. O usuário comum vai saber fazer um merge das configurações? Então o merge teria que ser automático. Mas como fazer o merge automático sendo o modo de realizar a configuração é direto no texto? Então o correto seria ter uma interface de configuração onde as alterações feitas pelos usuários ficassem bem explícitas para poder atualizá-las automaticamente.

Vejo isso no Tumbleweed, o Yast tenta ser esse agrupador, distanciando a edição dos arquivos textos.

Porém o jeito fácil é fazer as fixed releases, onde os patches e atualizações não tratam desse problema, pois atualizações menores não geram esse inconveniente. Então todos esses pequenos problemas que poderiam ter sido tratados ao longo do ano, acumulam-se numa nova versão da distribuição com um tsunami de trabalho. Alguns comentam ser mais fácil instalar do zero e configurar tudo de novo do que tentar a atualização e virar um detetive de erros.

2 Curtidas

Ninguém disse que Rolling Release é a solução. Eu acredito que as Distribuições que estão mais perto da solução é o Fedora por ter uma base rígida mas ser um sistema atualizado e prático e o Pop!_OS pelos mesmos motivos.

2 Curtidas

Gostei do texto, embora não concorde com algumas coisas do autor.

Uma coisa me chamou atenção no texto, o autor não é daquelas pessoas exaltadas ou ultra parciais, ele apenas aponta o que acha mais interessante no modelo que ele gosta. Gostei, isso é raro de ver. Embora, em minha experiência não tenha encontrado reais problemas em distros com distros fixed release.

Acredito que para alguns perfis de usuários, a ideia do autor, de manter pacotes sempre atualizados (ao invés de manter atualizações, correções etc. para versões específicas de pacotes), pode ser muito útil e interessante. Mas, por outro lado, pode passar a ideia de que algumas distros simplesmente não atualizam a versão de determinados pacotes. Isso também não é verdade. E me leva a pensar como o @TiagoCardoso é o copo meio cheio ou meio vazio.

Outra coisa que ele aponta e muita gente se confunde, é a confusão entre pacotes estáveis e pacotes velhos. E isso se dá, ao meu ver, por falta de informação mesmo. Podem existir distros que preferem manter pacotes em determinadas versões, mas, afirmar que pacotes estáveis são pacotes velhos não é, necessariamente, certo.

Para sair da minha zona de conforto, instalei uns meses atrás o Arch Linux. Porque? Nunca curti muito distros com atualizações muito frequentes e muitas atualizações, praticamente diárias no caso do Arch (porque sempre que usei alguma tive problemas). Bom, depois de uns 6 meses (não lembro exatamente quando instalei) usando o Arch em dual boot com o Debian/Mageia (no note debian e arch no outro pc que tenho, só tem o mageia instalado), passei a entender muito melhor a ideia de distros rolling release. O único “porém” que citaria é: em todas as distros rolling release que usei (Antergos, Manjaro, Fedora, Arch e Sabayon. Que me lembre agora foram só essas), eventualmente, tive problemas com alguma atualização ou algum pacote específico. Uns tempo atrás mesmo, um update do wine fez com que todos os softwares que tivesse deixassem de funcionar.

As três distros que tenho aqui tem propostas diferentes, no sentido de atualização e manutenção de pacotes. O Arch, como todos sabem, é sempre atualizada, com pacotes muito recentes, já vi programa atualizar duas vezes em uma semana no Arch. O Debian é mais estático nessa questão, mas o pacotes são atualizados, porém com bem menos frequência. Por fim o Mageia, embora não seja rolling release, tem um modelo meio intermediário entre o Arch e o Debian. Eles não mantém pacotes em versões muito específicas e costumam ter uma mescla interessante nesse aspecto. Nessa questão, que o autor levanta, acho que o OpenSuse mesmo, o Fedora e o Debian Sid são interessantes. Porém, essa discussão não é muito nova, e não estou falando de RR vs fixed release, e sim da relação entre pacotes sempre na última versão (ou o mais atualizado possível) e a manutenção de pacotes estáveis. De qualquer forma, o autor trouxe argumentos interessantes para esse debate.

Você pode explicar mais? Usei o Mageia 5.x por um tempo, mas nunca me atentei nisso.
Olhando aqui no site da distro, vi que o Mageia 7 não vem de fábrica com uma versão LTS do KDE Plasma, mas espero que isso seja o de menos.


É por isso que passo longe de distribuições rolling-release, quero poder atualizar meu sistema e então desligar o computador com a certeza de que quando eu ligá-lo novamente, tudo está rodando bem. É claro que problemas podem existir até em distribuições fixed-release, mas é bem menos.

Quero tranquilidade! Uso o sistema operacional para trabalhar nos meus projetos, navegar na internet e consumir mídia, não para ficar consertando o sistema.

Não uso a versão com KDE (uso xfce), mas o que quis dizer, é que eles não se preocupam tanto em manter, por exemplo, uma versão “estável” de um pacote se a versão mais recente for mais interessante para eles. Até porque, a distro tem repositórios próprios, então eles tem que pensar nesse tipo de coisa. As pessoas que conheço que utilizam a distro com KDE não tem reclamações, pelo contrário, vejo elogiarem bastante. Nesse ponto não posso falar porque minha experiência com o KDE não é grande e já tem um tempo que tentei utilizá-lo. Os DE’s principais (KDE, Gnome e Xfce) eles mantém sempre em versões mais recentes.

Uai, cê tá meio desatualizado então. O Mageia 5, se não estou enganado, perdeu o suporte em 2017. Eu, que uso, gosto e sempre falo da distro para as pessoas, achei que a versão 7 (7.1 atualmente) deu um salto legal de qualidade (CCM tá bem legal para quem gosta de ferramenta gráfica. Dá para fazer literalmente tudo que um usuário básico precisa por ele). Mas, eu sou suspeito para falar, adoro a distro e a sua comunidade. Embora não seja grande, eles são muito prestativos no fórum e são até bem abertos para a galera que quer ajudar.

Em relação a distros RR, confesso que tive mais problemas usando o Manjaro que o Arch puro, por exemplo. O que quero dizer é: se vai utilizar distros com essa proposta, opte sempre por uma distro “base” e terá menos problemas (ao menos a partir da minha experiência). Mas, quem usa distros RR eventualmente terá que fazer intervenções manuais, sim. Porém, acredito que isso se deva mais a forma como são mantidas as distros RR do que por ser RR em si. No texto o autor cita o OpenSuse na versão RR que não costuma apresentar problemas, ou mesmo o Fedora (que não é propriamente RR) mas não costuma apresentar problemas também.

Eu também prefiro não usar distros RR, não é atoa que utilizo Debian e Mageia. Já tive problemas com elas também. Quando saiu o Debian 10, eu tive um problema com meu vídeo (que é intel) e o light-locker. Quando eu bloqueava a tela, por causa de um bug, eu não conseguia retornar ao modo gráfico. Até eu descobrir a solução, encontrei o bug reportado no site oficial e corrigi o problema. Porém, uso o Debian 10 praticamente desde o lançamento e foi o único problema que tive. Tive um outro com o Firefox, mas foi burrice minha. Porque não uso a versão ESR e eu deixei duas versões instaladas e, sem querer, fiz uma zona nos arquivos de configuração do navegador hahahhhahaha O Mageia eu passei a usar o 7, uns 3 ou 4 meses depois que saiu a versão beta. Tive um problema com o xflock4 e nunca mais tive nada.

Para sintetizar, acredito que isso seja muito pessoal. Tem gente que gosta do modo de ser do Gentoo ou do Slackware, por exemplo, que é colocar a mão na massa. Outros tem pavor. Porque dizer ser trabalhoso, demorado etc. Porém, para quem usa, não é. Logo, é uma questão de perfil de usuário. Se você não curti RR, não use e seja feliz.

Sei disso, é que tem tempo que usei o Mageia. Eu a usei porque, assim como a sua distribuição ancestral Mandriva, era a única distribuição que suportava a placa de vídeo SiS do meu antigo notebook. O PCLinuxOS (distribuição rolling-release que também é derivada do Mandriva) também suportava minha placa de vídeo SiS. O problema é que a partir do Mageia 6 e do PCLinuxOS de 2018 ou 2019, a minha placa de vídeo deixou de ser suportada, nem sequer o modo gráfico subia.

Simplesmente neomania. As pessoas hoje tendem achar que tudo que é mais novo é melhor.

Cara, infezlimente, essas placas SIS são muuuuuuito problemáticas. Tive um notebook, uns 7 ou 8 anos trás, que tinha uma placa dessas. Era danado, todo mundo reclamava dessas placas.

até certo ponto, a única coisa que a SUSE fez foi reduzir a superfície de desastre mas ainda é uma boa ideia ser conservador no que tange a boot-manager, e o que for que automatize a gestão de snapshots ou possa provocar um belo estrago no sistema de arquivos.

De qualquer forma ninguém aqui está leva em consideração a confiabilidade do sistema, um bug silencioso e você pode fazer escolhas desastrosas embora seu sistema ainda esteja funcionando e nenhum dado integro tenha sido perdido localmente, supondo que os dados dos usuários estejam cobertos por backups/snapshots.

Eu entendo que as coisas evoluem, sou totalmente a favor de um sistema atômico e reversível mas precisamos ponderar por que nós recorremos a essas novas abordagens, quando fazemos isso para testar menos ou entregar software menos testado mais rápido como software seguro para produção, estamos somando zero.

Apesar de não discordar totalmente alguns pontos na minha opinião são equivocados, por exemplo:

“Essa mentalidade é frequentemente apreciada pelos usuários, que também desejam da computação uma experiência agradável, previsível e confiável. Mas também desejam novidades para acompanhar seus colegas, seja em comunidades ou comercialmente. E aqui começa o primeiro problema.”

Não existe problema, graças a modelos standalone ou com client com suporte a self update como AppImages e Snaps, é possível ter softwares bleeding edge com um sistema estável sem quebrar nada, por exemplo, é possível ter uma máquina com Debian Old Stable e ter o Libre Office 6.5 ou o GIMP 2.15.21, não é necessariamente um problema se bem feito

" Lançamentos regulares negligenciam os pontos fortes do código aberto"

Não necessariamente de novo, uma das principais características do FOSS é permitir lançamentos LTS

Em vez de tentar evitá-lo, por que não o abraçamos e lidamos com os problemas que isso traz?

É simples, a nível programador, algumas mudanças significam pegar o trabalho de anos, embolar e jogar no lixo, como por exemplo o Wayland, o GTK 3.x… Então só tem duas escolhas viáveis, manter a versão atual, mudar a plataforma ou desistir de vez

E por aí vai…

Será? Eu vou utilizar minha experiência como exemplo. Eu instalei o ElementaryOS (baseado no Ubuntu 18.04) e então eu fui instalar o aplicativo do Telegram e advinha, eu não consegui utilizar ele por ser uma versão datada do mesmo e o mesmo acontece se você tentar instalar o Telegram via APT pelo Mint, Ubuntu 18.04 etc. Em 2019 eu estava jogando loucamente um jogo chamado The Outer Worlds e então eu decidi testar o Linux Mint (baseado no Ubuntu 18.04) e por conseguinte jogar o jogo nele. Resultado? Eu não consegui porque a versão do Wine disponibilizada pelo Mint não tinha as otimizações necessárias que estão disponíveis nas novas versões do programa para que seja possível rodar o Outer Worlds e continua não tendo até hoje devido a política de congelamento de pacotes.

Será que é realmente uma simples neomania?

Quando a terceira geração de processadores Ryzen foi lançada recentemente, os processadores tinham – e tem – um problema de incompatibilidade com o SystemD, fazendo com que nenhuma Distribuição conseguisse realizar o boot, porém a System76 conseguiu resolver esse bug antes mesmo dos processadores serem lançados, fazendo com que Pop!_OS fosse a única distribuição funcionando com o Ryzen 3 por um tempo, permitindo que eles vendessem as suas máquinas com o Ryzen 3 no dia 1. Por outro lado, pelo Ubuntu (e outras Distros “estáveis”) seguir a política burocrática dos modelos “estáveis”, a atualização necessária para sanar os problemas com o Ryzen 3 só vai estar disponível no Ubuntu 20.04 e só após isso talvez essa atualização chegue no Ubuntu 18.04. Logo eu pergunto: um sistema com um problema desse pode ser considerado como um sistema estável? Ao meu ver, não.

2 Curtidas

Se formos ver as pessoas até podem não gostar de seus apartamentos porque não tem quintal, mas ninguém sai falando “prédios residenciais estão errados”.

Não sei se computação é uma área que passa um ar exagerado de que tudo é possível por você não conseguir ver quando de fato alguém “morre esmagado” nos escombros de um framework. :shushing_face: