Em Seg, 2007-10-01 às 15:15 -0300, Cabral escreveu: > Oi pessoal blz ? Eu li pelo site do liquuid sobre o haiku, resolvi > pegar o bonde andando. > > Queria corrigir uma coisa, o haiku não vai precisar nem usar o xorg > ainda bem. Ele têm um server proprio. O beos na epoca do lançamento do > 6 ia ter uma tecnologia similar ao quartz mais pegando bem mais fundo, > chamada picassogl. Eu li na lista que comentaram sobre emular pelo > vmware existe um build para qemu tambem. >
Esse servidor gráfico aceita aplicações linkadas com o xlib ? Posso migrar minhas aplicações X11 para o Beos sem mudar o código ? A grande vantagem do X11 é essa, portabilidade sem fronteiras, e é isso que fez o mac interessante pra muita gente, compatibilidade com o X. > r22396_raw.tar.bz2 > 01-Oct-2007 16:22:29 > 26.7 MB > > http://haikuhost.com/housestrain/ > > <quote> > > > Inclusive tinha 3 brasileiros (chegou a 90 após uma matéria na revista > do linux) no time que estava programando o file-system. > > </quote> > > De onde vc tirou esse numero de 90 brasileiros ? A muito tempo bati um papo por ICQ com um dos desenvolvedores , ele falou que depois de um artigo na revista do linux choveu gente na lista/fórum/seilá, fogo de palha. > > <quote> > > Bom, para cada uma das minhas críticas existem patchs ou soluções + ou > - viáveis, mas elas normalmente não trabalham juntas e são remendos > não uma solução. > > > </quote> > > Quais patchs vc se refere ? O rt do Ingo ? + adaptive > +ondemand-readahead ? + rcu ? + compressed caching ? Todos que não estão na árvore principal, kernel vanilla. São patchs não ? Todos que exigem patchs ou gambiarra nos makefiles pra fugir da árvore do FHS (coisa do linuxstep, e do gobo )... são "gambiarras" , se os programas fossem pensados de outra forma, nem que fosse como a galera do GNUstep pensou... /usr, /dev, /etc, /srv legal pra servidores, mas num desktop ? Não sei se ficou claro o que eu falei, o que eu quero dizer é que se desenvolve pro ambiente enterprise e depois se remenda pra atender o desktop. Quase todos os programas do linux são desenvolvidos com essa ótica, assim como o próprio kernel, os filesystems, o Xorg, o KDE, o GNOME... A milianos o povo do GNUStep mostrou uma nova forma de se desenvolver aplicativos totalmente integrados entre si, que dispensam gerenciadores de pacotes, daemons pra monitorar fontes, daemons pra controlar isso e aquilo, muito antes das convenções da freedesktop... Pacotes RPM e deb existem justamente devido a complexidade da árvore, a GNUStep propõe aplicativos com suas dependências secundárias, recursos, dados e configurações embaixo do diretório Nome.app, sendo suficiente copiar o diretório para ter o programa para outro sistema diferente (até mesmo distribuições diferentes ou versões diferentes da mesma). Isso já tá pronto, mas só a mesma dúzia de estudandes usa pros seus trabalhos de TCC. > > <quote> > > linux levar pau do haiku/mac/windows no quesito multimídia em tempo > real. > > </quote> > > O que seria multimídia em tempo real ? > Em benchmark o linux bate tanto mac quanto windows. > Mais se for ripar um dvd ou jogar o senario muda de figura a favor do > windows. Faz assim, pega sua distribuição favorita, compila um kernel vanilla do kernel.org, otimizado até o talo pra tirar a ultima gota de processamento possível, instale : jackd ardour hydrogen zynaddsubfx sooperlooper Abra todos, e grave suas saidas usando o ardour, se o som não pular baixa latência, se ele pular alta-latência. Claro que se sua placa de som for uma M-Audio da vida não faz muita diferença se o kernel tem baixa ou alta-latência, ele mastiga tudo. O Con Kolivas trampou pra melhorar isso, propondo um novo algoritmo pra gerenciar memória e recursos, melhorou muito, mas a resistência é tão grande dentro do proprio grupo que ele mesmo pulou fora. Sobre o linux bater o mac em processamento multimídia (vários canais de audio e vídeo entrando sendo processados e saindo ao mesmo tempo), adoraria ver isso, principalmente com o kernel da árvore principal. Enquanto em games 3d o linux mata o windows (fps) a pau (com placas nvidia), quando a tela enche de polígonos a latência da as caras, o tempo de resposta do mouse e teclado é prejudicado (doom3, quake4), testado na mesma máquina (tanto num amd64 quanto num Athlon XP, com placas Nvidia e dualboot). Por pior que o windows seja projetado, o processo burocrático entre o movimento do mouse e o DirectX é menor, o que me garante uma resposta no menor tempo possível, mesmo se a tela estiver cheia de poligonos e tocando 32 canais de áudio ao mesmo tempo. Adoro games, e os melhores eu compro original, dentre eles tenho doom3 e quake4 e para minha surpresa, aparentemente a galera do kernel mudou a API dos drivers de som e agora não tenho som em nenhum desses games com a nova versão do kernel 2.6.22.x ... E no meu lendário powerbook, agora é mudo... A solução é usar o kernel 2.6.18.x ... custa manter essas coisas simplesmente funcionando ? Pq diabos não se decide por um padrão ? Dizem que o windows é ruim por causa da retro-compatibilidade, mas o mac é bom e mantem a retrocompatibilidade com seus programas há pelo menos 6 anos. Num mundo onde tudo é software livre e todas as especificações são abertas eu não teria esses problemas, basta recompilar... Mas até esse mundo existir terei que usar outros sistemas operacionais ? Aguardo anciosamente pelo dia em que a IDsoft abrirá o código da engine doom3 assim terei som novamente nos meus dois games favoritos no linux com som, até lá, vou jogando no mac. -- LUN : #257752. http://www.liquuid.net Jabber: [EMAIL PROTECTED] http://www.flickr.com/photos/slave/ _______________________________________________ Lista de discuss�o da MetaReciclagem Envie mensagens para [email protected] http://lista.metareciclagem.org
