Sim, ainda existem versões do openSUSE em nosso futuro que não são baseadas em MicroOS

A imutabilidade poderia ser um salto longe demais para os usuários do openSUSE?

A atualização na próxima versão principal da distribuição Linux anuncia grandes mudanças pela frente

Quarta, 17 de janeiro de 2024 // 15:31 UTC

O futuro do openSUSE está se firmando, mas possivelmente não na direção que os usuários existentes da distro irão desfrutar.

A última atualização sobre o futuro do openSUSE Leap confirma que haverá um lançamento chamado Leap 16 em algum momento, junto com uma versão 6 do Leap Micro existente … mas a versão 16 será baseada na distribuição ALP conteinerizada da empresa . Isso significa que o Leap 16 está destinado a ser uma distro imutável com atualizações transacionais e, portanto, significativamente diferente da distribuição atual do openSUSE. Embora a empresa esteja prometendo um caminho de migração, parece muito improvável que seja uma simples atualização local.

Como descrevemos em detalhes no par de recursos do ano passado sobre como tornar o Linux mais seguro, distros imutáveis ​​são a novidade no mundo Linux. Um sistema de arquivos raiz somente leitura torna o sistema operacional muito mais resiliente contra corrupção de disco e está intimamente associado a atualizações transacionais, onde instantâneos significam que, se uma atualização causar problemas, ela poderá ser revertida, desfeita de forma limpa, como se nunca tivesse acontecido .

SUSE e seu projeto afiliado openSUSE têm uma grande e crescente família de distribuições, mas até a aquisição do Rancher pela empresa em 2020 , o relacionamento das distros com o antigo SUSE Linux permaneceu claro. openSUSE Leap é a distribuição estável e gratuita, com um ciclo de lançamento relativamente lento que é próximo o suficiente do SLE comercial para que seja possível migrar do Leap para o SLE in-loco por alguns anos . openSUSE Tumbleweed é uma distro de lançamento contínuo, cujos componentes fluem constantemente do modelo de desenvolvimento de fábrica do projeto . O principal é que ambas são distros convencionais, com sistema de arquivos raiz de leitura e gravação e gerenciamento de pacotes RPM usando a ferramenta Zypper da SUSE .

O ponto em que eles se afastam de outras distros convencionais é que as distros SUSE não apenas usam Btrfs como padrão, mas também se apoiam fortemente em seus recursos avançados de uma forma que poucas outras fazem. Especificamente, isso significa suporte para instantâneo COW do Btrfs. O Btrfs permitiu que a SUSE integrasse sua ferramenta Snapper diretamente em seu gerenciador de pacotes, com relativa facilidade. Como resultado, as distribuições SUSE criam automaticamente instantâneos de pré-instalação antes da instalação ou atualização do software. Se algo der errado, há um recurso de “desfazer”. Você pode voltar a ser como as coisas eram antes da mudança.

Esta é uma tecnologia excelente… mas, como sempre, há um custo para cada benefício. Btrfs não é o sistema de arquivos mais estável. A equipe do Reg FOSS está confiante de que o slogan do novo e radical bcachefs – “o sistema de arquivos COW para Linux que não consome seus dados” – é um golpe na reputação do Btrfs . (Aliás, achamos que a parte “para Linux” é um golpe no OpenZFS, que notoriamente não faz parte do kernel .)

Usar o Btrfs para fornecer gerenciamento de pacotes transacionais significa que a implementação do SUSE é tecnologicamente muito menos complexa do que o OSTree da Red Hat, usado no Endless OS, a variante imutável do Fedora Silverblue, e também no Flatpak, que está em muitas distros, incluindo o Linux Mint.

O Flatpak em si é simples e aberto, mas sua complexidade reside na sua implementação usando OSTree. A descrição do próprio projeto do OSTree o compara ao Git. O Git é notoriamente difícil de usar, mas a forma como ele é implementado é tão complexa e obscura que existem desenhos animados sobre ele . (Se você não usa Git, fique feliz… mas se quiser se divertir, procure um entusiasta do Git, pergunte como ele rastreia e gerencia as alterações e observe-os se debatendo.)

OSTree é complexo. Pior ainda, como o Flatpak é otimizado para aplicativos GUI e não funciona bem para aplicativos de linha de comando, você não pode criar uma distribuição a partir do Flatpaks. Você também precisa do OSTree, e isso significa reestruturar e reconstruir fundamentalmente todo o sistema operacional.

A Canonical enfrenta problemas semelhantes. O formato Snap da Canonical é muito mais simples: cada aplicativo é apenas um arquivo, um SquashFS e lida perfeitamente com aplicativos de linha de comando. Isso significa que o Snap não precisa de nenhuma travessura semelhante ao Git, nem de um sistema de arquivos sofisticado com instantâneos COW, e a Canonical pode usar uma única ferramenta para todo o sistema operacional. No entanto, é uma ferramenta completamente diferente do Ubuntu convencional, que é construído a partir do Debian – e o Debian é construído a partir de deb pacotes. Em vez disso, construir uma distro a partir do Snaps significa reconstruir tudo desde as fundações. Vimos o Ubuntu Core , a distribuição IoT da Canonical, em 2022, e ainda este ano a Canonical planeja lançar o Ubuntu Core Desktop , quando o Ubuntu Core completar dez anos.

A Canonical afirmou que o Core Desktop ainda não substituirá o Ubuntu convencional . Da mesma forma, as formas imutáveis ​​do Fedora ainda não estão prontas para substituir as versões convencionais. O RHEL certamente o seguirá com o tempo, mas só anos depois.

Em total contraste, a SUSE está planejando fazer a transição já no próximo ano. As distros mais recentes da família SUSE, openSUSE MicroOS e SLE Micro , já são sistemas operacionais minimalistas e imutáveis. Embora sejam construídos usando as mesmas ferramentas (RPMs, gerenciados usando Zypper), e seus pacotes sejam originados do Tumbleweed, ambos são fornecidos com sistemas de arquivos raiz somente leitura e suas ferramentas convencionais de gerenciamento de pacotes são inacessíveis. Mesmo o usuário root não pode adicionar, remover ou atualizar software de forma interativa; eles devem usar o novo transactional-update comando . Possui páginas úteisman e um bom manual – uma marca registrada da SUSE há décadas – mas significa uma nova maneira de gerenciar uma máquina Linux.

As ferramentas de software estão longe de ser novas e não testadas. Os comandos estavam disponíveis no Projeto Kubic da SUSE em 2017, embora tenha sido retirado em 2022 , substituído pelo agora popular MicroOS.

A SUSE tem um caminho mais direto para um sistema operacional imutável do que qualquer outro fornecedor de Linux. Nem precisa ser uma transição radical. Doug deMaio, da empresa, disse ao The Register :

Existe uma opção na construção de um sistema operacional para instalar transacional e não transacional (o instalador Tumbleweed suporta ambos, por exemplo)… Tecnicamente, não há muita diferença; o rootfs somente leitura é principalmente uma “garantia superior” para que o sistema não seja alterado imediatamente.

A empresa não planeja forçar cargas de trabalho baseadas em contêineres a seus usuários. O CTO da SUSE e presidente do openSUSE, Gerald Pfeiffer, também nos deu palavras tranquilizadoras:

Sim, ainda existem versões do openSUSE em nosso futuro que não são baseadas em MicroOS e não exigirão cargas de trabalho do usuário para aproveitar os contêineres. Estamos analisando outras modalidades, possivelmente do tipo MicroOS, para incluir. Em última análise, é tudo uma questão de escolha do usuário!

Quanto a quando chegará esta próxima geração do Leap, deMaio disse:

Estamos pensando no final de 2025, mas há chance de deslize, por isso colocamos o Leap 15.7 como último recurso.

A SUSE tem um caminho mais simples para fornecer Linux imutável do que qualquer outro fornecedor, e está perseguindo-o agressivamente. Até o final de 2025 será mais cedo do que qualquer outra pessoa no espaço empresarial. O risco é que isso possa afastar os usuários existentes para chegar lá. ®

1 curtida

Olá, estou aqui no fórum principalmente para aprender (não sou muito experiente nesse assunto) e pelo que entendi essa imutabilidade seria algo positivo, deixar a parte “core” (mais de baixo nível) imutável protegendo de quebrar o sistema sem nos impedir de instalar e alterar tudo que estiver ao lado do usuário como pacotes, serviços, etc.

1 curtida

É a impressão que também tenho:

Posso estar enganado, pois não sou “técnico”, e além disso nunca me interessei muito pela “imutabilidade”, e por isso, não li muita coisa.

Me parece o contrário do Arch Linux, por exemplo – que você “monta”, peça por peça – e se não quiser SystemD, pode usar as opções do Artix.

A “imutabilidade” me parece ser, também, a “in-opcionalidade”. – “É pegar ou largar”. – Como aqueles anúncios que dizem, “no estado” (do jeito que está). – Ou, “porteira fechada”.

“Compramos” essa ideia (ou ela é “vendida” para nós), pensando na perfeição, no “ideal”, na maravilha. – Um paraíso, que não conseguiremos escangalhar, por mais incompetentes e desastrados que possamos ser.

Mas não existe registro de perfeição, maravilha, paraíso etc. na história da humanidade. – A internet, por exemplo, ia colocar todo o conhecimento ao alcance de todos. – E de fato, agora sabemos de cada Fulana que se separou de cada Beltrano, e dos podres que uns dizem dos outros.

O Android já é “imutável”. Não posso eliminar vários aplicativos, que eu preferia não ter. Aliás, nem sei o que tem dentro dele. Comprei “de porteira fechada” – e as únicas opções, são entre 2 ou 3 mega-corporações.

Do meu ponto de vista, isso não é muito diferente do Windows – ou do Mac. – Pago caro, e não sou dono de nada.

É claro que faz coisas que a velha máquina de escrever não fazia – ou coisas que o telefone amarrado na parede não fazia. – Mas os belos adjetivos nunca foram além de puro marketing.