Em Tue, Aug 28, 2001 at 04:01:00PM -0300, Lisias Toledo escreveu:
> Arnaldo Carvalho de Melo wrote:
> > 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
Espere, sua tradu��o ficou assim:
"Um computador � uma m�quina de estados.
Threads nunca devem ser usadas em hip�tese alguma"
?
A minha ficou assim:
"Um computador � uma m�quina de estados.
Threads s�o para pessoas que n�o conseguem programar m�quinas de estados."
Nada pejorativo, apenas a verdade, como voc� disse, o c�rebro n�o � uma
m�quina de estados, se algu�m quer programar como acha que seu c�rebro
funciona, est� livre para faz�-lo, n�o?
Outra tradu��o poss�vel (da id�ia em ingl�s para um texto em portugu�s):
"J� que um computador � uma m�quina de estados,
se fizermos nossos programas como m�quinas de estados, teremos melhor
desempenho"
Mas isto n�o impede ningu�m de fazer a besteira ou genialidade que desejar.
> 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.
Bem, azar o de quem for usar algo n�o otimizado para o que pagou (n�o
importa o pre�o).
> � fato que as threads est�o sendo cada vez mais usadas. Se � a melhor forma de
Bom, cigarros tamb�m continuam um sucesso ;)
PS.: sou fumante ;)
> 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?
heh, finalmente descobrimos como o cer�bro funciona?
> 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
Hey, que peso � este? E quem disse que temos que usar POSIX para sempre se
ele tiver este peso todo?
> high end em vista. Um exemplo pr�tico disto � o enlighenment (putz... nunca
sigh, se John Doe da Silva na Chech�nia fizer ainda mais um gerente de
janelas que exija muito mais m�quina que o enlightenment n�o quer dizer que
a "tend�ncia" do Linux (e aqui est� uma generaliza��o) � exigir mais m�quina.
> 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.
Hey, a Intel acabou de lan�ar m�quinas de 2 Ghz e a AMD tem m�quinas
velozes (agora n�o ter�o mais seu clock revelado ;) ) ;)
> 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.
e voc� esperava por isto?
> 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.
ent�o n�o use o enlightenment com esta placa "chunda"
> > > 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.
e? O ponto aqui era mostar que n�o � porque algu�m implementa uma interface
gr�fica pesada que devemos concluir que a tend�ncia � exigir mais m�quina
de forma desnecess�ria. Existem op��es. Se nenhuma delas for satisfat�ria
para algu�m, boa motiva��o para:
1. melhorar algo existente
2. reimplementar algo existente
3. inventar algo novo
Ou tem alguma empresa "por tr�s" do Linux? Lembre-se, esfor�o volunt�rio,
quer seja de empresas, quer seja de pessoas. Afinal, como o KTB diz, n�o �
gastando muito tempo para implementar algo e liberando "di gr�tis" que n�s
tomaremos nossas cervejas de fim de semana.
> Por fim, um site bastante completo : http://www.plig.org/xwinman/
j� conhecia, bem antigo, mas �til para quem quer usar interface gr�fica
- Arnaldo
Assinantes em 29/08/2001: 2278
Mensagens recebidas desde 07/01/1999: 130160
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
