Atualizar o FC10 i386 com x86_64

[Gerente de Sistemas]

Olá.

Estou usando o FC10 i386 em um 64 bits.
Posso fazer o "upgrade" a partir do DVD FC10 x86_64 em cima do atual i386?
Outra questão: no diretório /home/usuario/Desktop fica(va) o Ambiente de
Trabalho do KDE.
Não encontrei o "Desktop" no KDE4 do FC10, e o Ambiente de Trabalho mostrado
pelo tal do Plasma não tem um diretório físico. Onde está?
Obrigado.

P. S.:

Para os que querem um descanso para o cérebro, sugiro abrirem um Firefox em
http://www.papervision3d.org/ em um Ambiente de Trabalho.

-- 
EquipeLinux(a)EquipeLinux.com
EquipeLinux(a)Skype.com

[Cristiano Furtado]

Infelismente não. Se vc esta usando uma arquitetura i386 e quer mudar para
x96_64 tem que formatar mesmo. Agora uma opinião minha certo? tenho um
Quad-core com 4GB de memoria e acho muito mais valido esta usando o i386 por
questoes de sotwares. Essa é a minha unica opinião.

2009/3/27 Marcio Carneiro <viabsb(a)gmail.com&gt;

>  Olá.
>
>  Estou usando o FC10 i386 em um 64 bits.
>  Posso fazer o "upgrade" a partir do DVD FC10 x86_64 em cima do atual i386?
>  Outra questão: no diretório /home/usuario/Desktop fica(va) o Ambiente de
>  Trabalho do KDE.
>  Não encontrei o "Desktop" no KDE4 do FC10, e o Ambiente de Trabalho
>  mostrado pelo tal do Plasma não tem um diretório físico. Onde está?
>  Obrigado.
>
>  P. S.:
>
>  Para os que querem um descanso para o cérebro, sugiro abrirem um Firefox em
>  http://www.papervision3d.org/ em um Ambiente de Trabalho.
>
>  --
>  EquipeLinux(a)EquipeLinux.com
>  EquipeLinux(a)Skype.com
>
>
>  --
>  Fedora-users-br mailing list
>  Fedora-users-br(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-users-br
>
>  

-- 
Atenciosamente,

------------------------------------------------
Cristiano Furtado
Gerente de TI - Projetos de Software Livre
Embaixador do Fedora no Brasil

Sites:
http://www.projetofedora.org
http://www.jasonnfedora.eti.br
http://www.fedora.org.br
http://www.ekaaty.com.br

[Hugo Cisneiros]

2009/3/27 Cristiano Furtado <jasonnfedora(a)gmail.com&gt;:
>  Infelismente não. Se vc esta usando uma arquitetura i386 e quer mudar
> para
>  x96_64 tem que formatar mesmo. Agora uma opinião minha certo? tenho um
>  Quad-core com 4GB de memoria e acho muito mais valido esta usando o i386 por
>  questoes de sotwares. Essa é a minha unica opinião. 
Eu tinha esse pensamento de 32-bits há algum tempo mas mudei. Hoje em
dia eu gosto de recomendar sempre sistemas 64-bits, com os "macetes"
para rodar coisas como Flash e Java. Principalmente no caso de
servidores :-) Se for uma estação de desenvolvimento então que requer
mais processamento, melhor ainda!

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

[Gerente de Sistemas]

2009/4/2 Hugo Cisneiros (Eitch) <hugo(a)devin.com.br&gt;

>  2009/3/27 Cristiano Furtado <jasonnfedora(a)gmail.com&gt;:
>  > Infelismente não. Se vc esta usando uma arquitetura i386 e quer mudar
>  para
>  > x96_64 tem que formatar mesmo. Agora uma opinião minha certo? tenho um
>  > Quad-core com 4GB de memoria e acho muito mais valido esta usando o i386
>  por
>  > questoes de sotwares. Essa é a minha unica opinião.
>
>  Eu tinha esse pensamento de 32-bits há algum tempo mas mudei. Hoje em
>  dia eu gosto de recomendar sempre sistemas 64-bits, com os "macetes"
>  para rodar coisas como Flash e Java. Principalmente no caso de
>  servidores :-) Se for uma estação de desenvolvimento então que requer
>  mais processamento, melhor ainda! 

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?

E quanto aos programas compilados em i386 que não aceitam rodar em uma
arquitetura 64?

Quanto tempo teremos de esperar para os programas serem compilados em 64? E
a compatibilidade?


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.

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.

Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um sistema
de gerenciamento de pacotes com um nome de distribuição.

Creio que o GoboLinux é a salvação do Linux.

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.

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.

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.

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

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.


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


-- 
EquipeLinux(a)EquipeLinux.com
EquipeLinux(a)Skype.com

[Hugo Cisneiros]

2009/4/3 Marcio Carneiro <viabsb(a)gmail.com&gt;:
>  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.

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

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

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

>  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

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

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

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

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

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

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

É 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 :(

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?

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

[Gerente de Sistemas]

2009/4/3 Hugo Cisneiros (Eitch) <hugo(a)devin.com.br&gt;

>  2009/4/3 Marcio Carneiro <viabsb(a)gmail.com&gt;:
>  > 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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-users-br
>  


-- 
EquipeLinux(a)EquipeLinux.com
EquipeLinux(a)Skype.com

[Hugo Cisneiros]

2009/4/4 Marcio Carneiro <viabsb(a)gmail.com&gt;:
> > > 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

Evolução do Linux

[Heitor Moraes]

Nem me dei o trabalho de ter a thread toda, mas ai vai minha
experiência com Mac.

Originalmente o MacOS era um sistema simples e leve.
Não havia preocupação com segurança, e a grande diferença entre ele e
o Windows, é que o Mac já nasceu gráfico, não herdando abstrações do
terminal de texto.

O OSX, cujo coração é um BSD, era capaz de rodar, quando sobre
PowerPC, uma versão do MacOS clássico.
Isso permitiu rodar aplicações antigas durante anos, depois a Apple
matou o suporte ao MacOS clássico.

Esse novo Mac, baseado em Unix, tem 10 anos. O OSX cresceu e ficou
bonitão, mas por baixo roda Apache, SAMBA, OpenSSH.
Tudo que a Apple faz é montar um SO com uma Gui própria e com uma base
sólida fortemente modificada de um SO pré-existente.

Essa base sólida é bastante segura, mas para permitir as customizações
de configuração e interface feitas pelo usuário, o MacOSX acaba não
sendo assim tão sólido.

Tudo lembra muito o uso do sudo no Ubuntu, e o comportamento do Ubuntu
com relação ao Debian.
Mas de fato, a chance de provocar um rombo com um shell script enviado
como anexo, no OSX, é bem grande, tamanho o número de usuários com
permissão de administrador e sessões do sudo abertas.

Acredito que a fraqueza nas permissões e o uso demasiado do sudo sejam
as maiores fraquezas do OSX.
Os buracos do Safari vão acabar sumindo com a criação dessas sandboxes
nos browsers modernos, mas esse modelo administrativo falho e
permissivo está viciando usuários que poderiam desde já aprender a
cuidar do computador, como cuidam do carro ou da casa.

2009/4/5 Leonardo Pinto (Gmail) <leonardoprc(a)gmail.com&gt;:
>  Antes de julgamos as questões alheias é preciso examinar o ponto de
> vista
>  das pessoas, de cada um. As vezes achamos insano um pensamento pelo simples
>  fato do conceito prévio (do vulgar - preconceito). A máxima do índio que
>  avistou as caravelas, realmente descreve muito bem as situações de TODOS
>  aqui. Percebo que o exposto pelo companheiro Marcio Carneiro tem muito em
>  comum com os meus expostos. Porém antes de julgar que o Linux tem um
>  conceito errado/diferente (olha o preconceito novamente aí), é preciso
>  entender os motivos que o leva a essa concepção. Depois de compreender, fica
>  até mais sensato criar sugestões e mais inovações.
>
>  Pontos em comum: Constatei que essas inconformações com o Linux vem se
>  generalizando (prova é o Gobo). De fato o Linux é concebido muito mais para
>  servidores do que para estações, e ótimo no que faz e na forma que faz com
>  servidores. Apesar das estações ficarem muito mais seguras com o conceito de
>  servidor, afinal toda estação é um servidor em potencial. Mas para ser
>  estação inegavelmente precisa ter acessibilidade e praticidade de uma
>  estação de trabalho. Percebí e constatei então que tudo que Eu vinha
>  idealizando de novo num Linux ENCONTREI JÁ PRONTO no Mac!!! A proposta Gobo
>  é bem parecida com o Mac, e olha que ele nem fez questão de esconder suas
>  raízes Unix/BSD. O que ele fez: Deixou o Kernel, árvore de diretório e seus
>  binários como parte Núcleo do SO, e a parte GUI do usuário que quer mover,
>  remover como quiser e bem entender deixou em /Applicattions. Foi simples
>  assim!!! Claro que tem outras facilidades e modificações a mais...
>
>  Foi genial a sacada da Apple. E acredito que mesmo com essas pequenas e
>  notórias modificações o MacOSX Server não deixou de ser um Unix e conter
>  nele toda segurança intrínseca. Pelo simples fato de ter ficado mais
>  acessível ao usuário final. Por isso que os leigos sempre acham que o Linux
>  é feito de programa-dores para programa-dores...
>
>  O Linux precisa mesmo se encontrar. Ou separar o joio do trigo, ou atender
>  bem suas segmentações de usuário.
>
>  Pessoal, são boas referências!!! O MacOSX é um meio termo e é a prova viva
>  de que não precisa nem ser um Rwindows e nem ser um Linux, para ser um
>  Sistema Operativo que verdadeiramente agrade e atenda gregos e troianos. Um
>  Unix muito mais acessível e muito porém bem seguro. (HAY QUE ENDURECER, PERO
>  SIN PERDER LA TERNURA JAMÁS!) :-P  ;-) 8-)
>
>
>
>  PS: Antiga trhead Re: [Fedora-users-br] Atualizar o FC10 i386 com x86_64 e
>  Re: [Fedora-users-br] Sobre o KDE 4.x
>
>  --
>  Leonardo Pinto
>  leonardoprc#gmail dot com
>
>  Marcio Carneiro escreveu:
>
>  RUINDOUS
>
>  Falar em polimorfismo no ruindous é uma inconsistência dimensional:
>  aquilo roda em um sistema operacional por disco, em 16 bits, faz
>  multi-tarefas compartilhadas (pelo tempo de idle) e não tem nada
>  orientado a objetos.
>  Aliás, uma linguagem orientada a objetos ser executada num SO
>  procedimental é puro desperdício de energia.
>  Nada no programa fala com o SO e não tem nada no SO à disposição da
>  linguagem.
>
>  KDE x KDE
>
>  Em minha opinião, o KDE3 é o KDE e o KDE4 é outra criatura.
>  Não existe evolução em programas e SSOO: existe alteração.
>  Veja-se a árvore de diretórios do UNIX, que é irracional, e nunca mudou.
>  Mando, aqui, meus mais sinceros votos de congratulações ao pessoal do
>  GoboLinux, pela coragem de mudar, e pela qualidade de melhorar.
>  Estou de ôlho na distro e espero que nunca se torne uma distro.
>  Sugiro que façam duas edições: uma com a árvore do UNIX e com as
>  receitas, e outra, SEM a árvore do UNIX, o que será um fator de
>  segurança adicional.
>  Sugiro, também, que êles usem uma edição do Fedora, abram, usem as
>  receitas em tudo e liberem para o Gobo.
>
>  OS SISTEMAS DE GERENCIAMENTO DE PACOTES
>
>  O Linux é um kernel, as distros são o que os Gerenciadores de Pacotes
>  permitem.
>  Não tem nada no UNIX ou no Linux Orientado a Usuário.
>  Evoluir é tornar-se orientado a usuários e a objetos, ou seja,
>  escrever o kernel com OCAMLDUCE ou ObjectiveC, e isto não vai ser
>  feito pelo simples fato que os codificadores dos Linuxes estão em um
>  corrida pela última "feature" e esquecem que não existe absolutamente
>  nenhuma vantagem significativa em usar o KDE 1 ou 4, pelo simples fato
>  que nenhuma necessidade dos então usuários do KDE1 evoluiu para
>  qualquer outra coisa, para que êles criassem o KDE4, para "atender" ao
>  usuário.
>  Concordo, estou usando o gnome por não desejar me submeter ao que os
>  codificadores "pensam" que é a "evolução" do KDE, e por enquanto
> tenho
>  o KDE instalado por algumas boas idéias, como o konqueror, knotes (vou
>  mudar para um wiki - TWiki).
>  São bem poucas as características do KDE não-disponíveis no gnome para
>  eu escolher o KDE, uma escolha, aliás, que já havia feito e estou
>  mudando.
>
>  QUEM SABE UM UNIX É MELHOR DO QUE UM alike?
>
>  Para falar a verdade, estou considerando seriamente o OpenBSD com
>  gnome, pois o Linux se tornou sinônimo de Sistema de Gerenciamento de
>  Pacotes, que é o que realmente funciona (e mal) numa distribuição, que
>  se resume, ao final, ao que o Sistema de Gerenciamento de Pacotes faz.
>  Se você apaga uma biblioteca necessária para o SO, você não consegue
>  mais recuperar o que saiu e não consegue atualizar o SO, pois êle
>  reclama de duplicidade ou simplesmente não deixa você instalar um SO
>  igual, tem de atualizar para uma versão maior, do FC9 para o FC10, por
>  exemplo.
>  Se eu disser que evoluir é "isto" e um codificador do KDE disser é
>  "aquilo", não há a menor diferença: não há nenhuma evolução em nenhuma
>  das assertivas.
>  O codificador não fêz o KDE que EU quero e não vai fazer. Podemos,
>  como usuários, concordar em muito com o que os codificadores do KDE
>  fazem (ou do gnome), mas não significa que êles me atenderam e
>  signfica que me entenderam.
>  Se êles tivessem a humildade de componentizar o KDE e o GNOME, de modo
>  a que uma característica nova não interfira no conjunto, então
>  estariam pensando nos usuários, do contrário, estão pensando nêles
>  próprios, em como são grandes codificadores e em como os usuários são
>  reacionários e contra-revolucionários, ou seja, o KDE é marxista ou
>  católico ou evangélico ou ....whatever... e os usuários são o
>  demônio....
>  O fato do gnome andar devagar é o seu grande mérito. Tem tempo de
>  respeitar os usuários e não nos põem a correr atrás das "features",
>  inúteis como as bugigangas a que se refere o De Masi quando critica o
>  consumismo de produtos inúteis que agregam estresse e desperdiçam a
>  energia humana em produzi-las.
>  Quanto às futilidades, tudo que não tem uso para um usuário É uma
>  futilidade e não deveria estar ali para atrapalhar, o que reforça
>  minha visão de que um SO e seus ambientes gráficos devem ser
>  componentizados de forma a permitir tirar o que se quiser tirar sem
>  comprometer o SO.
>
>  PORQUE NÃO UM KERNEL e UM SO?
>
>  Na minha opinião, deveria haver uma árvore de diretórios somente para
>  o kernel (do root) e outra para os usuários (o /home), onde o usuários
>  poderia instalar QUALQUER programa SEM interferir com os programas
>  necessários ao kernel.
>  Assim, haveria um python para o kernel e OUTRO para o usuários, de
>  modo que se um usuários retirasse um dos programas que são (hoje)
>  necessários ao SO, não perderia nada, pois os que o SO realmente usa
>  estariam protegidos na árvore do kernel.
>  Dêste modo, o kernel seria o kernel propriamente dito MAIS tudo o mais
>  necessário para gerar, editar compilar e instalar o kernel, em um só
>  pacote e à parte do restante do SO.
>  Mas isto é o que um usuário quer, e nenhum codificador liga a mínima
>  para mim ou para o que eu quero.
>  Não tem muita diferença entre o Linux (as distros) e o ruindous, pois
>  nenhum é Orientado a Usuário, e sou um usuário.
>  ... por enquanto....
>
>
>
>  Marcio Carneiro escreveu:
>
>  2009/4/3 Hugo Cisneiros (Eitch) <hugo(a)devin.com.br&gt;
> >
> > 2009/4/3 Marcio Carneiro <viabsb(a)gmail.com&gt;:
> > > 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.
>
>
>  Hugo Cisneiros (Eitch) escreveu:
>
>  Meu deus, que viagem, novamente... :P
>
>  --
>  Fedora-users-br mailing list
>  Fedora-users-br(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-users-br
>
>

Evolução do Linux

[Leonardo Pinto]

Experiências frustradas e fracassadas interdependem do SO. Dependendo do administra-dor
até o próprio Linux pode ser falho como o Rwindows. E a recíproca é verdadeira. Até o
próprio Rwindows pode ser tão seguro quanto o Linux, se for bem configurado e
administrado.

Uso o MacOSX Leopard e não tenho "usuários com permissão de administrador". Sim,
tenho um "root" que pode fazer todas as coisas assim como o root no Linux. Porém
é exatamente como no Linux. Se permitimos o root logar no GDM/KDM, todo o sistema fica
falho. Quanto ao resto, remova todos os programas como "rm -rf /Applicattions/*"
e no bojo (Apache, SAMBA, OpenSSH, etc...) tudo será como o Linux. As permissões, ACLs e
níveis de segurança serão as mesmas. Portanto fraco é o administrador, não o SO.
Exatamente assim como o motorista de um carro. Se ele não for bom motorista, pode ser uma
ferrari e ele perderá o controle.

Quanto ao Mac ter nascido já no gráfico, é justamente essas concepções que fazem ele TÃO
BOM, PRÁTICO e ACESSÍVEL!!! E para completar, a Apple colocou um super motor BSD nele, e
fez a bela arte. Juntou duas grandes forças!!!
 
--
Leonardo Pinto
leonardoprc#gmail dot com


Heitor Moraes escreveu:
>  Nem me dei o trabalho de ter a thread toda, mas ai vai minha
>  experiência com Mac.
>
>  Originalmente o MacOS era um sistema simples e leve.
>  Não havia preocupação com segurança, e a grande diferença entre ele e
>  o Windows, é que o Mac já nasceu gráfico, não herdando abstrações do
>  terminal de texto.
>
>  O OSX, cujo coração é um BSD, era capaz de rodar, quando sobre
>  PowerPC, uma versão do MacOS clássico.
>  Isso permitiu rodar aplicações antigas durante anos, depois a Apple
>  matou o suporte ao MacOS clássico.
>
>  Esse novo Mac, baseado em Unix, tem 10 anos. O OSX cresceu e ficou
>  bonitão, mas por baixo roda Apache, SAMBA, OpenSSH.
>  Tudo que a Apple faz é montar um SO com uma Gui própria e com uma base
>  sólida fortemente modificada de um SO pré-existente.
>
>  Essa base sólida é bastante segura, mas para permitir as customizações
>  de configuração e interface feitas pelo usuário, o MacOSX acaba não
>  sendo assim tão sólido.
>
>  Tudo lembra muito o uso do sudo no Ubuntu, e o comportamento do Ubuntu
>  com relação ao Debian.
>  Mas de fato, a chance de provocar um rombo com um shell script enviado
>  como anexo, no OSX, é bem grande, tamanho o número de usuários com
>  permissão de administrador e sessões do sudo abertas.
>
>  Acredito que a fraqueza nas permissões e o uso demasiado do sudo sejam
>  as maiores fraquezas do OSX.
>  Os buracos do Safari vão acabar sumindo com a criação dessas sandboxes
>  nos browsers modernos, mas esse modelo administrativo falho e
>  permissivo está viciando usuários que poderiam desde já aprender a
>  cuidar do computador, como cuidam do carro ou da casa.
>
>  2009/4/5 Leonardo Pinto (Gmail) <leonardoprc(a)gmail.com&gt;:
>    
> > Antes de julgamos as questões alheias é preciso examinar o ponto de vista
> > das pessoas, de cada um. As vezes achamos insano um pensamento pelo simples
> > fato do conceito prévio (do vulgar - preconceito). A máxima do índio que
> > avistou as caravelas, realmente descreve muito bem as situações de TODOS
> > aqui. Percebo que o exposto pelo companheiro Marcio Carneiro tem muito em
> > comum com os meus expostos. Porém antes de julgar que o Linux tem um
> > conceito errado/diferente (olha o preconceito novamente aí), é preciso
> > entender os motivos que o leva a essa concepção. Depois de compreender, fica
> > até mais sensato criar sugestões e mais inovações.
> >
> > Pontos em comum: Constatei que essas inconformações com o Linux vem se
> > generalizando (prova é o Gobo). De fato o Linux é concebido muito mais para
> > servidores do que para estações, e ótimo no que faz e na forma que faz com
> > servidores. Apesar das estações ficarem muito mais seguras com o conceito de
> > servidor, afinal toda estação é um servidor em potencial. Mas para ser
> > estação inegavelmente precisa ter acessibilidade e praticidade de uma
> > estação de trabalho. Percebí e constatei então que tudo que Eu vinha
> > idealizando de novo num Linux ENCONTREI JÁ PRONTO no Mac!!! A proposta Gobo
> > é bem parecida com o Mac, e olha que ele nem fez questão de esconder suas
> > raízes Unix/BSD. O que ele fez: Deixou o Kernel, árvore de diretório e seus
> > binários como parte Núcleo do SO, e a parte GUI do usuário que quer mover,
> > remover como quiser e bem entender deixou em /Applicattions. Foi simples
> > assim!!! Claro que tem outras facilidades e modificações a mais...
> >
> > Foi genial a sacada da Apple. E acredito que mesmo com essas pequenas e
> > notórias modificações o MacOSX Server não deixou de ser um Unix e conter
> > nele toda segurança intrínseca. Pelo simples fato de ter ficado mais
> > acessível ao usuário final. Por isso que os leigos sempre acham que o Linux
> > é feito de programa-dores para programa-dores...
> >
> > O Linux precisa mesmo se encontrar. Ou separar o joio do trigo, ou atender
> > bem suas segmentações de usuário.
> >
> > Pessoal, são boas referências!!! O MacOSX é um meio termo e é a prova viva
> > de que não precisa nem ser um Rwindows e nem ser um Linux, para ser um
> > Sistema Operativo que verdadeiramente agrade e atenda gregos e troianos. Um
> > Unix muito mais acessível e muito porém bem seguro. (HAY QUE ENDURECER, PERO
> > SIN PERDER LA TERNURA JAMÁS!) :-P  ;-) 8-)
> >
> >
> >
> > PS: Antiga trhead Re: [Fedora-users-br] Atualizar o FC10 i386 com x86_64 e
> > Re: [Fedora-users-br] Sobre o KDE 4.x
> >
> > --
> > Leonardo Pinto
> > leonardoprc#gmail dot com
> >

Evolução do Linux

[Hugo Cisneiros]

2009/4/5 Heitor Moraes <heitor.moraes(a)gmail.com&gt;:
>  Acredito que a fraqueza nas permissões e o uso demasiado do sudo
> sejam
>  as maiores fraquezas do OSX.
>  Os buracos do Safari vão acabar sumindo com a criação dessas sandboxes
>  nos browsers modernos, mas esse modelo administrativo falho e
>  permissivo está viciando usuários que poderiam desde já aprender a
>  cuidar do computador, como cuidam do carro ou da casa. 
É a famosa fina linha entre a segurança e a "usabilidade" do usuário.
Todos querem achar um ponto de equilíbrio: achar algo que deixe seguro
contra o usuário, ao mesmo tempo que deixe o usuário fazer o que
precisar se ele quiser. Pra mim isso vai mais da educação do usuário
(como citou o camarada acima), mas realmente pode-se chegar a um ponto
de equilíbrio aí.

O Leonardo tocou no ponto importante: não importa como o sistema
funciona por trás, para um usuário final/desktop. Ele quer que as
ferramentas de instalação/desinstalação funcionem, que os ícones das
suas aplicações estejam fáceis e disponíveis, que seus dispositivos
funcionem no seu computador e que seu sistema não fique travando toda
hora. É isso que o usuário quer, o resto é detalhe e capricho de
programador.

Na parte de servidor, como eu disse e como o Leonardo disse, o Linux é
muito forte porque o perfil dos administradores é mais de "usuário
avançado". Então ele se vira pra fazer as várias coisas. No desktop
isso é um pouco diferente. O Mac OS X realmente é um exemplo sólido de
um Unix voltado para o usuário final. E eu posso dizer com certeza que
isso seria possível no Linux se a gente não tivesse algumas vantagens
sobre o Mac OS X:

1. Pelo aspecto livre, não existe um padrão de API/implementação. Uns
gostam assim, outros gostam daquele jeito, e não existe uma interface
sólida para tudo. Isso divide esforços e acaba por afastar muitas
coisas "que seriam fáceis de fazer" dos desenvolvedores, concentrando
tudo nas pessoas que fazem cada distribuição.

2. Não existe uma empresa só que dita e mantém um foco. Esse também é
um dos motivos por qual não dá pra concentrar os esforços. Muda até
quando grandes empresas assumem a liderança, como a Canonical, Red Hat
e Novell. Mas não é nem um pouco certo isso.

3. Minha opinião pessoal: os softwares do Linux para desktop são, em
geral, mal feitos e não tem qualidade de software. Isso muda com o
tempo, mas eu ainda continuo achando que são ruins - muita qualidade
em alpha. Talvez precisasse de mais QA :( Lembrando que isso é uma
opinião bem radical, não levem muito em conta :P

E o problema agora é que: visto por outro lado, estas são vantagens:
temos a liberdade de escolher o que gostamos e como gostamos, não
ficamos preso a nada. Só que as vantagens, por outro lado, tem suas
coisas ruins também ;(

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

[Gerente de Sistemas]

2009/4/4 Hugo Cisneiros (Eitch) <hugo(a)devin.com.br&gt;

>  2009/4/4 Marcio Carneiro <viabsb(a)gmail.com&gt;:
>  >> > 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.
>
>  Ou seja, a distribuição limita-se ao gerenciador de pacotes. 
Você não tem a
liberdade de agir fora do que o gerenciador faz, pois o risco
de criar uma incompatibilidade com os arquivos instalados pelo gerenciador é
grande e você pode perder tudo, como você disse que aconteceu com você (o
mesmo comigo, era o que eu tentava dizer e foi exatamente com o glibc).
Eu não disse que uma distribuição é apenas um gerenciador de pacotes, digo
que se limita ao limite dêle.
Quanto às ligações dinâmicas, creio que não entendi, ou o que você disse ou
o que é uma ligação dinâmica.
Eu vi o seguinte: instalar um programa num diretório independente de
ligações dinâmicas e criar as ligações dinâmicas necessárias para a execução
do programa nos diretórios de binários e bibliotecas, OU, colocar os
caminhos da instalação nova no caminho do SO.
É isto que entendo como "independência" do gerenciador de pacotes, ou seja,
uma biblioteca instalada a partir dos fontes de um programa e compilado fora
do gerenciador não vai criar uma dependência que afete o SO ou os programas
instalados pelo gerenciador quando aquêle for eliminado.
E é isto que eu não vejo acontecer com os gerenciadores de pacotes e por
isto reduzi tudo ao mesmo denominador comum: o que um SO não faz fora do
gerenciador o torna limitado ao gerenciador, que, afinal, é o que importa.
NÃO se trata de "colocar todos os programas linkados estaticamente", nunca
disse isto, ou me expressei mal.
Quanto ao GoboLinux, os programas não são todos ligados dinamicamente, as
ligações dinâmicas é que são criadas nos diretórios onde estão os binários
do SO.
Os programas do GoboLinux ficam num diretório de Programas e para apagar um
programa você simplesmente elimina o diretório. Vão sobrar as ligações
dinâmicas nos diretórios dos binários e das bibliotecas, o que facilita a
manutenção num sistema Gobo, pois tudo que fôr ligação dinâmica ausente
poderá ser apagada pois pertenciam a programas que foram apagados.
Isto será assim até a mudança final da árvore de diretórios, física, o que
mudará a árvore do unix completamente.
Não vejo nenhuma idéia louca, o que vejo é que você entendeu mal o que eu
disse, ou eu me expressei mal, pelo que me desculpo.
Quanto à independência entre os programas no GoboLinux, sim, isto muda tudo,
porque você pode eliminar um programa sem se preocupar com qualquer
dependência.
Sim, eu sei que você pode instalar vários programas iguais. A questão não é
esta. É que você NÃO pode instalar dois pythons com um gerenciador de
pacotes (RPM) porque êle assume que você está instalando o MESMO que êle já
conhece e é INDISPENSÁVEL ao SO, no caso do python, por causa do yum, por
exemplo, se êle for não-relocável.
E poucos são relocáveis, problema que o GoboLinux resolve com a
não-dependência de ligações dinâmicas.
Quanto às compilações dinâmicas serem vantajosas em relação à compilação
estática, prefiro a redundância de arquivos e a segurança de poder tirar
qualquer coisa a qualquer hora do que ter um pesadelo de manutenção e
depender de um gerenciador de pacotes, que VAI falhar.
Pacotes de programas que contêm TUDO são mais seguros, o espaço em disco é
cada vez mais barato, como a memória, e o problema passa a ser de desempenho
do processador e otimização do código.
Um celeron com linux pode ser melhor do que com ruindous, ou entre dois
linux, um compilado para i386 e outro para i586. Do ponto de vista do pacote
estático, é indiferente.
"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": sim, porquê não, se
espaço e memória não são mais problemas técnicos ou de custo e se o tempo do
analista, do programador ou do usuário é que é caro?
E não necessariamente TODOS os programas seriam estaticamente ligados. O
problema aqui seria saber em cada programa o quê do SO estaria duplicado
para criar aquela compilação dinâmica, mas ainda creio que é mais barato
duplicar do que usar o tempo do programador, do analista e, principalmente,
do usuário.
Aqui, parece-me, discordamos.

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

Não disse isto, mas me sôa meio atrasado.
Johen Kennedy, em 1962, desafiou o povo Estadunidense a levar um homem à
Lua, pousar e trazê-lo de volta em segurança antes do fim da década.
É um exemplo de Projeto perfeito.
E êles fizeram.
Só para citar alguém que falava inglês.
Então, fazer uma porcaria de um sistema operacional do zero deveria ser uma
OPORTUNIDADE, e pelo visto, você não está á altura do desafio.
Creio que CADA faculdade de TI do .br DEVERIA entrar na corrida pelo SO.br!.
E creio que o SO deveria ser escrito em OCAMLDUCE com C ou assembler no que
fôsse necessário.



>  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 

Se a linguagem não importa porquê você acha que fizeram C para criar o UNIX?
Porquê não foi escrito em BASIC?
Porquê a SUN criou o java para aquecer torradeiras à distância e não usou o
pascal para fazer isto?


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

Isto é autoritário.


>  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 

Hein?


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

Você precisa estudar um pouco mais o idioma falado por aqui.
Sujeito, objeto direto, estas coisas.
Pessoas sadias NÃO têm idéias loucas, loucos as têm.
Eu não tenho de provar nada para você nem para ninguém, não estou aqui para
isto.
Estou debatendo um assunto que me interessa, e com você porque já demonstrou
ter conhecimento. Mas isto não te dá direitos extras.
Eu não acho nada, sou um cara sem sorte, se não faço ou não compro pronto,
fico sem.
Não se desculpe, desculpe-se, não tenho de ser instigado, pois estou,
justamente, instigando, e você não aceitou muito bem..... partiu para a
loucura ... mandou mudar conceitos ... e se parece que estou dizendo algo
que não sei o que é, não te pareceu que poderia ser justamente por isto que
estou nesta lista?

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

Então não é!


>  Se você dissesse que o
>  Linux não é orientado a usuário "final", eu concordo até certa parte.
>  
Não existem dois tipos de usuários, não existe o "usuário final".
Ou você codifica ou usa o código.
Você é um programador, quando não está fazendo o programa, está "usando" o
computador, o que faz de você um "usuário final".


>  Se você diz que Linux não é orientado a usuário "gamer", eu
> concordo
>  100%. Mas tudo isso é relativo não?
>  
Se ISTO é relativo, porquê não AQUILO?


>  Linux é orientado para os usuários corporativos e para os servidores, 

Não existem usuários corporativos, existem um ambiente corporativo.
Os usuários corporativos são os mesmos que qualquer outro usuário, êle usa.
Servidores não são usuários, são máquinas.
Servidores têm usuários.
O Linux NÃO é orientado a usuários, não pensa nos usuários e não é feito
para os usuários, é um esfôrço coletivo e vê apenas os usuários que são
capazes de participar do esfôrço.
Você quer tapar o sol com uma peneira.
Estamos envidando um esfôrço nôvo, para fazer o Linux ser tolerado pelo
usuário "final", que é o comercial, o usuário que compra um produto de TI,
enfim, um usuário que não participa da construção do Linux.


>  mas isso também está mudando: se chama crescimento/expansão.
>  Infelizmente nosso crescimento nessa área é uma porcaria :) 

Concordo.
Você já notou que praticamente nenhuma universidade têm um savane, um GForge
um ou um sourceproject?
Parece que a academia não liga a mínima para o mundo da produção de TI.
O mesmo com as SUCESU, não ligam para os usuários, não são focados nos
usuários, não investem nos usuários.
As universidades usam o google para fazer pesquisa internamente, nem se
dignaram a instalar um glimpse ou um htdig para criar o serviço dentro de
casa.
Imagine a quantidade de alunos de TI que poderiam estudar êstes ambientes e
não podem fazer porque as instituições investem na inteligência estrangeira
e marginalizam a nossa.
Você não se sente um pouco "menos" explorado do que poderia ser, dado o
conhecimento que já tem?


>  >>
>  >> 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/
>  
Saudações.

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


-- 
EquipeLinux(a)EquipeLinux.com
EquipeLinux(a)Skype.com

[Hugo Cisneiros]

2009/4/5 Marcio Carneiro <viabsb(a)gmail.com&gt;:
>  Ou seja, a distribuição limita-se ao gerenciador de pacotes.
>  Você não tem a liberdade de agir fora do que o gerenciador faz, pois o risco
>  de criar uma incompatibilidade com os arquivos instalados pelo gerenciador é
>  grande e você pode perder tudo, como você disse que aconteceu com você (o
>  mesmo comigo, era o que eu tentava dizer e foi exatamente com o glibc).
>  Eu não disse que uma distribuição é apenas um gerenciador de pacotes, digo
>  que se limita ao limite dêle. 
Disse sim. ;-)

>  Quanto às ligações dinâmicas, creio que não entendi, ou o que você
> disse ou
>  o que é uma ligação dinâmica.
>  Eu vi o seguinte: instalar um programa num diretório independente de
>  ligações dinâmicas e criar as ligações dinâmicas necessárias para a execução
>  do programa nos diretórios de binários e bibliotecas, OU, colocar os
>  caminhos da instalação nova no caminho do SO.
>  É isto que entendo como "independência" do gerenciador de pacotes, ou seja,
>  uma biblioteca instalada a partir dos fontes de um programa e compilado fora
>  do gerenciador não vai criar uma dependência que afete o SO ou os programas
>  instalados pelo gerenciador quando aquêle for eliminado. 
Não vou explicar novamente tudo de novo... Recomendo, assim como no
e-mail anterior, você dar uma pesquisada sobre a diferença entre
linkagem estática e dinâmica. Isso não envolve apenas links
simbólicos, vai muito além disso.

Se você deixar tudo independente do gerenciador de pacotes, você mesmo
terá que ser o gerenciador de pacotes. Eu prefiro que algo faça isso
pra mim, e acho que muita gente concorda comigo...

>  E é isto que eu não vejo acontecer com os gerenciadores de pacotes e
> por
>  isto reduzi tudo ao mesmo denominador comum: o que um SO não faz fora do
>  gerenciador o torna limitado ao gerenciador, que, afinal, é o que importa. 
Da mesma forma que você instalaria o programa cru, sem gerenciador de
pacote nenhum, você poderia muito bem fazer um pacote deste programa e
instalá-lo. Num mundo ideal, todos os programas teriam isto, mas como
eu já disse, existem muitas distribuições, muitos gostos e muitas
opções para poder unificar tudo.

>  NÃO se trata de "colocar todos os programas linkados
> estaticamente", nunca
>  disse isto, ou me expressei mal. 
Claro que se trata... Do jeito que você fala, para os programas serem
independentes uns dos outros, eles tem que ter todas as funções dentro
deles mesmos, sem chamadas externas. Senão é apenas uma mudança de
diretório de instalação: que dá pra fazer até com gerenciadores de
pacotes, com ./configure ; make ; make install, etc.

>  Quanto ao GoboLinux, os programas não são todos ligados
> dinamicamente, as
>  ligações dinâmicas é que são criadas nos diretórios onde estão os binários
>  do SO. 
Não são todos ligados dinamicamente? Já disse: não confunda esse
conceito com links simbólicos ou organização diferente dos diretórios.
Quero ver se os comandos "ldd" não mostram nenhuma dependência nos
vários programas

>  Os programas do GoboLinux ficam num diretório de Programas e para
> apagar um
>  programa você simplesmente elimina o diretório. Vão sobrar as ligações
>  dinâmicas nos diretórios dos binários e das bibliotecas, o que facilita a
>  manutenção num sistema Gobo, pois tudo que fôr ligação dinâmica ausente
>  poderá ser apagada pois pertenciam a programas que foram apagados.
>  Isto será assim até a mudança final da árvore de diretórios, física, o que
>  mudará a árvore do unix completamente. 
Pra apagar um programa numa distro com gerenciador de pacotes, basta o
cara digitar o comando de remoção do pacote. Não vai sobrar nenhuma
ligação, então o usuário não precisa remover mais nada. Isso torna a
manutenção do sistema ao longo prazo muito boa. Se você quer fazer a
mesma coisa que no GoboLinux, você simplesmente cria um pacote com seu
programa. O que muda aí?

>  Não vejo nenhuma idéia louca, o que vejo é que você entendeu mal o
> que eu
>  disse, ou eu me expressei mal, pelo que me desculpo.
>  Quanto à independência entre os programas no GoboLinux, sim, isto muda tudo,
>  porque você pode eliminar um programa sem se preocupar com qualquer
>  dependência. 
Duvido! E isso eu duvido muuuuuuuito! Se você me provar isso, eu
desisto e você me convence. E digo isso pelas razões que já expliquei
antes. Me prove! E não vale você remover algo tão banal como uma
aplicaçãozinha isolada, quero ver isso acontecer com bibliotecas
importantes para vários programas. Por exemplo, o GIMP e GTK. Se você
me provar que, numa instalação normal do GoboLinux, você remover o GTK
e continuar a usar o GIMP sem qualquer biblioteca GTK, então você me
prova que ele é compilado estaticamente.

Como eu disse antes, uma série de comandos "ldd" nos executáveis pode
mostrar isso também.

>  Sim, eu sei que você pode instalar vários programas iguais. A questão
> não é
>  esta. É que você NÃO pode instalar dois pythons com um gerenciador de
>  pacotes (RPM) porque êle assume que você está instalando o MESMO que êle já
>  conhece e é INDISPENSÁVEL ao SO, no caso do python, por causa do yum, por
>  exemplo, se êle for não-relocável. 
Opa, claro que pode. Como eu disse antes, o Debian faz isso com o php
(apenas um exemplo que eu dei, outro seria o Apache), é só mudar o
nome do pacote e sua localização. php4 para a versão 4, php5 para a
versão 5, apache para a versão 1.x, apache2 para a versão 2.x. Há uns
anos atrás, eu mantinha duas versões de pacotes para o MySQL no
CentOS: mysql (da distro) e mysql5 (personalizado) pra poder ter as
duas versões.

É a mesma coisa. O que muda é o método de fazer, e o GoboLinux fica
mais amigável aos olhos dos usuários finais. Da mesma forma que você
tem que criar um pacote personalizado, no GoboLinux você tem que
compilar o programa utilizando parâmetros especiais pra ele entender
que vai ser instalado em múltiplos diretórios (para versões
diferentes).

>  E poucos são relocáveis, problema que o GoboLinux resolve com a
>  não-dependência de ligações dinâmicas.
>  Quanto às compilações dinâmicas serem vantajosas em relação à compilação
>  estática, prefiro a redundância de arquivos e a segurança de poder tirar
>  qualquer coisa a qualquer hora do que ter um pesadelo de manutenção e
>  depender de um gerenciador de pacotes, que VAI falhar. 
Boa sorte... :P

>  Pacotes de programas que contêm TUDO são mais seguros, o espaço em
> disco é
>  cada vez mais barato, como a memória, e o problema passa a ser de desempenho
>  do processador e otimização do código. 
Eu odeio esse pensamento atual. "Ah, temos muita coisa, podemos deixar
pesado", e deixam de pensar em desempenho e otimização. Esse "problema
passa a ser de desempenho de processador e otimização de código" é sim
o mesmo problema, e QUE PROBLEMA.

Como você não pesquisou sobre os programas estaticamente linkados e
está defendendo isso, vou dar uma leve explicada sobre desempenho
nesse caso.

Se todo programa tivesse tudo estaticamente linkado, isso significa
que para cada programa rodado, uma instância de todas as bibliotecas
do sistema necessárias é feita. Isso significa que o programa vai
gastar mais disco, mais memória, mais processamento, tudo isso muito
desnecessariamente.

Imagine se no meu sistema:

$ ps ax | wc -l
112

Tenho 112 processos e cada um desses processos carrega todas as bibliotecas?

Meu deus! Seria o caos! Imagina que eu tenho aqui o yakuake (emulador
de terminal do KDE que utiliza o konsole) rodando:

$ ps ax | grep yakuake
 3217 ?        S      0:18 yakuake -session
10d8c2646f000121314150100000055050017_1238815489_972047

Agora vamos ver que bibliotecas compartilhadas ele está usando:

$ ldd /usr/bin/yakuake
        linux-gate.so.1 =>  (0xb7f6f000)
        libkdeui.so.4 => /usr/lib/libkdeui.so.4 (0xb7c4d000)
        libkio.so.4 => /usr/lib/libkio.so.4 (0xb78d6000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb77e7000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb77c1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb77b4000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7659000)
        libkdecore.so.4 => /usr/lib/libkdecore.so.4 (0xb73f5000)
        libDCOP.so.4 => /usr/lib/libDCOP.so.4 (0xb73be000)
        libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb6cc5000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6bd5000)
        libkdefx.so.4 => /usr/lib/libkdefx.so.4 (0xb6bab000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6b9d000)
        libkdesu.so.4 => /usr/lib/libkdesu.so.4 (0xb6b88000)
        libkwalletclient.so.1 => /usr/lib/libkwalletclient.so.1 (0xb6b78000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb6b62000)
        libfam.so.0 => /usr/lib/libfam.so.0 (0xb6b59000)
        libacl.so.1 => /lib/libacl.so.1 (0xb6b52000)
        libattr.so.1 => /lib/libattr.so.1 (0xb6b4d000)
        /lib/ld-linux.so.2 (0xb7f70000)
        libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb6b37000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0xb6b05000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb6afd000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb6ae6000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6ae2000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6ab8000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb6aa1000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb6a51000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6a32000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6a0f000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb6a07000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb69fe000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb69f7000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb69ee000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb69eb000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0xb69d8000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6963000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb694a000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb6947000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb692f000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb692c000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb6906000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6900000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb68fb000)

OMG! Então cada programa do KDE, como o yakuake, teria que carregar
todas as chamadas de biblioteca do KDE!  Todas as bibliotecas do Xorg!
A biblioteca do C++! Acredite em mim, isso é impraticável, NENHUM
sistema é assim e vai ser difícil de ser, porque o problema não é
apenas nessa perda de desempenho e recursos, mas também no
gerenciamento final do sistema.

É como os módulos do kernel. Imagine que você pode colocar tudo na
imagem principal do kernel. Pra que colocar tudo se você vai usar 10%?
Por que você tem espaço demais e memória demais e processamento
demais? E os dispositivos embarcados como celulares, roteadores,
appliances, etc?

>  Um celeron com linux pode ser melhor do que com ruindous, ou entre
> dois
>  linux, um compilado para i386 e outro para i586. Do ponto de vista do pacote
>  estático, é indiferente. 
*NADA* haver. Por favor, não fale coisas que não sabe.

> > >> > 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".
>
>  Não disse isto, mas me sôa meio atrasado.
>  Johen Kennedy, em 1962, desafiou o povo Estadunidense a levar um homem à
>  Lua, pousar e trazê-lo de volta em segurança antes do fim da década.
>  É um exemplo de Projeto perfeito.
>  E êles fizeram. 
É, e o pessoal lá falou assim para o pessoal da NASA:

"Ignorem todas as descobertas da física e tudo que já foi feito até
hoje e comecem a criar tudo do zero, aí vocês vão lá pra lua dessa
forma, ok?"

Mas que analogia nada haver hein?

>  Só para citar alguém que falava inglês.
>  Então, fazer uma porcaria de um sistema operacional do zero deveria ser uma
>  OPORTUNIDADE, e pelo visto, você não está á altura do desafio.
>  Creio que CADA faculdade de TI do .br DEVERIA entrar na corrida pelo SO.br!.
>  E creio que o SO deveria ser escrito em OCAMLDUCE com C ou assembler no que
>  fôsse necessário. 
Boa sorte!

Vamos aproveitar e montar um projeto para a paz mundial.

> > 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
>
>  Se a linguagem não importa porquê você acha que fizeram C para criar o UNIX?
>  Porquê não foi escrito em BASIC?
>  Porquê a SUN criou o java para aquecer torradeiras à distância e não usou o
>  pascal para fazer isto? 
Repetindo, "a linguagem não importa NA MAIORIA DAS VEZES". Não
desconsiderei tudo, eu quis dizer que o PROGRAMADOR importa e MUITO.
Citar exemplos desse de C vs. BASIC é meio ridículo. Não piore as
coisas.

> >
> > 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.
>
>  Isto é autoritário. 
Onde? Eu não obriguei nada e nem impus nada aqui.

> > 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
>
>  Hein?
>
> >
> > 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?
>
>  Você precisa estudar um pouco mais o idioma falado por aqui.
>  Sujeito, objeto direto, estas coisas.
>  Pessoas sadias NÃO têm idéias loucas, loucos as têm. 
Tá começando a viajar mais ainda né? Você tá levando tudo literalmente
então? Pessoas sadias tem idéias loucas sim, idéias fora do comum.
Isso não a deixa "louca". Faça-me um favor...

>  Eu não tenho de provar nada para você nem para ninguém, não estou
> aqui para
>  isto. 
Por que? Eu acho o contrário. Se você acha que tem uma idéia boa,
estude-a e prove-a para todos os outros! Não é você que quer um mundo
Unix/Linux melhor? Você acha que vai concretizar sua idéia se não
compartilhar, lutar e defender seus pontos de vista? Tá aqui pra que
então, criar polêmica apenas? Espero que não.

>  Estou debatendo um assunto que me interessa, e com você porque já
> demonstrou
>  ter conhecimento. Mas isto não te dá direitos extras.
>  Eu não acho nada, sou um cara sem sorte, se não faço ou não compro pronto,
>  fico sem.
>  Não se desculpe, desculpe-se, não tenho de ser instigado, pois estou,
>  justamente, instigando, e você não aceitou muito bem..... partiu para a
>  loucura ... mandou mudar conceitos ... e se parece que estou dizendo algo
>  que não sei o que é, não te pareceu que poderia ser justamente por isto que
>  estou nesta lista? 
Você acha que eu deveria fazer o que? Ler o seu e-mail e aceitar tudo
que, do meu ponto de vista, parece idéias loucas? Se eu te digo que
parece que você não sabe das coisas, eu tento lhe falar (como estou
fazendo) como as coisas funcionam e tento falar pra você pesquisar e
desenvolver seu conhecimento. Se você acha que é só birra minha, aí eu
não posso fazer nada ;-)

> > O mundo é grande e existem diversos tipos de usuários. O Linux é
> > orientado para usuários SIM, só não todos.
>
>  Então não é! 
Então nenhum sistema operacional é orientado a PN.

Da próxima vez então, diga que o Linux não é orientado a o nicho de
usuários que não quer saber de nada, só quer usar seus programinhas e
não quer aprender nada. EU sou um usuário, tenho muitos amigos
usuários e achamos que o Linux é SIM orientado para meu perfil. Tanto
que vou para os outros sistemas e me sinto muito preso: mesmo tendo
conhecimento de como eles funcionam.

> > Se você dissesse que o
> > Linux não é orientado a usuário "final", eu concordo até certa parte.
>
>  Não existem dois tipos de usuários, não existe o "usuário final".
>  Ou você codifica ou usa o código.
>  Você é um programador, quando não está fazendo o programa, está "usando" o
>  computador, o que faz de você um "usuário final". 
Claro que existe vários tipos de usuário. Um administrador de sistemas
não codifica, mas usa as várias ferramentas do sistema para fazer
tarefas. O usuário final utiliza apenas alguns programinhas que não
fazem coisas muito complexas com o próprio sistema, é outro perfil. Um
usuário gamer quer muito hardware e sempre está querendo jogar seus
jogos, é outro perfil.

Eu não jogo muito, então uso Linux. Linux não é bom para Jogos. Quando
jogo, vou pro Windows que tenho aqui.

Eu administro redes e servidores, Linux é ótimo para isso. Quando vou
pro Windows, vejo várias limitações nesse sentido.

É a mesma coisa que dizer que todos os clientes de uma loja são os
mesmos e tem os mesmos gostos. Vai com esse pensamento montar uma
empresa ou um produto que você vai pro limbo hoje em dia fácil fácil.
Por que você acha que data-mining e informações pessoais vale tanto
dinheiro hoje em dia?

> > Se você diz que Linux não é orientado a usuário
> "gamer", eu concordo
> > 100%. Mas tudo isso é relativo não?
>
>  Se ISTO é relativo, porquê não AQUILO? 
O que é aquilo? E a última frase eu falei ironizando mesmo.

> > Linux é orientado para os usuários corporativos e para os
> servidores,
>
>  Não existem usuários corporativos, existem um ambiente corporativo.
>  Os usuários corporativos são os mesmos que qualquer outro usuário, êle usa.
>  Servidores não são usuários, são máquinas.
>  Servidores têm usuários.
>  O Linux NÃO é orientado a usuários, não pensa nos usuários e não é feito
>  para os usuários, é um esfôrço coletivo e vê apenas os usuários que são
>  capazes de participar do esfôrço.
>  Você quer tapar o sol com uma peneira.
>  Estamos envidando um esfôrço nôvo, para fazer o Linux ser tolerado pelo
>  usuário "final", que é o comercial, o usuário que compra um produto de TI,
>  enfim, um usuário que não participa da construção do Linux. 
Já falado acima.

> > mas isso também está mudando: se chama crescimento/expansão.
> > Infelizmente nosso crescimento nessa área é uma porcaria :)
>
>  Concordo.
>  Você já notou que praticamente nenhuma universidade têm um savane, um GForge
>  um ou um sourceproject?
>  Parece que a academia não liga a mínima para o mundo da produção de TI.
>  O mesmo com as SUCESU, não ligam para os usuários, não são focados nos
>  usuários, não investem nos usuários.
>  As universidades usam o google para fazer pesquisa internamente, nem se
>  dignaram a instalar um glimpse ou um htdig para criar o serviço dentro de
>  casa.
>  Imagine a quantidade de alunos de TI que poderiam estudar êstes ambientes e
>  não podem fazer porque as instituições investem na inteligência estrangeira
>  e marginalizam a nossa.
>  Você não se sente um pouco "menos" explorado do que poderia ser, dado o
>  conhecimento que já tem? 
Eu não... Gosto de usar as coisas que já existem e reaproveitá-las da
melhor forma possível. Ficar criando coisas redundantes e não usar o
que já existe vai contra o princípio do software livre. Ele é livre
para isso.

Se as universidade usam o Google, é porque ele é bom, vale usar ele.
Vale mais do que investir e tentar criar uma ferramenta de busca
própria. Se têm uma idéia melhor, ótimo: criem, desenvolvam e a tornem
usável para todos. Se ela for realmente melhor em vários aspectos, ela
vai ser usada e você vai ser o centro das atenções.

Acho que um exemplo disso seria a criação de distribuições. Eu canso
de ver neguinho fazendo distribuição e defendendo a unhas e dentes, ao
invés de unir os esforços com uma distribuição que já existe:
adaptá-la, brigar e lutar por conceitos novos, tornar melhor. Ao invés
disso, é mais fácil você simplesmente pegar o código que é todo livre
e começar a modificá-lo sem ter que lutar nem nada e criar um novo
produto. Se esse novo produto se difere MUITO dos que ja existem, acho
bastante válido e interessante (exemplo do próprio GoboLinux), mas se
é quase igual, só que um "branding" diferente (como é muitas das
distribuições vendidas em computadores populares daqui do Brasil),
então eu acho totalmente inválido. Mas nem quero falar muito disso...

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

Evolução do Linux

[Heitor Moraes]

Venho usando Linux no trabalho e OSX no meu Mac a alguns anos.
O computador desde 2006 é um modelo MacBookPro2,2.

Acho o OSX é um ótimo sistema para Desktop.
É lindo, rápido e fácil.
Mas seguro ele não é.
Aquele cadeado que vive aberto nas preferências não me parece o bastante.
De fato, parece um SO inocente da malícia e estupidez humanas.

http://blogs.zdnet.com/security/?p=2941

PS: Meu Adium é muito mais bonito que meu GAIM.

2009/4/5 Leonardo Pinto (Gmail) <leonardoprc(a)gmail.com&gt;:
>  Experiências frustradas e fracassadas interdependem do SO. Dependendo
> do
>  administra-dor até o próprio Linux pode ser falho como o Rwindows. E a
>  recíproca é verdadeira. Até o próprio Rwindows pode ser tão seguro quanto o
>  Linux, se for bem configurado e administrado.
>
>  Uso o MacOSX Leopard e não tenho "usuários com permissão de administrador".
>  Sim, tenho um "root" que pode fazer todas as coisas assim como o root no
>  Linux. Porém é exatamente como no Linux. Se permitimos o root logar no
>  GDM/KDM, todo o sistema fica falho. Quanto ao resto, remova todos os
>  programas como "rm -rf /Applicattions/*" e no bojo (Apache, SAMBA, OpenSSH,
>  etc...) tudo será como o Linux. As permissões, ACLs e níveis de segurança
>  serão as mesmas. Portanto fraco é o administrador, não o SO. Exatamente
>  assim como o motorista de um carro. Se ele não for bom motorista, pode ser
>  uma ferrari e ele perderá o controle.
>
>  Quanto ao Mac ter nascido já no gráfico, é justamente essas concepções que
>  fazem ele TÃO BOM, PRÁTICO e ACESSÍVEL!!! E para completar, a Apple colocou
>  um super motor BSD nele, e fez a bela arte. Juntou duas grandes forças!!!
>
>  --
>  Leonardo Pinto
>  leonardoprc#gmail dot com
>
>
>  Heitor Moraes escreveu:
> >
> > Nem me dei o trabalho de ter a thread toda, mas ai vai minha
> > experiência com Mac.
> >
> > Originalmente o MacOS era um sistema simples e leve.
> > Não havia preocupação com segurança, e a grande diferença entre ele e
> > o Windows, é que o Mac já nasceu gráfico, não herdando abstrações do
> > terminal de texto.
> >
> > O OSX, cujo coração é um BSD, era capaz de rodar, quando sobre
> > PowerPC, uma versão do MacOS clássico.
> > Isso permitiu rodar aplicações antigas durante anos, depois a Apple
> > matou o suporte ao MacOS clássico.
> >
> > Esse novo Mac, baseado em Unix, tem 10 anos. O OSX cresceu e ficou
> > bonitão, mas por baixo roda Apache, SAMBA, OpenSSH.
> > Tudo que a Apple faz é montar um SO com uma Gui própria e com uma base
> > sólida fortemente modificada de um SO pré-existente.
> >
> > Essa base sólida é bastante segura, mas para permitir as customizações
> > de configuração e interface feitas pelo usuário, o MacOSX acaba não
> > sendo assim tão sólido.
> >
> > Tudo lembra muito o uso do sudo no Ubuntu, e o comportamento do Ubuntu
> > com relação ao Debian.
> > Mas de fato, a chance de provocar um rombo com um shell script enviado
> > como anexo, no OSX, é bem grande, tamanho o número de usuários com
> > permissão de administrador e sessões do sudo abertas.
> >
> > Acredito que a fraqueza nas permissões e o uso demasiado do sudo sejam
> > as maiores fraquezas do OSX.
> > Os buracos do Safari vão acabar sumindo com a criação dessas sandboxes
> > nos browsers modernos, mas esse modelo administrativo falho e
> > permissivo está viciando usuários que poderiam desde já aprender a
> > cuidar do computador, como cuidam do carro ou da casa.
> >
> > 2009/4/5 Leonardo Pinto (Gmail) <leonardoprc(a)gmail.com&gt;:
> >
> >>
> >> Antes de julgamos as questões alheias é preciso examinar o ponto de vista
> >> das pessoas, de cada um. As vezes achamos insano um pensamento pelo
> >> simples
> >> fato do conceito prévio (do vulgar - preconceito). A máxima do índio que
> >> avistou as caravelas, realmente descreve muito bem as situações de TODOS
> >> aqui. Percebo que o exposto pelo companheiro Marcio Carneiro tem muito em
> >> comum com os meus expostos. Porém antes de julgar que o Linux tem um
> >> conceito errado/diferente (olha o preconceito novamente aí), é preciso
> >> entender os motivos que o leva a essa concepção. Depois de compreender,
> >> fica
> >> até mais sensato criar sugestões e mais inovações.
> >>
> >> Pontos em comum: Constatei que essas inconformações com o Linux vem se
> >> generalizando (prova é o Gobo). De fato o Linux é concebido muito mais
> >> para
> >> servidores do que para estações, e ótimo no que faz e na forma que faz
> >> com
> >> servidores. Apesar das estações ficarem muito mais seguras com o conceito
> >> de
> >> servidor, afinal toda estação é um servidor em potencial. Mas para ser
> >> estação inegavelmente precisa ter acessibilidade e praticidade de uma
> >> estação de trabalho. Percebí e constatei então que tudo que Eu vinha
> >> idealizando de novo num Linux ENCONTREI JÁ PRONTO no Mac!!! A proposta
> >> Gobo
> >> é bem parecida com o Mac, e olha que ele nem fez questão de esconder suas
> >> raízes Unix/BSD. O que ele fez: Deixou o Kernel, árvore de diretório e
> >> seus
> >> binários como parte Núcleo do SO, e a parte GUI do usuário que quer
> >> mover,
> >> remover como quiser e bem entender deixou em /Applicattions. Foi simples
> >> assim!!! Claro que tem outras facilidades e modificações a mais...
> >>
> >> Foi genial a sacada da Apple. E acredito que mesmo com essas pequenas e
> >> notórias modificações o MacOSX Server não deixou de ser um Unix e conter
> >> nele toda segurança intrínseca. Pelo simples fato de ter ficado mais
> >> acessível ao usuário final. Por isso que os leigos sempre acham que o
> >> Linux
> >> é feito de programa-dores para programa-dores...
> >>
> >> O Linux precisa mesmo se encontrar. Ou separar o joio do trigo, ou
> >> atender
> >> bem suas segmentações de usuário.
> >>
> >> Pessoal, são boas referências!!! O MacOSX é um meio termo e é a prova
> >> viva
> >> de que não precisa nem ser um Rwindows e nem ser um Linux, para ser um
> >> Sistema Operativo que verdadeiramente agrade e atenda gregos e troianos.
> >> Um
> >> Unix muito mais acessível e muito porém bem seguro. (HAY QUE ENDURECER,
> >> PERO
> >> SIN PERDER LA TERNURA JAMÁS!) :-P  ;-) 8-)
> >>
> >>
> >>
> >> PS: Antiga trhead Re: [Fedora-users-br] Atualizar o FC10 i386 com x86_64
> >> e
> >> Re: [Fedora-users-br] Sobre o KDE 4.x
> >>
> >> --
> >> Leonardo Pinto
> >> leonardoprc#gmail dot com
> >>
>
>  --
>  Fedora-users-br mailing list
>  Fedora-users-br(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-users-br
>

Evolução do Linux

[Leonardo Pinto]

Pois bem, é isso mesmo. Usuário final é usuário final. Ele não sabe 
programar scripts, nem quer tão pouco ficar seguindo howtos. 
Infelizmente a falta de padrão, falta de auditoria como um todo no 
Linux, que uns consideram liberdade, e outros consideram 
armengues/improvisos, é o que acaba por distanciar o usuário final.

Então como o Mac conquista teus consumidores autênticos excêntricos 
pagadores de fortunas pela aquisição desses poderosos brinquedos de 
luxo?!!! Através de homologação de todo programa autenticado for 
Macintosh. Um programa para ser considerado autêntico Mac, antes de 
entrar no mercado precisa ser encaminhado ao laboratório da Apple, 
conferido seu código, auditado, a GUI conferida com os padrões Apple, e 
caso não esteja de acordo, é "sugerido" um novo layout, etc... E para o 
Linux estar chegando perto desse nível, a comunidade desenvolvedora 
teria que ao menos vislumbrar essa ordem. Teríamos que enxergar algum 
valor nesses princípios evolutivos.

Sim, o paradigma orientado a objeto resolve em parte na codificação. Sim 
poderia ser ObjectiveC, por que não?! Não a conheço, sequer uma linha, 
mas uso seus frutos que posso perceber o quão é poderosa. Contudo 
conheço a programação orientada a objetos, que resolve boa parte dos 
problemas do Padrão de Projeto, e é incontestavelmente o "novo" 
paradigma e tendência da área de desenvolvimento.

O Linux para ser agradável como desktop teria que estar centralizado num 
único objetivo em comum. E a meta TERIA que ser o USUÁRIO final, não o 
PROGRAMADOR final.

-- 
Leonardo Pinto
leonardoprc#gmail dot com



Hugo Cisneiros (Eitch) escreveu:
>  É a famosa fina linha entre a segurança e a "usabilidade"
> do usuário.
>  Todos querem achar um ponto de equilíbrio: achar algo que deixe seguro
>  contra o usuário, ao mesmo tempo que deixe o usuário fazer o que
>  precisar se ele quiser. Pra mim isso vai mais da educação do usuário
>  (como citou o camarada acima), mas realmente pode-se chegar a um ponto
>  de equilíbrio aí.
>
>  O Leonardo tocou no ponto importante: não importa como o sistema
>  funciona por trás, para um usuário final/desktop. Ele quer que as
>  ferramentas de instalação/desinstalação funcionem, que os ícones das
>  suas aplicações estejam fáceis e disponíveis, que seus dispositivos
>  funcionem no seu computador e que seu sistema não fique travando toda
>  hora. É isso que o usuário quer, o resto é detalhe e capricho de
>  programador.
>
>  Na parte de servidor, como eu disse e como o Leonardo disse, o Linux é
>  muito forte porque o perfil dos administradores é mais de "usuário
>  avançado". Então ele se vira pra fazer as várias coisas. No desktop
>  isso é um pouco diferente. O Mac OS X realmente é um exemplo sólido de
>  um Unix voltado para o usuário final. E eu posso dizer com certeza que
>  isso seria possível no Linux se a gente não tivesse algumas vantagens
>  sobre o Mac OS X:
>
>  1. Pelo aspecto livre, não existe um padrão de API/implementação. Uns
>  gostam assim, outros gostam daquele jeito, e não existe uma interface
>  sólida para tudo. Isso divide esforços e acaba por afastar muitas
>  coisas "que seriam fáceis de fazer" dos desenvolvedores, concentrando
>  tudo nas pessoas que fazem cada distribuição.
>
>  2. Não existe uma empresa só que dita e mantém um foco. Esse também é
>  um dos motivos por qual não dá pra concentrar os esforços. Muda até
>  quando grandes empresas assumem a liderança, como a Canonical, Red Hat
>  e Novell. Mas não é nem um pouco certo isso.
>
>  3. Minha opinião pessoal: os softwares do Linux para desktop são, em
>  geral, mal feitos e não tem qualidade de software. Isso muda com o
>  tempo, mas eu ainda continuo achando que são ruins - muita qualidade
>  em alpha. Talvez precisasse de mais QA :( Lembrando que isso é uma
>  opinião bem radical, não levem muito em conta :P
>
>  E o problema agora é que: visto por outro lado, estas são vantagens:
>  temos a liberdade de escolher o que gostamos e como gostamos, não
>  ficamos preso a nada. Só que as vantagens, por outro lado, tem suas
>  coisas ruins também ;(

Evolução do Linux

[Leonardo Pinto]

Heitor Moraes escreveu:
>  Venho usando Linux no trabalho e OSX no meu Mac a alguns anos.
>  O computador desde 2006 é um modelo MacBookPro2,2.
>     
Você é um felizardo!!! No trabalho por enquanto estamos com Rwindows, 
mas breve estaremos reescrevendo o produto em JAVA, e passaremos a usar 
Linux. Aliás, estou com projeto para implantar Linux e virtualizar as 
máquinas de programação e suporte, porém o Linux (leia-se KDE) vem 
demonstrando baixa performance para a realidade do park de máquinas da 
empresa. Estou por experimentar o gOS (by Ubuntu/Debian)... Por enquanto 
até onde posso afirmar o meu acesso ao Mac é um tanto "restrito"... 
ueueue O:-)


>  Acho o OSX é um ótimo sistema para Desktop.
>  É lindo, rápido e fácil.
>     
Ótimo??? Ele é tudo de bom... Nunca ví coisa igual. É muuuuuito rápido. 
É nítido que é a metodologia de programação adotada no Mac é bem 
especial e que faz a diferença. Diferente do que estamos habituados. As 
vezes parece magia, como se consegue fazer muito mais com tanta 
"simplicidade".

>  Mas seguro ele não é.
>  Aquele cadeado que vive aberto nas preferências não me parece o bastante.
>     
Depende!!! Tenho um usuário que nomeei convidado (hehehe). Nele deixo 
rodando o aMule, o BitTorrent, etc... E não vejo esses cadeados 
abrirem-se assim... Já até fiz um teste de fogo com "rm -rf /*" que não 
fez estrago... Tem que rever os privilégios. Até o Linux mau configurado 
fará o mesmo.


>  De fato, parece um SO inocente da malícia e estupidez humanas.
>
>  http://blogs.zdnet.com/security/?p=2941
>     
É... Isso parece preocupante... Mas acredito que a Apple está tomando 
suas devidas providências e precauções...


>  PS: Meu Adium é muito mais bonito que meu GAIM.
>     
Hummmm, ele é muito lindo. Gracioso, só falta aceitar a vídeo conferência...


--
Leonardo Pinto
leonardoprc#gmail dot com

Evolução do Linux

[Heitor Moraes]

Agora que a gente transformou isso num chat, ai vão minhas observações. :D

> > Acho o OSX é um ótimo sistema para Desktop.
> > É lindo, rápido e fácil.
> >
>
>  Ótimo??? Ele é tudo de bom... Nunca ví coisa igual. É muuuuuito rápido. É
>  nítido que é a metodologia de programação adotada no Mac é bem especial e
>  que faz a diferença. Diferente do que estamos habituados. As vezes parece
>  magia, como se consegue fazer muito mais com tanta "simplicidade". 
Ele faz uso da aceleradora  de vídeo para manter o feedback tão eficiente.
O problema é que em games o desempenho cai bastante.

Joguei o Prey inteiro no OSX, enquanto o Doom 3 jogo normalmente no Linux.

O Prey num MacBook Pro C2D 2.33 com 2GB DDR2 e uma Radeon X1600
Mobility de 256MB, ficou com desempenho "pouco melhor" que o o Doom 3
no meu antigo Athlon de 1.8 com 1GB e uma GeForce FX5200 (AGP) de
128MB.

Peguei com um amigo o Doom 3 para OSX e comparei com meu Doom 3 para Linux.
A diferença é de 40 FPS com quedas para 20 para 60 FPS travados sempre
no sync no Linux a 1440x900.
Mesma resolução e mesmos efeitos.

Isso se repete com The Sims 2, CoD e demais.

> > Mas seguro ele não é.
> > Aquele cadeado que vive aberto nas preferências não me parece o bastante.
> >
>
>  Depende!!! Tenho um usuário que nomeei convidado (hehehe). Nele deixo
>  rodando o aMule, o BitTorrent, etc... E não vejo esses cadeados abrirem-se
>  assim... Já até fiz um teste de fogo com "rm -rf /*" que não fez estrago...
>  Tem que rever os privilégios. Até o Linux mau configurado fará o mesmo. 
Eu mantenho o cadeado de acesso as configurações de sistema fechado,
até precisar modificar.
E tenho uma conta com perfil administrador e duas restritas para uso diário.
Mas a grande maioria usa uma conta de administrador e mantêm o cadeado
aberto por conveniência.
De qualquer forma, um rm -rf /Applications pode ferrar muitos
aplicativos instalados quando rodando com o administrador habitual -
sem falar que tua máquina pode facilmente virar vetor de infecção.

Para isso mantenho uma cópia  do XP instalado com um monte de joguinhos.
Metade deles no meu Steam. :D

Evolução do Linux

[Gerente de Sistemas]

2009/4/6 Leonardo Pinto (Gmail) <leonardoprc(a)gmail.com&gt;

>  Heitor Moraes escreveu:
>
> > Venho usando Linux no trabalho e OSX no meu Mac a alguns anos.
> > O computador desde 2006 é um modelo MacBookPro2,2.
> >
> >
>
>  Você é um felizardo!!! No trabalho por enquanto estamos com Rwindows, mas
>  breve estaremos reescrevendo o produto em JAVA, e passaremos a 

JAVA

Esta é uma linguagem de computador que foi feita para aquecer a torradeira
antes de você chegar na cozinha.

Você já ouviram falar em Engenharia de Requisitos?

Imaginem uma reunião de levantamento de requisitos para criar a linguagem: o
que uma torradeira e uma máquina de coca-cola têm em comum para codificar o
acesso? De qualquer maneira, terei de pôr o pão, e retirar quando estiver
pronto, mas a torradeira vai enviar-me uma carta avisando que o pão está
pronto, e terei de ir buscar a lata de coca na máquina, que também vai me
avisar: e acabou o JAVA.

Se você quer usar o paradigma da orientação a objetos, sugiro esperar que
venha um SO orientado a objetos, ou você vai desperdiçar tôda aquela teoria
bonita em um SO que não sabe o quer fazer com aquilo, e vai ter de continuar
codificando o acesso ao SO SEM a OO. Mas não conheço SO em teoria, e
certamente não serei o mais capacitado para emitir parecer sôbre SO, uso o
conhecimento que adquiri no dia-a-dia.

Nem vou abordar o uso de Bancos de Dados Relacionais com JAVA (em OO?)
enquanto as linguagens de programação OaO instanciam os dados em objetos -
você pode tentar OCAMLDUCE, que pode criar os dados em arquivos XML, e em
JAVA você interrompe o ciclo produtivo de OO para fazer o estudo relacional
e gerar o banco, relacionar JAVA com o banco relacional e usar dados
relacionais na sua linguagem OO.
Com o se os dados não fôssem objetos, são linhas e colunas numa tabela.

Mas se você realmente quer tentar a OO, sugiro a primeira parada em
http://eiffel.com/, e reproduzo aqui um texto que você vai ler lá depois e
que separa o jôio do trigo em têrmos de programação OO:"

>  Eiffel Software is the pioneer of Design by Contract (DbC) and the
>  Component Revolution. The notion of DbC is central in the systematic
>  approach to software quality, as embodied in the Eiffel method and IDE
>  EiffelStudio <http://eiffel.com/products/studio/index.html>;.
>
>  DbC is a metaphor on how elements of a software system collaborate with
>  each other, on the basis of mutual *obligations* and * benefits*. The
>  metaphor comes from business life, where a "client" and a "supplier"
> agree
>  on a "contract" which documents that:
>
>     - The supplier must provide a certain product (obligation) and is
>     entitled to expect that the client has paid its fee (benefit).
>     - The client must pay the fee (obligation) and is entitled to get the
>     product (benefit).
>     - Both parties must satisfy certain obligations, such as laws and
>     regulations, applying to all contracts.
>
>  To programmers and the projects they work on, this guarantees that bugs
>  will be prevented by a well defined mechanism based on checks and balances.
>  For managers, DbC ensures that programming is done correctly. For customers,
>  it offers a label of quality, seriousness, and a job well done.
>  https://www2.eiffel.com/download/)";.
>  
Em JAVA, você faz a tal da refatoração.... depois do êrro acontecer.

A segunda parada em http://www.cduce.org/ocaml/, esta com uma vantagem
definitiva, a que você pode escrever código procedimental, oo e funcional
que a linguagem implementa, além de ter um compilador que quase se compara
ao C em desempenho, o que DEFINITIVAMENTE joga JAVA no lixo.

OCAMLDUCE implementa XML como objetos da linguagem, o que permite a você
usar o poder do XML como extensão da OCAML.

Não esqueça de tentar um banco de dados XML nativo, sedna, em
http://modis.ispras.ru/sedna/.

E em http://www.tcl.tk/software/tcltk/, que é a linguagem de escrita do
OpenACS, o que por si só já diz tudo: o melhor em serviço de hipertexto.

Você também pode conhecer ruby, que é muito interessante mas não compila.

Veja em http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B

C++ is a powerful but complex language, with a bias for performance-oriented
>  applications and libraries. The Java language was designed to be
> simpler
>  (and therefore easier to learn), but does not always provide full access to
>  the features and performance of the platform that the software runs on.
>  Conversely, the C++ standard libraries are simple, bordering on basic, while
>  theJava standard library <http://en.wikipedia.org/wiki/Standard_library>is
> considerably large for a standard library.
>  [2]<http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#cite_no...

Em http://www.jvoegele.com/software/langcomp.html você tem uma comparação
mais abrangente. Nesta tabela você, provavelmente, fará a sua escolha. Logo
após a tabela:

>  Eiffel, Smalltalk, and Ruby are all pure Object-Oriented languages,
>  supporting all six qualities listed above. Java claims to be a pure
>  Object-Oriented language, but by its inclusion of "basic" types that are not
>  objects, it fails to meet our fourth quality. It fails also to meet quality
>  five by implementing basic arithmetic as built-in operators, rather than
>  messages to objects.
>
>  C++ is considered to be a multi-paradigm language, of which one paradigm it
>  supports is Object-Orientation. Thus, C++ is not (nor does it contend to be)
>  a pure Object-Oriented language.
>  
O debate estático x dinâmico está lá.

O Design By Contract é o que as linguagens deveriam fazer antes para não ter
de refatorar, se é que estou usando a palavra certa.

AS COMPARAÇÕES

Dê uma olhada nesta comparação:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=oc...,
e depois, nesta:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=oc...,
ou
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=oc...,
e finalmente, em:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=fp...
.
Comparando SmartEiffel com OCAML:
http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=...
.

Não fique envorgonhado de usar BASIC:
http://www.scriptbasic.org/wiki/index.php?title=ScriptBasic:UsersGuide.


usar Linux. Aliás, estou com projeto para implantar Linux e virtualizar as
>  máquinas de programação e suporte, porém o Linux (leia-se KDE) vem
>  demonstrando baixa performance para a realidade do park de máquinas da
>  empresa. Estou por experimentar o gOS (by Ubuntu/Debian)... Por enquanto até
>  onde posso afirmar o meu acesso ao Mac é um tanto "restrito"... ueueue O:-)

Abandonei o KDE como ambiente preferencial pelo GNOME pelo que fizeram com o
KDE4: não se pode confiar nêles.


>   Acho o OSX é um ótimo sistema para Desktop.
> > É lindo, rápido e fácil.
> >
> >
>  
É, creio que depois de tentar o OpenBSD também vou partir para o MAC.
Talvez os dois, desde que um é aberto e o outro não, fico com os dois
melhores dos dois paradigmas... certo?


>  Ótimo??? Ele é tudo de bom... Nunca ví coisa igual. É muuuuuito rápido. É
>  nítido que é a metodologia de programação adotada no Mac é bem especial e
>  que faz a diferença. Diferente do que estamos habituados. As vezes parece
>  magia, como se consegue fazer muito mais com tanta "simplicidade".
>
>   Mas seguro ele não é.
> > Aquele cadeado que vive aberto nas preferências não me parece o bastante.
> >
> >
>
>  Depende!!! Tenho um usuário que nomeei convidado (hehehe). Nele deixo 

Clever...


>  rodando o aMule, o BitTorrent, etc... E não vejo esses cadeados
> abrirem-se
>  assim... Já até fiz um teste de fogo com "rm -rf /*" que não fez estrago...
>  Tem que rever os privilégios. Até o Linux mau configurado fará o mesmo. 

E ainda tem a virtualização, com o QEMU ou outro. Basta criar uma virtual
com qualquer Linux, no MAC, e entrar na internet....


>   De fato, parece um SO inocente da malícia e estupidez humanas.
> >
> > http://blogs.zdnet.com/security/?p=2941
> >
> >
>
>  É... Isso parece preocupante... Mas acredito que a Apple está tomando suas
>  devidas providências e precauções...
>  
>   PS: Meu Adium é muito mais bonito que meu GAIM.
> >
> >
>
>  Hummmm, ele é muito lindo. Gracioso, só falta aceitar a vídeo
>  conferência... 

Que tal ekiga.net?
Você pode falar comigo em SIP:[e-mail] ou em ViaBsb(a)Ekiga.net.

Meu grande problema têm sido a escolha de uma Plataforma de Modelagem, com
ferramentas que modelem o sistema em OO que gerem OO, uma Plataforma de
Dados, com ferramentas em OO que gerem dados em OO e uma linguagem de
programação em OO, que gere o código em OO.

Creio que até tem tudo isto por aí, mas não conversam muito bem.
Posso estar enganado, afinal, tem muita coisa aí fora e, certamente, não vi
tudo de tudo.

Mas minha visão de paraíso é uma Plataforma de Modelagem de Sistema que use
linguagem OO para criar dados instanciados em objetos, provavelmente em XML,
tudo incluído ou conversando um com o outro.


>  --
>  Leonardo Pinto
>  leonardoprc#gmail dot com
>
>
>
>
>  --
>  Fedora-users-br mailing list
>  Fedora-users-br(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-users-br
>
>  

-- 
EquipeLinux EM EquipeLinux.com
EquipeLinux EM Skype.com