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.
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@gmail.com
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@EquipeLinux.com EquipeLinux@Skype.com
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
2009/3/27 Cristiano Furtado jasonnfedora@gmail.com:
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!
2009/4/2 Hugo Cisneiros (Eitch) hugo@devin.com.br
2009/3/27 Cristiano Furtado jasonnfedora@gmail.com:
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
2009/4/3 Marcio Carneiro viabsb@gmail.com:
O problema são os tais "macêtes". Você tem um passo-a-passo para fazer a instalação do flash, java, mplayer, vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?
Tem vários por aí na Internet.
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?
2009/4/3 Hugo Cisneiros (Eitch) hugo@devin.com.br
2009/4/3 Marcio Carneiro viabsb@gmail.com:
O problema são os tais "macêtes". Você tem um passo-a-passo para fazer a instalação do flash, java,
mplayer,
vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?
Tem vários por aí na Internet.
Obrigado.
E quanto aos programas compilados em i386 que não aceitam rodar em uma arquitetura 64?
Só conheço o Flash e o *plugin* do Java pro Firefox.
Creio ter lido que o flash para 64 já está disponível.
Quanto tempo teremos de esperar para os programas serem compilados em 64?
E
a compatibilidade?
Faz vários anos que as distribuições Linux vem com *todos* os pacotes compilados para x86_64. Só no escritório tem 8 servidores rodando CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho de formatar o disco novamente.
Tenho, sempre, muitos problemas com bibliotecas. Nêste momento estou com problemas com o FC10, que perdeu alguma
biblioteca
em python, provavelmente, e não consigo acessar o log in no kde. Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE, temos o KDE3 e uma criatura completamente nova, que deveria ter vida
própria
mas não acabar com o KDE.
Nisso eu concordo, mas essa criatura nova está evoluindo e um dia ficará boa ;-) Se não ficar, a concorrência come.
Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para o usuário, é o que existe funcionar e ser estável. É certo que você poderá dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no futuro. Tem de haver um ponto no meio em que uma distro SEJA estável e não haja comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma nova criatura. Talvez uma distro devêsse ter os dois KDE.
Com a facilidade com que os RedHat alike perdem bibliotecas
indispensáveis
ao SO e, depois, para re-instalar, impedem a instalação, alegando que um programa já existe e não pode ser re-escrito, ou que uma biblioteca é necessária mas não está disponível e você tem de formatar o HD novamente, parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por exemplo.
Sinceramente não sei o que você faz pra acontecer essas coisas... Eu nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O que eu vejo são pessoas instalando as coisas "natoralmente" e quebrando o sistema inteiro. Aí não tem sistema que aguente :P
Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc. Pedia uma lib que não podia ser instalada porque conflitava com outra existente. Quando removi esta, foi algo da dependência que afetava o SO. E o glibc foi corrompido, ou removido dentro da tal dependência.
Para instalar o galeon é necessário o mozilla e outras dependências, pode ter sido tentando instalar o galeon.
Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um
sistema
de gerenciamento de pacotes com um nome de distribuição.
Acho que você deve estar confundindo o termo "distribuição"... Leitura recomendada:
http://www.devin.com.br/intro_linux/ Parte "Distribuições"
Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com o que escrevi. Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o usuário ter problemas em instalar programas fora do gerenciador de pacotes. O sistema de gerenciamento de pacotes é muito bom para admistrar a distribuição mas não o Linux que o usuário instala.
"Para usar todas as ferramentas, ele teve que construí-las especificadamente para o seu kernel e uní-las para apresentar ao usuário uma interface para o uso do computador. Enquanto o kernel trabalhava com o hardware, as ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."
Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria e instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em separado aos pacotes que são usados pelo usuário. A liguagem python é NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo, o yum. Se houvesse um python somente para o kernel e outro instalado para o usuário, não haveria o risco.
Não entendi a parte do "E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P", pois a referência poderia ser com uma ligação dinâmica ao binário, e não ao binário que será necessário ao kernel. É o recurso que o GoboLinux usa, todos os programas binários instalados na árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas não estão lá.
Creio que o GoboLinux é a salvação do Linux.
LOL :-)
Tento esclarecer. Não cria uma dependência de um sistema de gerenciamento de pacotes e simplifica a inclusão e remoção de programas no SO. Você poderá qualquer pacote de fontes e instalar no diretório de programas.
Mas vai demorar até uma edição completa com as receitas necessárias à conversão facilitada.
Creio que o pessoal do GoboLinux deveria partir para a radicalização, ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a proposta do Gobo.
E assim quebrar milhares de programas que são feitos para funcionar de uma forma e ir contra milhares de programadores e padrões do mundo inteiro. Não é a melhor opção.
Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para o kernel, onde estariam o fonte do kernel e de TODOS os programas
necessários
para compilação e instalação do kernel.
LOL :-)
Por quê o lol? Ou você não entendeu?
Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS dois para o usuário, assim, não haveria risco de eliminar um programa ou biblioteca necessários ao kernel quando um usuário ou o próprio root apagasse alguma coisa.
E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P
Não jogue fora todas as vantagens de programas dinamicamente linkados...
Então você não entendeu. Não se trata disto, exatamente por validar isto é que sugiro que os programas necessários ao kernel devem estar fora da ação do usuário, que poderá instalar e remover qualquer programa sem afetar os que são necessários ao kernel. O kernel fica protegido na memória mas não no HD.
Considero uma grande BURRICE esta COMPLETA dependência do kernel da
árvore
de diretórios do usuário.
Ahnnnn???
Posso ter me expressado mal: a dependência do kernel de linguagens e programas que estão disponíveis ao usuário para remover. Melhorou?
Fica o pedido de socorro para instalar os tais macêtes.
Com relação ao kernel, minha sugestão é partir para a compilação do
kernel
com o OCAML DUCE.
LOL :-)
Nem mesmo uma razão para não fazer ou você não conhece a linguagem?
É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei até a entender que sou chato. Mas é, eu sou chato mesmo! :P
Sinceramente, você tem umas coisas muito loucas na cabeça, por favor reveja seus conceitos, tem muita coisa que você diz aí que nem parece que sabe do que tá falando :(
Quando o índio que viu a primeira caravela disse aos demais o que via também foi chamado de louco e via coisas que ninguém via: e era verdade.
Se você não vê algo que alguém disse que viu não diga que êle é louco, isto é rude, mal-educado.
Quando você me manda rever meus conceitos é autoritário e prepotente, aliás, "feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".
Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como não são Orientados a Objetos, o que reduz o usuário a objeto sem interêsse. Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO procedimental (se é esta a palavra).
Eu concordo sobre a parte dos "macetes", mas veja que isso não é problema do Linux. Isso é problema dos fabricantes dos programas proprietários. Esses macetes aí geralmente têm de ser feitos com programas que não fazem parceria com a distribuição, como o Flash e/ou Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%, esses macetes *nunca* iriam ser precisos, pois os fabricantes iam correr atrás.
Acredite, nos outros sistemas como Windows e Mac também é assim. A diferença é que eles são o foco principal. Agora vai tentar instalar coisas de Linux em outros sistemas, é mais fácil?
Esclareceu, concordo.
Obirgado pelos esclarecimentos. Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se você não concordar com algo que escrevo, é livre para discordar, e dizer. Também é livre para não dizer, mas não tem a liberdade que se deu.
-- []'s Hugo www.devin.com.br
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
2009/4/4 Marcio Carneiro viabsb@gmail.com:
E quanto aos programas compilados em i386 que não aceitam rodar em uma arquitetura 64?
Só conheço o Flash e o *plugin* do Java pro Firefox.
Creio ter lido que o flash para 64 já está disponível.
Alfa, não conta tanto assim. Mas é uma ótima notícia de que virá.
Quanto tempo teremos de esperar para os programas serem compilados em 64? E a compatibilidade?
Faz vários anos que as distribuições Linux vem com *todos* os pacotes compilados para x86_64. Só no escritório tem 8 servidores rodando CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho de formatar o disco novamente.
E...? Na sua pergunta, me pareceu que você estava perguntando sobre quanto tempo deveríamos esperar pelos programas já serem compilados para 64-bits, sendo que eu respondi que eles já o são, faz anos, com algumas excessões que eu também disse.
Tenho, sempre, muitos problemas com bibliotecas. Nêste momento estou com problemas com o FC10, que perdeu alguma biblioteca em python, provavelmente, e não consigo acessar o log in no kde. Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE, temos o KDE3 e uma criatura completamente nova, que deveria ter vida própria mas não acabar com o KDE.
Nisso eu concordo, mas essa criatura nova está evoluindo e um dia ficará boa ;-) Se não ficar, a concorrência come.
Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para o usuário, é o que existe funcionar e ser estável. É certo que você poderá dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no futuro. Tem de haver um ponto no meio em que uma distro SEJA estável e não haja comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma nova criatura. Talvez uma distro devêsse ter os dois KDE.
Eu nunca vou dizer que qualquer coisa será totalmente estável. Eu quis dizer que o KDE4 (IMO) ainda está muito "xulo" e tem muito o que melhorar pra chegar aos pés do 3.5. Mas essa discussão já é velha e desafasada: eu já sei que o KDE4 vai ficar legal lá pelo 4.4.
Em contrapartida ao que você disse, tem algumas distros bem estáveis sim. Ou você acha que um monte de super-computadores e milhares de servidores rodam distribuições Linux sendo instáveis? Paramos pra pensar: será que algumas dessas coisas 'instáveis' não são culpa de BIOS?
Não vou nem falar do Fedora aqui porque a proposta da distribuição não tem como prioridade ser estável, e sim ter mais funcionalidades e tudo ser "cutting-edge". O KDE seguiu a mesma direção (aliás, acho que ele sempre foi assim), só mudando quando sua "minor version" fica mais distante (por isso eu disse lá pelo 4.4).
Com a facilidade com que os RedHat alike perdem bibliotecas indispensáveis ao SO e, depois, para re-instalar, impedem a instalação, alegando que um programa já existe e não pode ser re-escrito, ou que uma biblioteca é necessária mas não está disponível e você tem de formatar o HD novamente, parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por exemplo.
Sinceramente não sei o que você faz pra acontecer essas coisas... Eu nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O que eu vejo são pessoas instalando as coisas "natoralmente" e quebrando o sistema inteiro. Aí não tem sistema que aguente :P
Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc. Pedia uma lib que não podia ser instalada porque conflitava com outra existente. Quando removi esta, foi algo da dependência que afetava o SO. E o glibc foi corrompido, ou removido dentro da tal dependência.
Para instalar o galeon é necessário o mozilla e outras dependências, pode ter sido tentando instalar o galeon.
Ou seja, não culpe a distribuição por algo que você fez de errado. Se você tentou fazer isso no Fedora, pode ter certeza que utilizou um repositório de terceiro e não o da distribuição. Depois imagino que forçou a remoção da biblioteca de modo errôneo e começou a afetar o SO. Como eu disse: não tem sistema a prova de usuário: só se o sistema não deixasse o usuário fazer quase nada.
Que nem eu há muito tempo atrás, fui fazer uma atualização de glibc na distribuição e acabei com tudo. Tive que reinstalar.
Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um sistema de gerenciamento de pacotes com um nome de distribuição.
Acho que você deve estar confundindo o termo "distribuição"... Leitura recomendada:
http://www.devin.com.br/intro_linux/ Parte "Distribuições"
Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com o que escrevi. Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o usuário ter problemas em instalar programas fora do gerenciador de pacotes. O sistema de gerenciamento de pacotes é muito bom para admistrar a distribuição mas não o Linux que o usuário instala.
Você falou que não existe uma distribuição e sim um gerenciador de pacotes. Falar isso é ignorar todo o trabalho que a distribuição tem de pegar os programas e montá-los de forma legal, colocar um instalador pra facilitar a vida do usuário, fornecer atualizações, personalizações, kernels para situações especiais, e inclusive colocar um gerenciador de pacotes para facilitar todas essas tarefas tanto para os desenvolvedores, quanto para os usuários.
Falar que uma distribuição é apenas um gerenciador de pacotes é dose.
E instalar pacotes fora do padrão da distribuição é um problema de qualquer outro sistema. Os gerenciadores de pacotes foram criados para evitar a "bagunça" que se faz quando se instala sem indexar os arquivos que foram espalhados: com o tempo eles vão acumulando no sistema e você nem sabe onde estão e o que fazem, isso gera um "bloat" no sistema com o tempo. É assim no Linux, é assim no Windows (muito mais, porque eles não tem controle sobre as milhões de aplicações que têm de ser instaladas separadas e cada fabricante instala do jeito que lhe for mais conveniente), é assim com qualquer outro sistema.
Mesmo que você siga o conceito de colocar todos os programas linkados estaticamente, sempre vai haver um ponto de falha provavel, por exemplo, você pode instalar uma própria glibc mais nova e quebrar qualquer chamada de sistema que esses programas utilizam. Ou, tenta instalar um driver do Windows 98 no Windows XP, sei lá.
"Para usar todas as ferramentas, ele teve que construí-las especificadamente para o seu kernel e uní-las para apresentar ao usuário uma interface para o uso do computador. Enquanto o kernel trabalhava com o hardware, as ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."
Exatamente ;-)
Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria e instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em separado aos pacotes que são usados pelo usuário. A liguagem python é NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo, o yum. Se houvesse um python somente para o kernel e outro instalado para o usuário, não haveria o risco.
Não entendi a parte do "E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P", pois a referência poderia ser com uma ligação dinâmica ao binário, e não ao binário que será necessário ao kernel. É o recurso que o GoboLinux usa, todos os programas binários instalados na árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas não estão lá.
É isso que eu quis dizer quando eu pensei que você não sabia muito bem o que tava falando. Sinto lhe informar, mas o GoboLinux não faz nenhum milagre não. O que o GoboLinux faz (e que é interessante mesmo) é re-organizar onde ficam as localizações dos arquivos dos programas e bibliotecas instaladas no sistema. Isso não elimina de forma alguma as dependências entre eles. Os programas não são todos linkados estaticamente. Se você remover algumas coisas, as outras vão pifar.
Sobre a biblioteca C, o que quero dizer é que todo comando/programa usa essa biblioteca para alocar memória por exemplo. Ela faz a interface com o kernel. Se você removê-la ou atualizá-la sem cuidado e sem prestar atenção em todas as aplicações do sistema, você pode quebrar esse sistema. Felizmente a gente não passa por isso porque as distribuições cuidam dessa parte mais complicada pros usuários.
Quando se tem um gerenciador de pacotes, não importa a localização dos arquivos, eles estão sempre indexados e podem ser removidos/atualizados de forma correta sem deixar resquícios. Por isso eu sempre achei essa localização de arquivos muito irrelevante.
Creio que o GoboLinux é a salvação do Linux.
LOL :-)
Tento esclarecer. Não cria uma dependência de um sistema de gerenciamento de pacotes e simplifica a inclusão e remoção de programas no SO. Você poderá qualquer pacote de fontes e instalar no diretório de programas.
Você pode fazer isso em qualquer distribuição. Sério, sabia que você pode instalar vários Pythons na mesma máquina? Basta, na hora de compilar, dizer pra ele instalar numa árvore de diretórios diferente. Ah, e é isso que o GoboLinux faz. Isso não impede de você fazer também.
Inclusive, isso me faz lembrar que o próprio Debian faz isso: ele tem algumas versões múltiplas, o exemplo mais recente que vi foi que você pode instalar, via gerenciador de pacotes, o php4 e o php5.
Mas vai demorar até uma edição completa com as receitas necessárias à conversão facilitada.
Creio que o pessoal do GoboLinux deveria partir para a radicalização, ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a proposta do Gobo.
E assim quebrar milhares de programas que são feitos para funcionar de uma forma e ir contra milhares de programadores e padrões do mundo inteiro. Não é a melhor opção.
Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para o kernel, onde estariam o fonte do kernel e de TODOS os programas necessários para compilação e instalação do kernel.
LOL :-)
Por quê o lol? Ou você não entendeu?
O LOL foi porque a idéia é muito sem noção (IMO), e por isso eu ri. É como dizer para o mundo que agora todos os servidores de DNS da Internet, cada um deles deve ter TODAS as informações sobre todos os hosts do mundo. Quando você fala um exemplo ou outro, até que não ficaria tão ruim, assim como se a Internet tivesse 100 domínios. Agora imagine quando se fala de belos milhões de programas.
Se formos seguir esse padrão que você disse, todo programa deveria ter suas bibliotecas e dependências todas linkadas estaticamente. Isso, em sistemas modernos é impraticável, a não ser que você queira perder espaço e memória exorbitantes. Significaria que cada um dos comandos: ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais simples teriam que ter dentro da sua compilação todas suas dependências:
madoka:~$ ldd /bin/ls linux-gate.so.1 => (0xb7f40000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7f1f000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7f06000) libacl.so.1 => /lib/libacl.so.1 (0xb7efe000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da3000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d8a000) /lib/ld-linux.so.2 (0xb7f41000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d86000) libattr.so.1 => /lib/libattr.so.1 (0xb7d81000)
Multiplique agora todas essas bibliotecas por milhares de comandos e milhões de programas por aí. Não seria muito legal né? E quando fosse atualizar uma dessas bibliotecas? Teria que atualizar centenas ou milhares de compilações!
O que eu acho que você tá pegando errado é que você só está considerando a localização dos programas. Onde ficam seus arquivos. Mas não é só isso que existe por trás de um funcionamento de um sistema operacional. Tem muita coisa por trás, acho melhor você dar uma pesquisada nisso (já enfatizei alguns pontos).
Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS dois para o usuário, assim, não haveria risco de eliminar um programa ou biblioteca necessários ao kernel quando um usuário ou o próprio root apagasse alguma coisa.
E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P
Não jogue fora todas as vantagens de programas dinamicamente linkados...
Então você não entendeu. Não se trata disto, exatamente por validar isto é que sugiro que os programas necessários ao kernel devem estar fora da ação do usuário, que poderá instalar e remover qualquer programa sem afetar os que são necessários ao kernel. O kernel fica protegido na memória mas não no HD.
Eu quero ter a liberdade de atualizar meu kernel quando quiser. Não quero que ele fique fora de minha ação não. Sobre isso, você tem que reclamar das distribuições que fazem as dependências de pacotes errôneamente. E acredite, pra algo ter dependência de kernel nas distribuições atuais, ele tem que *realmente* depender do kernel. Se um programa tem relação com o kernel diretamente, ou o programa está errado ou então tinha que ser ligado mesmo, não tem segredo!
Mas pra esclarecer isso, você teria que realmente me dizer exemplos concretos.
A única coisa que eu acho uma grande desvantagem do kernel Linux é a dependência de módulos do kernel ligados a versão/compilação específica de uma versão de kernel. Mas esse é outro assunto.
Considero uma grande BURRICE esta COMPLETA dependência do kernel da árvore de diretórios do usuário.
Ahnnnn???
Posso ter me expressado mal: a dependência do kernel de linguagens e programas que estão disponíveis ao usuário para remover. Melhorou?
As distribuições definem algo como base do sistema por uma razão: são aplicações-chave que não devem ser nunca removidos pelo usuário. Eles tem a liberdade de fazer isso se quiserem (mais uma vez, eu prezo por essa liberdade), mas se eles fizerem está errado! Aí é culpa do usuário!
Olha as dependências de um kernel antigo do Fedora 8:
$ rpm -qR kernel-2.6.26.3-14.fc8 rpmlib(VersionedDependencies) <= 3.0.3-1 fileutils module-init-tools initscripts >= 8.11.1-1 mkinitrd >= 6.0.9-7 /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Sinceramente, se o usuário não tiver essas coisas aí, é porque ele não tem nada mesmo.
Fica o pedido de socorro para instalar os tais macêtes.
Com relação ao kernel, minha sugestão é partir para a compilação do kernel com o OCAML DUCE.
LOL :-)
Nem mesmo uma razão para não fazer ou você não conhece a linguagem?
Não conheço, não posso opiniar. Eu ri porque você está sugerindo criar um sistema operacional do zero. "Talk is cheap, show me the code". Ainda mais, a linguagem não importa na maioria das vezes, o que importa é o programador e seu design de código. Pode ser a linguagem mais perfeita, um programador ruim pode fazer besteira do mesmo jeito. Falar que ficaria muito melhor utilizando linguagem X é desconsiderar todas essas variáveis.
É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei até a entender que sou chato. Mas é, eu sou chato mesmo! :P
Sinceramente, você tem umas coisas muito loucas na cabeça, por favor reveja seus conceitos, tem muita coisa que você diz aí que nem parece que sabe do que tá falando :(
Quando o índio que viu a primeira caravela disse aos demais o que via também foi chamado de louco e via coisas que ninguém via: e era verdade.
Se você não vê algo que alguém disse que viu não diga que êle é louco, isto é rude, mal-educado.
Interpreta-se como quer. Eu ainda acho suas idéias loucas. Você pode não ser louco (e nunca disse isso), mas pra mim tem idéias loucas e equivocadas. Ao invés de achar isso rude e mal-educado, instigue-se, use a cabeça e prove-me que suas idéias não são loucas! Senão como você vai convencer o resto do mundo?
Quando você me manda rever meus conceitos é autoritário e prepotente, aliás, "feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".
Eu seria autoritário se dissesse "mude seus conceitos". Quando eu falo "reveja seus conceitos", quero dizer pra você rever mesmo: pensar no que você tá falando ao invés de continuar falando. E essa "feature" aí que você disse não é dos unixers, é de qualquer programador idiota. A grande "feature" do código-aberto é quando a gente faz qualquer coisa, libera o código e todos podem criticar, opinar e ajudar/atrapalhar.
Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como não são Orientados a Objetos, o que reduz o usuário a objeto sem interêsse. Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO procedimental (se é esta a palavra).
O mundo é grande e existem diversos tipos de usuários. O Linux é orientado para usuários SIM, só não todos. Se você dissesse que o Linux não é orientado a usuário "final", eu concordo até certa parte. Se você diz que Linux não é orientado a usuário "gamer", eu concordo 100%. Mas tudo isso é relativo não?
Linux é orientado para os usuários corporativos e para os servidores, mas isso também está mudando: se chama crescimento/expansão. Infelizmente nosso crescimento nessa área é uma porcaria :)
Eu concordo sobre a parte dos "macetes", mas veja que isso não é problema do Linux. Isso é problema dos fabricantes dos programas proprietários. Esses macetes aí geralmente têm de ser feitos com programas que não fazem parceria com a distribuição, como o Flash e/ou Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%, esses macetes *nunca* iriam ser precisos, pois os fabricantes iam correr atrás.
Acredite, nos outros sistemas como Windows e Mac também é assim. A diferença é que eles são o foco principal. Agora vai tentar instalar coisas de Linux em outros sistemas, é mais fácil?
Esclareceu, concordo.
E a única vantagem que a gente tem disso daí é que não existem vírus eficientes e bem difundidos pra Linux :P
Obirgado pelos esclarecimentos. Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se você não concordar com algo que escrevo, é livre para discordar, e dizer. Também é livre para não dizer, mas não tem a liberdade que se deu.
\o/
2009/4/4 Hugo Cisneiros (Eitch) hugo@devin.com.br
2009/4/4 Marcio Carneiro viabsb@gmail.com:
E quanto aos programas compilados em i386 que não aceitam rodar em uma arquitetura 64?
Só conheço o Flash e o *plugin* do Java pro Firefox.
Creio ter lido que o flash para 64 já está disponível.
Alfa, não conta tanto assim. Mas é uma ótima notícia de que virá.
Quanto tempo teremos de esperar para os programas serem compilados em 64? E a compatibilidade?
Faz vários anos que as distribuições Linux vem com *todos* os pacotes compilados para x86_64. Só no escritório tem 8 servidores rodando CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha pergunta inicial era se é possível fazer a atualização com o 64 ou se
tenho
de formatar o disco novamente.
E...? Na sua pergunta, me pareceu que você estava perguntando sobre quanto tempo deveríamos esperar pelos programas já serem compilados para 64-bits, sendo que eu respondi que eles já o são, faz anos, com algumas excessões que eu também disse.
Tenho, sempre, muitos problemas com bibliotecas. Nêste momento estou com problemas com o FC10, que perdeu alguma biblioteca em python, provavelmente, e não consigo acessar o log in no kde. Com o tal do plasma e a completa mudança no KDE, não existe mais o
KDE,
temos o KDE3 e uma criatura completamente nova, que deveria ter vida própria mas não acabar com o KDE.
Nisso eu concordo, mas essa criatura nova está evoluindo e um dia ficará boa ;-) Se não ficar, a concorrência come.
Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa
para
o usuário, é o que existe funcionar e ser estável. É certo que você
poderá
dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE
no
futuro. Tem de haver um ponto no meio em que uma distro SEJA estável e não haja comprometimento com os próximos avanços, por isto me referi ao KDE4 como
uma
nova criatura. Talvez uma distro devêsse ter os dois KDE.
Eu nunca vou dizer que qualquer coisa será totalmente estável. Eu quis dizer que o KDE4 (IMO) ainda está muito "xulo" e tem muito o que melhorar pra chegar aos pés do 3.5. Mas essa discussão já é velha e desafasada: eu já sei que o KDE4 vai ficar legal lá pelo 4.4.
Em contrapartida ao que você disse, tem algumas distros bem estáveis sim. Ou você acha que um monte de super-computadores e milhares de servidores rodam distribuições Linux sendo instáveis? Paramos pra pensar: será que algumas dessas coisas 'instáveis' não são culpa de BIOS?
Não vou nem falar do Fedora aqui porque a proposta da distribuição não tem como prioridade ser estável, e sim ter mais funcionalidades e tudo ser "cutting-edge". O KDE seguiu a mesma direção (aliás, acho que ele sempre foi assim), só mudando quando sua "minor version" fica mais distante (por isso eu disse lá pelo 4.4).
Com a facilidade com que os RedHat alike perdem bibliotecas indispensáveis ao SO e, depois, para re-instalar, impedem a instalação, alegando que
um
programa já existe e não pode ser re-escrito, ou que uma biblioteca é necessária mas não está disponível e você tem de formatar o HD novamente, parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por exemplo.
Sinceramente não sei o que você faz pra acontecer essas coisas... Eu nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O que eu vejo são pessoas instalando as coisas "natoralmente" e quebrando o sistema inteiro. Aí não tem sistema que aguente :P
Realmente não lembro do programa, pode ter sido um MM como o mplayer ou
vlc.
Pedia uma lib que não podia ser instalada porque conflitava com outra existente. Quando removi esta, foi algo da dependência que afetava o SO.
E o
glibc foi corrompido, ou removido dentro da tal dependência.
Para instalar o galeon é necessário o mozilla e outras dependências, pode ter sido tentando instalar o galeon.
Ou seja, não culpe a distribuição por algo que você fez de errado. Se você tentou fazer isso no Fedora, pode ter certeza que utilizou um repositório de terceiro e não o da distribuição. Depois imagino que forçou a remoção da biblioteca de modo errôneo e começou a afetar o SO. Como eu disse: não tem sistema a prova de usuário: só se o sistema não deixasse o usuário fazer quase nada.
Que nem eu há muito tempo atrás, fui fazer uma atualização de glibc na distribuição e acabei com tudo. Tive que reinstalar.
Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um sistema de gerenciamento de pacotes com um nome de distribuição.
Acho que você deve estar confundindo o termo "distribuição"... Leitura recomendada:
http://www.devin.com.br/intro_linux/ Parte "Distribuições"
Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo
com
o que escrevi. Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes
e o
usuário ter problemas em instalar programas fora do gerenciador de
pacotes.
O sistema de gerenciamento de pacotes é muito bom para admistrar a distribuição mas não o Linux que o usuário instala.
Você falou que não existe uma distribuição e sim um gerenciador de pacotes. Falar isso é ignorar todo o trabalho que a distribuição tem de pegar os programas e montá-los de forma legal, colocar um instalador pra facilitar a vida do usuário, fornecer atualizações, personalizações, kernels para situações especiais, e inclusive colocar um gerenciador de pacotes para facilitar todas essas tarefas tanto para os desenvolvedores, quanto para os usuários.
Falar que uma distribuição é apenas um gerenciador de pacotes é dose.
E instalar pacotes fora do padrão da distribuição é um problema de qualquer outro sistema. Os gerenciadores de pacotes foram criados para evitar a "bagunça" que se faz quando se instala sem indexar os arquivos que foram espalhados: com o tempo eles vão acumulando no sistema e você nem sabe onde estão e o que fazem, isso gera um "bloat" no sistema com o tempo. É assim no Linux, é assim no Windows (muito mais, porque eles não tem controle sobre as milhões de aplicações que têm de ser instaladas separadas e cada fabricante instala do jeito que lhe for mais conveniente), é assim com qualquer outro sistema.
Mesmo que você siga o conceito de colocar todos os programas linkados estaticamente, sempre vai haver um ponto de falha provavel, por exemplo, você pode instalar uma própria glibc mais nova e quebrar qualquer chamada de sistema que esses programas utilizam. Ou, tenta instalar um driver do Windows 98 no Windows XP, sei lá.
"Para usar todas as ferramentas, ele teve que construí-las
especificadamente
para o seu kernel e uní-las para apresentar ao usuário uma interface para
o
uso do computador. Enquanto o kernel trabalhava com o hardware, as ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."
Exatamente ;-)
Isto vem de encontro ao que eu escrevi. O conjunto de programas que
cria
e instala o kernel poderia (eu penso que sim) estar no pacote do kernel,
em
separado aos pacotes que são usados pelo usuário. A liguagem python é NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por
exemplo,
o yum. Se houvesse um python somente para o kernel e outro instalado
para o
usuário, não haveria o risco.
Não entendi a parte do "E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória
e o
sistema iria explodir :P", pois a referência poderia ser com uma ligação dinâmica ao binário, e não ao binário que será necessário ao kernel. É o recurso que o GoboLinux usa, todos os programas binários instalados
na
árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX,
mas
não estão lá.
É isso que eu quis dizer quando eu pensei que você não sabia muito bem o que tava falando. Sinto lhe informar, mas o GoboLinux não faz nenhum milagre não. O que o GoboLinux faz (e que é interessante mesmo) é re-organizar onde ficam as localizações dos arquivos dos programas e bibliotecas instaladas no sistema. Isso não elimina de forma alguma as dependências entre eles. Os programas não são todos linkados estaticamente. Se você remover algumas coisas, as outras vão pifar.
Sobre a biblioteca C, o que quero dizer é que todo comando/programa usa essa biblioteca para alocar memória por exemplo. Ela faz a interface com o kernel. Se você removê-la ou atualizá-la sem cuidado e sem prestar atenção em todas as aplicações do sistema, você pode quebrar esse sistema. Felizmente a gente não passa por isso porque as distribuições cuidam dessa parte mais complicada pros usuários.
Quando se tem um gerenciador de pacotes, não importa a localização dos arquivos, eles estão sempre indexados e podem ser removidos/atualizados de forma correta sem deixar resquícios. Por isso eu sempre achei essa localização de arquivos muito irrelevante.
Creio que o GoboLinux é a salvação do Linux.
LOL :-)
Tento esclarecer. Não cria uma dependência de um sistema de gerenciamento de pacotes e simplifica a inclusão e remoção de programas no SO. Você poderá qualquer pacote de fontes e instalar no diretório de
programas.
Você pode fazer isso em qualquer distribuição. Sério, sabia que você pode instalar vários Pythons na mesma máquina? Basta, na hora de compilar, dizer pra ele instalar numa árvore de diretórios diferente. Ah, e é isso que o GoboLinux faz. Isso não impede de você fazer também.
Inclusive, isso me faz lembrar que o próprio Debian faz isso: ele tem algumas versões múltiplas, o exemplo mais recente que vi foi que você pode instalar, via gerenciador de pacotes, o php4 e o php5.
Mas vai demorar até uma edição completa com as receitas necessárias à conversão facilitada.
Creio que o pessoal do GoboLinux deveria partir para a radicalização, ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a proposta do Gobo.
E assim quebrar milhares de programas que são feitos para funcionar de uma forma e ir contra milhares de programadores e padrões do mundo inteiro. Não é a melhor opção.
Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE
para
o kernel, onde estariam o fonte do kernel e de TODOS os programas necessários para compilação e instalação do kernel.
LOL :-)
Por quê o lol? Ou você não entendeu?
O LOL foi porque a idéia é muito sem noção (IMO), e por isso eu ri. É como dizer para o mundo que agora todos os servidores de DNS da Internet, cada um deles deve ter TODAS as informações sobre todos os hosts do mundo. Quando você fala um exemplo ou outro, até que não ficaria tão ruim, assim como se a Internet tivesse 100 domínios. Agora imagine quando se fala de belos milhões de programas.
Se formos seguir esse padrão que você disse, todo programa deveria ter suas bibliotecas e dependências todas linkadas estaticamente. Isso, em sistemas modernos é impraticável, a não ser que você queira perder espaço e memória exorbitantes. Significaria que cada um dos comandos: ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais simples teriam que ter dentro da sua compilação todas suas dependências:
madoka:~$ ldd /bin/ls linux-gate.so.1 => (0xb7f40000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7f1f000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7f06000) libacl.so.1 => /lib/libacl.so.1 (0xb7efe000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da3000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d8a000) /lib/ld-linux.so.2 (0xb7f41000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d86000) libattr.so.1 => /lib/libattr.so.1 (0xb7d81000)
Multiplique agora todas essas bibliotecas por milhares de comandos e milhões de programas por aí. Não seria muito legal né? E quando fosse atualizar uma dessas bibliotecas? Teria que atualizar centenas ou milhares de compilações!
O que eu acho que você tá pegando errado é que você só está considerando a localização dos programas. Onde ficam seus arquivos. Mas não é só isso que existe por trás de um funcionamento de um sistema operacional. Tem muita coisa por trás, acho melhor você dar uma pesquisada nisso (já enfatizei alguns pontos).
Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS dois para o usuário, assim, não haveria risco de eliminar um programa
ou
biblioteca necessários ao kernel quando um usuário ou o próprio root apagasse alguma coisa.
E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P
Não jogue fora todas as vantagens de programas dinamicamente linkados...
Então você não entendeu. Não se trata disto, exatamente por validar isto é que sugiro que os programas necessários ao kernel devem estar fora da ação do usuário, que poderá instalar e remover qualquer programa sem afetar os que são necessários ao kernel. O kernel fica protegido na memória mas não no HD.
Eu quero ter a liberdade de atualizar meu kernel quando quiser. Não quero que ele fique fora de minha ação não. Sobre isso, você tem que reclamar das distribuições que fazem as dependências de pacotes errôneamente. E acredite, pra algo ter dependência de kernel nas distribuições atuais, ele tem que *realmente* depender do kernel. Se um programa tem relação com o kernel diretamente, ou o programa está errado ou então tinha que ser ligado mesmo, não tem segredo!
Mas pra esclarecer isso, você teria que realmente me dizer exemplos concretos.
A única coisa que eu acho uma grande desvantagem do kernel Linux é a dependência de módulos do kernel ligados a versão/compilação específica de uma versão de kernel. Mas esse é outro assunto.
Considero uma grande BURRICE esta COMPLETA dependência do kernel da árvore de diretórios do usuário.
Ahnnnn???
Posso ter me expressado mal: a dependência do kernel de linguagens e programas que estão disponíveis ao usuário para remover. Melhorou?
As distribuições definem algo como base do sistema por uma razão: são aplicações-chave que não devem ser nunca removidos pelo usuário. Eles tem a liberdade de fazer isso se quiserem (mais uma vez, eu prezo por essa liberdade), mas se eles fizerem está errado! Aí é culpa do usuário!
Olha as dependências de um kernel antigo do Fedora 8:
$ rpm -qR kernel-2.6.26.3-14.fc8 rpmlib(VersionedDependencies) <= 3.0.3-1 fileutils module-init-tools initscripts >= 8.11.1-1 mkinitrd >= 6.0.9-7 /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Sinceramente, se o usuário não tiver essas coisas aí, é porque ele não tem nada mesmo.
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
2009/4/5 Marcio Carneiro viabsb@gmail.com:
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...
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@gmail.com:
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@devin.com.br
2009/4/3 Marcio Carneiro viabsb@gmail.com:
O problema são os tais "macêtes". Você tem um passo-a-passo para fazer a instalação do flash, java, mplayer, vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?
Tem vários por aí na Internet.
Obrigado.
E quanto aos programas compilados em i386 que não aceitam rodar em uma arquitetura 64?
Só conheço o Flash e o *plugin* do Java pro Firefox.
Creio ter lido que o flash para 64 já está disponível.
Quanto tempo teremos de esperar para os programas serem compilados em 64? E a compatibilidade?
Faz vários anos que as distribuições Linux vem com *todos* os pacotes compilados para x86_64. Só no escritório tem 8 servidores rodando CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.
Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho de formatar o disco novamente.
Tenho, sempre, muitos problemas com bibliotecas. Nêste momento estou com problemas com o FC10, que perdeu alguma biblioteca em python, provavelmente, e não consigo acessar o log in no kde. Com o tal do plasma e a completa mudança no KDE, não existe mais o KDE, temos o KDE3 e uma criatura completamente nova, que deveria ter vida própria mas não acabar com o KDE.
Nisso eu concordo, mas essa criatura nova está evoluindo e um dia ficará boa ;-) Se não ficar, a concorrência come.
Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para o usuário, é o que existe funcionar e ser estável. É certo que você poderá dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no futuro. Tem de haver um ponto no meio em que uma distro SEJA estável e não haja comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma nova criatura. Talvez uma distro devêsse ter os dois KDE.
Com a facilidade com que os RedHat alike perdem bibliotecas indispensáveis ao SO e, depois, para re-instalar, impedem a instalação, alegando que um programa já existe e não pode ser re-escrito, ou que uma biblioteca é necessária mas não está disponível e você tem de formatar o HD novamente, parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por exemplo.
Sinceramente não sei o que você faz pra acontecer essas coisas... Eu nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O que eu vejo são pessoas instalando as coisas "natoralmente" e quebrando o sistema inteiro. Aí não tem sistema que aguente :P
Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc. Pedia uma lib que não podia ser instalada porque conflitava com outra existente. Quando removi esta, foi algo da dependência que afetava o SO. E o glibc foi corrompido, ou removido dentro da tal dependência.
Para instalar o galeon é necessário o mozilla e outras dependências, pode ter sido tentando instalar o galeon.
Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um sistema de gerenciamento de pacotes com um nome de distribuição.
Acho que você deve estar confundindo o termo "distribuição"... Leitura recomendada:
http://www.devin.com.br/intro_linux/ Parte "Distribuições"
Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com o que escrevi. Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o usuário ter problemas em instalar programas fora do gerenciador de pacotes. O sistema de gerenciamento de pacotes é muito bom para admistrar a distribuição mas não o Linux que o usuário instala.
"Para usar todas as ferramentas, ele teve que construí-las especificadamente para o seu kernel e uní-las para apresentar ao usuário uma interface para o uso do computador. Enquanto o kernel trabalhava com o hardware, as ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."
Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria e instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em separado aos pacotes que são usados pelo usuário. A liguagem python é NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo, o yum. Se houvesse um python somente para o kernel e outro instalado para o usuário, não haveria o risco.
Não entendi a parte do "E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P", pois a referência poderia ser com uma ligação dinâmica ao binário, e não ao binário que será necessário ao kernel. É o recurso que o GoboLinux usa, todos os programas binários instalados na árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas não estão lá.
Creio que o GoboLinux é a salvação do Linux.
LOL :-)
Tento esclarecer. Não cria uma dependência de um sistema de gerenciamento de pacotes e simplifica a inclusão e remoção de programas no SO. Você poderá qualquer pacote de fontes e instalar no diretório de programas.
Mas vai demorar até uma edição completa com as receitas necessárias à conversão facilitada.
Creio que o pessoal do GoboLinux deveria partir para a radicalização, ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com a proposta do Gobo.
E assim quebrar milhares de programas que são feitos para funcionar de uma forma e ir contra milhares de programadores e padrões do mundo inteiro. Não é a melhor opção.
Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para o kernel, onde estariam o fonte do kernel e de TODOS os programas necessários para compilação e instalação do kernel.
LOL :-)
Por quê o lol? Ou você não entendeu?
Assim, haveria um python e um perl DENTRO do diretório do kernel e OUTROS dois para o usuário, assim, não haveria risco de eliminar um programa ou biblioteca necessários ao kernel quando um usuário ou o próprio root apagasse alguma coisa.
E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o sistema iria explodir :P
Não jogue fora todas as vantagens de programas dinamicamente linkados...
Então você não entendeu. Não se trata disto, exatamente por validar isto é que sugiro que os programas necessários ao kernel devem estar fora da ação do usuário, que poderá instalar e remover qualquer programa sem afetar os que são necessários ao kernel. O kernel fica protegido na memória mas não no HD.
Considero uma grande BURRICE esta COMPLETA dependência do kernel da árvore de diretórios do usuário.
Ahnnnn???
Posso ter me expressado mal: a dependência do kernel de linguagens e programas que estão disponíveis ao usuário para remover. Melhorou?
Fica o pedido de socorro para instalar os tais macêtes.
Com relação ao kernel, minha sugestão é partir para a compilação do kernel com o OCAML DUCE.
LOL :-)
Nem mesmo uma razão para não fazer ou você não conhece a linguagem?
É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei até a entender que sou chato. Mas é, eu sou chato mesmo! :P
Sinceramente, você tem umas coisas muito loucas na cabeça, por favor reveja seus conceitos, tem muita coisa que você diz aí que nem parece que sabe do que tá falando :(
Quando o índio que viu a primeira caravela disse aos demais o que via também foi chamado de louco e via coisas que ninguém via: e era verdade.
Se você não vê algo que alguém disse que viu não diga que êle é louco, isto é rude, mal-educado.
Quando você me manda rever meus conceitos é autoritário e prepotente, aliás, "feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".
Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como não são Orientados a Objetos, o que reduz o usuário a objeto sem interêsse. Não vejo muita vantagem em usar uma linguagem orientada a objetos em um SO procedimental (se é esta a palavra).
Eu concordo sobre a parte dos "macetes", mas veja que isso não é problema do Linux. Isso é problema dos fabricantes dos programas proprietários. Esses macetes aí geralmente têm de ser feitos com programas que não fazem parceria com a distribuição, como o Flash e/ou Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%, esses macetes *nunca* iriam ser precisos, pois os fabricantes iam correr atrás.
Acredite, nos outros sistemas como Windows e Mac também é assim. A diferença é que eles são o foco principal. Agora vai tentar instalar coisas de Linux em outros sistemas, é mais fácil?
Esclareceu, concordo.
Obirgado pelos esclarecimentos. Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se você não concordar com algo que escrevo, é livre para discordar, e dizer. Também é livre para não dizer, mas não tem a liberdade que se deu.
Hugo Cisneiros (Eitch) escreveu:
Meu deus, que viagem, novamente... :P
-- Fedora-users-br mailing list Fedora-users-br@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
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@gmail.com:
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
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@gmail.com:
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@gmail.com:
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
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.
É... 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
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
2009/4/6 Leonardo Pinto (Gmail) leonardoprc@gmail.com
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_libraryis considerably large for a standard library. [2]http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#cite_note-1
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=ocaml..., e depois, nesta: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ocaml..., ou http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ocaml..., e finalmente, em: http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=fpasc... . Comparando SmartEiffel com OCAML: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=oca... .
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.
É... 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:ViaBsb@IPTEL.org ou em ViaBsb@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-users-br
2009/4/5 Heitor Moraes heitor.moraes@gmail.com:
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 ;(
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.
br-users@lists.fedoraproject.org
-
Cristiano Furtado -
Gerente de Sistemas -
Heitor Moraes -
Hugo Cisneiros -
Leonardo Pinto