Arnaldo Carvalho de Melo wrote:
>
> Em Mon, Aug 27, 2001 at 09:55:09PM -0300, Lisias Toledo escreveu:
> > lista1 wrote:
> > Um dos primeiros motivos � que o X roda no userspace, como se fosse um
[...]
> > X derrubaria a m�quina, o que n�o acontece quando o X roda no userspace).
>
> humm, o X _pode_ derrubar a m�quina, mesmo rodando em userspace, j� que ele
> tem acesso iopl, acessando portas de forma direta, sem nem comunicar ao
> kernel.
Whoops... � verdade...
> > Outro � que mo LinuX ainda n�o d� um suporte muito bom para threads. Elas
> > acabam virando chamadas especiais para processos, o que � mais demorado. Como
> > a maioria dos programas gr�ficos hoje em dia fazem uso pesado de threads, este
> > � outro motivo para a perda de performance.
>
> humm, h� quem discorde, vide, por exemplo, esta thread (gigante) da lkml:
> Se procurarem por "Threads linux-kernel McVoy" no google, encontrar�o um
> monte de discuss�es sobre isto.
Fui l� conferir...
> S� para dar um gostinho:
>
> T�tulo da thread (uh, combinou ;) ): "Alan Cox quote?"
>
> raz�o da thread:
>
> "A Computer is a state machine.
> Threads are for people who can't program state machines."
> - Alan Cox
Com o devido respeito ao Alan Cox, aqui ele falou caca. Pelo que andei lendo
por a�, n�o � a primeira vez. � fato que M�quinas Von Newman s�o maquinas de
estado com mem�ria. � fato que h� d�cadas nossos computadores s�o m�quinas Von
Newman, e n�o conhe�o nada num futuro pr�ximo que nos liberte disto (existem
gargalos graves nas m�quinas Von Newman - os processadores modernos est�o
r�pidos gra�as � t�cnicas que aliviam estes gargalos).
Mas querer limitar o conhecimento humano � esta tecnologia � idiotice, e sim,
considero o coment�rio do Alan Cox sobre isto uma grande idiotice. As m�quinas
existem para nos servirem, n�o o contr�rio. O pensamento humano n�o � uma
m�quina de estados, os computadores devem se adaptar a n�s, n�o vice-versa. Se
neste processo eles perderem efici�ncia, azar o deles.
� fato que as threads est�o sendo cada vez mais usadas. Se � a melhor forma de
se dividir os sub-processos de um programa, esta discuss�o eu deixo em aberto
(mas eu creio que a melhor solu��o � uma mistura de ambas as t�cnicas - ali�s,
quase tudo na vida � assim). Mas isto n�o muda o fato de que compro um
computador hoje por uns 1000 reais. Por quanto eu compro um c�rebro novo
"thread-free" pra p�r na cuca?
Uma discuss�o extremamente superficial pode ser encontrada em
http://linux-br.conectiva.com.br/arquivo/2001/07/msg01338.html e seq��ncias,
onde eu digo o que eu penso sobre threads e processos. Inclusive, uma
explica��o muito detalhada do Thiago explicando porque as thredas se d�o mal
no Linux (um kernel monol�tico).
> > Mais um motivo � o alto gasto de mem�ria das aplica��es POSIX. A POSIX � bem
[...]
> > gasto muito maior de mem�ria no Linux que no Windows.
>
> humm, eu diria mais que as interfaces gr�ficas no Linux ainda n�o est�o
[..]
> mem�ria por n�o serem compartilhadas.
S�o pontos interessant�ssimos os seus, e n�o poderiam estar mais corretos. Mas
s�o, tbm, transientes. Eles comentam o estado atual das interfaces, mas elas
tendem a melhorar e otimizar seus recursos internos com o tempo. O pr�prio
Linux passou por este processo (algu�m aqui viveu os tempos do a.out?).
Mas existem os pontos que n�o v�o mudar nunca. O peso da camada POSIX � uma
delas. Outra, o fato das interfaces estarem sendo constru�das com m�quinas
high end em vista. Um exemplo pr�tico disto � o enlighenment (putz... nunca
consigo me lembrar como se escreve isto direito!). Ele tem um recurso
simplesmente fant�stico, que � deixar a janela transparente durante o arrasto.
L�gico que eu uso isto (fa�o pequenas concess�es � natureza humana de vez em
quando... heheheh), mas minha m�quina n�o chega a ser um micro popular =
embora pendurada num K6-2/500, a placa de v�deo � a GeForce2 com mem�ria DDR,
e com 256 megabytes de mem�ria 2-2-2.
Se eu pegar a mesm�ssima m�quina e colocar 16 (ou mesmo 32!!) mega de mem�ria
3-2-2 e uma placa de v�deo chunda, como as Trident ou aquelas Cirrus de 1
mega, duvi-de-o-d� que eu consiga rodar as mesmas interfaces com as mesmas
configura��es.
Pior ainda. A mesma m�quina, com a mesma mem�ria. S� com a placa de v�deo
chunda (j� fiz o teste). A placa simplesmente freia o resto do sistema no
englightement. Usando o fwvm, n�o.
> > Existem interfaces gr�ficas bem levinhas, como a fvwm, mas elas possuem um
> > look & feel bastante simples, com pouqu�ssimo uso de gr�ficos (o que as torna
> > mais leves!).
>
> ent�o tente o xfce, levinho e bonito.
Rolou uma discuss�o bastante extensa sobre isto aqui na Linux-br. D� uma
fu�ada em http://linux-br.conectiva.com.br/arquivo/2001/07/msg03839.html e nas
demais msgs com o mesmo subject.
Por fim, um site bastante completo : http://www.plig.org/xwinman/
[...]
> <plug>J� h� bastante tempo o Conectiva Linux, mesmo quando o usu�rio
> insiste em que ele instale todos os pacotes, n�o habilita nenhum dos
> servidores, sendo necess�rio habilita��o expl�cita pelo usu�rio</plug>
8-)
--
[]s,
([EMAIL PROTECTED])
Quote of week: The day Micro$oft makes something that doesn't suck is the day
they start selling vacuum cleaners.
Assinantes em 29/08/2001: 2270
Mensagens recebidas desde 07/01/1999: 129996
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
