<br><br><div class="gmail_quote">2009/4/4 Hugo Cisneiros (Eitch) <span dir="ltr"><<a href="mailto:hugo@devin.com.br">hugo@devin.com.br</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/4/4 Marcio Carneiro <<a href="mailto:viabsb@gmail.com">viabsb@gmail.com</a>>:<br>
<div class="im">>> > E quanto aos programas compilados em i386 que não aceitam rodar em uma<br>
>> > arquitetura 64?<br>
>><br>
>> Só conheço o Flash e o *plugin* do Java pro Firefox.<br>
><br>
> Creio ter lido que o flash para 64 já está disponível.<br>
<br>
</div>Alfa, não conta tanto assim. Mas é uma ótima notícia de que virá.<br>
<div class="im"><br>
>> > Quanto tempo teremos de esperar para os programas serem compilados em<br>
>> > 64? E<br>
>> > a compatibilidade?<br>
>><br>
>> 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>
><br>
> Minha dúvida começou quando instalei o FC10 i386 e depois vi que estava<br>
> errado, pois pensei que o disco era 64 e instalei assim mesmo. Minha<br>
> pergunta inicial era se é possível fazer a atualização com o 64 ou se tenho<br>
> de formatar o disco novamente.<br>
<br>
</div>E...? Na sua pergunta, me pareceu que você estava perguntando sobre<br>
quanto tempo deveríamos esperar pelos programas já serem compilados<br>
para 64-bits, sendo que eu respondi que eles já o são, faz anos, com<br>
algumas excessões que eu também disse.<br>
<div class="im"><br>
>> > Tenho, sempre, muitos problemas com bibliotecas.<br>
>> > Nêste momento estou com problemas com o FC10, que perdeu alguma<br>
>> > 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<br>
>> > própria<br>
>> > mas não acabar com o KDE.<br>
>><br>
>> Nisso eu concordo, mas essa criatura nova está evoluindo e um dia<br>
>> ficará boa ;-) Se não ficar, a concorrência come.<br>
><br>
> Pode ser, mas não é a corrida pela mais nova distro ou KDE que importa para<br>
> o usuário, é o que existe funcionar e ser estável. É certo que você poderá<br>
> dizer que qualquer coisa que será feita SERÁ estável, mas é justamente aí<br>
> que está o problema, NUNCA haverá uma distro estável, pois estará SEMPRE no<br>
> futuro.<br>
> Tem de haver um ponto no meio em que uma distro SEJA estável e não haja<br>
> comprometimento com os próximos avanços, por isto me referi ao KDE4 como uma<br>
> nova criatura. Talvez uma distro devêsse ter os dois KDE.<br>
<br>
</div>Eu nunca vou dizer que qualquer coisa será totalmente estável. Eu quis<br>
dizer que o KDE4 (IMO) ainda está muito "xulo" e tem muito o que<br>
melhorar pra chegar aos pés do 3.5. Mas essa discussão já é velha e<br>
desafasada: eu já sei que o KDE4 vai ficar legal lá pelo 4.4.<br>
<br>
Em contrapartida ao que você disse, tem algumas distros bem estáveis<br>
sim. Ou você acha que um monte de super-computadores e milhares de<br>
servidores rodam distribuições Linux sendo instáveis? Paramos pra<br>
pensar: será que algumas dessas coisas 'instáveis' não são culpa de<br>
BIOS?<br>
<br>
Não vou nem falar do Fedora aqui porque a proposta da distribuição não<br>
tem como prioridade ser estável, e sim ter mais funcionalidades e tudo<br>
ser "cutting-edge". O KDE seguiu a mesma direção (aliás, acho que ele<br>
sempre foi assim), só mudando quando sua "minor version" fica mais<br>
distante (por isso eu disse lá pelo 4.4).<br>
<div class="im"><br>
>> > Com a facilidade com que os RedHat alike perdem bibliotecas<br>
>> > 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<br>
>> > novamente,<br>
>> > parece-me que a solução em *nix é, mesmo, um Unix, como o OpenBSD, por<br>
>> > exemplo.<br>
>><br>
>> 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<br>
><br>
> Realmente não lembro do programa, pode ter sido um MM como o mplayer ou vlc.<br>
> Pedia uma lib que não podia ser instalada porque conflitava com outra<br>
> existente. Quando removi esta, foi algo da dependência que afetava o SO. E o<br>
> 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<br>
> ter sido tentando instalar o galeon.<br>
<br>
</div>Ou seja, não culpe a distribuição por algo que você fez de errado. Se<br>
você tentou fazer isso no Fedora, pode ter certeza que utilizou um<br>
repositório de terceiro e não o da distribuição. Depois imagino que<br>
forçou a remoção da biblioteca de modo errôneo e começou a afetar o<br>
SO. Como eu disse: não tem sistema a prova de usuário: só se o sistema<br>
não deixasse o usuário fazer quase nada.<br>
<br>
Que nem eu há muito tempo atrás, fui fazer uma atualização de glibc na<br>
distribuição e acabei com tudo. Tive que reinstalar.<br>
<div class="im"><br>
>> > Na realidade, NÃO EXISTE uma distribuição Linux, o que existe é um<br>
>> > sistema<br>
>> > de gerenciamento de pacotes com um nome de distribuição.<br>
>><br>
>> Acho que você deve estar confundindo o termo "distribuição"... Leitura<br>
>> recomendada:<br>
>><br>
>> <a href="http://www.devin.com.br/intro_linux/" target="_blank">http://www.devin.com.br/intro_linux/</a><br>
>> Parte "Distribuições"<br>
><br>
> Não creio que tenha feito a confusão. Li o referido e não tem desacôrdo com<br>
> o que escrevi.<br>
> Disse da distribuição DEPENDER de um sistema de gerenciamento de pacotes e o<br>
> usuário ter problemas em instalar programas fora do gerenciador de pacotes.<br>
> O sistema de gerenciamento de pacotes é muito bom para admistrar a<br>
> distribuição mas não o Linux que o usuário instala.<br>
<br>
</div>Você falou que não existe uma distribuição e sim um gerenciador de<br>
pacotes. Falar isso é ignorar todo o trabalho que a distribuição tem<br>
de pegar os programas e montá-los de forma legal, colocar um<br>
instalador pra facilitar a vida do usuário, fornecer atualizações,<br>
personalizações, kernels para situações especiais, e inclusive colocar<br>
um gerenciador de pacotes para facilitar todas essas tarefas tanto<br>
para os desenvolvedores, quanto para os usuários.<br>
<br>
Falar que uma distribuição é apenas um gerenciador de pacotes é dose.<br>
<br>
E instalar pacotes fora do padrão da distribuição é um problema de<br>
qualquer outro sistema. Os gerenciadores de pacotes foram criados para<br>
evitar a "bagunça" que se faz quando se instala sem indexar os<br>
arquivos que foram espalhados: com o tempo eles vão acumulando no<br>
sistema e você nem sabe onde estão e o que fazem, isso gera um "bloat"<br>
no sistema com o tempo. É assim no Linux, é assim no Windows (muito<br>
mais, porque eles não tem controle sobre as milhões de aplicações que<br>
têm de ser instaladas separadas e cada fabricante instala do jeito que<br>
lhe for mais conveniente), é assim com qualquer outro sistema.<br>
<br>
Mesmo que você siga o conceito de colocar todos os programas linkados<br>
estaticamente, sempre vai haver um ponto de falha provavel, por<br>
exemplo, você pode instalar uma própria glibc mais nova e quebrar<br>
qualquer chamada de sistema que esses programas utilizam. Ou, tenta<br>
instalar um driver do Windows 98 no Windows XP, sei lá.<br>
<div class="im"><br>
> "Para usar todas as ferramentas, ele teve que construí-las especificadamente<br>
> para o seu kernel e uní-las para apresentar ao usuário uma interface para o<br>
> uso do computador. Enquanto o kernel trabalhava com o hardware, as<br>
> ferramentas trabalhavam servindo como ponte entre o usuário e o kernel."<br>
<br>
</div>Exatamente ;-)<br>
<div class="im"><br>
>> Isto vem de encontro ao que eu escrevi. O conjunto de programas que cria<br>
>> e instala o kernel poderia (eu penso que sim) estar no pacote do kernel, em<br>
>> separado aos pacotes que são usados pelo usuário. A liguagem python é<br>
>> NECESSÁRIA ao kernel e se um usuário remove a linguagem, perde, por exemplo,<br>
>> o yum. Se houvesse um python somente para o kernel e outro instalado para o<br>
>> usuário, não haveria o risco.<br>
><br>
> Não entendi a parte do "E assim, existiria uma biblioteca C para CADA<br>
> PROGRAMA do sistema. Então cada comando/chamada iria carregar na memória e o<br>
> sistema iria explodir :P", pois a referência poderia ser com uma ligação<br>
> 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<br>
> árvore do Gobo têm uma ligação dinâmica para a árvore original do UNIX, mas<br>
> não estão lá.<br>
<br>
</div>É isso que eu quis dizer quando eu pensei que você não sabia muito bem<br>
o que tava falando. Sinto lhe informar, mas o GoboLinux não faz nenhum<br>
milagre não. O que o GoboLinux faz (e que é interessante mesmo) é<br>
re-organizar onde ficam as localizações dos arquivos dos programas e<br>
bibliotecas instaladas no sistema. Isso não elimina de forma alguma as<br>
dependências entre eles. Os programas não são todos linkados<br>
estaticamente. Se você remover algumas coisas, as outras vão pifar.<br>
<br>
Sobre a biblioteca C, o que quero dizer é que todo comando/programa<br>
usa essa biblioteca para alocar memória por exemplo. Ela faz a<br>
interface com o kernel. Se você removê-la ou atualizá-la sem cuidado e<br>
sem prestar atenção em todas as aplicações do sistema, você pode<br>
quebrar esse sistema. Felizmente a gente não passa por isso porque as<br>
distribuições cuidam dessa parte mais complicada pros usuários.<br>
<br>
Quando se tem um gerenciador de pacotes, não importa a localização dos<br>
arquivos, eles estão sempre indexados e podem ser<br>
removidos/atualizados de forma correta sem deixar resquícios. Por isso<br>
eu sempre achei essa localização de arquivos muito irrelevante.<br>
<div class="im"><br>
>> > Creio que o GoboLinux é a salvação do Linux.<br>
>><br>
>> LOL :-)<br>
><br>
> Tento esclarecer.<br>
> Não cria uma dependência de um sistema de gerenciamento de pacotes e<br>
> 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>Você pode fazer isso em qualquer distribuição. Sério, sabia que você<br>
pode instalar vários Pythons na mesma máquina? Basta, na hora de<br>
compilar, dizer pra ele instalar numa árvore de diretórios diferente.<br>
Ah, e é isso que o GoboLinux faz. Isso não impede de você fazer<br>
também.<br>
<br>
Inclusive, isso me faz lembrar que o próprio Debian faz isso: ele tem<br>
algumas versões múltiplas, o exemplo mais recente que vi foi que você<br>
pode instalar, via gerenciador de pacotes, o php4 e o php5.<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>
>> 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>
>><br>
>> > Penso que o SO deveria ter uma árvore de diretórios EXCLUSIVAMENTE para<br>
>> > o<br>
>> > kernel, onde estariam o fonte do kernel e de TODOS os programas<br>
>> > necessários<br>
>> > para compilação e instalação do kernel.<br>
>><br>
>> LOL :-)<br>
><br>
> Por quê o lol?<br>
> Ou você não entendeu?<br>
<br>
</div>O LOL foi porque a idéia é muito sem noção (IMO), e por isso eu ri. É<br>
como dizer para o mundo que agora todos os servidores de DNS da<br>
Internet, cada um deles deve ter TODAS as informações sobre todos os<br>
hosts do mundo. Quando você fala um exemplo ou outro, até que não<br>
ficaria tão ruim, assim como se a Internet tivesse 100 domínios. Agora<br>
imagine quando se fala de belos milhões de programas.<br>
<br>
Se formos seguir esse padrão que você disse, todo programa deveria ter<br>
suas bibliotecas e dependências todas linkadas estaticamente. Isso, em<br>
sistemas modernos é impraticável, a não ser que você queira perder<br>
espaço e memória exorbitantes. Significaria que cada um dos comandos:<br>
ls, cd, ln, grep, mkdir, rmdir, rm, ping, ifconfig e todos estes mais<br>
simples teriam que ter dentro da sua compilação todas suas<br>
dependências:<br>
<br>
madoka:~$ ldd /bin/ls<br>
linux-gate.so.1 => (0xb7f40000)<br>
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7f1f000)<br>
libselinux.so.1 => /lib/libselinux.so.1 (0xb7f06000)<br>
libacl.so.1 => /lib/libacl.so.1 (0xb7efe000)<br>
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7da3000)<br>
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7d8a000)<br>
/lib/ld-linux.so.2 (0xb7f41000)<br>
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7d86000)<br>
libattr.so.1 => /lib/libattr.so.1 (0xb7d81000)<br>
<br>
Multiplique agora todas essas bibliotecas por milhares de comandos e<br>
milhões de programas por aí. Não seria muito legal né? E quando fosse<br>
atualizar uma dessas bibliotecas? Teria que atualizar centenas ou<br>
milhares de compilações!<br>
<br>
O que eu acho que você tá pegando errado é que você só está<br>
considerando a localização dos programas. Onde ficam seus arquivos.<br>
Mas não é só isso que existe por trás de um funcionamento de um<br>
sistema operacional. Tem muita coisa por trás, acho melhor você dar<br>
uma pesquisada nisso (já enfatizei alguns pontos).<br>
<div class="im"><br>
>> > Assim, haveria um python e um perl DENTRO do diretório do kernel e<br>
>> > 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>
>> 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...<br>
><br>
> Então você não entendeu.<br>
> Não se trata disto, exatamente por validar isto é que sugiro que os<br>
> programas necessários ao kernel devem estar fora da ação do usuário, que<br>
> poderá instalar e remover qualquer programa sem afetar os que são<br>
> necessários ao kernel.<br>
> O kernel fica protegido na memória mas não no HD.<br>
<br>
</div>Eu quero ter a liberdade de atualizar meu kernel quando quiser. Não<br>
quero que ele fique fora de minha ação não. Sobre isso, você tem que<br>
reclamar das distribuições que fazem as dependências de pacotes<br>
errôneamente. E acredite, pra algo ter dependência de kernel nas<br>
distribuições atuais, ele tem que *realmente* depender do kernel. Se<br>
um programa tem relação com o kernel diretamente, ou o programa está<br>
errado ou então tinha que ser ligado mesmo, não tem segredo!<br>
<br>
Mas pra esclarecer isso, você teria que realmente me dizer exemplos concretos.<br>
<br>
A única coisa que eu acho uma grande desvantagem do kernel Linux é a<br>
dependência de módulos do kernel ligados a versão/compilação<br>
específica de uma versão de kernel. Mas esse é outro assunto.<br>
<div class="im"><br>
>> > Considero uma grande BURRICE esta COMPLETA dependência do kernel da<br>
>> > árvore<br>
>> > de diretórios do usuário.<br>
>><br>
>> Ahnnnn???<br>
><br>
> Posso ter me expressado mal: a dependência do kernel de linguagens e<br>
> programas que estão disponíveis ao usuário para remover.<br>
> Melhorou?<br>
<br>
</div>As distribuições definem algo como base do sistema por uma razão: são<br>
aplicações-chave que não devem ser nunca removidos pelo usuário. Eles<br>
tem a liberdade de fazer isso se quiserem (mais uma vez, eu prezo por<br>
essa liberdade), mas se eles fizerem está errado! Aí é culpa do<br>
usuário!<br>
<br>
Olha as dependências de um kernel antigo do Fedora 8:<br>
<br>
$ rpm -qR kernel-2.6.26.3-14.fc8<br>
rpmlib(VersionedDependencies) <= 3.0.3-1<br>
fileutils<br>
module-init-tools<br>
initscripts >= 8.11.1-1<br>
mkinitrd >= 6.0.9-7<br>
/bin/sh<br>
/bin/sh<br>
rpmlib(PayloadFilesHavePrefix) <= 4.0-1<br>
rpmlib(CompressedFileNames) <= 3.0.4-1<br>
<br>
Sinceramente, se o usuário não tiver essas coisas aí, é porque ele não<br>
tem nada mesmo.<br>
<div class="im"><br>
</div></blockquote><div>Ou seja, a distribuição limita-se ao gerenciador de pacotes.<br>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).<br>
Eu não disse que uma distribuição é apenas um gerenciador de pacotes, digo que se limita ao limite dêle.<br>Quanto às ligações dinâmicas, creio que não entendi, ou o que você disse ou o que é uma ligação dinâmica.<br>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.<br>
É 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.<br>
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.<br>
NÃO se trata de "colocar todos os programas linkados estaticamente", nunca disse isto, ou me expressei mal.<br>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.<br>
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.<br>
Isto será assim até a mudança final da árvore de diretórios, física, o que mudará a árvore do unix completamente.<br>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.<br>
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.<br>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.<br>
E poucos são relocáveis, problema que o GoboLinux resolve com a não-dependência de ligações dinâmicas.<br>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.<br>
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.<br>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.<br>
"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?<br>
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.<br>
Aqui, parece-me, discordamos. <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>
>> > 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<br>
>> > kernel<br>
>> > com o OCAML DUCE.<br>
>><br>
>> LOL :-)<br>
><br>
> Nem mesmo uma razão para não fazer ou você não conhece a linguagem?<br>
<br>
</div>Não conheço, não posso opiniar. Eu ri porque você está sugerindo criar<br>
um sistema operacional do zero. "Talk is cheap, show me the code".</blockquote><div><br>Não disse isto, mas me sôa meio atrasado.<br>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.<br>
É um exemplo de Projeto perfeito.<br>E êles fizeram.<br>Só para citar alguém que falava inglês.<br>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.<br>
Creio que CADA faculdade de TI do .br DEVERIA entrar na corrida pelo SO.br!.<br>E creio que o SO deveria ser escrito em OCAMLDUCE com C ou assembler no que fôsse necessário.<br><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>
Ainda mais, a linguagem não importa na maioria das vezes, o que<br>
importa é o programador e seu design de código. Pode ser a linguagem</blockquote><div><br>Se a linguagem não importa porquê você acha que fizeram C para criar o UNIX?<br>Porquê não foi escrito em BASIC?<br>Porquê a SUN criou o java para aquecer torradeiras à distância e não usou o pascal para fazer isto?<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>
mais perfeita, um programador ruim pode fazer besteira do mesmo jeito.<br>
Falar que ficaria muito melhor utilizando linguagem X é desconsiderar<br>
todas essas variáveis.<br>
<div class="im"><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 :(<br>
><br>
> Quando o índio que viu a primeira caravela disse aos demais o que via também<br>
> 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<br>
> é rude, mal-educado.<br>
<br>
</div>Interpreta-se como quer. </blockquote><div><br>Isto é autoritário.<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;">Eu ainda acho suas idéias loucas. Você pode<br>
não ser louco (e nunca disse isso), mas pra mim tem idéias loucas e</blockquote><div><br>Hein?<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>
equivocadas. Ao invés de achar isso rude e mal-educado, instigue-se,<br>
use a cabeça e prove-me que suas idéias não são loucas! Senão como<br>
você vai convencer o resto do mundo?</blockquote><div><br>Você precisa estudar um pouco mais o idioma falado por aqui.<br>Sujeito, objeto direto, estas coisas.<br>Pessoas sadias NÃO têm idéias loucas, loucos as têm.<br>Eu não tenho de provar nada para você nem para ninguém, não estou aqui para isto.<br>
Estou debatendo um assunto que me interessa, e com você porque já demonstrou ter conhecimento. Mas isto não te dá direitos extras.<br>Eu não acho nada, sou um cara sem sorte, se não faço ou não compro pronto, fico sem.<br>
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? <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>
> Quando você me manda rever meus conceitos é autoritário e prepotente, aliás,<br>
> "feature" dos unixers, no geral, algo como "se eu fiz, faça, não me enche".<br>
<br>
</div>Eu seria autoritário se dissesse "mude seus conceitos". Quando eu falo<br>
"reveja seus conceitos", quero dizer pra você rever mesmo: pensar no<br>
que você tá falando ao invés de continuar falando. E essa "feature" aí<br>
que você disse não é dos unixers, é de qualquer programador idiota. A<br>
grande "feature" do código-aberto é quando a gente faz qualquer coisa,<br>
libera o código e todos podem criticar, opinar e ajudar/atrapalhar.<br>
<div class="im"><br>
> Customo dizer que o Unix e o Linux não são Orientados a Usuários tal como<br>
> 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<br>
> procedimental (se é esta a palavra).<br>
<br>
</div>O mundo é grande e existem diversos tipos de usuários. O Linux é<br>
orientado para usuários SIM, só não todos.</blockquote><div><br>Então não é!<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;">
Se você dissesse que o<br>
Linux não é orientado a usuário "final", eu concordo até certa parte.<br>
</blockquote><div><br>Não existem dois tipos de usuários, não existe o "usuário final".<br>Ou você codifica ou usa o código.<br>Você é um programador, quando não está fazendo o programa, está "usando" o computador, o que faz de você um "usuário final".<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;">Se você diz que Linux não é orientado a usuário "gamer", eu concordo<br>
100%. Mas tudo isso é relativo não?<br>
</blockquote><div><br>Se ISTO é relativo, porquê não AQUILO?<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>
Linux é orientado para os usuários corporativos e para os servidores,</blockquote><div><br>Não existem usuários corporativos, existem um ambiente corporativo.<br>Os usuários corporativos são os mesmos que qualquer outro usuário, êle usa.<br>
Servidores não são usuários, são máquinas.<br>Servidores têm usuários.<br>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.<br>
Você quer tapar o sol com uma peneira.<br>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.<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>
mas isso também está mudando: se chama crescimento/expansão.<br>
Infelizmente nosso crescimento nessa área é uma porcaria :)</blockquote><div><br>Concordo.<br>Você já notou que praticamente nenhuma universidade têm um savane, um GForge um ou um sourceproject?<br>Parece que a academia não liga a mínima para o mundo da produção de TI. <br>
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.<br>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.<br>
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.<br>Você não se sente um pouco "menos" explorado do que poderia ser, dado o conhecimento que já tem?<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>
>><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?<br>
><br>
> Esclareceu, concordo.<br>
<br>
</div>E a única vantagem que a gente tem disso daí é que não existem vírus<br>
eficientes e bem difundidos pra Linux :P<br>
<div class="im"><br>
> Obirgado pelos esclarecimentos.<br>
> Não vou recomendar nada a você, não tenho esta postura, lido com a sua. Se<br>
> você não concordar com algo que escrevo, é livre para discordar, e dizer.<br>
> Também é livre para não dizer, mas não tem a liberdade que se deu.<br>
<br>
</div>\o/<br>
<font color="#888888"></font></blockquote><div><br>Saudações. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">[]'s<br>
Hugo<br>
<a href="http://www.devin.com.br" target="_blank">www.devin.com.br</a><br>
<br>
--<br>
Fedora-users-br mailing list<br>
<a href="mailto:Fedora-users-br@redhat.com">Fedora-users-br@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-users-br" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-users-br</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>EquipeLinux@EquipeLinux.com<br>EquipeLinux@Skype.com<br><br>