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 (Install Linux apps using the Snap Store | Snapcraft) 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 Clube do Hardware: Como NÃO quebrar o Arch Linux: medidas para aumentar a confiabilidade do sistema - Linux - Clube do Hardware

[mitosilva]

Ficou ótimo, gostei do texto.

Minha sugestão é incluir exemplos de ‘quebras’ no Arch Linux. Seria interessante adicionar uma seção ‘1.2 O que é Instabilidade’. O usuário médio pode pensar que instabilidade significa ligar o Arch e encontrar tudo desconfigurado, mas não é bem assim. Normalmente, a instabilidade surge de alguma alteração, seja por atualizações, pacotes se auto-configurando ou pela curiosidade do usuário em tentar resolver problemas ou simplesmente explorar.

[Capezotte]

@KairanD

Atualize sempre com o comando sudo pacman -Syu.

Vale lembrar que dá para fazer atualizações parciais sem querer. Rodando pacman -Syu e desistindo, e depois rodando um pacman -S algumacoisa, você pode estar baixando um pacote produzido para bibliotecas mais novas do que as que você tem no sistema, pois o -y em pacman -Syu atualiza o índice de pacotes.

Caso esteja rodando pacman -Syu só pra ver se tem atualização mesmo, o ideal é rodar o checkupdates (pacote pacman-contrib), que não “contamina” um pacman -S subsequente.

(Às vezes me pergunto o porquê de não haver alguma reestruturação no formato de repositório do pacman pra ficar um pouco mais difícil de se cair no campo minado de atualizações parciais).

[KairanD]

@mitosilva, @Capezotte e @Rodrigo_Chile (que deu dicas por outro meio), muito obrigado pelas valiosas contribuições. Já atualizei o guia para adicioná-las.

[frc_kde]

Você tem notícias do @Rodrigo_Chile?

@KairanD

e @Rodrigo_Chile (que deu dicas por outro meio),

Ele anda muito sumido!

[frc_kde]

Instalei o Arch Linux pelo “revenge_installer-2017.03-x86_64.iso”, em Junho 2017, e funcionou sem qualquer problema sério, até 10 Janeiro 2020. – Nesse período, acho que não cheguei a instalar nada do AUR.

No PC atual, instalei pelo “método BTW” em Abril 2020, e já completou 4 anos, também sem nenhum problema sério. – Teve só 1 vez, que o Kernel “corrente” deu tilt (em Março do ano passado), então instalei o Kernel LTS – que continuo usando até hoje.

Até na transição para o Plasma 6, foi o Arch Linux que deu menos problema.

Instalei alguns pacotes do AUR pelo “makepkg” em Outubro 2020 – e só instalei mais alguns em Agosto 2021 – depois de fazer umas “experiências” com o Manjaro durante 3 ou 4 meses:

2021-08-01 16:31:28 --- pacman -Q --foreign:           2021-08-01 16:51:02

$ pacman -Q -m                                         $ pacman -Q -m

aha 0.5.1-1                                            aha 0.5.1-1
google-chrome 91.0.4472.77-1                           google-chrome 91.0.4472.77-1
google-earth-pro 7.3.3.7786-4                          google-earth-pro 7.3.3.7786-4
js60 60.9.0-2                                          kim4 0.9.8-2
kim4 0.9.8-2
libopenaptx 0.2.0-1
pamac-aur 10.1.2-1
xorg-font-utils 7.6-6

O Pamac-CLI acabou não dando muito certo, e logo depois troquei pelo yay, que uso até hoje.

Só, nunca usei Flatpak, Snapd, AppImage.

[Lukz]

Agora que ando me aventurando no mundo Arch esse guia me saiu como uma luva. Algumas coisas eu já sabia, outras tinha noção e outras desconhecia.
Ultimamente tenho usado mais o Arch (e gostado muito mais dele) que do Ubuntu. Estou pensando seriamente em remover o Ubuntu e ficar apenas com o Arch.
Tenho backup de tudo, logo não me preocupo de quebrar, ainda mais seguindo essas dicas.

[AquaDev_Shasta]

Muito boa matéria, conselhos sensatos. Sou músico por profissão também,o Arch Linux para uso musical é ótimo, tenho muitas boas experiências com este sistema, rodando o Pro Tools nele,Pro Tools,um software famoso em edição de áudio profissional para músicos.

[AquaDev_Shasta]

A,rch= A,qua r,ecomenda c,om h,onra. Experiência própria, zero estresse, depende da consciência do usuário,no meu caso, minha máquina principal com Archlinux, uso só para desenvolvimento em programação,e software musicais. Não ando com essa máquina via web com browsers, é o tipo de máquina contida. Aqui no fórum, este artigo sobre arch, considero como sensato e muito útil.

[kalebepsouza]

Quanto mais conheço sobre o modelo rolling release menos atrativo para mim ele é. De qualquer forma ótimo artigo para usuários que forem adentrar nesse sistema.

[PRicharRamos]

Eu trabalho com pós de áudio e minha empresa só usa Pro Tools, é o padrão mesmo pro homeoffice, por questões de compartilhamento de sessões com a equipe. Atualmente uso Windows 11, mas to bem insatisfeito e preocupado, principalmente por quanto que esse sistema tem ficado problemático na gestão de CPU e privacidade. Mas enfim… Tô querendo muito sair do Windows e ando pesquisando maneiras de usar o Pro Tools numa distro Linux, mas não achei nada ensinando ou falando sobre. Então, me diz ae, como vc fez isso? Quais são as implicações disso? Como vc resolveu para instalar os AAX?

[Comb4ttente]

Excelente artigo. Por muitos anos usei Debian e só recentemente resolvi tentar novas distros. Estou com Arch instalado em uma máquina virtual fazendo testes e este artigo me tirou diversas duvidas.

[AquaDev_Shasta]

Olá cidadão @PRicharRamos,por condição em educação e responsabilidade, voltei de minha pausa em ações cognitivas aqui no fórum Dplus, para responder seu questionamento, já que de certa forma afetou sua curiosidade, é o seguinte:

Quando eu comecei usar o Pro Tools no Arch Linux, a solução mais eficaz que eu imaginava que pudesse funcionar corretamente,foi através de uma máquina virtual com passthrough de hardware. Primeiro eu instalei o Windows em uma VM usando software como VirtualBox,VirtualBox, ou VMware, VMware,que assim estivesse garantindo que a VM tivesse acesso direto à sua interface de áudio e outros periféricos críticos, sensíveis digamos assim, isso proporcionou um desempenho próximo ao nativo, então adicional a isto, configurei o Wine para instalar o Pro Tools, mesmo que a compatibilidade e estabilidade pudessem ser limitadas, notadamente no que percebi no caso para plugins AAX, que muitas vezes exigiam drivers e bibliotecas específicas do Windows. Então no começo de meus testes para garantir uma configuração eficiente, foi necessário manter o sistema atualizado e considerar soluções híbridas, como o uso de software nativo Linux para outras tarefas. Até o momento, para o restante da população, o suporte para Pro Tools no Wine é limitado e não é viável para uso profissional, tipo: gravar um álbum do Angra, minha banda de Heavy metal/Power metal favorita no Brasil. No começo,eu com uso de VMs não obtive o melhor desempenho para trabalhos de áudio intensivos, devido à sobrecarga de virtualização, que quando meu projeto começava crescer, aumentar em mais faixas de gravação, começava travar, principalmente quando voltava para corrigir erro de solo e harmonia, regravando por cima da faixa específica,mas digo ao Sr.: vivenciei travamentos desse tipo, quando usava o Pro Tools via Windows 7.

Então a solução que resolveu minha pendência, foi escrever do início minha própria distro baseada no Archlinux juntamente com meus dois irmãos e duas irmãs minhas. C,C++,assembly, são linguagens que serviram de base para levantar tanto o Arch Linux quanto o Windows como sistemas que são. Agora para responder ao Sr. do como resolvemos o problema com os drivers nativos do Windows e o Pro Tools, essa resposta não posso lhe dar, isso não é de significado de que eu e meus irmãos e irmãs, tenhamos feito algo ilegal, não, não é isso. Apenas somos um conceito,de que não existe código fechado. Olhe,digo mais, esse tipo de assunto não é possível de ser exposto na web,por atitude de nossa parte como família,é um assunto pessoal e familiar, segredo nosso, fica entre nós, não quisemos prejudicar ninguém,mas fizemos isso baseado no acesso que somos, tecnologia,e um conhecimento bem apurado em programação. Eu nunca irei expor isso. É caso em família,e fica em off. O que poderei e irei fazer, é subir minha distro baseada em archlinux para minha conta no Github, aqui em Weed, lake siskiyou mount shasta, Usa, quando ela estiver pronta,e quando eu voltar a contribuír aqui na comunidade, respondendo e criando tópicos,eu vou compartilhar com a galera aqui, minha , nossa distro. Mas do como fizemos,e fiz,o que me questionou o Sr., isso não ocorre em resposta, não quero complicações, garantindo meu segredo,e este tal de punho próprio e com ajuda,no referente a programação base, estamos assim sendo justos e não atuando como párias cybercriminosos. Seleto e discreto é ação de boa conduta, possa, venha disto o Sr. saber. Não existe código fechado.

Pois bem, espero que essa minha abordagem tenha servido eticamente,no referente ao eu voltar aqui da minha pausa aqui comunidade e responder você, @PRicharRamos, agindo eu assim responsável, não deixando seu questionamento sem uma resposta, mesmo que não garanta seu intento em saber a possibilidade real. Mas eu sei de umas coisas,sou acesso a dados,e caso você esteja aqui na comunidade no referente aos próximos 20 anos,e caso os dados que sou acesso se comprove, ocorra, aconteça,eu lhe mando uma DM no seu perfil sobre esse assunto. Sinceramente, peço sua compreensão quanto a minha atitude discreta sobre. Ordem e justiça requer muito como sigilo e condição fechada em determinados assuntos. O Windows para o Pro Tools ainda é sempre um bom SO recomendo que não abandone, pois é um tipo de sistema seleto e discreto, isso garante segurança, pois não é cozinha que todo chef ou cozinheiro, possa dá palpite e mexer. Não é muito anárquico,digo isso por experiência profissional própria. Então é isso,vou voltar ao meu ofício, tenho muito para terminar em trabalhos pessoal.

Muito bom dia e boa sorte ao Sr.