Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
m*rda (Pontos:2, Engraçado) |
| | Ainda há uns 5 dias saquei o slackware7.1 =) "Remember children, there are no stupid questions, only stupid people", in Southpark |
| |
| por Anonimo Cobarde em 01-07-01 22:13 GMT (#2) |
| Quando é que o Slackware começa a ter um gestor de pacotes decente como o DEB ou mesmo o RPM ? |
| |
|
|
| | tipico de alguem que administra 1 ou 2 servidores... Quando tiveres 50/60, começas a achar menos piada, ou contratas 100 gajos para te ajudarem ;)
-------------------------------------------- If there is such a thing as too much power... I've not discovered it... |
| |
| | qual o problema com os .tgz ?! porque razao ira' dar mais trabalho instalar em mais do que um, quando comparado a um rpm (a um .deb e' simples de perceber 8) queres actualizar a distro, usas o autoslack e actualizas o ramo da tua versao (usualmente apenas actualizacoes de seguranca) ou contra o -current que ira produzir a ultima beta queres instalacoes automaticas, tipo debian, usas o mais uma vez o autoslack que ainda nao e' perfeito mas cada vez melhora mais claro que apenas podes instalar pacotes desta forma se sao incluidos na tua versao de slackware mas com umas pequenas alteracoes apontas o autoslack para um servidor teu e ele ira' actualizar, instalar o que tu la' colocas queres instalar novo algo em 100 computadores, sacas a source , sacas o protopkg, instalas crias as regras e instalas nos 100 o tgz que ele cria usando o autoslack. ate' e' mais simples que com os RPM 8) assim ele faz a compilacao e as instalacao personalizadas para cada um dos computadores o que o pessoal normalmente quer e' pacotes binarios criados para nao ter trabalho para compilar (alguns porque nem sequer sabem, ie: newbies de mandrake e redhat demasiados habituados com o M$ window$) dependencias?! tirando os deb tens sempre que verificar as dependencias, com a slackware podes instalar sem estarem satisfeitas mas depois podes instalar a que falta, com os RPM nao te deixa ate' o obrigares a instalar ou instalares o que falta e depois voltar a tentar... eu nao sei, mas acho que prefiro o metodo da slackawre, pois nao me apetece passar dias a lutar contra outro OS, chega-me (e sobra) os da M$ mas mesmo assim, para quem quer, podes usar RPM no slackare, ele traz suporte para eles, cabe ao administrador escolher
Higuita |
| |
| | Yeap... Se calhar tens razão... Agora tirar listagens de pacotes com rpms é muito mais simples, se precisares de um index de ficheiros respectivo a cada pacote... Klaro que o tgz é super poderoso, essa coisa foi feita para guardar backups em Tape's... nao para packet manager... Claro que o autoslack tambem perde muito comparado com o Sistema da Red Hat Network... o rpmfind ajuda bastante... enfim... Cada um com os seus...
-------------------------------------------- If there is such a thing as too much power... I've not discovered it... |
| |
| | Claro que os RPM e os DEB teem mais potencial que os TGZ, mas muita gente tem ideia que os TGZ sao inuteis, que dao muito mais trabalho que os restantes o que actualmente nao e' verdade todos os 3 pacotes tem os sem pontos fortes e pontos fracos o resto e' como tu dizes, uma questao de gosto...
Higuita |
| |
| | o que o pessoal normalmente quer e' pacotes binarios criados para nao ter trabalho para compilar (alguns porque nem sequer sabem, ie: newbies de mandrake e redhat demasiados habituados com o M$ window$)
Ta' mesmo visto que tens demasiado tempo para "brincar". Se tivesses que manter N servidores actualizados perdendo o minimo de tempo possivel nao dizias isso.
Quando me vem pessoas com este tipo de argumentos, normalmente nem discuto mais, porque eles nem sabem de que estamos a falar. Afinal eles tem o seu PC de casa actualizado e nao lhes custou nada. :)) |
| |
| | sim eu tambem uso pacotes binarios, mas geralmente gosto mais de os compilar pessoalmente...(tirando os grandes pacotes, tipo X, KDE, mozilla) mas tu nao deves ter lido totalmente o meu post, pois nao? actualizar servidores= autoslack(actualiza toda a distro)+protopkg(para produzir facilmente actualizacoes dos pacotes nao incluidos na distro, usando depois o autoslack para actualizar apartir do master) agora nao percebo que tempo e' que ser perde em fazer "tar zvfx ???.tar.gz; cd ???; less README;less INSTALL;./configure; make;su -c 'make install'" se e' um pacote que eu ja' conheco, que ja' sei o que precisa, passo em frente os less se e' para instalar em varios, faco um tgz com o protopkg e instalo com o autoslack o protopkg e' um script que tu defines o que ele deve fazer para instalar atravez da source tipo defines o nome, o local onde instalar, os comandos para compilar e instalar e ele produz um tgz que ao ser instalado com o installpkg compila e instala como nos o configuramos em cada maquina... claro que eu nao ando manualmente a compilar a source em todos os servidores, configuro num, instalo em todos como um pacote binario (apesar de nao o ser) sim, pacotes binarios sao mais simples... sim, pacotes binarios podem dar mais problemas cada um decida para o uso que da' as suas maquinas
Higuita |
| |
| | "agora nao percebo que tempo e' que ser perde em fazer "tar zvfx ???.tar.gz; cd ???; less README;less INSTALL;./configure; make;su -c 'make install'" So podes estar a brincar!!! Eu tb gosto muito de tarballs, mas vai buscar o tar e o rpm de um programa qq e compara o tempo que demoras a instalar um e outro... Cumps.
It doesn't matter who made it... It matters who got the idea (monk) |
| |
| | hehehe eu sabia que alguem me iria apanhar aqui ;) "apenas" 3 ou 4x mais demorado 8) mas a nao demora assim tanto tempo como isso nao te esquecas que depois do less INSTALL podes fazer o ./configure; make; make install de uma so' vez e mudas para outra consola para fazer outra coisa como ninguem instala software todos os dias, a diferenca e' um pouco insignificante nao estamos a falar de uma diferenca de horas, mas sim de alguns (poucos) minutos Higuita |
| |
| | Só isso ? Ainda bem enquanto ali vou tomar um café aqui na tasca ao lado porque ja tive tempo de deixar o meu sistema instalar sozinho os meus rpms e deb enquanto tu tais ai em frente ao computador a espera de... que talvez de um erro e tenhas que mudar isso tudo a mao etc etc... enfim.. quando eu chegar da tasca e isso tiver dado problemas talvez saque o source ou se calhar ate um tarball e porque não a ver o que se passou... mais enfim é uma questao de gosto e de ... Talvez seja por usar um sistema a la redhat, não sei deve ser mania minha mesmo. Meus 2 escudos |
| |
| | sim eu tambem uso pacotes binarios, mas geralmente gosto mais de os compilar pessoalmente...(tirando os grandes pacotes, tipo X, KDE, mozilla) Curioso, pois é precisamente em pacotes grandes desse tipo que o aumento de velocidade "compilado" vs. "binario 386" mais se nota... |
| |
| | pois, mas tambem se tornam mais complexos e atraem mais problemas... e ai sim, caio no problema do post anterior, onde um binario demora ate' 5 minutos a instalar, mas resolver um problema na source demora horas mas mesmo assim o meu proximo alvo vai ser o mozilla... acho que o kde e o gnome nao irei tentar a nao ser que tenha mesmo muito tempo de sobra mas o objectivo e' ir evoluindo aos poucos ;) Higuita |
| |
| | Eu no slackware 7.0 (modificado) compilei o X 4.0.0 e o Mozilla 0.8. Acho que o Mozilla demorou mais tempo a compilar que o X... |
| |
| | heheehe eu sei que o mozilla e' um monstro mesmo grande... ja' li varias referencias que gasta 80Mb para compilar, para alem da source o X eu ia compilar, mas nao havia na altura suporte para a minha placa grafica caseira (s3 savage4) logo deixei passar... agora tenho instalado os pacotes da slackware ja' agora sobre o mozilla, usaste alguma optimizacao?! afinal qual a optimizacao original (eu ja' li que era nenhuma, era -02, -O3, era mcpu=pentium e sem tirar a source ainda nao cheguei a conclusao nenhuma)
Higuita |
| |
| | Eu (acho que) usei simplesmente uma opção que era do tipo optimize no ./configure. Passei algum tempo a ler os README's e INSTALL's e acho que na altura a opinião com que fiquei foi que o ./configure script detectava o tipo de processador e outras características, pelo que só era preciso por uma flag no ./configure para optimizar. Mas não tenho a certeza, já foi há algum tempo e desde aí já compilei montes de outras coisas, pelo que não há espaço em memória para me lembrar dos pormenores todos ;) |
| |
| | Tenho visto este thread e n resisti a dar a minha opinião :) Tenho tido uns tripes com as optimizações na compilação e pelo q vi existem bons programas e maus programas a nível de código. Uns aguentam as optimizações e outros n aguentam enquanto os estás a correr. Por isso escolhe bem as optimizações, mas é a respeito disto q eu ia dizer. Acho q pouco vais ganhar usando outras opções de optimização além do '-march=aqui_o_teu_processador'. Esta opção já inclui essas q vocês têm falado e outras mais adequados ao vosso processador.
[]'s |
| |
| | E tá visto q não conheces o slack :) Se tiveres N servidores, então tens apenas 1 deles a servir por ftp os pacotes aos outros todos. A seguir automatizas tudo com o autoslack a partir desse ftp_server. Podes até compilar um pkg e colocar nesse server e instalar em todos os pc's muito rápido. Agora explica-me uma outra distro q faça melhor este trabalho :) []'s |
| |
| | Ja' agora, vejam o artigo anterior sobre o Linux Standard Base, especialmente o Chapter 13:
Package Format
Applications should be provided in the RPM packaging format as defined in the appendix of Maximum RPM, with some restrictions listed below. [1]
Por isso, julgo que o Slackware (e a Debian e outros) vao ter RPMs muito rapidamente, se quiser ser parecido com alguma coisa (standard). |
| |
| | talvez a Debian venha a ter mais um sabor (codename BrainDamaged) que esteja de acordo com os "standards"! |
| |
| | caso nao tenhas lido a nota no fim, as distros podem usar outros pacotes, apenas teem de ser capazes de usar os rpm... ora a slackware ja' traz o rpm pelo menos desde a 7.0 (ou talvez mais tarde, nunca me interessei em usa-lo) logo ja' cumpre este standard a uns tempos... claro que o melhor e' usar o alien ou o rpm2tgz 8) agora um comentario off topic: claro que os RPM foram escolhidos, existem mais distro a usa-lo, a deb nao tem tanto suporte...(apesar de eu os considerar melhor) continuo a achar que um sistema de pacotes novo feito de raiz a aproveitar o melhor dos .deb e dos rpm seria o ideal (e com um nome diferente para nao se mostrar tendencioso para uma distro)
Higuita |
| |
| | Ha ja sei daqui a pouco começo a chegar a conclusão que o mau do rpm é se chamar rpm... porque se tivesse outro nome menos sugestivo até se podia usar... *g* |
| |
| | 8) nao propriamente... o que eu acho pior no RPM e' a base de dados ser binaria e impossivel de aldrabar mas acho tambem que para um standard o nome deveria ser generico, nao a apontar para alguma distro digo o mesmo do .deb e ate' do .tgz pois ja' sao conotadas com uma distro em especial e continuo a dizer, um sistema de pacotes com o melhor dos 3 seria o ideal e ja' que se esta' a fazer um standard, porque nao fazer logo um melhor que todos os actuais?! Higuita |
| |
| | Claro que compilar é aqula coisa trivial: Não leva tempo nenhum. Não precisas de ter o código fonte O código fonte não ocupa muito espaço de qualquer maneira. Não precisas de saber minimamente desevolver software para interpretar as mensages de erro. Por outro lado, um tarball com o código fonte tem todas as capacidades de gestão de software que alguma vez vais precisar: Sabe perfeitamente quais os ficheiros que lhe pertencem, principalmente aqueles que são gerados a partir do conteúdo do tarball. Dispõe de um sistema sofisticado de dependencias, recomendações e sugestões. Os programadores preocupam-se em fazer scripts de instalação/upgrade/desinstalação que vão além de colocar os executáveis e libs nos directórios certos. Fazem uso de ferramentas adicionais para gerir o software existente no sistema. Vantagens de tudo isto: Quando queres instalar algo em N máquinas, metes cada uma a compilar para si. Podes-te divertir a resolver N vezes o mesmo problema Evitas a complexa operação de fazer o teu próprio pacote pré-compilado, se não existir um. Quando fazes upgrades, os scripts de instalação apagam ficheiros que deixaram de ser precisos. Quando queres remover algo do sistema, não precisas dos scripts do código fonte para eliminar os ficheiros que instalou, porque vais apagá-los um a um. Há mais, só que estou a ficar cansado. Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | ai ai... eu nao digo que e' perfeito, que e' o melhor do mundo... sim os pacotes binarios sao bons, eu tambem uso, mas tambem nao tenho *nenhum* problema em usar o codigo fonte, ate' muitas vezes prefiro >* Não leva tempo nenhum. nao me digas que ficas a olhar para o monitor a ver compilar... nao me digas que tens falta de CPU a coisa que gasta mais tempo e' ler os README e os INSTALL, mas isso ate' faz bem a saude do servidor claro que os pacotes binarios instalam mais rapido, mas eu nao instalo software todos os dias logo 1 minuto ou 5 minutos e' indiferente >* Não precisas de ter o código fonte sim e ... em vez de sacar o binario saco a source depois de compilar, apago-a igual ao pacote binario... >* O código fonte não ocupa muito espaço de qualquer maneira. falta de espaco de disco?! para pacote complicados e grandes eu uso os binarios, nao sou doido (embora possa parecer 8) >* Não precisas de saber minimamente desevolver software para interpretar as mensages de erro. bem, eu estou a falar de programas finais para serem usados, nao em betas para serem testados tirando betas, quase nunca tive problemas a compilar nada em linux e mais uma vez, os pacotes grandes e complicados eu deixo para a distro >* Sabe perfeitamente quais os ficheiros que lhe pertencem, principalmente aqueles que são gerados a partir do conteúdo do tarball. bem, normalmente deve-se instalar as coisas pela source para /usr/local a distro deixo para os pacotes produzidos pela equipa da slackware >* Dispõe de um sistema sofisticado de dependencias, recomendações e sugestões. README, INSTALL e o ./configure geralmente muito melhor que a info que os RPM dao >* Os programadores preocupam-se em fazer scripts de instalação/upgrade/desinstalação que vão além de colocar os executáveis e libs nos directórios certos. tirando pacotes muito pequenos, todos os que eu usei trazem o script para o make install para desinstalar usas o removepkg (lembras-te do protopkg?!) ora para actualizar e' que poderia ser um problema, mas nada que um backup da /etc e da /usr/local/etc nao resolvam como ja' disse, depois de instalar eu apago a source >* Fazem uso de ferramentas adicionais para gerir o software existente no sistema. ou sera' que os gestores de pacotes tambem nao querem saber o que instalas pela source? >* Quando queres instalar algo em N máquinas, metes cada uma a compilar para si. sim e... eu nao uso RC5 ou la' como se chama, se o cpu nao e' usado, esta' idle assim ate' permite optimizacoes locais, mas eu nao me dou ao trabalho >* Podes-te divertir a resolver N vezes o mesmo problema 8) bem por essa logica, tens o mesmo problema com os RPM, deb, etc resolves para um, clonas para os outros apartir do master se sao servidores muito diferentes, entao tens de ter os mesmo cuidados como com os outros pacotes >* Evitas a complexa operação de fazer o teu próprio pacote pré-compilado, se não existir um. yep, configuro o protopkg para compilar na altura e instalar-se... mais simples que fazer um pacore pre'-compilado >* Quando fazes upgrades, os scripts de instalação apagam ficheiros que deixaram de ser precisos. upgradepkg ??? (que e' quase igual a removepkg ??; installpkg ???)
claro, fazendo sempre um backup dos etc, mas isso quer em binario, quer em source... mais vale salvaguardar que reconstruir 8)
>* Quando queres remover algo do sistema, não precisas dos scripts do código fonte para eliminar os ficheiros que instalou, porque vais apagá-los um a um. removepkg mais uma vez, depois de instalado nao preciso da source... ou pode-se usar o checkinstall para fazer tgz ou rpm agora mais a serio... eu nao quero gozar com a vossa cara, eu sei o que voces querem dizer, os binarios sao mais simples de usar, mas o que eu quero dizer e' que o pessoal desconhece que usar a source nao e' um bicho de 7 cabecas, com um bom sistema pode ser tao simples como com os binarios se se usar a source de modo muito manual, seria um inferno, mas com a ajuda de umas ferramentas pode-ser transformar a source num pacote tal como os outros agora e' uma questao de gosto decidir o que usar eu uso um pouco dos dois, voces usam o que vos da' mais jeito
Higuita |
| |
| | Oh amigo... não é questão de não querer ter trabalho .... é mais uma questão prática. Tenho mas o que fazer do que a gastar o meu tempo a compilar tarballs. Meus 2$00 escudos |
| |
| | Outra vez ... Vocês é q n têm ideias práticas ! Como disse num post anterior: Qq admin q s preze tem um pc a servir os packages (qq q seja a distro) para o resto da rede. Então basta compilar 1 ÚNICA vez e servir pela rede aos outros todos !!! Alguma vantagem noutros package-manager ?! Capiche ? |
| |
| | ALELUIA!!! tava a ver que ninguem percebia 8) Higuita |
| |
| | A questão não e servir os pacotes porque isso é a parte mais pratica da questão o problema mesmo é compilar/instalar aquilo tudo que no caso dos packages .deb rpm etc etc.. e so clicar e ja esta.... magico :) isto é quando nao dá problemas claro... mais será so os rpms que os dao ? e emsmo se derem a sempre alternativas... |
| |
| | É assim, o problema é q tavam a dizer que ninguém tava com pachorra para compilar aquilo tudo no slack ... o slack era o PIOR =:-)) Mesmo sem ser slack TODA a gente tem de compilar quando o soft n existe em package. Ok, no debian com 'apt-get --source ...' faz isso, mas em slack tb nao o deixa de ser menos ou mais prático/demorado. No debian precisas de 3 linhas para trazer/compilar/instalar um source e no slack tb só precisas de 3 comandos. O tempo demora o mesmo a compilar tanto em slack como com o debian. Por isso tá igual ! Quanto a binaries a história é diferente, acaba por ser mais prático (n estou a falar de dificuldade) instalar software pelo debian se n soubermos quais são as dependencias.
[]'s |
| |
| | Já está a ser desenvolvido o autoslack. Claro q n chega aos pés do dpkg, mas faz tudo o que um user precisa: Instalas-te o teus pkg's direitinhos ... então depois correndo o autoslack por exemplo na cron ele faz um check ao site da slack para ver se existem atualizações. Caso existam, faz o q tu configuraste. Faz o upgrade, ou apenas grava no disco para tu veres antes de instalares, ... Um dia ele será integrado no slackware, se bem que ele já está bastante estável. ftp://ftp.slackware.com/pub/slackware/unsupported/autoslack/ |
| |
| | O slack não tinha um CVS central como os BSDs? Em que actualizar todo o SO é só questão de: cd /usr cvs blábláblá cd /usr/src make world (ou parecido)
"Ford, you're turning into a penguin. Stop it." - Arthur Dent |
| |
| | Nop, mas por acaso acho q era a melhor opção/solução. Acho bastante prático e eficaz o 'make world;mergemaster'. Existe uma nova distro da OpenWall (conhecida pelos maravilhosos patch's de segurança para o kernel_linux) mesmo muito beta que vai utilizar o mesmo sistema além de ser mesmo muito segura. http://www.openwall.com/Owl/ [OFF-TOPIC] A gildot recusou esta notícia. Até achei bem importante para o linux por causa das suas features q provávelmente mais nenhuma tem. Mas ... |
| |
| | A segurança de uma distro vem de quem esta por detras dela... A nivel de kernel a que traz mais segurança é possivelmente a VA e a Immunix com o FormatGuard, StackGuard (Egcs) e o ScaFolder, e vem optimizada para Server, nao traz pacotes de lixo tipo GNOME/KDE...
-------------------------------------------- If there is such a thing as too much power... I've not discovered it... |
| |
| | A nível de kernel?? A nível de kernel tens os patchs openwall, lids, etc. A VA apenas adiciona alguns patches para hardware, e a Immunix não toca no kernel...
hugs Strange |
| |
| | A Immunix nao toca no kernel ?? tsk tsk, pega no pacote da source do kernel, instala com -Uvh e ve se toca ou nao!!... tirando os patch's que traz, sim... traz patch's, faz um diff com a kernel standard e depois evitas asneiras como essa!
-------------------------------------------- If there is such a thing as too much power... I've not discovered it... |
| |
| | "patch's, faz um diff com a kernel standard e depois evitas asneiras como essa!" igualmente. o kernel da immunix é o mesmo que da redhat (tb traz patches, sabias?). Além disso, tenta só compilar um kernel num sistema immunix...
hugs Strange |
| |
| | nao, podes fazer isto (cvs) ao pacotes binarios e depois usar o autoslack para actualizar (ou usar o upgradepkg *) mas nao tens nenhuma opcao para fazer um make world com ja' foi dito o autoslack ira' resolver quase todos os problemas de actualizacao, pois e' esse o seu objectivo... ele ira' um dia poder actualizar, remover e instalar a distro de uma versao para a seguinte neste momento quase faz isso, apenas se tem de ter cuidado com as dependencias (tipo instalar file-utils.tgz compilado para a ultima glibc e so' depois tentar instalar a glibc... tambem nada dificil de resolver), tendo ja' havido varias alteracoes para prevenir isto mas ainda nao completas...mas por alguma razao ainda nao esta' na versao official do slackware 8)
Higuita |
| |
| | CVS a binários?? Para que serve isso?? Deviam antes usar rdist ou rsync... Ou apenas o mirror...
hugs Strange |
| |
| | sim tens toda a razao, e' rsync e nao CVS... nao liguem, era o sono e a normal estupidez do dia a dia 8) Higuita |
| |