raserafim
(usa Slackware)
Enviado em 03/05/2018 - 13:45h
o termo "ódio" talvez não seja o melhor a se utilizar...
- Quanto ao SystemD:
vai contra a dois dos princípios mais caros ao slackware: a filosofia KISS e a filosofia UNIX.
enquanto que o sistema de inicialização do slackware (sysvinit) é todo ele composto por simples scripts em modo texto, no entanto, o systemd se tornou um sistema de inicialização grande, complexo, expansivo, que se utiliza de binários e que extrapola, em muito, as funções entendidas típicas e essenciais de um init.
se tornou tão expansivo a ponto de interfaces gráficas e, às vezes, até mesmo aplicativos, lhe terem como dependência.
dois exemplos ilustrativos:
- os logs em toda a história dos sistemas GNU/Linux sempre foram armazenados em arquivos texto puro: de modo a ser possível analisá-los em qualquer situação. no systemd os logs são armazenados em arquivos binários, em que é preciso aplicativos próprios e específicos para lê-los.
- os daemons e comandos executados na inicialização, e o seu ordenamento, no slackware é tudo configurado em um arquivo de texto puro: podendo assim ser alterado em qualquer editor de texto; enquanto que no systemd essas informações, fundamentalmente, encontram-se em binários, que apenas é possível configurá-las por meio de um sistema de comandos próprios.
- Quanto às Dependências:
um dos principais fundamentos para a não utilização de um gerenciador de dependências é que este tipo de gerenciador coloca uma complexidade a mais no sistema: de certa forma, acrescenta uma camada intermediária.
no caso do slackware, por princípio, a adição de camadas intermediárias devem ser evitadas o máximo possível: a ideia geral é procurar sempre colocar o usuário no acesso direto às configurações fundamentais do sistema.
uma outra razão importante é que as dependências indispensáveis ao funcionamento de uma aplicação, por vezes, podem ser relativas.
é importante observar que não se trata aqui da distinção comum em muitas distribuições entre "dependências obrigatórias" e "dependências recomendadas". trata-se apenas do que se entende por "dependências obrigatórias".
por exemplo, um determinado pacote pode ter a dependência do pulseaudio porque foi compilado habilitando a flag que faz esse aplicativo utilizar seus recursos. no entanto, essa flag poderia ser desabilitada, fazendo com que o aplicativo se adeque aos recursos simples do alsa e, assim, dispense a dependência do pulseaudio.
vide o caso recente do slackware: para possibilitar que seus usuários possam escolher entre pulseaudio e alsa, esta distribuiçao mantém alguns arquivos que possuem duas versões (uma para pulseaudio e outra para alsa)
essa mesma lógica de definir as reais dependências em tempo de compilação, logo, existe em várias outras situações. um caso ilustrativo é o do libreoffice: muitas bibliotecas são definidas em tempo de compilação se serão incorporadas em forma de recursos ou não. (veja:
https://slackbuilds.org/repository/14.2/office/LibreOffice/)
ou seja, em síntese, apenas com o usuário tendo contato direto com processo de compilação é que se torna possível definir quais dependências esse usuário quer realmente utilizar ou não.
utilizar um gerenciador de pacotes é entregar essas decisões para a equipe que compilou ou que preparou os scripts de compilação.
uma vez que o slackware preza pelo controle do usuário e os aplicativos que não estão no repositório oficial tem a recomendação de serem instalados a partir do código-fonte (valendo-se de slackbuilds), então, faz algum sentido essa distribuição não fornecer suporte a um gerenciador de dependências.
no entanto, não utilizar um gerenciador de pacotes traz uma série de trabalho, dificuldades e, talvez, até de limitações.
uma das principais limitações é a extrema dificuldade para se manter um sistema mínimo e enxuto -- uma vez que cada instalação de pacotes demandará a instalação de várias dependências.
para contornar de alguma maneira essas dificuldades, o slackware fornece um sistema mínimo de outro tipo: não é um mínimo super enxuto; mas é um mínimo para subsidiar as principais bibliotecas que costumam ser demandadas. (observe que bibliotecas não significa aplicativos -- só para dar um exemplo, no slackware não há qualquer suíte de escritório: como o libreoffice).
interessante observar o caso do Salix: para viabilizar um sistema realmente mínimo e enxuto esta distribuição implementou o gerenciador de dependências -- o que faz com que seja frequentemente referenciada como um "slackware para leigos" (embora realmente essa distribuição possua um instalador mais fácil e algumas telas de configuração que não existem no slackware, entretanto, em minha avaliação, entendo que a sua particularidade mesmo é possibilitar um slackware realmente mínimo)
