-- Leo's gemini proxy

-- Connecting to gemini.eletrotupi.com:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

Alpine Linux


Eu comecei a utilizar o Alpine Linux já faz um tempo, em especial porque eu

sabia que ele era conhecido por ser uma distribuição leve, um requisito do qual

eu julgo muito necessário e da qual eu já escrevi a respeito. Depois de um ano

trabalhando de casa devido a pandemia de Covid-19, decidi parar de utilizar um

notebook como minha ferramenta principal. Os motivos são variados, mas a falta

de espaço para armazenamento e ter que lidar com bateria me fizeram eu

finalmente fazer um merecido upgrade para uma estação de trabalho desktop.


Artigo Sobre Software Durável

Artigo Sobre Complexidade na Tecnologia


Depois que eu migrei tudo do notebook para a nova máquina, vi que era uma ótima

oportunidade de fazer um tão desejado test-drive do Alpine no notebook. Não

preciso dizer que nunca mais voltei atrás.


Sinceramente, o que eu mais gosto no Alpine é o fato de que ele é *muito*

simples. Tudo nele me remete a um certo minimalismo, a um desejo de não ser

intrusivo e de tentar ser um sistema _barebones_ (apenas o mínimo), mas sem ser

masoquista. Tudo nele me parece que foi feito com o objetivo de optar pelo

caminho mais simples, mesmo que isso signifique sacrificar algumas

"otimizações" para você, e escolher poucas peças, mas peças que apresentem um

funcionamento correto.


Eu sinto que também é uma distribuição que eu consigo confiar como que ela vai

se portar e que simplesmente emana estabilidade. Todo o desenvolvimento é feito

em uma branch "edge" (ponta) e a cada seis meses se congela uma nova versão,

versão essa que tem suporte por até dois anos. O modelo de _rolling release_,

ou seja, onde assim que um pacote é atualizado _upstream_¹ é

automaticamente atualizado pelos empacotadores na distribuição já se provou um

sucesso entre outras distribuições (implementado por distribuições respeitáveis

como o Arch Linux, Gentoo, etc), e o Alpine seguiu o mesmo caminho. Eu

considero o período de dois anos um pouco longo, mas o suficiente para que não

deixe o sistema atrofiar. Atualizar entre versões do Alpine é tão simples

quanto editar um arquivo, trocar a versão e mandar atualizar os pacotes. Manter

um sistema atualizado é o mínimo de qualquer infra-estrutura decente, e o

Alpine consegue tornar isso ainda menos doloroso.


¹ _upstream_ remete à fonte, ou seja, onde o software é publicado e

_downstream_ onde ele é consumido e mantido.


O gerenciador de serviços, openRC, é pequeno e simples, e essencilamente existem

dois formatos de escrever serviços para ele, preenchendo algumas variaveis no

arquivo de serviço ou escrevendo scripts mais complexos se necessário,

afinal é tudo shell-script.


Exemplo de um serviço simples

Exemplo de um serviço mais complexo


O gerenciador de pacotes do sistema é incrívelmente rápido e vastamente

documentado. Empacotar programas é realmente muito direto ao ponto. Fora que em

menos de uma hora é possível montar uma infra-estrutura para oferecer pacotes

customizados, ou que ainda não estão disponíveis nos repositórios oficiais. O

próprio Alpine oferece as ferramentas para você montar essa infra-estrutura,

assinar pacotes, manter um índice para consulta (o comando abuild) e basta você

expor esse repositório por um proxy reverso e pronto.


O ponto mais fraco, infelizmente, é a documentação que além de ser bastante

incompleta em alguns lugares, muitas vezes se refere a documentações externas

como a wiki do Arch Linux ou até mesmo de versões antigas do Alpine. Dito isso,

desenvolvedores do Alpine tem colocado bastante peso em manter as _man pages_

dos pacotes atualizadas e disponíveis, e alguns esforços tem sido feito para

melhorar a documentação como um todo.


Outro ponto que ainda atrapalha, mas que na minha opinião revela muito mais

sobre como desenvolvedores veem Linux, é o fato de que a maior parte de

softwares externos tem dificuldade de funcionar no Alpine. Em especial, pelo

fato que o Alpine usa como biblioteca C o projeto do musl-c, ao invés do GNU.

O projeto do musl-c tenta implementar uma versão "correta, simples e segura" da

biblioteca C, o que faz com que alguns softwares específicos não consigam rodar

por ser extremamente dependente de uma implementação específica da biblioteca

C, ou seja, não são por si só, softwares portáveis.


Projeto do musl-c


Apesar disso, não é uma causa perdida e existem algumas camadas de

compatibilidade que a própria equipe do musl e do Alpine disponibilizam, e são

muitos poucos programas que de fato não funcionam ou quebram (eu pessoalmente,

só vi ocorrer em alguns jogos).


Em suma, eu realmente gosto muito do Alpine Linux e me pego muitas vezes

preferindo utilizar o meu notebook justamente porque roda Alpine. Todos os meus

servidores rodam Alpine, e em breve a minha estação de trabalho irá também. Eu

mantenho um repositório de pacotes de terceiros, algumas dezenas de pacotes e

se possível utilizo em máquinas virtuais/dockers do trabalho.


Meu repositório de pacotes pessoais


--


O texto "Alpine Linux" foi publicado em 15 de Junho de 2021.


Voltar para a página inicial


O Conteúdo desse site é sob os termos da licença Creative Commons CC-BY-SA. O código desse site é sob os termos da licença GPL-3.0.

-- Response ended

-- Page fetched on Sun May 19 03:28:13 2024