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!

Veja também:
Transferindo uma instalação do Mailman entre servidores
Renomeando uma lista do Mailman

Para a minha necessidade, o script deveria fazer o seguinte:
1- Obter um arquivo CSV com uma lista de filiados a uma Instituição, a partir de um endereço de um sistema Web
2- Gerar uma lista de endereços de e-mails dos filiados ativos. A situação do filiado ficava no 24º campo do CSV e o e-mail no 18º campo.
3- Limpar os membros de uma lista de e-mails do Mailman e carregar novamente a lista de endereços recém gerada.

O script que fiz foi o seguinte. É claro que, dificilmente, alguém terá necessidades exatamente iguais às minhas, mas fica um exemplo que pode ser adaptado conforme a necessidade. Este script foi feito e testado no Fedora 10.

#! /bin/bash

wget -O membros.csv https://www.site.com.br/sistema/get_filiados.asp

IFS=$'\r'
for line in $(cat membros.csv)
do
  situacao=`echo -e "$line" | cut -d ';' -f 24`
  email=`echo -e "$line" | cut -d ';' -f 18`
  if [ $situacao = "Ativo" ]
  then
    echo -e "$email"
  fi
done >emails_membros.txt
IFS=$

/usr/lib/mailman/bin/remove_members -a -n -N nome-lista
/usr/lib/mailman/bin/add_members -r emails_membros.txt -w n -a n nome-lista

A linha “IFS=$’\r’” define o separador de campos, para identificar as quebras de linhas. Como o sistema que gera o CSV funciona com ASP em servidor Windows, ele gera o arquivo com ‘\r’ ao invés de ‘\n’.

As opções “-a -n -N” na remoção dos membros e “-w n -a n” na adição fazem com que nem os membros nem os administradores da lista recebam e-mails de confirmação de inscrição/desinscrição. Como esse era um script para ser executado diariamente, não seria boa ideia enviar avisos diários para cada um.

Depois de testado o script, movi para o diretório /etc/cron.daily para que ele fosse executado automaticamente e já está funcionando há algumas semanas sem problemas.

Veja também:
Transferindo uma instalação do Mailman entre servidores
Atualização automática dos membros de uma lista do Mailman

As instruções a seguir foram encontradas no blog de Chris Lamb e funcionaram bem no Fedora 10 com mínimas alterações. Lembrando que, no Fedora, todos os comandos devem ser executados com o usuário root ou, no Ubuntu, todos com “sudo” na frente.

Primeiro, sugere-se criar variáveis com o nome das listas para facilitar a digitação e evitar erros. Confira bem os nomes definidos nestas variáveis!

OLD=old-list-name
NEW=new-list-name
set -u

Em seguida, parar o Mailman enquanto a operação é realizada:

/etc/init.d/mailman stop

Os comandos a seguir movem os arquivos da lista e geram novamente os aliases (que fazem o Postfix encaminhar os e-mails recebidos para o Mailman):

mv /var/lib/mailman/lists/${OLD} /var/lib/mailman/lists/${NEW}
mv /var/lib/mailman/archives/private/${OLD} \
  /var/lib/mailman/archives/private/${NEW}
mv /var/lib/mailman/archives/private/${OLD}.mbox \
  /var/lib/mailman/archives/private/${NEW}.mbox
mv /var/lib/mailman/archives/private/${NEW}.mbox/${OLD}.mbox \
  /var/lib/mailman/archives/private/${NEW}.mbox/${NEW}.mbox
/usr/lib/mailman/bin/arch ${NEW}

Se quiser que as mensagens para o endereço antigo da lista sejam encaminhados para a lista nova, devem ser criados alguns aliases para direcionamento.

cp /etc/aliases `mktemp aliases-backup.XXXX`
printf "\\n# '${OLD}' -> '${NEW}' mailing list rename \\n" | \
  sudo tee --append /etc/aliases
echo "${OLD}: ${NEW}" | tee --append /etc/aliases
for SUFFIX in \
  admin bounces confirm join leave owner request subscribe unsubscribe; \
  do \
    echo "${OLD}-${SUFFIX}: ${NEW}-${SUFFIX}" | tee --append /etc/aliases; \
  done

Agora, deve-se abrir a página de administração da lista pelo browser (que já deverá estar com o nome novo) e, na parte de configurações gerais, alterar o Nome Real, o Prefixo e qualquer outra informação desejada, para incluir o novo nome. Se quiser que os e-mails com o endereço antigo também sejam recebidos, nas opções de Privacidade, Filtro de Destinatários, incluir o nome antigo da lista nos aliases aceitos.

Finalmente, já é possível terminar a operação e ativar o Mailman novamente:

newaliases
/usr/lib/mailman/bin/genaliases
/etc/init.d/mailman start

Por último, não esquecer de avisar os usuários sobre a alteração!

Neste post, vou mostrar como transferir uma instalação do Mailman entre servidores.

Veja também:
Renomeando uma lista do Mailman
Atualização automática dos membros de uma lista do Mailman

No meu caso, eu estava transferindo uma instalação do Mailman de um antigo Fedora 7 para um novo servidor com Fedora 10 e o Mailman 2.1.11.

O primeiro passo, logicamente, é instalar o Mailman no novo servidor se ainda não estiver (no caso do Fedora, isto é feito com o comando “yum install mailman” no Terminal com usuário root, para Ubuntu, “sudo apt-get install mailman”).

Antes de continuar, algumas observações:

Obs. 1: Todos os comandos indicados a seguir precisam ser executados com usuário root, no Fedora basta executar “su -” e digitar a senha de root antes de começar os comandos, no Ubuntu, coloca-se “sudo” antes de cada comando.
Obs. 2: As instruções assumem que o servidor SMTP usado é o Postfix. Caso não seja, é preciso ver como fazer as configurações equivalentes no servidor SMTP utilizado.

Depois de instalado o Mailman, é necessário criar uma primeira lista de e-mails chamada”mailman”. Para isto, no terminal, executar o comando:

/usr/lib/mailman/bin/newlist mailman

No final da criação da lista, serão mostrados alguns “aliases” de e-mail que precisarão ser configurados no Postfix:

# a lista de discussão mailman
mailman:              "|/usr/lib/mailman/mail/mailman post mailman"
mailman-admin:        "|/usr/lib/mailman/mail/mailman admin mailman"
mailman-bounces:      "|/usr/lib/mailman/mail/mailman bounces mailman"
mailman-confirm:      "|/usr/lib/mailman/mail/mailman confirm mailman"
mailman-join:         "|/usr/lib/mailman/mail/mailman join mailman"
mailman-leave:        "|/usr/lib/mailman/mail/mailman leave mailman"
mailman-owner:        "|/usr/lib/mailman/mail/mailman owner mailman"
mailman-request:      "|/usr/lib/mailman/mail/mailman request mailman"
mailman-subscribe:    "|/usr/lib/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe:  "|/usr/lib/mailman/mail/mailman unsubscribe mailman"

Abra o arquivo /etc/aliases e confira se as linhas acima estão no final do arquivo, se não estiverem, elas devem ser adicionadas. Neste caso, depois de incluir as linhas no arquivo /etc/aliases e salvá-lo, executar o comando:

newaliases

No arquivo /etc/httpd/conf.d/mailman.conf, recomenda-se habilitar o direcionamento do endereço do mailman, para que um acesso à www.nomedosite.com.br/mailman seja redirecionado para a página de informações sobre as listas. Para isso, a última linha do arquivo deve ser descomentada (apagar o símbolo #) e o nome do servidor www.example.com deve ser substituído pelo nome real, por exemplo:

RedirectMatch ^/mailman[/]*$ http://www.nomedosite.com.br/mailman/listinfo

O próximo passo é copiar as listas de e-mails do servidor antigo, assim como todos os seus dados, para o servidor novo. Para isto, basta copiar o conteúdo completo do diretório /var/lib/mailman do servidor antigo para o mesmo local no servidor novo.

Também é preciso copiar os arquivos /etc/mailman/aliases e /etc/mailman/aliase.db do servidor antigo para o novo. As permissões destes arquivos devem ser alteradas para serem acessadas pelo usuário mailman. No meu caso, alterei os dois arquivos para ter o grupo mailman como dono:

chown root:mailman /etc/mailman/aliases
chown root:mailman /etc/mailman/aliases.db

Confira se estes dois arquivos estão no banco de dados de aliases do Postfix: abra o arquivo /etc/postfix/main.cf e procure as linhas que começam com alias_maps e alias_databases, acrescentando o /etc/mailman/aliases no final se não estiver, por exemplo:

alias_maps = hash:/etc/aliases,hash:/etc/mailman/aliases
alias_database = hash:/etc/aliases,hash:/etc/mailman/aliases

Para estas configurações no Postfix serem atualizadas, executar o comando newaliases novamente e reiniciar o Postfix:

newaliases
service postfix restart

Finalmente, só falta um comando, que irá criar a senha de administrador do Mailman. Lembre-se que esta será a senha para criar novas listas e administrar as existentes.

/usr/lib/mailman/bin/mmsitepass

Pronto! Abra o seu navegador no endereço do Mailman (www.nomedosite.com.br/mailman) e todas as listas que existiam no servidor antigo deverão estar no servidor novo, com todas as configurações, os membros e os arquivos de mensagens antigas.

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!

A leitura do artigo original é um pouco difícil, pois, além de estar em inglês, é um artigo da área de economia, mas é interessante ler pelo menos a introdução e a conclusão.

Sintetizando, o autor analisou a questão da compatibilidade entre diferentes plataformas de hardware/software e montou um modelo dos efeitos econômicos e sociais da existência de compatibilidade ou incompatibilidade entre elas. A conclusão é que o caso mais comum encontrado é o de uma plataforma que domina o mercado e cujo fornecedor propositalmente a mantém incompatível com as demais plataformas para alcançar maiores lucros. Isto faz com que a compatibilidade entre diferentes plataformas, que seria o ideal do ponto de vista social, segundo o autor, dificilmente seja alcançada.

Este modelo talvez explique as dificuldades encontradas para a definição de alguns padrões mundiais que beneficiariam muito a sociedade, por exemplo, o que ocorreu recentemente quanto à definição de padrões para documentos, em que acabamos ficando com dois padrões — Open Document e Open XML — e, pelo menos por enquanto, a existência de aplicativos totalmente compatíveis com ambos os padrões não foi alcançada.

Será que isto quer dizer que, infelizmente, em algumas áreas, nunca poderemos ter plataformas totalmente compatíveis de hardware e software?

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!