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

[Hugo Cisneiros (Eitch)]

2009/4/4 Marcio Carneiro <viabsb em gmail.com>:
>> > 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.

Alfa, não conta tanto assim. Mas é uma ótima notícia de que virá.

>> > 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.

E...? Na sua pergunta, me pareceu que você estava perguntando sobre
quanto tempo deveríamos esperar pelos programas já serem compilados
para 64-bits, sendo que eu respondi que eles já o são, faz anos, com
algumas excessões que eu também disse.

>> > 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.

Eu nunca vou dizer que qualquer coisa será totalmente estável. Eu quis
dizer que o KDE4 (IMO) ainda está muito "xulo" e tem muito o que
melhorar pra chegar aos pés do 3.5. Mas essa discussão já é velha e
desafasada: eu já sei que o KDE4 vai ficar legal lá pelo 4.4.

Em contrapartida ao que você disse, tem algumas distros bem estáveis
sim. Ou você acha que um monte de super-computadores e milhares de
servidores rodam distribuições Linux sendo instáveis? Paramos pra
pensar: será que algumas dessas coisas 'instáveis' não são culpa de
BIOS?

Não vou nem falar do Fedora aqui porque a proposta da distribuição não
tem como prioridade ser estável, e sim ter mais funcionalidades e tudo
ser "cutting-edge". O KDE seguiu a mesma direção (aliás, acho que ele
sempre foi assim), só mudando quando sua "minor version" fica mais
distante (por isso eu disse lá pelo 4.4).

>> > 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.

Ou seja, não culpe a distribuição por algo que você fez de errado. Se
você tentou fazer isso no Fedora, pode ter certeza que utilizou um
repositório de terceiro e não o da distribuição. Depois imagino que
forçou a remoção da biblioteca de modo errôneo e começou a afetar o
SO. Como eu disse: não tem sistema a prova de usuário: só se o sistema
não deixasse o usuário fazer quase nada.

Que nem eu há muito tempo atrás, fui fazer uma atualização de glibc na
distribuição e acabei com tudo. Tive que reinstalar.

>> > 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.

Você falou que não existe uma distribuição e sim um gerenciador de
pacotes. Falar isso é ignorar todo o trabalho que a distribuição tem
de pegar os programas e montá-los de forma legal, colocar um
instalador pra facilitar a vida do usuário, fornecer atualizações,
personalizações, kernels para situações especiais, e inclusive colocar
um gerenciador de pacotes para facilitar todas essas tarefas tanto
para os desenvolvedores, quanto para os usuários.

Falar que uma distribuição é apenas um gerenciador de pacotes é dose.

E instalar pacotes fora do padrão da distribuição é um problema de
qualquer outro sistema. Os gerenciadores de pacotes foram criados para
evitar a "bagunça" que se faz quando se instala sem indexar os
arquivos que foram espalhados: com o tempo eles vão acumulando no
sistema e você nem sabe onde estão e o que fazem, isso gera um "bloat"
no sistema com o tempo. É assim no Linux, é assim no Windows (muito
mais, porque eles não tem controle sobre as milhões de aplicações que
têm de ser instaladas separadas e cada fabricante instala do jeito que
lhe for mais conveniente), é assim com qualquer outro sistema.

Mesmo que você siga o conceito de colocar todos os programas linkados
estaticamente, sempre vai haver um ponto de falha provavel, por
exemplo, você pode instalar uma própria glibc mais nova e quebrar
qualquer chamada de sistema que esses programas utilizam. Ou, tenta
instalar um driver do Windows 98 no Windows XP, sei lá.

> "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."

Exatamente ;-)

>>  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á.

É isso que eu quis dizer quando eu pensei que você não sabia muito bem
o que tava falando. Sinto lhe informar, mas o GoboLinux não faz nenhum
milagre não. O que o GoboLinux faz (e que é interessante mesmo) é
re-organizar onde ficam as localizações dos arquivos dos programas e
bibliotecas instaladas no sistema. Isso não elimina de forma alguma as
dependências entre eles. Os programas não são todos linkados
estaticamente. Se você remover algumas coisas, as outras vão pifar.

Sobre a biblioteca C, o que quero dizer é que todo comando/programa
usa essa biblioteca para alocar memória por exemplo. Ela faz a
interface com o kernel. Se você removê-la ou atualizá-la sem cuidado e
sem prestar atenção em todas as aplicações do sistema, você pode
quebrar esse sistema. Felizmente a gente não passa por isso porque as
distribuições cuidam dessa parte mais complicada pros usuários.

Quando se tem um gerenciador de pacotes, não importa a localização dos
arquivos, eles estão sempre indexados e podem ser
removidos/atualizados de forma correta sem deixar resquícios. Por isso
eu sempre achei essa localização de arquivos muito irrelevante.

>> > 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.

Você pode fazer isso em qualquer distribuição. Sério, sabia que você
pode instalar vários Pythons na mesma máquina? Basta, na hora de
compilar, dizer pra ele instalar numa árvore de diretórios diferente.
Ah, e é isso que o GoboLinux faz. Isso não impede de você fazer
também.

Inclusive, isso me faz lembrar que o próprio Debian faz isso: ele tem
algumas versões múltiplas, o exemplo mais recente que vi foi que você
pode instalar, via gerenciador de pacotes, o php4 e o php5.

>> > 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?

O LOL foi porque a idéia é muito sem noção (IMO), e por isso eu ri. É
como dizer para o mundo que agora todos os servidores de DNS da
Internet, cada um deles deve ter TODAS as informações sobre todos os
hosts do mundo. Quando você fala um exemplo ou outro, até que não
ficaria tão ruim, assim como se a Internet tivesse 100 domínios. Agora
imagine quando se fala de belos milhões de programas.

Se formos seguir esse padrão que você disse, todo programa deveria ter
suas bibliotecas e dependências todas linkadas estaticamente. Isso, em
sistemas modernos é impraticável, a não ser que você queira perder
espaço e memória exorbitantes. Significaria que cada um dos comandos:
ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais
simples teriam que ter dentro da sua compilação todas suas
dependências:

madoka:~$ ldd /bin/ls
        linux-gate.so.1 =>  (0xb7f40000)
        librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7f1f000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7f06000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7efe000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da3000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d8a000)
        /lib/ld-linux.so.2 (0xb7f41000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d86000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7d81000)

Multiplique agora todas essas bibliotecas por milhares de comandos e
milhões de programas por aí. Não seria muito legal né? E quando fosse
atualizar uma dessas bibliotecas? Teria que atualizar centenas ou
milhares de compilações!

O que eu acho que você tá pegando errado é que você só está
considerando a localização dos programas. Onde ficam seus arquivos.
Mas não é só isso que existe por trás de um funcionamento de um
sistema operacional. Tem muita coisa por trás, acho melhor você dar
uma pesquisada nisso (já enfatizei alguns pontos).

>> > 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.

Eu quero ter a liberdade de atualizar meu kernel quando quiser. Não
quero que ele fique fora de minha ação não. Sobre isso, você tem que
reclamar das distribuições que fazem as dependências de pacotes
errôneamente. E acredite, pra algo ter dependência de kernel nas
distribuições atuais, ele tem que *realmente* depender do kernel. Se
um programa tem relação com o kernel diretamente, ou o programa está
errado ou então tinha que ser ligado mesmo, não tem segredo!

Mas pra esclarecer isso, você teria que realmente me dizer exemplos concretos.

A única coisa que eu acho uma grande desvantagem do kernel Linux é a
dependência de módulos do kernel ligados a versão/compilação
específica de uma versão de kernel. Mas esse é outro assunto.

>> > 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?

As distribuições definem algo como base do sistema por uma razão: são
aplicações-chave que não devem ser nunca removidos pelo usuário. Eles
tem a liberdade de fazer isso se quiserem (mais uma vez, eu prezo por
essa liberdade), mas se eles fizerem está errado! Aí é culpa do
usuário!

Olha as dependências de um kernel antigo do Fedora 8:

$ rpm -qR kernel-2.6.26.3-14.fc8
rpmlib(VersionedDependencies) <= 3.0.3-1
fileutils
module-init-tools
initscripts >= 8.11.1-1
mkinitrd >= 6.0.9-7
/bin/sh
/bin/sh
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1

Sinceramente, se o usuário não tiver essas coisas aí, é porque ele não
tem nada mesmo.


>> > 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?

Não conheço, não posso opiniar. Eu ri porque você está sugerindo criar
um sistema operacional do zero. "Talk is cheap, show me the code".
Ainda mais, a linguagem não importa na maioria das vezes, o que
importa é o programador e seu design de código. Pode ser a linguagem
mais perfeita, um programador ruim pode fazer besteira do mesmo jeito.
Falar que ficaria muito melhor utilizando linguagem X é desconsiderar
todas essas variáveis.

>> É 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.

Interpreta-se como quer. Eu ainda acho suas idéias loucas. Você pode
não ser louco (e nunca disse isso), mas pra mim tem idéias loucas e
equivocadas. Ao invés de achar isso rude e mal-educado, instigue-se,
use a cabeça e prove-me que suas idéias não são loucas! Senão como
você vai convencer o resto do mundo?

> 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".

Eu seria autoritário se dissesse "mude seus conceitos". Quando eu falo
"reveja seus conceitos", quero dizer pra você rever mesmo: pensar no
que você tá falando ao invés de continuar falando. E essa "feature" aí
que você disse não é dos unixers, é de qualquer programador idiota. A
grande "feature" do código-aberto é quando a gente faz qualquer coisa,
libera o código e todos podem criticar, opinar e ajudar/atrapalhar.

> 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).

O mundo é grande e existem diversos tipos de usuários. O Linux é
orientado para usuários SIM, só não todos. Se você dissesse que o
Linux não é orientado a usuário "final", eu concordo até certa parte.
Se você diz que Linux não é orientado a usuário "gamer", eu concordo
100%. Mas tudo isso é relativo não?

Linux é orientado para os usuários corporativos e para os servidores,
mas isso também está mudando: se chama crescimento/expansão.
Infelizmente nosso crescimento nessa área é uma porcaria :)

>>
>> 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.

E a única vantagem que a gente tem disso daí é que não existem vírus
eficientes e bem difundidos pra Linux :P

> 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.

\o/

-- 
[]'s
Hugo
www.devin.com.br