<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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...<br>
<br>
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...<br>
<br>
O Linux precisa mesmo se encontrar. Ou separar o joio do trigo, ou
atender bem suas segmentações de usuário.<br>
<br>
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!) <span
class="moz-smiley-s4"><span> :-P </span></span><span
class="moz-smiley-s3"><span> ;-) </span></span><span
class="moz-smiley-s11"><span> 8-) </span></span><br>
<br>
<br>
<br>
PS: Antiga trhead Re: [Fedora-users-br] Atualizar o FC10 i386 com
x86_64 e Re: [Fedora-users-br] Sobre o KDE 4.x<br>
<pre class="moz-signature" cols="72">--
Leonardo Pinto
leonardoprc#gmail dot com</pre>
<br>
Marcio Carneiro escreveu:
<blockquote
cite="mid:e4fd21940904041131x356036l42872e6689bfbc56@mail.gmail.com"
type="cite">
<pre wrap="">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....
</pre>
</blockquote>
<br>
<br>
Marcio Carneiro escreveu:
<blockquote
cite="mid:e4fd21940904041316ve04e298yf8fd5a9e39c4f15c@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">2009/4/3 Hugo Cisneiros (Eitch) <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:hugo@devin.com.br">hugo@devin.com.br</a>></span><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2009/4/3
Marcio Carneiro <<a moz-do-not-send="true"
href="mailto:viabsb@gmail.com">viabsb@gmail.com</a>>:<br>
<div class="im">> O problema são os tais "macêtes".<br>
> Você tem um passo-a-passo para fazer a instalação do flash, java,
mplayer,<br>
> vlc e outras bugigangas no CentOS 5 e Fedora 10. por exemplo?<br>
<br>
</div>
Tem vários por aí na Internet.</blockquote>
<div><br>
Obrigado. <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> E quanto aos programas compilados em i386 que não aceitam rodar em
uma<br>
> arquitetura 64?<br>
<br>
</div>
Só conheço o Flash e o *plugin* do Java pro Firefox.</blockquote>
<div><br>
Creio ter lido que o flash para 64 já está disponível. <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Quanto tempo teremos de esperar para os programas serem compilados
em 64? E<br>
> a compatibilidade?<br>
<br>
</div>
Faz vários anos que as distribuições Linux vem com *todos* os pacotes<br>
compilados para x86_64. Só no escritório tem 8 servidores rodando<br>
CentOS totalmente x86_64 e umas 10 estações com Ubuntu x86_64 também.<br>
</blockquote>
<div><br>
Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava
errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha
pergunta inicial era se é possível fazer a atualização com o 64 ou se
tenho de formatar o disco novamente. <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Tenho, sempre, muitos problemas com bibliotecas.<br>
> Nêste momento estou com problemas com o FC10, que perdeu alguma
biblioteca<br>
> em python, provavelmente, e não consigo acessar o log in no kde.<br>
> Com o tal do plasma e a completa mudança no KDE, não existe mais o
KDE,<br>
> temos o KDE3 e uma criatura completamente nova, que deveria ter
vida própria<br>
> mas não acabar com o KDE.<br>
<br>
</div>
Nisso eu concordo, mas essa criatura nova está evoluindo e um dia<br>
ficará boa ;-) Se não ficar, a concorrência come.</blockquote>
<div><br>
Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa
para o usuário, é o que existe funcionar e ser estável. É certo que
você poderá dizer que qualquer coisa que será feita SERÁ estável, mas é
justamente aí que está o problema, NUNCA haverá uma distro estável,
pois estará SEMPRE no futuro.<br>
Tem de haver um ponto no meio em que uma distro SEJA estável e não haja
comprometimento com os próximos avanços, por isto me referi ao KDE4
como uma nova criatura. Talvez uma distro devêsse ter os dois KDE. <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Com a facilidade com que os RedHat alike perdem bibliotecas
indispensáveis<br>
> ao SO e, depois, para re-instalar, impedem a instalação, alegando
que um<br>
> programa já existe e não pode ser re-escrito, ou que uma
biblioteca é<br>
> necessária mas não está disponível e você tem de formatar o HD
novamente,<br>
> parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD,
por<br>
> exemplo.<br>
<br>
</div>
Sinceramente não sei o que você faz pra acontecer essas coisas... Eu<br>
nunca vejo bibliotecas se perderem assim do nada, com "facilidade". O<br>
que eu vejo são pessoas instalando as coisas "natoralmente" e<br>
quebrando o sistema inteiro. Aí não tem sistema que aguente :P</blockquote>
<div><br>
Realmente não lembro do programa, pode ter sido um MM como o mplayer ou
vlc. Pedia uma lib que não podia ser instalada porque conflitava com
outra existente. Quando removi esta, foi algo da dependência que
afetava o SO. E o glibc foi corrompido, ou removido dentro da tal
dependência.<br>
<br>
Para instalar o galeon é necessário o mozilla e outras dependências,
pode ter sido tentando instalar o galeon.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um
sistema<br>
> de gerenciamento de pacotes com um nome de distribuição.<br>
<br>
</div>
Acho que você deve estar confundindo o termo "distribuição"... Leitura<br>
recomendada:<br>
<br>
<a moz-do-not-send="true"
href="http://www.devin.com.br/intro_linux/" target="_blank">http://www.devin.com.br/intro_linux/</a><br>
Parte "Distribuições"</blockquote>
<div><br>
Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo
com o que escrevi. <br>
Disse da distribuição DEPENDER de um sistema de gerenciamento de
pacotes e o usuário ter problemas em instalar programas fora do
gerenciador de pacotes.<br>
O sistema de gerenciamento de pacotes é muito bom para admistrar a
distribuição mas não o Linux que o usuário instala.<br>
<br>
"Para usar todas as ferramentas, ele teve que construí-las
especificadamente para o seu kernel e uní-las para apresentar ao
usuário uma interface para o uso do computador. Enquanto o kernel
trabalhava com o hardware, as ferramentas trabalhavam servindo como
ponte entre o usuário e o kernel."</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Isto
vem de encontro ao que eu escrevi. O conjunto de programas que cria e
instala o kernel poderia (eu penso que sim) estar no pacote do kernel,
em separado aos pacotes que são usados pelo usuário. A liguagem python
é NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por
exemplo, o yum. Se houvesse um python somente para o kernel e outro
instalado para o usuário, não haveria o risco.</blockquote>
<div>Não entendi a parte do "E assim, existiria uma biblioteca C
para CADA PROGRAMA do sistema.
Então cada comando/chamada iria carregar na memória e o sistema iria
explodir :P", pois a referência poderia ser com uma ligação dinâmica ao
binário, e não ao binário que será necessário ao kernel. <br>
É o recurso que o GoboLinux usa, todos os programas binários instalados
na árvore do Gobo têm uma ligação dinâmica para a árvore original do
UNIX, mas não estão lá.<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Creio que o GoboLinux é a salvação do Linux.<br>
<br>
</div>
LOL :-)</blockquote>
<div><br>
Tento esclarecer.<br>
Não cria uma dependência de um sistema de gerenciamento de pacotes e
simplifica a inclusão e remoção de programas no SO.<br>
Você poderá qualquer pacote de fontes e instalar no diretório de
programas.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Mas vai demorar até uma edição completa com as receitas
necessárias à<br>
> conversão facilitada.<br>
><br>
> Creio que o pessoal do GoboLinux deveria partir para a
radicalização,<br>
> ELIMINAR a árvore de diretório do *nix e RE-ESCREVER de acôrdo com
a<br>
> proposta do Gobo.<br>
<br>
</div>
E assim quebrar milhares de programas que são feitos para funcionar de<br>
uma forma e ir contra milhares de programadores e padrões do mundo<br>
inteiro. Não é a melhor opção.<br>
<div class="im"><br>
> Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE
para o<br>
> kernel, onde estariam o fonte do kernel e de TODOS os programas
necessários<br>
> para compilação e instalação do kernel.<br>
<br>
</div>
LOL :-)</blockquote>
<div>Por quê o lol?<br>
Ou você não entendeu? <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Assim, haveria um python e um perl DENTRO do diretório do kernel e
OUTROS<br>
> dois para o usuário, assim, não haveria risco de eliminar um
programa ou<br>
> biblioteca necessários ao kernel quando um usuário ou o próprio
root<br>
> apagasse alguma coisa.<br>
<br>
</div>
E assim, existiria uma biblioteca C para CADA PROGRAMA do sistema.<br>
Então cada comando/chamada iria carregar na memória e o sistema iria<br>
explodir :P<br>
<br>
Não jogue fora todas as vantagens de programas dinamicamente linkados...</blockquote>
<div><br>
Então você não entendeu.<br>
Não se trata disto, exatamente por validar isto é que sugiro que os
programas necessários ao kernel devem estar fora da ação do usuário,
que poderá instalar e remover qualquer programa sem afetar os que são
necessários ao kernel.<br>
O kernel fica protegido na memória mas não no HD.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Considero uma grande BURRICE esta COMPLETA dependência do kernel
da árvore<br>
> de diretórios do usuário.<br>
<br>
</div>
Ahnnnn???</blockquote>
<div><br>
</div>
<div><br>
Posso ter me expressado mal: a dependência do kernel de linguagens e
programas que estão disponíveis ao usuário para remover.<br>
Melhorou? <br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
> Fica o pedido de socorro para instalar os tais macêtes.<br>
><br>
> Com relação ao kernel, minha sugestão é partir para a compilação
do kernel<br>
> com o OCAML DUCE.<br>
<br>
</div>
LOL :-)</blockquote>
<div><br>
Nem mesmo uma razão para não fazer ou você não conhece a linguagem? <br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
É sério, reli meu e-mail e ficou com um tom muito sarcástico... Dei<br>
até a entender que sou chato. Mas é, eu sou chato mesmo! :P<br>
<br>
Sinceramente, você tem umas coisas muito loucas na cabeça, por favor<br>
reveja seus conceitos, tem muita coisa que você diz aí que nem parece<br>
que sabe do que tá falando :(</blockquote>
<div><br>
Quando o índio que viu a primeira caravela disse aos demais o que via
também foi chamado de louco e via coisas que ninguém via: e era verdade.<br>
<br>
Se você não vê algo que alguém disse que viu não diga que êle é louco,
isto é rude, mal-educado.<br>
<br>
Quando você me manda rever meus conceitos é autoritário e prepotente,
aliás, "feature" dos unixers, no geral, algo como "se eu fiz, faça, não
me enche".<br>
<br>
Customo dizer que o Unix e o Linux não são Orientados a Usuários tal
como não são Orientados a Objetos, o que reduz o usuário a objeto sem
interêsse.<br>
Não vejo muita vantagem em usar uma linguagem orientada a objetos em um
SO procedimental (se é esta a palavra).<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Eu concordo sobre a parte dos "macetes", mas veja que isso não é<br>
problema do Linux. Isso é problema dos fabricantes dos programas<br>
proprietários. Esses macetes aí geralmente têm de ser feitos com<br>
programas que não fazem parceria com a distribuição, como o Flash e/ou<br>
Java. Tenha certeza de que se o mercado de usuários Linux fosse 90%,<br>
esses macetes *nunca* iriam ser precisos, pois os fabricantes iam<br>
correr atrás.<br>
<br>
Acredite, nos outros sistemas como Windows e Mac também é assim. A<br>
diferença é que eles são o foco principal. Agora vai tentar instalar<br>
coisas de Linux em outros sistemas, é mais fácil?</blockquote>
<div><br>
Esclareceu, concordo. <br>
<br>
Obirgado pelos esclarecimentos.<br>
Não vou recomendar nada a você, não tenho esta postura, lido com a sua.
Se você não concordar com algo que escrevo, é livre para discordar, e
dizer. Também é livre para não dizer, mas não tem a liberdade que se
deu.<br>
</div>
</div>
</blockquote>
<br>
<br>
Hugo Cisneiros (Eitch) escreveu:
<blockquote
cite="mid:1012f2090904041210s15e7bb0dhddfb97858ab91fad@mail.gmail.com"
type="cite">
<pre wrap="">Meu deus, que viagem, novamente... :P</pre>
</blockquote>
</body>
</html>