Sbopkg e afins enquanto heresia: um mito que afastou iniciantes do Slackware?

RLFontan
(usa Red Hat)

Enviado em 18/08/2017 - 22:43h

Olá senhores tudo bem?

Estou um tanto polêmico nos últimos tempos, vamos lá. Muitos usuários famosos na comunidade do Slackware defendem que é um desrespeito a filosofia da distro usar ferramentas como Sbopkg, Slackpkg++ e etc. O negócio todo parece ser falado em alguns momentos em tom de brincadeira, mas assumiu uma força maior do que o esperado, e muito gente passou a defender isso com seriedade, de que caso alguém queria usar Slackware de verdade deve saber editar shell scripting. A própria wiki oficial do Slackware tem escrito em um dos seus pontos filosóficos:



Porém eu dei uma pesquisada, e fiz eu mesmo minhas perguntas, uma vez que eu mesmo sempre tive esses problemas, devido a minha falta de tempo para estudar Shell Scripting, já que eu não sou de T.I e nem sou um dinossauro no mundo linux e eu descobri que na verdade o assunto é bem controverso, vejam lá:

https://alien.slackbook.org/blog/ten-years-of-slackbuilds-org/ - Artigo do Alien BOB comemorando o aniversário do Slackbuilds e olhem você mesmos o que ele diz:



Há um tempo atrás eu também abordei o assunto no Slackware Brasil no Facebook, e teve até o Piter Punk aparecendo para defender as ferramentas de automatização:

https://www.facebook.com/groups/slackwarebr/permalink/1225738997452173/

Ele comenta inclusive, que o próprio AlienBOB faz uso dessas ferramentas.

E então senhores, o que vocês pensam sobre esse paranauê todo?

edps
(usa Slackware)

Enviado em 18/08/2017 - 23:13h

Não tenho nada contra usar sbopkg (que inclusive resolve dependências) ou outra ferramenta que lide com repositórios externos, mas para lidar com o repositório oficial eu aceito no máximo o slackpkg+.

Não gosto do slapt-get, e nunca testei o slpkg (ao que parece) o mais habilitado para exercer a função "all-in-one".

Essa coisa de entender ou não de shell script, ou de alguma linguagem é pura besteira! isso não é pré-requisito para um usuário básico. No SlackBuilds são disponibilizadas receitas-de-bolo, existe uma para cada sabor rsrs:

http://slackbuilds.org/templates/

E geralmente (claro, se o pacote a ser compilado tiver suas dependências supridas), o mesmo será empacotado facilmente, no máximo se terá que fazer uns pequenos ajustes no script, no arquivo .info, etc

* lá na antiguidade tive problemas testando o Salix e seu slapt-get, por isso que o descarto.
** se manjar de shell script fosse requisito para utilizar Slackware, imagine o que seria necessário para utilizar CRUX, Gentoo ou algo mais exótico?

RLFontan
(usa Red Hat)

Enviado em 18/08/2017 - 23:18h

Rapaz, isso me triou do Slackware durante um tempinho... vou dar uma chance... só preciso resolver meu problema aqui no HD veinho, que deu erro duas vezes no ext4, aí estou com medo de manter os arquivos nele.

removido
(usa Nenhuma)

Enviado em 18/08/2017 - 23:34h

Aceita por questões técnicas ou por ideologia?

Pelo que se lê sobre o Slack e observando comentários de usuários, se torna questão de ter orgulho em saber quais dependências estão instaladas para determinado pacote, um conhecimento geral sobre a sua distro com o passar do tempo, resultando em controle total da mesma. O que quanto mais automatizado, mais se perde desse conceito.

Ter essa visão de um Slacker não é tão compreensível para quem utilizada distros "amigáveis" e automatizadas. Como da mesma forma não deve ser compreensível para um Slacker do pq alguns usuários preferem deixa tudo na mão de outros programas para resolverem qualquer problema sem se preocupar muito com o que está sendo feito.

Acho que por isso cria todo esse clima de heresia, sendo que no final o rola é questão ter ou não controle absoluto sobre a distro.

"Failure is an option here. If things are note failing, you are not innovating enough" - Elon Musk

slackjeff
(usa Slackware)

Enviado em 19/08/2017 - 03:39h

Minha opinão!
Para meu uso eu acho desrespeito a filosofia que a distro preza. se quer automatização as pessoas devem ir para outra distro, Slackware não é o lugar delas.
Nunca usei nenhum gerenciador que não seja o slackpkg.

GPG KeyId: <0xD9EC33CD>



Meu Site:

http://slackjeff.emmilinux.com.br/



 

lcavalheiro
(usa Slackware)

Enviado em 19/08/2017 - 04:07h

Até onde eu saiba, o sbopkg não resolve dependências, mas você pode facilmente fazer uma queue com as dependências. Mas essa não é a questão. O ponto levantado é a velha questão do mundo slacker: purismo vs praticidade. Eu não me incomodo em usar o sbopkg que no fundo me poupa o trabalho de ir no slackbuilds.org, baixar dependência a dependência e compilar. Isso não é uma questão de automatização do processo, é questão de bom senso. A filosofia do Slackware é a favor da simplicidade, e o sbopkg, paradoxalmente, torna o processo de instalar um pacote mais simples do que ir no site, baixar o cacete todo, compilar tudo manualmente e tals.
Sobre o slackpkg+ eu tenho opiniões controversas sobre ele. É inegável que ele facilita muito a vida em permitir que repositórios adicionais sejam usados no sistema. Mas a não ser que você esteja usando o MLED, é muito melhor usar o sbopkg e compilar localmente os pacotes.
Como (acredito) o usuário mais experiente de Slackware aqui do VOL (21 anos de estrada com a distro), concordo com a filosofia por trás do Slackware: keep it simple, stupid, não keep it pure, stupid. Se uma ferramenta torna o processo mais simples, é coerente com a filosofia da distro usá-la.
--
Dino®
Vi veri universum vivus vici
Public GPG signature: 0x246A590B
Só Slackware é GNU/Linux e Patrick Volkerding é o seu Profeta

Mensagem do dia: Satã representa conhecimento sem limites e não auto-ilusão hipócrita. 

RLFontan
(usa Red Hat)

Enviado em 19/08/2017 - 04:22h

Interessante, acabei de reparar que eu estava confundindo o sbopkg com o sbotools.

raserafim
(usa Slackware)

Enviado em 19/08/2017 - 11:16h

não vejo nenhuma contradição entre as posições que o colega "RLFontan" mencionou.

uma SlackBuils é exatamente um script facilmente configurável que gera um pacote compilado no formato do gerenciador de pacotes do Slackware. tudo é simples (no sentido de ser objetivo) e transparente em uma SlackBuilds.

Aliás, a utilização de SlackBuilds é considerado uma forma "padrão" para a administração de uma das dimensões dos pacotes em um sistema Slackware.

já há muito tempo é possível encontrar arquivos SlackBuilds (ou build) nos repositórios oficiais do slackware (no 14.1, por exemplo, tem do "flash", do "chrome"...)

vejamos, também por exemplo, o que diz o SlackBook sobre o SlackBuild:



o "sbopkg" é uma ferramenta de modo texto que nos permite baixar uma SlackBuilds e os pacotes a ela relacionada (sem precisar entrar em um navegador) e executar essa SlackBuild. além disso, nos permite gerenciar as atualizações dos pacotes que estão no repositório do slackbuilds.org -- portanto dos pacotes que não estão no repositório oficial (e o faz de modo semelhante ao "slackpkg": ferramenta que faz parte oficialmente da administração do Slackware).

(obs: sbopkg não resolve dependências; já o sbopkg+, esse sim resolve dependências.)


de fato me parece haver alguns mitos em torno do Slackware (ou, no mínimo, do que se costuma chamar de "Filosofia Slack").

penso que esses mitos estão mais relacionados com as pessoas que não utilizam essa distribuição (ou aquelas que o utilizam, porém sequer compreendem a distinção entre as duas dimensões paralelas da administração do sistema) do que, propriamente, com os usuários conhecedores do Slackware.

utilizar os famigerados comandos "#./configure && make && make install" não tem nada a ver com o "jeito Slack" de instalar programas. nada!

utilizar esses três comandos para instalar um programa em qualquer distribuição que tenha um gerenciador de pacotes, por mais simples que seja, é um erro. por este método a tendência é se perder o controle da administração do sistema.

há uma enorme distinção entre fazer "trabalho braçal" e ter um "sistema simples"; ter um sistema simples não significa ausência de automação (presença de "trabalho braçal").

não podemos reduzir a compreensão de um gerenciador de pacotes com resolução de dependências, simplesmente, à automação de um "trabalho braçal".

um gerenciador de pacotes com resolução de dependências coloca uma carga adicional de complexidade no sistema: o que, por sua vez, sob determinada perspectiva, pode ser interpretado como uma infração à simplicidade.

para ser breve, vejamos...: em certo sentido uma dependência é relativa. algumas dependências só se tornam dependências a depender das FLAGS de compilação utilizadas.

por exemplo, peguemos o caso do Slackware e do Gentoo: os mesmos pacotes que no Slackware (a partir da versão 14.2) tem como dependência o PulseAudio, no Gentoo, esses mesmos pacotes não possuem essa dependência.

podemos comparar também o Slackware com o próprio Slackware, versão 14.1 com a versão 14.2: na 14.1 o ALSA era o padrão; no 14.2 o PulseAudio é o padrão; os mesmos pacotes passaram a serem compilados na 14.2 com FLAGS que deixam o pacote pronto para operar em com o PulseAudio, tornando-o uma dependência.

o que quero enfatizar com estes exemplos é que um gerenciador de pacotes com resolução de dependência, embora traga uma série de vantagens, traz também uma série de desvantagens: um gerenciador de pacotes com resolução de dependências, em geral, nos retira o poder de controle sobre uma parte do que é realmente dependência e do que não é dependência.

um sistema mínimo sem gerenciador de pacotes com resolução de dependência é, praticamente, inviável. mas um sistema mínimo não é bem a proposta do Slackware.

talvez por isso manter um sistema sem as complexidades de um gerenciador de pacotes com resolução de dependências seja mais vantajoso, ao menos no caso específico do Slackware, do que ter a complexidade, e a sua consequente perda de parte do controle, de um sistema com resolução de dependências.


por fim, mesmo podendo soar esquisito para muitos..., particularmente, utilizo o Slackware, entre outros motivos, porque não tenho muito tempo disponível para gastar com a administração do sistema!!

edps
(usa Slackware)

Enviado em 19/08/2017 - 16:11h

Thitos escreveu:



Técnicas, é muito mais prático utilizar o slackpkg++ que inclusive permite o uso de repositório local, aqui utilizo todos os SlackBuilds que empacoto e deixo-os neste local, e para instalá-los basta um simples slackpkg install. Isso sem falar a possibilidade de utilizar repositórios externos como o MATE, Cinnamon, etc



Não gosto de fanatismo, mas cada um sabe o que melhor lhe atende, eu sei quantos SBos estão instalados em minha máquina (o faço via script) e posso afirmar que o Slackware é o único sistema que utilizei onde não tenho nada instalado manualmente, o que eu precisava e não existia empacotei para o SlackBuild.

* a única exceção é o VirtualBox, cujo instalador e extensões são obtidos manualmente.

edps
(usa Slackware)

Enviado em 19/08/2017 - 16:20h

O sbopkg sozinho não resolve as dependências, mas junto ao pacote sbopkg vem um utilitário chamado sqg, esse sim faz o trabalho! que é gerar o arquivo .sqf, por exemplo para instalar o plank:

# sqg -p plank

# sbopkg -i plank  

E caso se queira gerar os arquivos queue para todos os SlackBuilds, bastará executar:

# sqg -a 

Eis o arquivo plank.sqf:

json-glib

libdbusmenu

vala

libgee

libwnck3

libgtop

bamf

plank 

Então ao rodar os 2 comandos acima, segue-se a ordem de instalação de cima para baixo até que se chegue ao pacote desejado, no caso o Plank.

O sbotools por sua vez já faz isso de forma automática.

73du4rd0
(usa Void Linux)

Enviado em 19/08/2017 - 19:31h

Não tenho nada contra quem usa slapt-get ou até mesmo GSLAPT(sério que algum slacker usa isso?), mas eu mesmo não uso tais ferramentas. Já testei o slapt-get, e não me foi em nada melhor que o bom e "velho" slackpkg. O que ainda chego a usar é o slackpkg+ que facilita bastante a vida, podendo adicionar repositórios tanto locais como da comunidade, como por exemplo o slackonly, o repositório do slackware com o maior número de pacotes pré-compilados (=~6200), ou alienBob, repositórios do KDE Plasma 5, Mate, e outros projetos mantidos de maneira não-oficial...
Não gosto muito do sbopkg, porque as vezes gosto de modificar os slackbuilds e acho mais fácil e prático fazer diretamente.
Esse negócio de heresia é pura bobagem filósofica de alguns usuários, e as vezes acho que faço parte deles, mesmo indiretamente.

---------------------------------------------------------------------------------|

The best benevolent dictator for life = Patrick Volkerding 

---------------------------------------------------------------------------------|

 

RLFontan
(usa Red Hat)

Enviado em 19/08/2017 - 20:58h

Não é melhor usar logo o sbotools que apresenta os pacotes 1 por 1 e lhe diz a função de cada um no processo de instalação?