Bom, tentei de várias formas colocar o BrOffice (ou o OpenOffice mesmo) para funcionar, mas não dei, desinstalei e reinstalei várias vezes de diferentes formas, etc. Concluí então que eu ia precisar reinstalar o Sistema Operacional, pois ficar sem BrOffice seria impossível… Não pensei que iria precisar fazer isto com o Linux, mas não encontrei outra solução.

Ao fazer esta operação, me perguntei se não seria melhor testar alguma outra distribuição, já que esta versão do Ubuntu aparentemente tem apresentado alguns problemas (segundo muitos relatos pela Internet). Resolvi então tentar o Fedora 10 no Notebook, que eu já conhecia rodando em Servidor, mas sempre tinha evitado usar em Desktop (mais por preferência pelo kubuntu). Considerei também o Mandriva, mas por motivo desconhecido, o Live CD que testei não rodou no Notebook…

Depois da instalação e tudo funcionando, algumas diferenças já puderam ser notadas.

A primeira impressão é que o Fedora em geral é atualizado mais frequentemente. Pode ser somente impressão, mas pareceu. Por exemplo, enquanto o BrOffice estava na versão 3.0.1.7 no kubuntu, o Fedora já atualizou para o OpenOffice 3.0.1.15; enquanto o Kernel estava na versão 2.6.27.14 no kubuntu, no Fedora a atualização foi para a 2.6.27.19.

Em compensação, alguns itens comumente usados em Desktops, que no kubuntu são muito fáceis de instalar, são um pouco menos fácil no Fedora. Enquanto no kubuntu a instalação do plugin Flash e dos drivers para a placa de vídeo ATI foram automáticos apenas selecionando a opção na interface, no Fedora tive que seguir pequenos tutoriais para fazer a instalação manualmente — nada muito difícil, mas não foi automático.

Outra coisa que percebi é que o Fedora está rodando um pouco mais pesado que o kubuntu. No meu computador com 1,5 GB de RAM, o kubuntu chegava a 1 GB de uso com vários programas abertos e raramente usava o swap; já o Fedora tem chegado a 1 GB mesmo com poucos programas abertos e tem passado disto com mais programas em uso, além de trabalhar com o swap frequentemente. Não sei se a diferença é pela distribuição ou pelo uso do Gnome ao invés do KDE, mas é perceptível.

Bom, agora que tenho tudo configurado, vou continuar usando o Fedora por um tempo para ver. Se alguém souber alguma configuração que possa otimizar a execução do Fedora, principalmente o consumo de memória, aceito sugestões!

Se você não conhece o NX Server e gostaria de saber como ele funciona e como instalá-lo, existe um ótimo tutorial no Guia do Hardware: Usando o NX Server.

Nas versões mais novas do X, algumas alterações nas fontes podem causar problemas com o NX Server. No tutorial no Guia do Hardware existem algumas orientações que podem solucionar alguns destes problemas. Porém, eu fiz a instalação do NX Server no Fedora 10 e o erro foi diferente: neste caso, quando eu tentava me conectar a partir de um NX Client, um erro ocorria e os logs do NX no servidor mencionavam algo sobre a fonte fixed que não havia sido encontrada.

Depois de várias pesquisas, encontrei a solução: a fonte fixed no Fedora 10 estava no pacote xorg-x11-fonts-misc-7.2.6.fc9, bastou instalá-lo e em seguida o NX Client foi capaz de se conectar sem mais nenhum problema ou configuração adicional.

Abrir o Terminal e copiar os seguintes comandos:

sudo apt-get install ia32-libs lib32asound2 libasound2-plugins
wget -N boundlesssupremacy.com/Cappy/getlibs/getlibs-all.deb
wget -O skype-install.deb http://www.skype.com/go/getskype-linux-ubuntu-amd64
sudo dpkg -i skype-install.deb
sudo dpkg -i getlibs-all.deb
sudo getlibs -p libqtcore4 libqtgui4 bluez-alsa

Para mim funcionou perfeitamente, inclusive com a inclusão de um ícone para o Skype no menu Internet no KDE.

O que deu um pouco mais de trabalho foi a configuração do microfone para poder usá-lo no Skype. Na interface Linux do Skype não tem botão para controlar o nível do microfone, então é preciso configurá-lo antes de entrar no Skype, pois se o microfone estiver com volume baixo, o Skype não vai captar nada.

Não sei como seria no GNOME, mas pelo menos usando o KMix do KDE eu não consegui configurar o volume de entrada do microfone, somente o de saída, o que não adianta neste caso. Para conseguir realmente usar o microfone do Skype, utilizei o aplicativo AlsaMixer (se não estiver instalado, é só instalar pelo apt-get ou Adept. Ele roda no Terminal, portanto, é necessário abrir o terminal e digitar alsamixer.

Na tela do AlsaMixer, os primeiros controles que aparecem são os de saída, é preciso pressionar Tab para ativar os controles de entrada. Uma vez na configuração dos volumes de entrada, utilize as setas esquerda/direita para selecionar os controles, setas para cima/para baixo para controles os volumes, e a barra de espaços para ativar/desativar. Eu fiz o seguinte:

• Aumentei os controles Mic Boost para o máximo
• Selecionei cada um dos dois controles Capture, aumentei o volume e os ativei (com a barra de espaços)
• Selecionei cada um dos dois controles Input Source e selecionei a fonte do meu microfone — no caso da minha placa de som, descobri que Front Mic é o microfone interno do Notebook e Mic é o microfone conectado pelo plug; se houver mais de uma opção como o meu, é só ir testando com cada um

Abaixo uma figura mostrando como ficou na minha configuração. Depois de pronto, é só apertar Esc para sair e abrir o Skype: o microfone deve estar funcinando — ou pelo menos funcionou comigo. O controle de volume de saída do som pode ser controlado normalmente pelo ícone do volume.

É uma pena que o Skype para Linux seja bem pobre de recursos se comparado com as versões mais recentes para Windows. Espero que ele receba alguma atualização em breve… Aqui no meu computador também percebi que, em alguns momentos, o Skype fica lento e em outros até chega a travar, então, aparentemente, estabilidade também não é o forte desta versão (2.0.0.72). Recomendo certo cuidado no uso.

Uma observação: sobre o funcionamento do Skype com web cam não posso comentar nada, pois estou sem web cam no momento…

Seguem abaixo as instruções para quem quiser instalar. Elas foram encontradas ao longo de uma discussão no Ubuntu Forums e, pelo menos para mim, funcionaram.

Instalação automática

Existem alguns pacotes feitos por Daniel Freer para instalação automática do pSX no Ubuntu e postados na discussão citada.

Para o Ubuntu 8.10 64 bit, basta fazer o download e instalar os seguintes pacotes:

• lib32gtkglext1_1.2.0-3.2_intrepid-amd64.deb (91,0 kB)
• psx32_1.13-3.2_intrepid-amd64.deb (563,3 kB)

Também há o pacote para instalação no Ubuntu 8.10 32 bit:

• psx_1.13-3.2_intrepid-i386.deb (563,5 kB)

Para outras versões do Ubuntu, procure na discussão no fórum ou no site do Daniel, pois ele fez outros pacotes também.

O pacote do Daniel já deverá colocar um atalho para o pSX no menu. No entanto, antes de usá-lo, é necessário copiar um arquivo de boot do PlayStation. Este arquivo não pode ser distribuído livremente por questões legais, mas uma procura na Internet permite encontrá-lo — ele se chama SCPH1001.bin. Depois do download, é só copiar este arquivo para o diretório /usr/local/games/pSX/bios/ e executar o programa pelo menu.

Instalação manual

Caso a instalação automática não funcione por algum motivo na arquitetura 64 bit, também se pode tentar a instalação manual. Neste caso, basta abrir o terminal e executar os seguintes comandos, dentro do diretório onde ser quer instalar o pSX (que não pode ser o diretório /, por causa do pacote que será descompactado libgtkglext1_1.2.0-0ubuntu1_i386):

sudo apt-get install ia32-libs ia32-libs-sdl ia32-libs-gtk
wget http://psxemulator.gazaxian.com/pSX_linux_1_13.tar.bz2
wget http://mirrors.kernel.org/ubuntu/pool/universe/g/gtkglext/libgtkglext1_1.2.0-0ubuntu1_i386.deb
tar vx ./libgtkglext1_1.2.0-0ubuntu1_i386.deb
tar -xvzf ./data.tar.gz
sudo cp ./usr/lib/libg* /usr/lib32/
rm -rf ./usr
rm libgtkglext1_1.2.0-0ubuntu1_i386.deb
tar -xvjpf ./pSX_linux_1_13.tar.bz2
rm pSX_linux_1_13.tar.bz2

Da mesma forma que na instalação automática, é necessário copiar um arquivo de boot do PlayStation (veja acima). Depois de encontrar na Internet e fazer o download do arquivo SCPH1001.bin, ele deverá ser copiado para o diretório ./pSX/bios/ (sendo ./ o diretório onde foram executados os comandos acima).

Se tudo estiver certo, o programa pode ser executado pelo comando:

./pSX/pSX

Funcionando, agora é interessante criar um item no menu para executar o programa. No meu caso, como uso o KDE, isto foi feito da seguinte forma: clicar com o botão direito no Menu K, abrir o Editor de Menu, selecionar a opção Jogos na árvore, clicar em Novo Item, e preencher as seguintes informações:

Nome: pSX emulator
Comando: <diretório onde foi instalado o pSX>/pSX/pSX

Salvar as alterações e está pronto!

Por que é preciso copiar manualmente arquivos para /usr/lib32/?

Uma pergunta que pode surgir é por que é preciso copiar manualmente alguns arquivos para o diretório /usr/lib32/. A questão é programas de 32 bit rodando no Ubuntu 64 bit precisam ter acesso às libs que seriam instaladas em um sistema 32 bit. Muitas destas libs são instaladas no diretório /usr/lib32/ quando se instala o pacote ia32-libs, mas não é o caso da libgtkglext. É por isso que é preciso descompactar manualmente o pacote de instalação desta lib para a arquitetura 32 bit e copiar os arquivos para este diretório. Note que não é possível simplesmente instalar o pacote, pois, neste caso, o que seria feito seria substituir as libs correspondentes de 64 bit (no diretório /usr/lib/) pelas de 32 bit, causando uma bagunça no sistema.

Problema de “sound underrun”?

Aqui no meu computador, inicialmente, o emulador funcionava, porém o som ficava cortando e no terminal aparecia o erro “sound underrun”. Aparentemente, o meu sistema (AMD Turion 2.0 GHz) não dá conta do processamento com a configuração padrão. O que fiz foi diminuir um pouco a configuração e isto resolveu:

No pSX, menu Arquivo -> Configurações, aba Gráficos, mudei a opção 16bit display format para o valor GL_RGB5 (16bit 555). Além disso, na aba Som, precisei ajustar a latência. Para mim, o que funcionou foi a Latência em 80,0 ms e a Latência de sons XA em 40,0 ms. Mas o ideal é que elas sejam o menor possível, então, pode-se ir testando até ficar bom.

Finalmente, tudo funcionando!

Recentemente, encontrei um artigo que me pareceu unir as duas questões. Na verdade, o artigo é um pouco antigo, mas achei que valia a pena apresentá-lo novamente, porque já pode estar um pouco esquecido e também porque, nas referências a ele que encontrei em português, sempre se focou mais em outros aspectos, não neste.

Dois pesquisadores da Escola de Negócios de Harvard decidiram criar um modelo econômico da competição entre a Microsoft e o Linux pelo mercado e realizaram simulações para ver como cada um deve se sair na competição. Os resultados foram publicados em 2005.

O artigo é muito interessante e vale uma leitura com atenção  (em inglês), mas o que eu quero destacar aqui são apenas algumas das conclusões apresentadas.

Os autores chegaram a conclusão que vai ser muito difícil que qualquer um dos competidores consiga tirar o outro completamente do jogo. Porém, eles identificaram algumas coisas que podem ajudar ou prejudicar o avanço de um ou outro. Eles apontaram o que mais pode facilitar a adoção do software livre no lugar do proprietário e o que mais pode prejudicar:

• O que mais pode ajudar o software livre é a adoção por grandes empresas e governos;
• E o que mais pode prejudicar é o code forking, ou, na minha interpretação, no caso do Linux, a multiplicidade exagerada de distribuições.

No caminho inverso, recentemente foi noticiado que Linus Torvalds defendeu a multiplicidade de distribuições como algo “absolutamente necessário”.

Será que esta multiplicidade pode mesmo ser um dos fatores mais prejudiciais na batalha do software livre contra o proprietário? Infelizmente, a referência não explicava em maiores detalhes o porquê desta afirmação, mas até sugeria como uma das estratégias que a Microsoft poderia adotar para frear o avanço do Linux o estímulo ao code forking.

Pode-se ver que ainda há muito a se pensar neste sentido.

Há uma coisa, entretanto, que parece certa a curto prazo: se houvesse pelo menos uma padronização maior das distribuições, de forma que os aplicativos, drivers, configurações, etc. feitos em uma funcionassem sem grandes problemas na outra, a comunidade só teria a ganhar.

O que falta para que seja possível alcançar pelo menos este nível de padronização? E será que os pesquisadores acertaram ao dizer que o code forking atrasa a popularização do Linux? Se você tem alguma ideia, aproveite e deixe seu comentário!