| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Se é um escritório onde não te interessa instalar mais nada a não ser o que venha na distribuição então compra o SuSE 9.1. Eu estou a considerar tirar o Debian cá de casa (heresia!) e trocar pelo SuSE, perdi a pachorra para andar a configurar algum hardware à lá pate e gosto bastante do YaST.
O Fedora sofre dos males do legado RedHat. É impossível puxar uma aplicação per-se que faça parte do Gnome, tem de se puxar todo o package gnome-xpto.
Ainda tens o Caixa Mágica cuja vantagem é poder ir bater à porta deles caso tenhas algum problema e não to resolvam :)
Se quiseres um servidor RedHat experimenta o White Box Linux, porque segundo o que li no site eles pegaram nos SRPMS do RedHat Server 7 (ou será o 7,3?) e fizeram os CD's de instalação. Claro que não tem suporte mas sempre podes visitar o site da RedHat porque pode haver alguém que já tenha tido o problema e eles o tenham resolvido.
Continuas a ter a opção portuguesa do Caixa Mágica.
Se nada disto te interessar - provável - sempre tens o Debian 3.0 - que bem conheces ;)
---
Este espaço pode ser seu! |
| | | | | | Olá!
Nos servidores nunca instalo autoconfiguração de hardware. Mas isso são gostos...
De qualquer modo se é só por causa disso que vais trocar debian, tenta a autoconfiguração do knoppix. Ou se quiseres ser menos "automágico":
# apt-get install discover hotplug
(Ou não estás a falar dele reconhecer a placa de rede ou o gravador de dvd's USB, etc... Mas sim de adicionar uma impressora de rede, configurar endereços ip na placa de rede, etc?)
paz,
ratao |
| | | | Em vez do hotplug eu aconselho o murasaki - another HotPlug Agent.
Pelo menos comigo tem dado melhores resultados.
Enquanto o hotplug so detectava o meu rato USB se ele estivesse plugged no arranque, o murasaki detecta-o em qualquer altura e posso tirá-lo e voltar a pôr que ele fica sempre a funcionar.
Outra ferramenta de autodetecção e configuração de hardware disponivel em Debian é o kudzu - The Red Hat Linux hardware probing tool.
Ainda não cheguei a experimentá-lo porque neste momento tenho o hardware todo funcionar bem... :-)
BTW, tenho Debian instalado no portatil já há uns meses e, depois de já ter experimentado um monte de distros, nunca nenhuma me agradou tanto... nem mesmo SuSE com o excelente YaST... e pode ser que este venha a ser adoptado pelo Debian, agora que é GPL...
|
| | | | | "segundo o que li no site eles pegaram nos SRPMS do RedHat Server 7 (ou será o 7,3?) e fizeram os CD's de instalação" Lê outra vez. Não é essa a versão que eles foram e estão a ir buscar as actualizações...
"No comments"
|
| | | | woops sorry, tens razão, é o RHEL 3.
"This product is derived from the Free/Open Source Software made available by Red Hat, Inc but IS NOT produced, maintained or supported by Red Hat. Specifically, this product is forked from the source code for Red Hat's _Red Hat Enterprise Linux 3_ product under the terms and conditions of it's EULA.
---
Este espaço pode ser seu! |
| | | | | Eu estou a considerar tirar o Debian cá de casa (heresia!) e trocar pelo SuSE, perdi a pachorra para andar a configurar algum hardware à lá pate e gosto bastante do YaST.
Caro amigo, desde que conheci o SuSE, nunca mais quis outra.. e assim vivo :-)
Dominus vobiscum |
| | | | | por mais que custe aos respectivos fãs, Debian decididamente não é para desktop. pode servir para o desktop caseiro de um "carola" que goste de andar a partir pedra até ter as coisas a funcionarem, ou para um discípulo do Stallman. porém, quem gere desktops empresariais deseja máximo de funcionalidades com mínimo esforço de configuração. e para conseguir isso terá que ir procurar a outro lado... eu sempre fui um RedHat/Fedora man. porém, há três meses experimentei o SuSE 9 Professional e fiquei maravilhado. o Yast é uma ferramenta muito poderosa. fiquei também impressionado com a quantidade de software que vem nos CDs (ou DVD) e com a forma bem pensada como os pacotes estão compilados. traz um kernel que suporta filesystems para todos os gostos: JFS, ReiserFS, XFS, Ext2, Ext3,... sem esquecer suporte completo para ACLs! praticamente todo o hardware pode ser configurado usando o Yast.
o SuSE 9.1 parece que traz o kernel 2.6 por default. há um iso do Live CD ao estilo Knoppix para ter uma ideia do como é a nova versão.
|
| | | | | | | À uns meses para cá que instalei mantive o meu desktop com Debian sem ter qualquer trabalho e já tive num projecto profissional em que se utilizou os cd's de knoppix como base de instalação de Debian e também não se teve qualquer trabalho que não se tivesse com qualquer outra distribuição ou mesmo qualquer outro sistema operativo. Já usaste Debian? Se sim à quanto tempo? Que versão de Debian? Debian Sid está muito boa no desktop, não é perfeita, mas também nenhuma outra distro é e eu já experimentei muitas, incluindo Red Hat Linux, Suse e Mandrake. Já agora não te esqueças que a maior parte das distribuições que são exclusivamente viradas para o desktop são baseadas em Debian. Porque será?
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | servidor: arch linux (preferencialmente) ou gentoo linux desktop: mandrake, suse, lindows, xandros e cia. Já agora, é Closed Source, e não Close Source. E não, o closed source não é o futuro do Linux, como é óbvio. Bem pelo contrário.
|
| | | | | "a distribuição é debian, claro." porque?
thing |
| | | | | | Porque gosto bastante desta distribuição e quem me conhece, sabe isso ... heehe
Cumps-
Gass |
| | | | É claro que a distro ainda não apanhou uma mandrake ou Suse na configuração automática de todas as tralhas, mas está a fazer por isso, e tem "provavelmente" o melhor sistema de gestão de packages do mundo Unix.
Gustavo Felisberto
(HumpBack)
Web: http://dev.gentoo.org/~humpback |
| | | | | | Eu não sou avesso a compilar coisas mas entre compilar o mozilla de vez em quando (sim, eu sou desses malucos) a compilar tudo o que vem parar à minha máquina vai uma grande distância... Sou maluco mas não tanto.
Ainda para mais a minha experiência com Gentoo foi bastante frustrante. Tentei instalar aquilo num Alpha (afinal de contas é o mais cutting-edge que se pode arranjar para essa arquitectura) e depois de 24 horas a moer aquilo decidiu estoirar, fixe, ainda por cima nem sequer foi nenhum erro de compilação de um pacote, bloqueou simplesmente (não crashou mas não saia do mesmo sítio). Não me apeteceu recomeçar e instalei lá o SuSE 8.1 (que na realidade é o 8.1 + pacotes novos diversos).
-- Carlos Rodrigues
|
| | | | Ainda para mais a minha experiência com Gentoo foi bastante frustrante. Tentei instalar aquilo num Alpha (afinal de contas é o mais cutting-edge que se pode arranjar para essa arquitectura) e depois de 24 horas a moer aquilo decidiu estoirar, fixe, ainda por cima nem sequer foi nenhum erro de compilação de um pacote, bloqueou simplesmente (não crashou mas não saia do mesmo sítio).
A mim aconteceu-me algo bastante parecido, mas felizmente ainda não tinha chegado às 24 horas... só às 3 ou 4...
Mas por acaso até voltei a instalar e acho que aquilo está bastante engraçado, mas para desktop acho que só para quem tenha muita paciencia... e para servidores acho que ainda não está suficiente maduro e estável.
|
| | | | A culpa é tua!
Não ficaste lá a soprar para cima do CPU para o arrefecer!
|
| | | | Antes que alguem modere isto como FlameBaite eu vou aqui deixar uma pequena historia.
Uma amigo meu tinha (e tem) um dual Athlon XP com dois GRANDES coolers. Ao tentar instalar gentoo aquilo estoirava sempre a compilar gcc/glibc whatever. Depois de testes de memoria, testes aos cpu's e tudo o mais resolvi colocar a maquina a fazer o bootstrap junto da saida de um ar condicionado.... BINGO. O processo de instalação do gentoo de stage 1 consegue ser um dos melhores testes de estabilidade de hardware :)
Gustavo Felisberto
(HumpBack)
Web: http://dev.gentoo.org/~humpback |
| | | | | Olha que não, hoje em dia já podes ter uma máquina gentoo completamente funcional recorrendo aos ebuilds. No meu caso tenho um portátil a funcionar a 100% sem "compilar" nada. Dá uma vista de olhos ao Gentoo 2004.1, terás algumas supresas agradáveis. Jaime Teixeira
|
| | | | O Gentoo para desktop é suicidio... santa compilação...
No entanto manter um servidor com o portage faz do Gentoo uma das melhores distros, poupa muito tempo e salvo um problema ou outro que aparece quando decidem uma mudança mais critica (tipo mudar o nome do vcron para vixie-cron) aquilo funciona como um relógio suiço.
|
| | | | Eu uso o Gentoo para desktop.... depois de passar 3 ou 4 dias a compilar e a configurar tudo ao meu gosto, fico com um sistema operativo, ao meu gosto... E isto num portátil... actualizações? emerge sync, e ou actualizo/instalo o que quero, ou faço um update à tree world e/ou system.... o mais moroso é só a primeira instalação, e deixar como se quer... a partir daí são simples actualizações... De todas as distros que alguma vez usei ou experimentei, é a melhor (IMHO)... Dá trabalho a configurar/instalar (e mesmo esse é pouco... é mais o tempo que se perde a compilar), mas (quase) nenhum a manter... Das poucas dificuldades que tive com Gentoo, ficou sempre resolvido ao dar uma vista de olhos pelos bug reports no bugzilla da gentoo, ou a fazer search nos forums da gentoo.
Espero que com isto tenha mostrado que Gentoo para desktop não é suícidio nenhum.... só dá um pouco mais de trabalho para quem está habituado à _tecnologia_ "point'n'click". E eu sei que seria impraticavel para alguns utilizadores de linux usarem gentoo porque teriam dificuldades em instala-lo... refiro-me a users com muito pouco conhecimento sobre linux... e digo muito pouco pois eu não sou nenhum entendido, e consigo safar-me bem a instalar e a configurar as coisas em linux... e claro, procurar para as soluções dos problemas invês de perguntar a alguem também ajuda... até encontrar a solução de um problema específico que tenho, já passei por uns 30 ou 40 formas de resolver algum problema que eu não tenho, mas que já me ensinou a fazer algo que eu provavelmente não saberia, e que posso aplicar posteriormente... logo, não há grande ciência: ler os How-to e install notes, e em qualquer problema que apareça, procurar no nosso amigo google, forums e bugzilla :) (em ultimo caso, depois de esgotadas as opções, ou por falta de tempo e necessidade de resolução rapida: perguntar).
HiTek DeVil |
| | | | e só depois fedora, mas ... o seu sistema de pacotes não chega aos calcanhares dos .deb.
Ficarias surpreendido se te dissesse que o RPM é superior ao .deb? E se estás a falar do apt devo informar-te que o Fedora usa o yum que não lhe fica atrás (e pode também usar o apt/synaptic pois fazem parte do Fedora Extras).
-- Carlos Rodrigues
|
| | | | | | Ficarias surpreendido se te dissesse que o RPM é superior ao .deb?
Eu fiquei. Gostava que explicasses porquê, não vejo nenhuma razão obvia para isso.
E se estás a falar do apt devo informar-te que o Fedora usa o yum que não lhe fica atrás (e pode também usar o apt/synaptic pois fazem parte do Fedora Extras).
Já agora, por curiosidade, também pode usar o auto-apt?
auto-apt: package search by file and on-demand package installation tool auto-apt checks the file access of programs running within its environments, and if a program tries to access a file known to belong in an uninstalled package, auto-apt will install that package using apt-get. This feature requires apt and sudo to work.
It also provides simple database to search which package contains a requesting file.
Ou seja, fazes 'auto-apt run cmd', e se o cmd (por exemplo um make) tentar aceder a um ficheiro que não exista, o auto-apt verifica se existe algum .deb que tenha esse ficheiro e pergunta se o queres instalar. Damn cool :D
E em relação aos repositórios de software, os do Fedora comparam-se aos do Debian?
|
| | | | Eu fiquei. Gostava que explicasses porquê, não vejo nenhuma razão obvia para isso.
Existem três razões principais para isto:
- file dependencies - permite fazer um pacote depender de um determinado ficheiro sem especificar o pacote.
- triggers - permite que determinados pacotes executem acções como resposta à alteração do estado de outros. Imaginemos um pacote A que pode usar outro B mas não obrigatoriamente. A pode ser instalado sozinho e aquando da instalação de B alterar alguma configuração para passar a usar B.
- verificação - a possibilidade de verificar se um pacote está exactamente nas condições em que foi instalado é bastante útil.
Uma comparação mais exaustiva pode ser encontrada aqui.
E em relação aos repositórios de software, os do Fedora comparam-se aos do Debian?
Não posso dar uma certeza pois não conheço o estado dos do Debian, mas existem alguns repositórios interessantes como o fedora.us (Fedora Extras), o freshrpms e o do Dag Wieërs, além dos da própria distribuição.
-- Carlos Rodrigues
|
| | | | 1. é mau... se não diz qual é o package de que depende como é que se vai adivinhar? Ah, o google...
2. o teu exemplo não é lá muito feliz: no caso do .deb frequentemente o package B tem um script e um interface Curses que é executado durante a instalação e pergunta se vais querer alterar a configuração do package A. Exemplo prático: mod_php.
3.mudança de filosofia. essa tarefa talvez se assemelhe ao dpkg -C (verifica se existem "broken packages" no sistema).
Àcerca da tabela, é uma boa comparação: .deb - 6 "no", .rpm - 8 "no" entre as quais: recomendações, sugestões, relações booleanas entre packages (package A depende de B ou C) e prioridades (package A depende de B ou C mas o C tem prioridade sobre o B). E segundo o teu ponto de vista nada disto é superior às falhas que apresentas.
---
Este espaço pode ser seu! |
| | | | Ainda sobre o .2, na actualização de um package, olha, mais uma vez o Samba :), o script de configuração detecta se existem alterações no ficheiro smb.conf e dá a escolher a acção a tomar. Se bem me recordo o rpm não faz nada disto.
---
Este espaço pode ser seu! |
| | | | 1. é mau... se não diz qual é o package de que depende como é que se vai adivinhar? Ah, o google...
O yum resolve as dependências automaticamente. Além disso isto isto é bom para se poder, por exemplo, ter mais do que um pacote a fornecer a mesma funcionalidade.
2. o teu exemplo não é lá muito feliz: no caso do .deb frequentemente o package B tem um script e um interface Curses que é executado durante a instalação e pergunta se vais querer alterar a configuração do package A. Exemplo prático: mod_php.
Isto não funciona se o B for uma dependência não obrigatória de A que não sabe que existe o pacote A.
3.mudança de filosofia. essa tarefa talvez se assemelhe ao dpkg -C (verifica se existem "broken packages" no sistema).
Não sei, se isso também verificar os md5sums dos ficheiros e as datas e suas permissões...
-- Carlos Rodrigues
|
| | | | huuu, vários packages com, por exemplo, a mesma lib? hmmm desorganização...
---
Este espaço pode ser seu! |
| | | | | > O yum resolve as dependências automaticamente. Além disso isto isto é bom para se poder, por exemplo, ter mais do que um pacote a fornecer a mesma funcionalidade. [19:09] <manuel@gada> ~ $ apt-cache show apache2-mpm-prefork
Package: apache2-mpm-prefork
Priority: optional
Section: net
Installed-Size: 488
Maintainer: Debian Apache Maintainers
Architecture: i386
Source: apache2
Version: 2.0.49-1
Provides: apache2-modules, apache2, httpd, httpd-cgi
Depends: libapr0 (>= 2.0.49), libc6 (>= 2.3.2.ds1-4), libdb4.2, libexpat1 (>= 1.95.6), libldap2 (>= 2.1.17-1), libssl0.9.7, zlib1g (>= 1:1.2.1), apache2-common (= 2.0.49-1)
Conflicts: apache2-mpm-worker, apache2-mpm-threadpool, apache2-mpm-perchild, apache2
Filename: pool/main/a/apache2/apache2-mpm-prefork_2.0.49-1_i386.deb
Size: 204668
MD5sum: e614ce5fe8950b5b484a7e49d66725e0
Description: Traditional model for Apache2
Prefork uses the same model to handle requests as Apache.
This Multi-Processing Module (MPM) implements a non-threaded,
pre-forking web server that handles requests in a manner similar to
Apache 1.3. It is appropriate for sites that need to avoid threading for
compatibility with non-thread-safe libraries. It is also the best MPM
for isolating each request, so that a problem with a single request will
not affect any other.
.
It is not as fast, but is considered to be more stable.
Task: web-server
> Isto não funciona se o B for uma dependência não obrigatória de A que não sabe que existe o pacote A. então não pode mirar se está instalado? :) de facto muitos pacotes fazem isso, uma vez que sabes o estado de cada pacote no sistema é muito simples fazer isso que dizes. pex o php4, dependendo se o que há instalado é apache1 ou apache2... > Não sei, se isso também verificar os md5sums dos ficheiros e as datas e suas permissões... [19:11] <manuel@gada> ~ $ apt-cache show debsums
Package: debsums
Priority: optional
Section: admin
Installed-Size: 48
Maintainer: Brendan O'Dea
Architecture: all
Version: 2.0.6
Depends: perl (>= 5.8.0-3)
Filename: pool/main/d/debsums/debsums_2.0.6_all.deb
Size: 16804
MD5sum: ac3bf6bdde8b32ca1908100f64c1f2bd
Description: Verify installed package files against MD5 checksums.
debsums can verify the integrity of installed package files against
MD5 checksums installed by the package, or generated from a .deb
archive.
não utilizo muito estas coisas, mas não é muito difícil comprovar a integridade do que tens instalado além dessa comprovação de md5sum, uma vez que se guarda a lista de ficheiros instalados por cada pacote e outras coisas que se utilizam ao instalar, configurar, eliminar, ...
--
Pela ribeira do rio cantando
ia la virgo d'amor: quen amores
à como dormirá, ai bela frol! |
| | | | Quanto ao teu primeiro exemplo, o rpm também permite "virtual provides" mas é completamente impossível exigir a quem cria os pacotes incluir provides para todos os ficheiros inclusos. Mas o .deb já suporta isto portanto não vale a pena bater mais neste ponto.
então não pode mirar se está instalado?
A questão é o pacote A ser instalado sem B existir e mais tarde, quando/se B for instalado, o pacote A adaptar a sua configuração a isso.
não utilizo muito estas coisas, mas não é muito difícil comprovar a integridade do que tens instalado além dessa comprovação de md5sum, uma vez que se guarda a lista de ficheiros instalados por cada pacote e outras coisas que se utilizam ao instalar, configurar, eliminar, ...
Tão fácil quanto um "rpm -V pacote"? Saber se os timestamps, permissões ou md5sums foram alterados é muito útil para resolver problemas que aparecem com software que funcionava mas deixou de funcionar após a instalação de outro software, por exemplo.
-- Carlos Rodrigues
|
| | | | | a respeito do primeiro, não vejo a necessidade/vantagem de depender dum ficheiro, e sim de um pacote que faz algo real. pex, está o gawk e mawk, ou os diferentes compiladores para uma linguagem particular, ou navegadores; ou também os gnome/apache/oquefor/-common para pacotes que dependam de coisas muito particulares; ou ainda diferentes versões de livrarias para pacotes que foram compilados contra elas em momentos diferentes (é bastante habitual na instável..). ora, por um só ficheiro, eu não vejo a necessidadade, mas nesse caso sempre podes criar um pacote virtual para ele... o caso referido acima sobre o módulo de serviço para apache2 não é muito diferente do que dizes, é apenas uma parte pequenina, um modulinho, dum pacote mais grande. depois sobre o segundo tens razão, entendi mal o funcionamento. já agora, poderias explicar alguma utilidade real disto? eu acho que não deve ser uma coisa fulcral, ou pelo menos que haverá outras maneiras de contornar a falta dessa funcionalidade, uma vez que eu levo 6 anos com Debian instalado num PC, com actualizações periódicas, e que lembre nunca lhe fez falta nem reiniciar nem fazer nada especial além de instalar o pacote normalmente, incluindo câmbios na libc, etc. a respeito do terceiro, acabo de mirar, e penso que isto é equivalente ao que dizes (sem ser automático!!):
[23:37] ~ # dpkg -c /var/cache/apt/archives/xmms-liveice_1.0.0-4_i386.deb
drwxr-xr-x root/root 0 2001-10-29 08:45:07 ./
drwxr-xr-x root/root 0 2001-10-29 08:45:02 ./usr/
drwxr-xr-x root/root 0 2001-10-29 08:45:01 ./usr/lib/
drwxr-xr-x root/root 0 2001-10-29 08:45:01 ./usr/lib/xmms/
drwxr-xr-x root/root 0 2001-10-29 08:45:05 ./usr/lib/xmms/Effect/
-rw-r--r-- root/root 36968 2001-10-29 08:45:05 ./usr/lib/xmms/Effect/libliveice.so
drwxr-xr-x root/root 0 2001-10-29 08:45:02 ./usr/share/
drwxr-xr-x root/root 0 2001-10-29 08:45:02 ./usr/share/doc/
drwxr-xr-x root/root 0 2001-10-29 08:45:06 ./usr/share/doc/xmms-liveice/
-rw-r--r-- root/root 542 2001-05-29 14:28:13 ./usr/share/doc/xmms-liveice/copyright
-rw-r--r-- root/root 252 2000-01-29 19:53:29 ./usr/share/doc/xmms-liveice/changelog.gz
-rw-r--r-- root/root 2247 2000-03-14 11:51:07 ./usr/share/doc/xmms-liveice/README.gz
-rw-r--r-- root/root 370 2001-10-29 08:36:27 ./usr/share/doc/xmms-liveice/changelog.Debian.gz
[23:50] ~ # debsums xmms-liveice
usr/lib/xmms/Effect/libliveice.so OK
usr/share/doc/xmms-liveice/copyright OK
usr/share/doc/xmms-liveice/changelog.gz OK
usr/share/doc/xmms-liveice/README.gz OK
usr/share/doc/xmms-liveice/changelog.Debian.gz OK
não conheço um programa integrado que faça isto automaticamente, mas é capaz de haver. de qualquer jeito a capacidade para fazê-lo está já aí, não seria uma falha do desenho do pacote .deb, em todo caso é coisa de que nunca ninguém viu utilidade em criar essa ferramenta :) finalmente, é capaz de o .rpm ter algumas funções interessantes que o .deb não tenha, mas olhando essa lista de comparação que alguém deu para mim é mais importante por exemplo o das sugestões e recomendações, poder aceder aos ficheiros onde se guarda a configuração com ferramentas normais -são em formato texto simples- ou poder alterar o formato do pacote (o que permite acrescentar essas funcionalidades que os outros sistemas de gestão de pacotes têm ;)), com o qual parece-me que o .deb ainda me parece o pequeno vencedor nesta guerrinha de formatos ;) PS: já agora, o rpm também permite descarregar-compilar-instalar tipo Gentoo? ainda me admira como é que criaram essa nova distribuição, havendo já outras distribuições no que isto era possível. se o rpm tb deixa fazer isso, a coisa é mesmo de doidos.. tanta trabalheira só para fazer aquecer o processador.. =)
--
Pela ribeira do rio cantando
ia la virgo d'amor: quen amores
à como dormirá, ai bela frol! |
| | | | | Para o rpm não sei, mas sei que em debian podemos utilizar o build+apt-build, ou em alternativa o apt-src.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | | Que o formato per-se seja superior talvez tenhas razão, se o formato é melhor utilizado que o .deb estás redondamente enganado. A culpa não é do package mas sim de quem os publica.
Quem publica packages para Debian tem tido o cuidado de verificar que a coisa marcha com a instalação base de uma das versões (woody, sarge ou sid) e isto não é de todo verdade com muito pessoal que publica rpm's para, por exemplo, RedHat ou SuSE. Demasiadas vezes instalei a aplicação que pretendia, mas as dependências e suas dependências até chegar a um package que afinal só podia ser instalado se uma versão anterior do package xpto (que depende desse) estivesse instalada.
A culpa não é dos formatos é das pessoas.
Outra coisa que me irrita são os repositórios minúsculos das distribuições baseadas em RPM quando comparadas com os da Debian. Mais ainda, esses repositórios minusculos frequentemente agrupam aplicações dos DE's (gnome ou kde) num package monstruoso. Em Debian tens o meta-package (que não é nada) que depende dos packages das aplicações que o formam, daí posso instalar o kde-amusements ou apenas o kdegames ou ainda apenas o ktron.
Mais ainda, os utilitários satélites são superiores em debian: um dpkg -l *samba* mostra-me imediatamente o que tenho e tive instalado no meu computador relacionado com o samba podendo depois eu filtrar o que me interessa (se adicionar um | grep ^ii mostra-me o que tenho actualmente instalado). Com um rpm para saber se tenho alguma coisa instalada tem de ser um rpm -qa | grep package. Até nem chateava muito não fosse o rpm -qa um "bocado" demorado. Ah, e não tem histórico.
Espero que tenhas percebido porque é que se diz que .deb é superior que .rpm.
---
Este espaço pode ser seu! |
| | | | Outra coisa que me irrita são os repositórios minúsculos das distribuições baseadas em RPM quando comparadas com os da Debian.
Bem, o repositório do Dag Wieërs tem mais de 19 mil pacotes, o que não é assim tão pequeno. Mas acredito que os do Debian possam ter mais, até porque raros são or projectos que disponibilizam deb, logo é natural que os pacotes feitos à posteriori apareçam mais concentrados.
frequentemente agrupam aplicações dos DE's (gnome ou kde) num package monstruoso
Vai-te queixar aos tipos do KDE então. Eles é que lançam aquilo em tgz enormes. A RedHat já tentou separar aquilo mais mas acabou por desistir, não compensava o trabalho.
<flame_mode> Debian é tão bom que só agora se lembraram de mudar para um instalador decente, e ainda por cima, se não estou em erro, vão usar o anaconda. Um dia destes ainda mudam para RPM. :) </flame_mode>
-- Carlos Rodrigues
|
| | | | respondendo ao flame:
porque e' que a redhat nao usou o apt-* que a conectiva portou para o rpm e que funciona muito bem e decidiu (mais uma vez) fazer uma coisa nova ignorando tudo que ja' existe se criado por outra distro?!
e' lhe tao dificil unir forcas e usar e ajudar algo que nao deles? as outras nao teem esses problemas, se eles fazem algo bom, toca a aproveitar a source...
Higuita |
| | | | porque e' que a redhat nao usou o apt-* que a conectiva portou para o rpm e que funciona muito bem e decidiu (mais uma vez) fazer uma coisa nova ignorando tudo que ja' existe se criado por outra distro?!
O YUM não é nada de novo, como o nome indica é o "YellowDog Updater, Modified". Outras possíveis razões incluem a melhor integração com o RPM e o facto de ser feito em Python (o que permitirá integração com as ferramentas da Red Hat). No YUM os repositórios são simplesmente constituídos pelos headers dos pacotes RPM e é o próprio RPM que gere as dependências.
FAQ do YUM.
-- Carlos Rodrigues
|
| | | | porque e' que a redhat nao usou o apt-* que a conectiva portou para o rpm... Porque na altura o apt usava o rpm de forma externa e tinha uma forma de calcular as dependências diferente do rpm. Desde então isto já foi corrigido. E sim estou a usar o apt e não o yum embora goste bastante de python. Casa de ferreiro, espeto de pau. ;-)
|
| | | | Qual anaconda qual carapuça, o debian installer é todo em modo texto e está muito mais funcional que o vem nas distribuições.
|
| | | | estou agora a testar o debian-installer beta4 (?) e olha, quem me dera que tivesse disponível quando instalei o Debian :D
Isto aparentemente detectou o hardware automágicamente, tem um wizard intuitivo q.b. para criar partição de disco e na instalação do grub viu que era o único SO no computador e indicou-me que ia instalar o dito na MBR.
Reboot feito tenho duas entradas no GRUB, uma para o kernel 2.6.3 e uma failsafe também para o 2.6.3, acho que isto indica que quando o n00b instalar um kernel novo vai continuar com o failsafe para o 2.6.3 o que não é bom, é excelente :)
Depois de me ser apresentado um ecrã de boas vindas e configurar a timezone, fiquei a saber que a rede ficou automaticamente configurada por causa do DHCP que tenho no router (+1 ponto a favor do debian installer) e fez download de um package qualquer (suponho que tenha sido um update de segurança pois foi ao http://security.debian.org).
Estou a escrever isto ao mesmo tempo que estou a instalar :)
Na instalação de software apresentou-me 4 opções, usar o tasksel, o debconf, o aptitute ou nenhum destes e depois fazer o que quero com o apt-get. Como nunca vi o aptitude seleccionei este.
Parece-me mais fácil que o tasksel que usei da primeira vez. Devia ser o default e o primeiro da lista ao invés de ser o tasksel.
Terminada a instalação (não vou descrever o processo de descarregamento de packages porque é igual ao que sempre foi) posso confirmar que o hardware foi detectado correctamente. Ao contrário do instalador antigo não tive de mexer uma palha no que respeita a configurações do kernel, nomeadamente decidir quais os módulos que quero ou não carregar. Isto para um utilizador que nunca viu linux era um bocado complicado.
Assim sendo, o novo Debian Installer não está bom. Bom sou eu, o debian installer está perfeito!
ok ok, não é clickty clickty com artwork a passar, etc., mas acho que qualquer um consegue orientar-se nisto.
---
Este espaço pode ser seu! |
| | | | | Tenho a impressão de já ter lido algures que iam fazer uma versão GTK do novo installer.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Debian é tão bom que só agora se lembraram de mudar para um instalador decente, e ainda por cima, se não estou em erro, vão usar o anaconda. Um dia destes ainda mudam para RPM. :)
O objectivo do instalador Debian é funcionar no maior número de arquitecturas possivel, objectivo esse plenamente atinjido. Eu nunca tive problemas com ele, mas acredito que possa fazer confusão a algumas pessoas.
|
| | | | Vai-te queixar aos tipos do KDE então. Eles é que lançam aquilo em tgz enormes. A RedHat já tentou separar aquilo mais mas acabou por desistir, não compensava o trabalho.
Eu não me vou queixar aos tipos do KDE porque o pessoal da Debian parte esses packages independentemente do trabalho que possa dar. É tudo uma questão de ter ou não utilizadores contentes.
---
Este espaço pode ser seu! |
| | | | http://dag.wieers.com/home-made/apt/
Total number of all (S)RPM packages: 14043
Number of unique RPM packages: 4855 (distro-sum)
Number of unique RPM packages: 1069 (distro-independent)
Number of unique source packages: 788
http://www.linuxmafia.com/faq/Debian/package-count.html
Rick Moen adds: You can get a count of packages available for your system by running "grep Packages: /var/lib/apt/lists/*Packages | wc -l" at any time. As of 25 November 2003, on i386 architecture, this returns total available binary package counts as follows:
* unstable branch: 13514
* testing branch: 12619
* stable branch: 8977
É tudo um caso de fazer as contas. Ah, btw, 4855 + 1069 +788 = 6712. Até 19 mil ainda faltam 12288 ;)
---
Este espaço pode ser seu! |
| | | | Boa, ganhaste o pissing contest de hoje! No entanto devo dizer-te que, sendo um pissing contest, é irrelevante. Os repositórios para Fedora são grandes o suficiente para 90% das pessoas e para as restantes 10%, 9% ficam bem servidas com os RPMS disponibilizados por grande parte dos projectos, como pode ser observado no sourceforge.
-- Carlos Rodrigues
|
| | | | o problema é que esse 9% de rpms podem ter dependências circulares. é isto que te estou a tentar explicar há um monte de horas. e uma parte dos 90% de repositório fedora está mal organizado devido ao legado redhat.
---
Este espaço pode ser seu! |
| | | | | bem ...
A debian tem 3 tipos de instalações: stable, testing e unstable.
tem 3 repositorios conjuntos, com pacotes testados para cada uma delas podendo ser utilizado sistemas conjuntos ... stable/testing ou o tão aclamado senhor das badalhoquices stable/testing/unstable, n aconselhado a cardiacos.
Aqui temos tudo bleeding edge no unstable, pacotes garantidos à distância de um apt-get upgrade.
é claro que se os rpms provêm de certos projectos, n são garantidos pela propria distro.
Além disso, os mirror estão organizados, agrupados e há-os por todo o lado ... onde estão os repositorios rpm?
O que acontece é k com o sistema unstable, o sistema é, 90% das vezes, estavel, sem problemas de maior, ou até mesmo sem problemas ... o que quer dizer que temos um sistema com todo o software actual, à distância de um apt-get nacional, internacional ou afins.
Mas se ainda n estão convencidos que que o .deb é um pacote massificado (n, ele n anda aí pela net como os rpms), eis que temos o alien (eu, eu sei k tb dá ao contrario) ... o k ker dizer que ... se queremos akele pacote manhoso que nos escapa ... trunfas, é nosso ... se não funcionar ... olha ... paciencia ... apt-get remove --purge o bicho.
mas se ainda n estão convencidos com tudos isto ... que tal actualizarem todo o software de um desktop, ou de 100 desktops, ou de 1 servidor ou de 200 servidores, à distância de um apt-get, sabendo e tendo a certeza de que todos, sem excepção, se irão portar da mesma maneira (sem bugs- stable - ou quase sem bugs - testing - ou com alguns bugs - unstable).
é na garantia dos pacotes .deb que está a sua virtude. até se podiam chamar .psd , .cds , .pcp, ou .ps (epah ... desculpem, mas .be, é que não!) a coisa seria a mesma ... está visto que os .rpm são melhores, mas não são bem usados.
depois ... ir ao packages.debian.org e procurar pseja por akilo que for, lista de ficheiros, o ppl k mantem, bugs etc, tudo concentrado, dá gosto ... nem k seja apenas por uma visita!
Cumps-
Gass |
| | | | Depois de colocar aqui o artigo, continuo a dar as minhas voltinhas e voltei a ter contacto com a novell, pois são sem+pre uma boa base e encontrei uma coisa extraordinária: http://www.novell.com/pt-br/licensing/indemnity/
indeminizações para fracassos na utilização de linux?
De qualquer maneira, finalmente esta grande empresa de software corporativo se libertou das garras da microsoft, que andava a encostá-la a um canto. Agora adquiriu 2 empresas mestras na sua arte ... a ver vamos!
Cumps-
Gass |
| | | | | | hu? o que eu percebi é que a indeminização só funciona para casos de violação de copyrights no código fonte de aplicações/kernel do Linux. Um pouco à semelhança da treta da SCO. Não é para fracassos na utilização de Linux...
---
Este espaço pode ser seu! |
| | | | pois :) gafe ... n li akilo mto bem ... ai, ai
Cumps-
Gass |
| | | | | O teu artigo é uma confusão pegada no que respeita o licenciamento. Nota-se que é por utilizarem termos como opensource e software comercial que existe essa confusão. Todo o Software Livre com copyleft, NUNCA deixa de ser Software Livre. Todo o software é comercial, desde que se possa fazer negocio com ele, seja a vende-lo seja a vender algo directamente relacionado com ele (produtos ou mesmo serviços). O oposto de Software Livre é software proprietário e não o software comercial (esse tipo de licenciamento nem existe). Open Source Software é um tipo de licenciamento de software (tal como o Software Livre também é um tipo). O open source pode ser apenas uma forma de dizer que apesár de proprietário o código fonte está disponivél pelo menos a alguns, sob condições de licenciamento que não são nem Software Livre, nem Open Source Software. Nem o Software Livre, nem o Open Source Software, significam software de borla, nem nunca significaram (apesár de a maior parte poder ser adquirida gratuitamente). Embora seja possivél licenciar uma distribuição de qualquer sistema operativo com uma licença proprietária (desde que o Software Livre que o compõe fassa parte de um pacote maior), não é correcto dizer que a distribuição é closed source, ou pelo menos totalmente cloused source, pois o distribuidor aínda é obrigado a respeitar totalmente os termos das licenças de Software Livre que compõe o pacote. Por isso, se por exemplo pedires o source de um software licenciado como Software Livre e que esteja na distribuição eles são obrigados a fornecer. Quanto ao acompanhamento e suporte. Caso ainda não tenhas percebido no Software Livre qualquer um o pode fazer, ou seja, só tens é que chegár a algumas empresa da àrea e propor-lhes que o façam, escolhe o que te oferecer o melhor preço, mas claro não podes estár à espera que seja gratuito.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | E que tal experimentares a versão desktop 8.1 da Caixa Mágica? Em minha opinião, está excelente! Detectou todo o meu hardware e, até agora, tem estado a funcionar 100%. É uma distro portuguesa bastante "user-friendly". O url é o seguinte: http://www.caixamagica.pt
PS: O que é nacional é bom :)
|
| |
|
