<br><br><div class="gmail_quote">2009/4/3 Hugo Cisneiros (Eitch) <span dir="ltr"><<a href="mailto:hugo@devin.com.br">hugo@devin.com.br</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/4/3 Marcio Carneiro <<a href="mailto:viabsb@gmail.com">viabsb@gmail.com</a>>:<br>
<div class="im">> O problema são os tais "macêtes".<br>
> Você tem um passo-a-passo para fazer a instalação do flash, java, mplayer,<br>
> vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?<br>
<br>
</div>Tem vários por aí na Internet.</blockquote><div><br>Obrigado. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> E quanto aos programas compilados em i386 que não aceitam rodar em uma<br>
> arquitetura 64?<br>
<br>
</div>Só conheço o Flash e o *plugin* do Java pro Firefox.</blockquote><div><br>Creio ter lido que o flash para 64 já está disponível. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
> Quanto tempo teremos de esperar para os programas serem compilados em 64? E<br>
> a compatibilidade?<br>
<br>
</div>Faz vários anos que as distribuições Linux vem com *todos* os pacotes<br>
compilados para x86_64. Só no escritório tem 8 servidores rodando<br>
CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.<br>
<div class="im"></div></blockquote><div><br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> Tenho, sempre, muitos problemas com bibliotecas.<br>
> Nêste momento estou com problemas com o FC10, que perdeu alguma biblioteca<br>
> em python, provavelmente, e não consigo acessar o log in no kde.<br>
> Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE,<br>
> temos o KDE3 e uma criatura completamente nova, que deveria ter vida própria<br>
> mas não acabar com o KDE.<br>
<br>
</div>Nisso eu concordo, mas essa criatura nova está evoluindo e um dia<br>
ficará boa ;-) Se não ficar, a concorrência come.</blockquote><div><br>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.<br>
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. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
> Com a facilidade com que os RedHat alike perdem bibliotecas indispensáveis<br>
> ao SO e, depois, para re-instalar, impedem a instalação, alegando que um<br>
> programa já existe e não pode ser re-escrito, ou que uma biblioteca é<br>
> necessária mas não está disponível e você tem de formatar o HD novamente,<br>
> parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por<br>
> exemplo.<br>
<br>
</div>Sinceramente não sei o que você faz pra acontecer essas coisas... Eu<br>
nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O<br>
que eu vejo são pessoas instalando as coisas "natoralmente" e<br>
quebrando o sistema inteiro. Aí não tem sistema que aguente :P</blockquote><div><br>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.<br>
<br>Para instalar o galeon é necessário o mozilla e outras dependências, pode ter sido tentando instalar o galeon.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
> Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um sistema<br>
> de gerenciamento de pacotes com um nome de distribuição.<br>
<br>
</div>Acho que você deve estar confundindo o termo "distribuição"... Leitura<br>
recomendada:<br>
<br>
<a href="http://www.devin.com.br/intro_linux/" target="_blank">http://www.devin.com.br/intro_linux/</a><br>
Parte "Distribuições"</blockquote><div><br>Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com o que escrevi. <br>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.<br>
O sistema de gerenciamento de pacotes é muito bom para admistrar a distribuição mas não o Linux que o usuário instala.<br><br>"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."</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote>
<div>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. <br>É 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á.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Creio que o GoboLinux é a salvação do Linux.<br>
<br>
</div>LOL :-)</blockquote><div><br>Tento esclarecer.<br>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.<br>Você poderá qualquer pacote de fontes e instalar no diretório de programas.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Mas vai demorar até uma edição completa com as receitas necessárias à<br>
> conversão facilitada.<br>
><br>
> Creio que o pessoal do GoboLinux deveria partir para a radicalização,<br>
> ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a<br>
> proposta do Gobo.<br>
<br>
</div>E assim quebrar milhares de programas que são feitos para funcionar de<br>
uma forma e ir contra milhares de programadores e padrões do mundo<br>
inteiro. Não é a melhor opção.<br>
<div class="im"><br>
> Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para o<br>
> kernel, onde estariam o fonte do kernel e de TODOS os programas necessários<br>
> para compilação e instalação do kernel.<br>
<br>
</div>LOL :-)</blockquote><div>Por quê o lol?<br>Ou você não entendeu? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS<br>
> dois para o usuário, assim, não haveria risco de eliminar um programa ou<br>
> biblioteca necessários ao kernel quando um usuário ou o próprio root<br>
> apagasse alguma coisa.<br>
<br>
</div>E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema.<br>
Então cada comando/chamada iria carregar na memória e o sistema iria<br>
explodir :P<br>
<br>
Não jogue fora todas as vantagens de programas dinamicamente linkados...</blockquote><div><br>Então você não entendeu.<br>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.<br>
O kernel fica protegido na memória mas não no HD.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Considero uma grande BURRICE esta COMPLETA dependência do kernel da árvore<br>
> de diretórios do usuário.<br>
<br>
</div>Ahnnnn???</blockquote><div><br></div><div><br>Posso ter me expressado mal: a dependência do kernel de linguagens e programas que estão disponíveis ao usuário para remover.<br>Melhorou? <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
> Fica o pedido de socorro para instalar os tais macêtes.<br>
><br>
> Com relação ao kernel, minha sugestão é partir para a compilação do kernel<br>
> com o OCAML DUCE.<br>
<br>
</div>LOL :-)</blockquote><div><br>Nem mesmo uma razão para não fazer ou você não conhece a linguagem? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei<br>
até a entender que sou chato. Mas é, eu sou chato mesmo! :P<br>
<br>
Sinceramente, você tem umas coisas muito loucas na cabeça, por favor<br>
reveja seus conceitos, tem muita coisa que você diz aí que nem parece<br>
que sabe do que tá falando :(</blockquote><div><br>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.<br><br>Se você não vê algo que alguém disse que viu não diga que êle é louco, isto é rude, mal-educado.<br>
<br>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".<br><br>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.<br>
Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO procedimental (se é esta a palavra).<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Eu concordo sobre a parte dos "macetes", mas veja que isso não é<br>
problema do Linux. Isso é problema dos fabricantes dos programas<br>
proprietários. Esses macetes aí geralmente têm de ser feitos com<br>
programas que não fazem parceria com a distribuição, como o Flash e/ou<br>
Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%,<br>
esses macetes *nunca* iriam ser precisos, pois os fabricantes iam<br>
correr atrás.<br>
<br>
Acredite, nos outros sistemas como Windows e Mac também é assim. A<br>
diferença é que eles são o foco principal. Agora vai tentar instalar<br>
coisas de Linux em outros sistemas, é mais fácil?</blockquote><div><br>Esclareceu, concordo. <br><br>Obirgado pelos esclarecimentos.<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">[]'s<br>
Hugo<br>
<a href="http://www.devin.com.br" target="_blank">www.devin.com.br</a><br>
<br>
--<br>
Fedora-users-br mailing list<br>
<a href="mailto:Fedora-users-br@redhat.com">Fedora-users-br@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-users-br" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-users-br</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>EquipeLinux@EquipeLinux.com<br>EquipeLinux@Skype.com<br><br>