On 5/9/10, Leonardo <[email protected]> wrote: > Em 9 de maio de 2010 00:53, Max Miorim <[email protected]> escreveu: >> (...) >> >> Mas o que tem de especial nisto? Não tem nada, qualquer usuário de >> qualquer distro pode escolher trabalhar assim. É assim que muitos de >> nós trabalhamos com outras distros como SLES, RHEL, Debian e tantas >> outras que *precisam* ser usadas num ambiente "enterprise". >>(...) > > mas você não concorda que o ubuntu user dificilmente irá "escolher" > trabalhar assim?
Por mais que eu deteste o ubuntu, eu só não concordo com essa premissa de que os usuários ubuntu vão fugir do console. Se tu disser para estes usuários - na grande maioria entusiastas - que é possível instalar o Webmin num Slackware e configurar quase tudo de forma fácil, eles vão usar o Webmin sempre e vai dar na mesma. 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. > 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. 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. 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. >> 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. ;) De certa forma, eu posso dizer que por muito tempo eu usei um monstro baseado em Slackware e não Slackware propriamente dito: 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) e depois de um tempo eu comecei a incorporar os meus pacotes (ou de terceiros) no Slackware64-current (e eu quebrei a compatibilidade de muita coisa com isso :P). Eu também já testei coisas bizarras como o emerde, um outro ports-like que eu nem lembro mais o nome, sbopkg, slapt-get, swaret, sbopkg, criei *vários* scripts para fazer coisas banais e no fim das contas eu vi que tudo que eu fiz foi reinventar a roda. Isso é legal na primeira vez, tu aprende muito com o processo, mas como os caras da Linux Journal falaram no podcast deste mes, depois de um tempo a tendencia é que isso se torne chato, eu não quero perder meu tempo rodando o ldd e recompilando um mesmo programa 4 ou 5 vezes até ficar como eu quero, eu quero só usar o programa e neste departamento ainda temos muito que avançar. ;) > é verdade que ultimamente o /testing tem ficado vazio, e que certas > coisas que não quebravam passaram a quebrar, mas isso é evolução do > software básico, não tem muito o que fazer à respeito. Isso se dá por dois motivos: o primeiro é a tendência (retardada por sinal) do pessoal do freedesktop/xorg em usar essas aberrações como HAL, PolicyKit, ConsoleKit e etc. que sequer tem alguém que responda por elas (é um desenvolvedor e pelo que sei não é tão fácil assim achar o cara...). O segundo motivo é que os DE de peso - KDE e GNOME - tem cada vez mais usando bibliotecas e mais bibliotecas que conflitam umas com as outras e isso aumenta consideravelmente o tempo de teste. > 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. 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. 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. 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. ;) >> E ai eu entro no terceiro problema: com o passar do tempo, as distros >> incorporam funcionalidades e melhoram processos, o que tem de novo no >> Slackware desde a primeira vez que eu usei? A versão dos sofwares e >> uma ou outra mudança menor como trocar o formato de compactação dos >> pacotes de Gzip para LZMA. > > isto não é problema, é uma feature pouco conhecida em outras > distribuições chamada estabilidade, ;) 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... Existe uma diferença gritante entre mudar as coisas por mudar e ouvir dos usuários sugestões para melhorar a distro mantendo as suas características. A questão é que as mudanças não são ruins, são de fato saudáveis e o medo de fazê-las é mais uma das coisas que mantém a distro parada. 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". -- 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]
