eu ia retrucar, mas aí... Em 9 de maio de 2010 11:28, Max Miorim <[email protected]> escreveu: > (...) > E apesar de ser um dos que mais criticam GUIs, eu também sou contra a > falsa afirmação de que o cara que configura as coisas no vim sabe mais > do que o que usa uma interface gráfica para tanto. Não existe > diferença entre usar um editor de textos para mudar o valor de uma > opção e usar uma interface gráfica qualquer para tanto - no fim das > contas tu faz a mesma coisa, a diferença é que o editor de textos > costuma ser mais flexivel, uma vez que a maioria das GUis é projetada > para o "arroz-com-feijão" básico. >(...)
já estava retrucado, ;) >> normalmente as distros "enterprise" dão uma ferramenta pronta que >> abstrai as ferramentas padrão de cada pacote/programa; é justamente >> esse o diferencial de quem opta por "aprender console" num red hat ou >> num slackware. e é justamente essa ferramenta padrão que diminui a capacidade dum admin de outra distro dar suporte numa máquina slackware. ele terá de fazer todo o "caminho longo" do usuário de slackware. inclusive, aqui mesmo na lista tem muito cara bom em slackware que dá suporte em outras distros, e com uma curva de aprendizado menor, graças ao slackware. > > A questão das distros "enterprise" (assumindo que falamos de RHEL e > SLES) é mais por facilitar a administração. Quando tu tem mais de 1000 > máquinas num datacenter fica meio complicado ter uma pessoa editando > confs ou fazendo scripts para editar e deployar estes confs em todos > os servidores e é exatamente este o propósito da maioria das > ferramentas de configuração destas. nesse eu concordo. > > Além disso, falando ainda de RHEL e SLES, boa parte das ferramentas > system-config-* e dos módulos do yast focam justamente em > particularidades das distros, principalmente arquivos no > /etc/sysconfig. Eu não vejo nada de ruim nisto para ser honesto, bem > como também não vejo nenhum problema em usar o dpkg-reconfigure no > Debian e derivados, a questão é que é apenas mais uma ferramenta e a > única coisa a discutir é o quão flexivel está ferramenta se torna para > cada caso. veja veja, se não existisse a particularidade, não existiria a ferramenta dedicada aos problemas particulares. mas aí caímos no ponto de dar suporte a várias máquina e esse é um exemplo que não há como bater, por mais que você gostasse de dar scp pra rede toda, haha. > >>> Além disso, na minha opinião, o Slackware virou uma distro meio que >>> sem fundamento: os hobbistas usam Ubuntu e Madriva porque é mais >>> fácil, perfeccionistas usam Arch e/ou Gentoo por darem um potencial de >>> customização muito maior e os cabeças duras continuam usando o >>> Slackware. :) >> >> não acho isso, perfeccionistas controladores vão encontrar seu lar num >> slackware; o slackware é muito bom pra experimentar e mesmo reaplicar >> soluções que você já tentou, digamos, umas 3 versões atrás, e elas >> continuam funcionando. > > Eu discordo e como indiquei no e-mail original, é uma questão de preferência. > ;) é, mas eu não sou cabeça dura, :P > De certa forma, eu posso dizer que por muito tempo eu usei um monstro > baseado em Slackware e não Slackware propriamente dito: (...) era slackware, o meu era por que o seu não seria? > (...)no começo eu > recompilava *todos* os pacotes para usar as minhas CFLAGS (o que é > muito mais facil de fazer num Gentoo), depois eu comecei a recompilar > estes pacotes para ter mais opções (que também é mais simples no > Gentoo e em distros que segmentam os pacotes como Debian e Arch) (...) isso não é verdade, em uma única linha de menos de 80 caracteres vamos da compilação ao pacote. insisto, em outras passamos pela necessidade de ter artefatos para gerar o pacote, num slackware isso é opcional. > Isso é legal na primeira vez, tu aprende muito com o processo, (...) por isso usar slackware, você aprende as coisas. Já escutei essa história de usabilidade algumas vezes, eu mesmo já pensei que não tinha o que precisava, mas basta ver a evolução dos programas que compõem o slackware que você usabilidade não é problema do empacotador; a usabilidade, facilidade de configuração não deveria ser mérito da distribuição. Se oé é porque eles inventaram algo e não contribuiram de volta para o projeto original. Muitas vezes é algo simples, mas não há o retorno para os desenvolvedores originais. O problema do empacotador é resolver os problemas que ele mesmo cria, ou os que aparecem após juntar tudo numa iso só, :) (...) >> experimente montar você mesmo um pacote para arch, ou ainda montar >> corretamente um .ebuild do gentoo, e todo aquele sistema de slots que >> ele tem, aí o perfeccionista irá reencontrar suas decisões, :) > > Eu já fiz, e não difere muito de um SlackBuild para ser honesto. Os > pacotes RPM precisam de um .spec, que também é quase a mesma coisa e > os mais complicados são os DEB, mas eu não tenho dificuldade em nenhum > formato. >(...) como queríamos desmonstrar: nos rpm precisa-se do .spec, e os .deb são "mais complexos". veja, se você fosse ensinar a empacotar, para cada formato, quantos minutos levaria, supondo que os alunos tem background apenas de bash? > Aqui entra denovo a questão dos "cabeças duras". Muita gente tem má > experiência com um sistema de resolução de dependencias ou gerenciador > de pacotes em particular e passa o resto da vida condenando os mesmos. >(...) mas é porque essa arquitetura de dependências está condenada mesmo. ela não escala. ela permite, por exemplo, dentro de uma mesma árvore tenha-se defeitos e referências cíclicas e deadlocks. dependência de pacote é meta-informação e se até hoje aquele artigo do linuxpackages sobre os slack-required da vida não virou documento oficial é porque algum ex-estudante de lisp já viu isso. se eu fosse fazer, tería um repositório de dependências, que "conheceria" o mínimo possível acerca dos pacotes e mesmo assim ainda seria algo muito baseado na fé. > Eu já tive muitas brigas e "elogiei" muito a mãe dos caras que fizeram > o yast, yum e up2date mas ao invés de me trancar numa bolha eu corri > atrás e aprendi a usar eles de forma que não seja uma experiência tão > ruim. >> num slackware por outro lado até a parte do .SlackBuild é opcional, >> quem aqui já não empacotou o programa na horinha final, dando um >> simples make install DESTDIR=$(pwd)/meu-pacote ? sai uma desgraça, sem >> descrição e tudo mais, mas é muito rápido pra testar, e posso instalar >> e desinstalar normalmente pelo pkgtool. > > Praticamente todas as distros tem isso, é só tu instalar o > checkinstall e usar o checkinstall ao invés do make install. > não falei do checkinstall, apenas do pkgtool/makepkg. vide respostas acima. > Além disso, isso expõe a diferença de nível que nós estamos falando: > quando preciso testar um pacote eu faço num user-mode-linux (as vezes > uma VM qualquer) ou num chroot com o mínimo rodando. Montar o chroot > ou o UML é meio chatingo mas pra usar é só extrair um tar ou montar > uma imagem, eu não sei porque todos os sabidos usuários de Slackware > não fazem isso e arriscam jogar lixo num sistema funcional. ;) >(..) ah, mas tudo tem um limite! você compilaria algo em que não confia? >(...) > > Assim tu ofende não só o Patrick e o pessoal por tráz do Slackware mas > a todo usuário da distro, é como se tu dissesse que somos > incompetentes incapazes de adicinoar funcionalidade e manter > estabilidade... >(...) não falei isso, tem uma tela que é a mesma faz uns 5 anos ou mais e graças a isso é fácil ensinar a instalar slackware. e a inovação acontece também, veja a versão do kernel, o slackpkg, o instalador via usb e tantas outras pequenas firulinhas que nos passam despercebido. > Olha quanto tempo levou até termos um port oficial x86_64, para uam > distro que se diz de vanguarda, nós deveriamos incentivar cada vez > mais a experimentação e implementação de novas soluções e não se > esconder atrás da bandeira de que "é estável porque não foi mexido". >(...) desconheço essa bandeira mas eu concordo com a inovação. só não gosto e dessa novela de toda vez que sai um slack aparece um flame sobre "ah, é velho, ah isso, ah aquilo". acredito que inovação tenha mais a ver com projetos d que com debates, -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.istf.com.br/perguntas/ Para sair da lista envie um e-mail para: [email protected]
