[Fedora-users-br] Atualizar o FC10 i386 com x86_64

[Marcio Carneiro]

2009/4/3 Hugo Cisneiros (Eitch) <hugo em devin.com.br>

> 2009/4/3 Marcio Carneiro <viabsb em gmail.com>:
> > O problema são os tais "macêtes".
> > Você tem um passo-a-passo para fazer a instalação do flash, java,
> mplayer,
> > vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?
>
> Tem vários por aí na Internet.


Obrigado.

>
>
> > E quanto aos programas compilados em i386 que não aceitam rodar em uma
> > arquitetura 64?
>
> Só conheço o Flash e o *plugin* do Java pro Firefox.


Creio ter lido que o flash para 64 já está disponível.

>
>
> > Quanto tempo teremos de esperar para os programas serem compilados em 64?
> E
> > a compatibilidade?
>
> Faz vários anos que as distribuições Linux vem com *todos* os pacotes
> compilados para x86_64. Só no escritório tem 8 servidores rodando
> CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
>

Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava
errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha
pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho
de formatar o disco novamente.

>
> > Tenho, sempre, muitos problemas com bibliotecas.
> > Nêste momento estou com problemas com o FC10, que perdeu alguma
> biblioteca
> > em python, provavelmente, e não consigo acessar o log in no kde.
> > Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE,
> > temos o KDE3 e uma criatura completamente nova, que deveria ter vida
> própria
> > mas não acabar com o KDE.
>
> Nisso eu concordo, mas essa criatura nova está evoluindo e um dia
> ficará boa ;-) Se não ficar, a concorrência come.


Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para
o usuário, é o que existe funcionar e ser estável. É certo que você poderá
dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí
que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no
futuro.
Tem de haver um ponto no meio em que uma distro SEJA estável e não haja
comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma
nova criatura. Talvez uma distro devêsse ter os dois KDE.

>
>
> > Com a facilidade com que os RedHat alike perdem bibliotecas
> indispensáveis
> > ao SO e, depois, para re-instalar, impedem a instalação, alegando que um
> > programa já existe e não pode ser re-escrito, ou que uma biblioteca é
> > necessária mas não está disponível e você tem de formatar o HD novamente,
> > parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por
> > exemplo.
>
> Sinceramente não sei o que você faz pra acontecer essas coisas... Eu
> nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O
> que eu vejo são pessoas instalando as coisas "natoralmente" e
> quebrando o sistema inteiro. Aí não tem sistema que aguente :P


Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc.
Pedia uma lib que não podia ser instalada porque conflitava com outra
existente. Quando removi esta, foi algo da dependência que afetava o SO. E o
glibc foi corrompido, ou removido dentro da tal dependência.

Para instalar o galeon é necessário o mozilla e outras dependências, pode
ter sido tentando instalar o galeon.

>
>
> > Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um
> sistema
> > de gerenciamento de pacotes com um nome de distribuição.
>
> Acho que você deve estar confundindo o termo "distribuição"... Leitura
> recomendada:
>
> http://www.devin.com.br/intro_linux/
> Parte "Distribuições"


Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com
o que escrevi.
Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o
usuário ter problemas em instalar programas fora do gerenciador de pacotes.
O sistema de gerenciamento de pacotes é muito bom para admistrar a
distribuição mas não o Linux que o usuário instala.

"Para usar todas as ferramentas, ele teve que construí-las especificadamente
para o seu kernel e uní-las para apresentar ao usuário uma interface para o
uso do computador. Enquanto o kernel trabalhava com o hardware, as
ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."

>  Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria e
> instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em
> separado aos pacotes que são usados pelo usuário. A liguagem python é
> NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo,
> o yum. Se houvesse um python somente para o kernel e outro instalado para o
> usuário, não haveria o risco.

Não entendi a parte do  "E assim, existiria uma biblioteca C para CADA
PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o
sistema iria explodir :P", pois a referência poderia ser com uma ligação
dinâmica ao binário, e não ao binário que será necessário ao kernel.
É o recurso que o GoboLinux usa, todos os programas binários instalados na
árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas
não estão lá.

>
>
> > Creio que o GoboLinux é a salvação do Linux.
>
> LOL :-)


Tento esclarecer.
Não cria uma dependência de um sistema de gerenciamento de pacotes e
simplifica a inclusão e remoção de programas no SO.
Você poderá qualquer pacote de fontes e instalar no diretório de programas.


>
>
> > Mas vai demorar até uma edição completa com as receitas necessárias à
> > conversão facilitada.
> >
> > Creio que o pessoal do GoboLinux deveria partir para a radicalização,
> > ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a
> > proposta do Gobo.
>
> E assim quebrar milhares de programas que são feitos para funcionar de
> uma forma e ir contra milhares de programadores e padrões do mundo
> inteiro. Não é a melhor opção.
>
> > Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para o
> > kernel, onde estariam o fonte do kernel e de TODOS os programas
> necessários
> > para compilação e instalação do kernel.
>
> LOL :-)

Por quê o lol?
Ou você não entendeu?

>
>
> > Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS
> > dois para o usuário, assim, não haveria risco de eliminar um programa ou
> > biblioteca necessários ao kernel quando um usuário ou o próprio root
> > apagasse alguma coisa.
>
> E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema.
> Então cada comando/chamada iria carregar na memória e o sistema iria
> explodir :P
>
> Não jogue fora todas as vantagens de programas dinamicamente linkados...


Então você não entendeu.
Não se trata disto, exatamente por validar isto é que sugiro que os
programas necessários ao kernel devem estar fora da ação do usuário, que
poderá instalar e remover qualquer programa sem afetar os que são
necessários ao kernel.
O kernel fica protegido na memória mas não no HD.


>
>
> > Considero uma grande BURRICE esta COMPLETA dependência do kernel da
> árvore
> > de diretórios do usuário.
>
> Ahnnnn???



Posso ter me expressado mal: a dependência do kernel de linguagens e
programas que estão disponíveis ao usuário para remover.
Melhorou?


>
> > Fica o pedido de socorro para instalar os tais macêtes.
> >
> > Com relação ao kernel, minha sugestão é partir para a compilação do
> kernel
> > com o OCAML DUCE.
>
> LOL :-)


Nem mesmo uma razão para não fazer ou você não conhece a linguagem?

>
>
> É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei
> até a entender que sou chato. Mas é, eu sou chato mesmo! :P
>
> Sinceramente, você tem umas coisas muito loucas na cabeça, por favor
> reveja seus conceitos, tem muita coisa que você diz aí que nem parece
> que sabe do que tá falando :(


Quando o índio que viu a primeira caravela disse aos demais o que via também
foi chamado de louco e via coisas que ninguém via: e era verdade.

Se você não vê algo que alguém disse que viu não diga que êle é louco, isto
é rude, mal-educado.

Quando você me manda rever meus conceitos é autoritário e prepotente, aliás,
"feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".

Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como
não são Orientados a Objetos, o que reduz o usuário a objeto sem interêsse.
Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO
procedimental (se é esta a palavra).

>
> Eu concordo sobre a parte dos "macetes", mas veja que isso não é
> problema do Linux. Isso é problema dos fabricantes dos programas
> proprietários. Esses macetes aí geralmente têm de ser feitos com
> programas que não fazem parceria com a distribuição, como o Flash e/ou
> Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%,
> esses macetes *nunca* iriam ser precisos, pois os fabricantes iam
> correr atrás.
>
> Acredite, nos outros sistemas como Windows e Mac também é assim. A
> diferença é que eles são o foco principal. Agora vai tentar instalar
> coisas de Linux em outros sistemas, é mais fácil?


Esclareceu, concordo.

Obirgado pelos esclarecimentos.
Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se
você não concordar com algo que escrevo, é livre para discordar, e dizer.
Também é livre para não dizer, mas não tem a liberdade que se deu.


>
> --
> []'s
> Hugo
> www.devin.com.br
>
> --
> Fedora-users-br mailing list
> Fedora-users-br em redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-users-br
>



-- 
EquipeLinux em EquipeLinux.com
EquipeLinux em Skype.com
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listman.redhat.com/archives/fedora-users-br/attachments/20090404/07d658bc/attachment.htm>