Os lançamentos das próximas versões de distribuições Linux, poderão muito bem apontar o início do há anos falado ‘ano do Linux no desktop’. Esta discussão nunca foi algo que me preocupasse, mas acho NMHO que é desta. 😀
Para quem não viu ainda o estado do Compiz Fusion, e das novas capacidades do Avant Window Navigator prepare-se…
Não deve ser novidade para muitos a existência deste mapa, porém fica a referência interessante para a cronologia das várias distribuições GNU/Linux.
Relativamente a distribuições nacionais, está lá a Caixa Mágica, mas falta a Alinex, e talvez outras menos duradouras.
Parece que a o líder do projecto OLPC fez as pazes com a Intel.
Isto poderá contribuir para o sucesso do projecto ‘One Laptop Per Child’ (Um Portátil Por Criança), e para a sua viabilidade no âmbito do seu objectivo primordial, que é fornecer ferramentas para ajudar ao avanço de países menos desenvolvidos. A forma encontrada pelos responsáveis de ambos os lados é a de desenvolver uma cooperação para que seja implementada uma solução baseada numa ou outra plataforma, com base nas necessidades de cada local. Parece-me uma ideia sensata, apesar de a plataforma da Intel não me parecer assente nos mesmos princípios com que foi iniciado o projecto OLPC.
Sendo o projecto OLPC um excelente exercício (e se tudo correr bem, uma solução) para a criação de um conceito novo de utilização do computador e proliferação de conhecimento, é sem dúvida importante que exista cooperação dos possíveis concorrentes ao produto final.
O XO não é mais um portátil, mas barato, como o Classmate. Gira em torno desta questão (ser mais barato) um esforço tremendo para criar algo inovador e verdadeiramente revolucionário na área da informática.
Na minha opinião, o mais importante do projecto OLPC é a plataforma de software que está em desenvolvimento, todo o estudo feito para arranjar soluções para as dificuldades existentes no terreno. Se a Intel tivesse sido um apoiante desde o início do projecto será que o preço do XO tinha saltado para os $175? Será que não seria possível manter o valor de $100? E isto sem colocar de lado a possibilidade de a Intel fornecer equipamentos como o Classmate, mas pelo menos o objectivo principal era o software e o conteúdo, deixando-se de lado as guerras de quem tem o computador mais barato, não criando confusão aos responsáveis pela decisões de implementação em cada país. Afinal o Classmate corre sistemas operativos “normais”, mas será que isso é uma mais valia? Será que esses são a melhor forma de computação e aprendizagem? Que está à frente do desenvolvimento do software para o XO acha que não, e eu concordo com eles, apesar de ainda não ter tido a sorte de ver como funciona o XO. 🙂
Está disponível para compra o FIC Neo1973, um telemóvel livre, baseado na plataforma OpenMoko.
A versão actual é direccionada a programadores, a versão para utilizadores finais está planeada para Outubro.
Em termos de capacidades a versão actual tem:
– Ecrã de 2.8″ VGA (640×480), sensível ao toque e usável com uma caneta ou com os dedos
– Processador Samsung a 266MHz
– 64MB de memória flash
– USB 1.1 sem alimentação, mas com suporte para periféricos
– AGPS integrado
– GSM 2.5G quad band
– Bluetooth 2.0
– Suporte para cartões Micro SD
A versão que vai sair em Outubro adiciona:
– WiFi 802.11 b/g
– Novo chip Samsung 2442 SoC
– Chip gráfico SMedia 3362 com aceleração
– 2 sensores de movimento 3D
– 256MB de memória flash
– Bateria com maior capacidade: 1700mAh
– Processador a 400MHz
E isto por $450, ou seja, cerca de €330. Traz um cartão de 512Mb, um cartão micro SD de 2GB custa à volta de €25, se quisermos ter mais espaço. A duração da bateria não é algo certo (as medidas da versão actual são pouco animadoras no meu ponto de vista…), e não me parece que venha a ter câmara integrada para já.
Um sistema bastante capaz e completamente livre!
Claro que uma solução ainda melhor, e explicada de forma satisfatória neste artigo no Viva Linux, é conjugar o XMMS com o dbmix.
Ganha-se um interface simples e eficaz com controlo de volume, pitch, suporte de sampling e N canais distintos e também controlo de playlists unificado. Está em banho maria desde 2002, mas funciona. Portar isto para gtk2 e rejuvenescer o interface não era mal pensado… 🙂
Também tem suporte para cueing numa placa de som independente.
No meu setup não funciona bem ao nível do hardware. Mas calculo que seja uma conjugação de factores, ter uma placa no bus USB, mau suporte da placa onboard e da USB, problemas de latência, etc.
Será que a libertação da versão em condições do OSS vai mudar o panorama actual?
Melhor que usar o XMMS para este fim, talvez seja usar o Audacious. Baseado no XMMS tem um feeling mais actualizado e parece-me que o desenvolvimento continua. As notícias no site do XMMS parecem ser actualmente anúncios cheios de sarcasmo quando uma distribuição qualquer deixa de ter o XMMS nos repositórios… 😛
Podemos usar o truque que usei para o XMMS de redefinir a variável de ambiente $HOME para ter configurações independentes para cada player, mas no Audacious não é assim tão simples, porque algumas coisas ficam na directoria principal de configuração, como as presets de equalização, mas isso não é algo negativo, já que basta definirmos as que pretendemos usar e ficam disponíveis nos dois players e no player principal.
Além disso não existe opção de várias instâncias nas configurações do Audacious, mas podemos editar o ficheiro de configuração para obter essa funcionalidade.
As minhas configurações estão disponíveis aqui.
O mais certo é ser necessário reconfigurar a posição de cada janela, etc, depois de correr o script de arranque das duas instâncias.
Da próxima vez que o script for lançado estará tudo como ficou, inclusive as posições das janelas.
Quanto a equalização as principais presets serão o corte das frequências agudas, graves e médias (vozes e idênticos). Eu estou a usar este ficheiro que pode ser copiado para $HOME/.audacious/eq.preset.
Graças ao esforço do Jono em incentivar quem pegue nesta matéria, estive a brincar com os exemplos dele, no Eclipse+PyDev (entretanto fartei-me das manias do Eclipse e passei a usar o PyPe) e no Glade.
Fiz um simples player com controlo de pitch, ganho de volume e bending. 🙂
O código foleiro em Python está aqui, e o interface glade, aqui.
Entretanto refiz o GUI e estou a tentar fazer alguma coisa de jeito e usável (o código actual está aqui). 🙂
Com o poder que os pipelines do GStreamer permitem, talvez consiga aquilo que pretendo, um player simples com controlo de pitch e possibilidade de definir as opções do sink para poder usar duas placas de som independentes. Até os kill switches devem ser simples de implementar (adicionando um bpwsinc ao pipeline ou algo do género), só não sei como será a latência… 😛
Alteração ao GUI para os kill switches:
Muito obrigado Jono!
Este será o primeiro do acompanhar de uma ideia que andava há vários meses para experimentar, usar placas de som baratas USB para misturar música.
Comecei por adquirir um par de placas USB baratas. Em Linux funcionam na perfeição, são do mais simples possível, uma saída e uma entrada. Tive alguns problemas de latência se usar ambas num hub USB, mas este hub não tem alimentação, nem tenho a certeza que suporte a versão 2.0 do protocolo USB, mas poderá ser que o tráfego no barramento USB seja demasiado para duas placas em simultâneo. 🙂
Tenho para aqui uma mesa de mistura com a minha idade, mas que já tem crossfader, dado que a equalização será feita por software também é desprezável o facto de não haver equalização por canal na mesa.
Para já testei ambas as placas a funcionar com o xmms e corre tudo sem problemas, dado que as ligue a portas USB independentes sem passar pelo hub. A minha ideia era usar o mixxx, mas ainda não suporta várias placas de som… por isso vou para já fazer uns testes com o mais que testado xmms.:)
Para poder ter duas instâncias de xmms sem partilha de definições, configurei o xmms como queria (activei o suporte para múltiplas instâncias):
Depois criei uma pasta onde vou guardar as definições de cada instância, chamei-lhe xmms. O xmms recorre apenas à variável $HOME para saber onde está o directório onde guardará as suas definições, daí podermos mudá-lo a nosso favor.
Criei o seguinte script bastante simples para gerir o arranque das duas instâncias e no meu caso chamei-lhe launch_xmms:
#! /bin/bash
# Player 1
export HOME=$PWD/player1
xmms&# Player 2
export HOME=$PWD/player2
xmms&
Dei-lhe permissões de execução com
chmod +x launch_xmms
Depois criei dois directórios, player1 e player2, para onde copiei a configuração original do xmms:
cp -r $HOME/.xmms player1 && cp -r $HOME/.xmms player2
Agora posso correr o script de arranque e tenho duas instâncias do xmms com definições independentes entre si e do xmms normal:
./launch_xmms
Agora em cada instância defino a placa de saída, hw:1,0 e hw:2,0:
Agora falta apenas ligar as placas à mesa e testar. Com o suporte de filtros LADSPA do xmms posso usar os filtros disponíveis para esta framework no xmms, inclusive controlo de pitch, além de haver um plugin também para esse fim.
Nos próximos posts pretendo documentar melhor todo o processo com mais imagens e fotografias e talvez alguns samples do resultado.
Aspecto exemplificativo:
