Silverblue e o Desktop Linux

Hoje vou tentar resumir minha experiência com esta “variante” do Fedora e como me levou a questionar ou refletir sobre o “Linux Desktop”.

Comecei a usar o SB (Silverblue) no Fedora 30, já era possível usar o “Atomic Workstation” (que viria a se tornar o Silverblue) a algumas versões, creio que versão 26/27. Mas foi na versão 29 que nasceu “oficialmente”.

Transição para full Flatpak

Minha transição foi suave pois não tenho nenhuma “necessidade especial” que me impeça de usar apenas app’s em Flatpak. Mais a títulos de testes usei por um tempo pacotes do RPMFusion e não tive nenhum problema, mas ainda não estava usando o sistema com seu propósito principal, ou de uma maneira que exija menos intervenção manual, digamos assi…

Então quando a Mozilla passou a suportar o Firefox no Flathub, minha migração para apenas Flatpak’s aconteceu. Porém algumas ferramentas a nível de sistema são necessárias via rpm-ostree e é aí que faz sentido usá-las!

A desvantagem do rpm-ostree, para mim é que ele não esta imune a problemas de dependências de pacotes como acontece com dnf, na situação onde se instala muitos pacotes além de repos de terceiros.

Ferramentas CLI e GUI também podem ser usadas via rpm-ostree, mas para isso existe também o Toolbox e distrobox, que uso para alguns testes…

Uso Firefox como navegador padrão, Youtube, Netflix, Twitter etc.. Jogo na Steam incluindo jogos via Proton, Telegram, GNOME Games para emuladores e Boxes para máquinas virtuais entre vários app’s da imagem acima.

Experiência GNOME

Eu sei que o GNOME é o mesmo usado na Workstation, mas a GNOME Software funciona até melhor (obs: não usa packagekit como o Workstation) talvez por não buscar app’s do repo RPM, mas apenas Flatpak’s.

O Ostree (tecnologia GNOME) também faz parte da experiência do ambiente e é usado de forma muito eficiente no Flatpak e no sistema de atualização. No SB(Silverblue) não precisa ter a espera por um update de versão como no Workstation com DNF (via dnf tambem não mprecisa, mas tem mais riscos…), além de proporcionar segurança no processo e permitindo voltar ao estado anterior facilmente e isso também de forma mais segura que o dnf. Não existe aquele famoso dilema que vemos em outras distros quando lançam nova versão, com novidades que você gostaria de usar:

“atualizar ou não atualizar? eis a questão…”

Posso testar o Fedora Rawhide ou uma versão recém lançada fazendo um simples rebase e voltar a versão estável a qualquer momento, o que me permite testar facilmente versões em desenvolvimento do GNOME por exemplo.

“Produto Linux Desktop”

Quando olhamos produtos como o Playstation da Sony, vemos um sistema fechado para cumprir um propósito, que é basicamente rodar jogos e alguns serviços de multimídia. Os usuários não se preocupam em modificar partes do sistema, ou seja, usam um sistema “imutável”.

Quando olhamos para celulares com Android vemos o mesmo, assim como MacOS/iOS, ChromeOS…

São todos sistemas ou “produtos” bem sucedidos no mercado, o que eles tem em comum é a imutabilidade ou o foco em cumprir sua tarefa.

O que me leva a crer que o SB se aproxima muito deste modelo de sistema operacional/produto. Aquele que não irá te atrapalhar, que tenta ser “invisível” para o usuário que só quer cumprir suas tarefas do dia dia.

Agora você me pergunta:

E para aqueles com necessidades especificas em modificação do sistema como: alguns desenvolvedores, engenheiros de software, SysAdmin’s etc?

Bom, apesar de o SB suprir a necessidade de muitos desenvolvedores e usuários, de fato não é um modelo de sistema que supre a necessidade de 100% das pessoas no mundo e creio que nenhum outro supre.

A verdade é que o workflow em container está sendo cada vez mais usado em servidores, por desenvolvedores e aparelhos de uso pessoal no geral, incluindo desktop’s.

Distros precisam manter / empacotar todos app’s por sua conta?

É algo me questiono, agora que temos muitos app’s sendo mantidos e distribuído por desenvolvedores focados nisso e para todas distros com Flatpak.

Não seria uma grande economia de mão de obra para distribuições, deixar de manter app’s como por exemplo: GIMP, LibreOffice, Firefox… e deixar o trabalho principal para os desenvolvedores ou mantenedores dos mesmos?

Isto também ajudaria a diminuir o numero de “pacotes órfãos”, problema que acontece em todas distribuições.

Eu estou tendo a tendência em achar que seria uma boa ideia, principalmente para distribuições focadas em usuário final/comum. Já vi alguns argumentos furados contra isso como:

“o usuário ficaria refém do desenvolvedor”

“Flatpak ocupa mais espaço”

“Existe um bug especifico em um app da versão Flatpak…”

Sei que existe um mercado enterprise, que talvez tenha alguma necessidade de congelamento de software + garantia de receber backport de possíveis correções de segurança.

Entendo que existe questões de adaptação de alguns softwares aos projetos. A exemplo do Fedora, que modifica o Firefox original, adicionando um patch de compatibilidade com Wayland e outras questões de segurança. Neste caso até faz algum sentido o Fedora manter seu próprio Firefox, mas isto não acontece em todos app’s, assim como nem todos tem a necessidade de uso enterprise. Fora que, em nenhum outro sistema operacional popular, as pessoas usam seus app’s em versões antigas (falo de app’s, não componentes do sistema).

A distribuição EndlessOS (que se assemelha muito com o SB tem quase tudo que estou falando aqui) está a caminho de usar a maioria dos seus app’s default na versão do Flathub, na qual ela já ajuda a manter, logo, não faz sentido manter 2 versões de vários app’s. Creio que o mesmo pode acontecer com outras distribuições.

Me questiono sobre isso, por conta de que praticamente uso o Flathub como repositório principal de app’s.

Rolling Release / Fixed Release não importa realmente

Do ponto de vista do usuário, usando um sistema com OSTree, ser Fixed ou Rolling release não importa realmente. O fato de você poder mudar para a versão em desenvolvimento contínuo (rawhide) ou estável faz com que o usuário não lide com os dilemas das Fixed Release (atualizar ou não atualizar) e das rolling, que é temida por muitos por possíveis problemas em updates que podem quebrar o sistema.

“Contra a liberdade do Linux Desktop”

É assim que me sinto usando o Silverblue quando vejo comentário deste tipo, foi com ele, ou mais precisamente com o Fedora, que percebo como a comunidade Linux é contra mudanças (muitas vezes progresso) e as vezes com pensamento retrógrado. Vemos claramente isto com o “caso systemd” até hoje.

É como se 1 projeto interno de 1 distribuição estivesse colocando em risco a “liberdade do usuário e do software, propondo um esquema para impedir o usuário de modificar o sistema Linux, na qual nasceu justamente com este propósito…”

Ao meu ver o modelo de sistema operacional do Silverblue ou Ostree based aumenta o controle e segurança do usuário ao sistema operacional.

Atualmente, em qualquer distribuição tradicional, se você quiser trocar de DE, é praticamente um inferno para o usuário final. Terá que lidar com gerenciador de pacotes/dependências/meta-pacotes e corre um grande risco de quebrar o sistema ao remover a DE antiga.

Com o Ostree, você pode simplesmente fazer um seguro rebase para uma versão com outra DE.

Em qualquer distribuição tradicional, se você quiser gerenciar permissões de programas .deb, bom, isso praticamente é inviável sem muita gambiarra.

Usando programas Flatpak você pode gerenciar via Flatseal / CLI (atualmente) ou a DE pode implementar isso nativamente como o Elementary OS 6.

Então na parte de customização na escolha da DE e permissões dos programas, este modelo de sistema aumenta o controle e possibilidades do usuário.

Limitadamente, ainda é permitido o usuário instalar pacotes .rpm de terceiros mantendo a integridade do sistema, coisa que não existe em distribuições tradicionais.

Nem tudo são flores

Muito por conta do tal “tradicionalismo” existe muitos programas/desenvolvedores que não ligam em criar programas totalmente invasivos ao sistema operacional e alguns propõem mudanças que podem comprometer a segurança do sistema, se você não sabe do que estou falando, um driver de impressora ou módulo de terceiro no kernel pode muito bem se encaixar nestas características.

Este tipo de programa existe aos montes e provavelmente não irão ser compatíveis com o Silverblue.

Apesar do sistema operacional oferecer soluções, nem todas vão ser o suficiente e alguns programas para serem compatíveis, terão que se adaptarem ao OS e não o contrário.

Felizmente, não dependo de nenhum software ou hardware que me induza a modificar o SB de tal forma a não ser compatível com o mesmo.

Como será o futuro deste modelo de OS?

Não sou vidente, mas o que posso dizer é que as principais tecnologias que compõem o SB, agora são praticamente as principais/oficiais do projeto Fedora, falo do GNOME principal do Workstation, Ostree no IoT e DNF no Server/Workstation. O SB não usa o DNF propriamente dito, mas faz uso de lib’s (libdnf) do mesmo no rpm-ostree.

Não creio que tão cedo o SB se tornará o Workstation do Fedora, porém mais importante que isto, é seguir usando tecnologias bem mantidas e com desenvolvimento ativo como é atualmente.

O SB não está sozinho, de OS tipo “imutável” temos: EndlessOS, Fedora IoT, ClearLinux, ChromeOS, MacOS, MicroOS (OpenSUSE), GNOME OS, Android… são sistemas que estão em um caminho parecido.

Gostaria que futuramente, fosse possível para usuários que precisam de módulos de terceiros (como drivers de impressoras) instalar de maneira segura e prática. As spins com outras DE’s também são importantes para o Fedora, portanto espero que mais pessoas se interessem em mantê-las. Atualmente o Fedora Kinoite (spin KDE ostree based) será lançado na versão 35.

Algo que é sempre bom, é divulgação dos usuários / blogs / sites sobre estas tecnologias.

O aumento da adoção com Flatpak é algo que já está acontecendo e quanto maior for, mais vai fazer sentido usar um sistema como o Silverblue.

Se deseja me dar sugestões, mande para fastos2016@gmail.com ou nas redes sociais.