Como NÃO quebrar o Arch Linux: medidas para aumentar a confiabilidade do sistema

[KairanD]

Olá, pessoal! Neste artigo, procuro fornecer algumas dicas para aumentar a confiabilidade de sistemas rolling release, com foco no Arch Linux.

 

 

1. INTRODUÇÃO

 

Sistemas rolling release são aqueles sem lançamentos periódicos. Ou seja, atualizações são fornecidas continuamente ao longo do tempo, assim que são lançadas e aprovadas pelos mantenedores dos repositórios.

 

Por um lado, esses sistemas - no caso de serem também de fluxo rápido - geralmente permitem o acesso antecipado a versões mais recentes de pacotes e programas, ou mesmo a elementos centrais como o kernel. Com isso, pode-se ganhar em funcionalidades e desempenho. Por outro lado, o sistema pode exigir mais manutenção e alguns cuidados para evitar falhas decorrentes das frequentes atualizações.

 

1.1 O que é “estabilidade”?

 

A palavra “estável” costuma assumir dois significados distintos no mundo Linux.

 

O primeiro significa não sofrer mudanças constantes ao longo do tempo, evitando também diferenças disruptivas que afetam o fluxo de trabalho. Distros rolling release de fluxo rápido como o Arch Linux são opostas a esse conceito.

 

O segundo se refere à confiabilidade, ou seja, “não quebrar”. E o Arch pode sim ser bem confiável. Com algumas poucas atitudes, é possível tornar o sistema muito menos propenso a falhas.

 

1.2 O que é “instabilidade”?

 

Muitas pessoas correlacionam “instabilidade” com quebra generalizada do sistema. Contudo, mesmo atualizando um sistema como o Arch Linux diariamente, a chance disso acontecer é muito baixa.

 

A “instabilidade” refere-se, geralmente, a pequenas alterações ou bugs menores, que podem derivar de atualizações - com possíveis mudanças no comportamento de alguns pacotes - ou da própria curiosidade do usuário ao modificar o sistema. Não são, necessariamente, alterações que prejudicarão a experiência.

 

2. COMO NÃO QUEBRAR O ARCH LINUX

 

Neste item, abordarei nove dicas para tornar seu sistema menos propenso a falhas.

 

2.1 Flatpaks, Snaps e AppImages são seus melhores amigos!

 

Priorize pacotes do Flathub (https://flathub.org/), da Snap Store (https://snapcraft.io/store) e do AppImage Hub (https://www.appimagehub.com/). Esses pacotes contêm as dependências necessárias para funcionarem e não irão interferir com o funcionamento do sistema.

 

A lógica é simples: quanto menos pacotes dos repositórios forem instalados, menor a chance desses pacotes apresentarem bugs após atualizações. Falhas em pacotes Flatpak, por exemplo, ficam restritas ao aplicativo em questão. Falhas em pacotes do sistema - e suas dependências - podem afetar mais coisas.

 

2.2 Os repositórios oficiais são confiáveis!

 

Pacotes provenientes dos repositórios oficiais, instalados por meio do comando sudo pacman -S, são sincronizados com os demais componentes do sistema.

 

Esses pacotes sempre devem ser priorizados no caso de não haver opções nas fontes listadas no item anterior (ou caso as opções anteriores tenham alguma limitação).

 

2.3 Cuidado com o AUR!

 

O Arch User Repository (AUR) é um repositório comunitário. Por mais que seja impressionante, não necessariamente tudo o que estiver ali estará em condições de funcionamento e integração com o restante do sistema.

 

Use o AUR somente para o que for realmente necessário e não puder ser instalado por meio das opções mencionadas anteriormente. Isso é válido especialmente para os drivers, que só devem ser puxados do AUR como último recurso.

 

Cabe citar que é esperado, do usuário do AUR, alguma noção sobre o funcionamento do sistema. É altamente recomendável que os scripts e comentários na página do pacote no AUR sejam analisados antes de qualquer operação. Não saia instalando pacotes usando helpers como o Yet Another Yogurt (Yay) indiscriminadamente!

 

Ao instalar pacotes do AUR, cabe ainda mencionar que você deve priorizar pacotes -bin. Eles são pré-compilados. Consequentemente, há ganhos na velocidade de instalação e na estabilidade, embora possam não ser a versão mais atualizada.

 

2.4 Viu algum programa interessante solto na Internet?

 

Essa dica pode ser aplicada a qualquer sistema operacional. Pacotes avulsos da Internet podem ser altamente prejudiciais. Em primeiro lugar, porque podem conter malware. Em segundo lugar, porque podem não ser compatíveis com a versão atual do sistema, podendo ocasionar quebras e problemas.

 

Em resumo: evite, a todo custo, baixar, compilar ou instalar pacotes avulsos da Internet. Além disso, quando for fazê-lo, certifique-se de conhecer bem o desenvolvedor - para avaliar se é confiável - e, se possível, analise o código-fonte.

 

Lembre-se que máquinas virtuais podem ser grandes aliadas para testar pacotes. Experimente o GNOME Boxes.

 

2.5 Tenha mais de um kernel

 

O Arch Linux usa, por padrão, um kernel rolling release. Isso é super legal e pode melhorar a compatibilidade com hardware mais recente. Por outro lado, pode ser fonte de problemas.

 

Mantenha sempre instalado pelo menos o kernel LTS além do kernel rolling. Assim, se houver algum problema no kernel principal, você sempre poderá iniciar com o LTS e usar seu computador normalmente, retornando ao kernel principal quando a falha for eventualmente corrigida.

 

2.6 Visite a página do sistema

 

O Arch Linux sempre mantém notícias atualizadas em sua página principal (https://archlinux.org/). Antes de executar qualquer procedimento de atualização, visite-a e analise o que foi publicado.

 

Eventualmente, intervenções manuais podem ser necessárias para corrigir problemas em atualizações. Ao ler a página principal, você estará ciente caso exista alguma. As instruções costumam ser bem claras.

 

2.7 Não faça atualizações parciais!

 

O Arch Linux não suporta atualizações parciais. Quando algum pacote é publicado nos repositórios, os desenvolvedores e mantenedores trabalham para sincronizar o restante do sistema, evitando conflitos.

 

Atualizações parciais - de apenas poucos pacotes - podem quebrar esse fluxo, criando conflitos de dependências, pois você pode estar baixando pacotes desenvolvidos para versões de bibliotecas distintas daquelas que você tem instaladas.

 

Atualize sempre com o comando sudo pacman -Syu e conclua o procedimento. Pois, ao rodar o comando e desistir, você pode acabar provocando uma atualização parcial involuntária ao instalar algum pacote em seguida.

 

Caso deseje apenas verificar se existem atualizações - sem efetivamente instalá-las no momento -, você pode executar o comando checkupdates, incluído no pacote pacman-contrib.

 

2.8 Não seja ansioso

 

Não atualize indiscriminadamente. Você não precisa (e nem deve) atualizar todos os dias. Deixe para os finais de semana, quando não estiver dependendo do computador para trabalhar. Para quê correr riscos à toa?

 

A frequência pode ser semanal, quinzenal ou mensal. Caso seu sistema fique sem atualizar por mais tempo, pode ser necessário atualizar o keyring antes de rodar o comando sudo pacman -Syu. Para isso, execute sudo pacman -S archlinux-keyring, e depois proceda normalmente com a atualização do sistema.

 

2.9 Leia a Wiki!

 

A Wiki do Arch Linux é um dos recursos mais completos à disposição. Se estiver com dúvidas sobre o sistema ou antes de executar algum comando, leia-a!

 

3. CONCLUSÃO

 

Muitos dos problemas atribuídos a distros rolling release de fluxo rápido estão associados à imperícia do usuário. Seguindo as diretrizes acima, a chance de ter alguma quebra no sistema tende a zero. É perfeitamente possível usar o Arch Linux como daily driver.

 

Agradecimentos

 

Aos colegas @mitosilva, @Capezotte e @Rodrigo_Chile, que contribuíram com pontos relevantes para o aprimoramento deste tutorial.

 

Nota

 

Tópico também publicado no Diolinux Plus: https://plus.diolinux.com.br/t/como-não-quebrar-o-arch-linux-medidas-para-aumentar-a-confiabilidade-do-sistema/62419

[Marcos FRM]

Hoje reinstalei meu Arch e vi que o módulo do VirtualBox está disponível, pré-compilado, para o kernel LTS! É uma adição recente, coisa de um mês atrás (começou na versão 6.6.49-1), que me permitiu passar a usá-lo. O nome do novo pacote é virtualbox-host-modules-lts, enquanto virtualbox-host-modules-arch é para o kernel rolling. O driver proprietário da Nvidia tem esse mesmo tratamento (nvidia-lts e nvidia) há muito tempo.

 

Sim, sim, tem o horroroso virtualbox-host-dkms, que eu evitava por achar o DKMS uma gambiarra.