Em S�b, 2001-10-27 �s 00:11, Everardo Ferreira Ara�jo escreveu:
> > > ah... ent�o n�o temos aplicativos para linux? eu tenho tudo o que
> > > preciso... ali�s, nem uso mais Windows...
> >
> > Eu tbem naum.... no meu Athlon 1GHZ.... mas num 486 a hist�ria
> > muda!!!
> =====
> Essa coisa de "opini�o" sobre performance s� tem validade cient�fica se
> for realizada atrav�s de "testes de desempenho" (benchmark) ou n�o
> passar� de "achismo". J� rodei o kernel 2.0.x com kde 1.0 num 486dx266
> com 32Mb de mem�ria. Me lembro que na �poca o Netscape rodava sem
> "perda de paci�ncia"; ou seja: n�o era uma bala mas tamb�m n�o era uma
> lesma. Tinha tamb�m um Rwin95 e me lembro que n�o via diferen�a de
> performance, no entanto, a diferen�a de estabilidade era gritante.
Cuidado com o que diz! Um benchmark na verdade n�o � cient�fico. Se diz
de cient�fico algo que reproduza exatamente as condi��es de um ambiente,
isto �, tenha equival�ncia exata. Um benchmark, por mais par�metros que
tenha, sempre ser� ESPECULA��O sobre o ambiente em quest�o. Por isso que
temos benchmarks tendenciosos a um ou outro produto, como os da
Mindcraft. Est�o dizendo a� que a ATI RAGE 128 foi constru�da *tendo em
vista o Quake3*, pois praticamente todos os benchmarks de placa 3D s�o
feitos usando este jogo!
> > > >Um 486 eu rodo tranquilamente Windows 95 / MS-Office 97 (vamos
> > > > esquecer a quest�o do custo por um momento, ok ?)
Nesse thread eu acho que as coisas est�o sendo colocadas de um jeito
extremamente inadequado -- � �BVIO que as aplica��es demoram menos a
iniciar no Windows 95 ou mesmo no 98 do que no GNU/Linux. Isso decorre
por causa da arquitetura de cada um desses sistemas. Os Windows citados
s�o sistemas feitos para desktop, em que o importante � disponibilizar o
m�ximo de recursos para o usu�rio em detrimento de qualquer outra coisa.
J� o GNU/Linux (e o Unix em geral) � constru�do em cima de preceitos de
engenharia de software mais robustos, incluindo multitarefa real.
Assim, quando voc� chama um programa no Windows, ele n�o se acanha de
esquecer todo o resto dos servi�os, processos e programas rodando para
disponibilizar todos os recursos para carregar o novo programa e o GDI
integrado ao kernel para apresent�-lo o mais r�pido poss�vel na tela.
J� no GNU/Linux, quando voc� chama um programa, ele vai, em
multitarefa, fazer cada parte do processo cuidadosamente: chamar o
programa, cuidar do ajuste dos recursos no X, para finalmente fazer
aparecer a aplica��o na tela.
Assim, se eu usasse Windows 98, e chamasse o media player, eu esperaria
que ele aparecesse imediatamente na tela. No entanto, se eu estivesse
tocando um filme no media player e chamasse o mIRC, eu iria esperar umas
tremidas no filme - ou at� mesmo que ele sa�sse de sincronia.
No GNU/Linux, se eu chamo o mplayer, eu vou esperar que ele demore um
pouco mais do que o Media Player, mas enquanto eu estiver tocando o
filme e eu chamar o X-Chat, vou ficar simplesmente surpreso se ao
contr�rio das outras vezes ele der uma paradinha que seja no filme para
o processo de carregamente do programa.
E ainda assim, eu tamb�m vou esperar um desempenho maior do mplayer no
GNU/Linux do que o Media Player do Windows, pois devido a extens�es de
escrita direta e de xvideo do XFree86 4, o desempenho de v�deo no
GNU/Linux est� conseguindo efeitos muito bons, mesmo com a parte gr�fica
do Windows estando no kernel.
[]s,
--
Patola (Cl�udio Sampaio) - Solvo S/A
IBM Certified Advanced Technical Expert and Systems Developer
SAIR GNU/Linux Certified Systems Administrator
PGP/GPG Public Key Available Upon Request
Try http://www.automatos.com - The Automatic MSP
Unix sex: unzip; strip; touch; finger; mount; fsck; more; yes; umount;
sleep
--
/"\
\ / ASCII RIBBON CAMPAIGN - NO HTML EMAIL!
X PLEASE QUOTE ONLY RELEVANT PARTS OF THIS MESSAGE.
/ \ DON'T QUOTE THIS SIGNATURE! / N�O CITE ESTA ASSINATURA!
PGP signature
