Contudo esta versão não funciona com kernel 2.6.33, mas esta lista de bugs do gentoo tem um patch que permite a compilação sem problemas.

Basicamente os erros são estes:

- No arquivo /usr/share/ati/fglrx-install.log:

cd /var/lib/dkms/fglrx/8.723/build; sh make.sh --nohints \
   --uname_r=2.6.33.2-diesel-amd64-1 --norootcheck....(bad exit status: 1)
0
0
[Error] Kernel Module : Failed to build fglrx-8.723 with DKMS
[Error] Kernel Module : Removing fglrx-8.723 from DKMS

- O arquivo /var/lib/dkms/fglrx/8.723/build/make.log apresenta os erros:

firegl_public.c:1473: error: variable or field ‘__ret’ declared void
firegl_public.c:1473: error: variable or field ‘__old’ declared void
firegl_public.c:1473: error: variable or field ‘__new’ declared void
make[2]: ** [/var/lib/dkms/fglrx/8.721/build/2.6.x/firegl_public.o] Erro 1
make[1]: ** [_module_/var/lib/dkms/fglrx/8.721/build/2.6.x] Erro 2
make[1]: Saindo do diretório `/usr/src/linux-2.6.33.2'

Passos para a instalação 

Estes passo foram realizados utilizando um kernel versão 2.6.33.2 amd64 em um Debian Squeeze para uma Radeon Mobility HD 3200

1. Baixar o arquivo ati-driver-installer-10-4-x86.x86_64.run de http://support.amd.com

2. Tornar o arquivo executável:

#chmod 755 ati-driver-installer-10-4-x86.x86_64.run

3. Extrair os arquivos de instalação para a pasta ati-installer (ou outra qualquer)

./ati-driver-installer-10-4-x86.x86_64.run --extract ati-installer

4. Baixar o arquivo 2.6.33-10.2-fix_compilation.patch e copiar para a pasta ati-installer/common/lib/modules/fglrx/build_mod

5. Ir para a pasta ati-installer/common/lib/modules/fglrx/build_mod e aplicar o patch:

#patch -p6 < 2.6.33-10.2-fix_compilation.patch

6. O compilador tenta localizar os arquivos utsrelease.h e autoconf.h na pasta /lib/modules/<kernel-version>/build/include/linux/, por isto é necessário copiar estes arquivos da pasta /usr/src/<kernel-source>/include/generated/ ou criar um link simbólico. No meu caso eu criei um link simbólico:

#ln -s /usr/src/linux-2.6.33.2/include/generated/utsrelease.h \
      /lib/modules/2.6.33.2-diesel-amd64-1/build/include/linux/
#ln -s /usr/src/linux-2.6.33.2/include/generated/autoconf.h \
     /lib/modules/2.6.33.2-diesel-amd64-1/build/include/linux/

7. Executar o instalador na pasta ati-installer:

./ati-installer.sh nada –install

Se estiver no modo gráfico, aparecerá a janela de instalação, e na janela do console não deverá aparecer nenhum erro.

O arquivo /usr/share/ati/fglrx-install.log deve se parecer com este:

Creating symlink /var/lib/dkms/fglrx/8.723/source ->
                 /usr/src/fglrx-8.723

DKMS: add Completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area....
cd /var/lib/dkms/fglrx/8.723/build; sh make.sh --nohints --uname_r=2.6.33.2-diesel-amd64-1 --norootcheck.......
cleaning build area....

DKMS: build Completed.

fglrx.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.33.2-diesel-amd64-1/updates/dkms/

depmod....

DKMS: install Completed.

8. Modificar o arquivo /etc/X11/Xorg.conf manualmente ou com o comando:

#aticonfig --initial -f

Eu uso um notebook e um monitor externo, então o meu arquivo /etc/X11/xorg.conf está assim:

# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerLayout"
	Identifier     "aticonfig Layout"
	Screen      0  "aticonfig-Screen[0]-0" 0 0
EndSection

Section "Files"
EndSection

Section "Module"
EndSection

Section "ServerFlags"
	Option	    "Xinerama" "off"
EndSection

Section "InputDevice"
	Identifier  "Generic Keyboard"
	Driver      "kbd"
	Option	    "XkbRules" "xorg"
	Option	    "XkbModel" "abnt2"
	Option	    "XkbLayout" "br"
	Option	    "XkbVariant" "abnt2"
EndSection

Section "InputDevice"
	Identifier  "Configured Mouse"
	Driver      "mouse"
EndSection

Section "Monitor"
	Identifier   "Configured Monitor"
EndSection

Section "Monitor"
	Identifier   "aticonfig-Monitor[0]-0"
	Option	    "VendorName" "ATI Proprietary Driver"
	Option	    "ModelName" "Generic Autodetecting Monitor"
	Option	    "DPMS" "true"
EndSection

Section "Device"
	Identifier  "Configured Video Device"
EndSection

Section "Device"
	Identifier  "aticonfig-Device[0]-0"
	Driver      "fglrx"
	Option	    "MonitorLayout" "CRT1,LCD"
	BusID       "PCI:1:5:0"
EndSection

Section "Screen"
	Identifier "Default Screen"
	Monitor    "Configured Monitor"
EndSection

Section "Screen"
	Identifier "aticonfig-Screen[0]-0"
	Device     "aticonfig-Device[0]-0"
	Monitor    "aticonfig-Monitor[0]-0"
	DefaultDepth     24
	SubSection "Display"

 # x y resolution of both screens!
		Viewport   0 0
		Virtual   2720 900
		Depth     24
	EndSubSection
EndSection

9. Reiniciar o computador e está feito.

Boa sorte!

Em CPD's com muitos servidores existe a necessidade de constante refrigeração da sala de equipamentos, visto que eles produzem grande quantidade de calor.

Como qualquer outro equipamento, o sistema de refrigeração também podem apresentar problemas, deixando de refrigerar a sala de servidores, o que pode ocasionar o superaquecimento dos mesmos levando-os a falhar e deixar de prestar os serviços de um CPD.

Para estes casos é necessário estar prevenido com, no mínimo, um sistema de controle de temperatura da sala, para que sejam tomadas as providências antes do superaquecimento. Com um sistema de controle também é possível fazer o levantamento estatístico e histórico das falhas de refrigeração, para verificar se é necessário melhorias ou exigir da empresa terceirizada melhor qualidade no serviço de refrigeração.

Em tempos de recessão, programas de redução de custos, e demora na compra de equipamentos novos, fica inviável solicitar à empresa a compra de um sistema monitor de temperatura de ambientes. Nestas horas é necessário se utilizar da criatividade e procurar soluções alternativas.

Nestas condições a Internet é a nossa principal fonte de informação e pesquisa, e o Software Livre a solução para a maioria dos problemas envolvendo custos.

Muitos sites dão informações completas de como construir um sistema de monitoramento de temperatura baseado no sensor Dallas DS18S20  e um software chamado DIGITEMP, e tentarei aqui reproduzir algumas destas informações e instruções de como montar este sistema.

O DIGITEMP é um software desenvolvido para Linux que se comunica com o sensor de temperatura Dallas DS18S20 através da porta serial do computador. Para fazer esta comunicação, é necessário uma interface, que pode ser construída com poucos componentes.

Construindo o sensor

Existem vários modos de construir a interface, variando de acordo com a distância do cabo e a forma de energizar o circuito. A forma mais simples é o modo parasita, em que a energização do componente se dá através da linha de dados da porta serial.

Para construir a interface serial são necessários os seguintes componentes:

Para o cabo foi utilizado um cabo telefônico comun de duas vias.

Os componentes devem ser montados conforme o esquema abaixo:

No modo parasita, é necessário unir os pinos GND e Vdd. Os números no lado da porta serial representam os pinos do conector DB9.

É possível utilizar vários sensores em paralelo, pois cada componente utiliza um identificador único de 64bits, formando um barramento chamada 1-Wire Bus. O esquema abaixo representa vários sensores ligados em paralelo:

Antes de soldar os componentes na placa, é interessante montá-los em uma protoboard:

Para montar os componentes na placa, peguei a dica no site Pontas da Madrugada. O desenho na placa de fenolite ficou assim:

Após soldar os componentes na placa e encaixá-lo no conector DB9, o resultado ficou assim:

A solda não ficou esteticamente perfeita, mas o mais importante é não ter nenhum curto-circuito e nenhuma solda fria. O conector RCA fêmea teve que ser reduzido para caber na capa do DB9. A parte externa do conector RCA ficou como GND, e a parte interna, os dados.

O sensor foi soldado em uma extremidade do cabo, e na outra, o conector RCA macho:

O resultado final ficou assim:

Software para comunicação com o sensor

O Digitemp pode ser baixado do site http://www.digitemp.com ou do repositório oficial da distribuição. No debian pode ser baixado com o comando:

#apt-get install digitemp

O próximo passo é criar o arquivo de configuração com o identificador do sensor:

#digitemp_ds9097 -s /dev/ttyUSB0 -i
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Turning off all DS2409 Couplers
.
Searching the 1-Wire LAN
10F2EFF0010800FE : DS1820/DS18S20/DS1920 Temperature Sensor
ROM #0 : 10F2EFF0010800FE
Wrote .digitemprc

Para obter a temperatura do sensor usa-se o comando:

#digitemp_ds9097 -t0 -c .digitemprc
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 - http://www.digitemp.com
Apr 27 22:33:02 Sensor 0 C: 24.25 F: 75.65

Traçando gráficos de acompanhamento

O pacote do Digitemp fornece alguns scripts para gerar gráficos armazenados em um banco de dados RRD. Utilizando vários sensores pode-se conseguir um resultado como este:

Note que no gráfico os valores estão em Fahrenheit (F), mas pode-se configurar o Digitemp para exibir em Celcius (C).

O Nagios possui alguns plugins para o monitoramento de temperatura, como o check_temperature e o check_digitemp. 

Dificuldades e problemas

Para desenvolver este projeto encontrei algumas dificuldades. A primeira delas foi encontrar o sensor Dallas DS18S20 em lojas de eletrônica. As principais lojas em Porto Alegre (Severo Roth, RF, etc) nem sequer tinham este componente no cadastro, ou seja, nunca foi vendido por eles.

Segui a dica de um colega de trabalho (obrigado Ronaldo!) e entrei no site do fabricante Maxim (http://www.maxim-ic.com/) e solicite algumas amostras. Recebi-as em 30 dias. Obrigado Maxim!

Importante: Todos os sites indicavam o sensor DS1820, mas segundo a Maxim ele foi substituido pelo DS18S20, e o que eu recebi foi o DS18S20+, que funcionou perfeitamente.

A segunda e maior dificuldade foi: O sistema não funcionou no primeiro teste. Nenhuma mensagem de erro era apresentado. Simplesmente o sensor não era lido. Tira componente, testa componente, baixa código fonte, compila código fonte… Muitos sites na internet informam que os notebooks não fornecem a carga necessária de energia na serial para alimentar o sensor, e quase nenhum informa sobre o funcionamento com um adaptador USB-Serial que, no meu caso, tive que utilizar, pois o notebook não tem porta serial. Testei inclusive com uma placa ExpressCard RS232. Nada funcionava. Verifiquei que existem outras formas de construir a interface serial, com componentes extras para gerar alimentação para o circuito, mas não os construí, pois não tinha nenhum desses outros componentes.

Por sorte, testando os componentes na protoboard tive uma surpresa. Notei que quando o pino RXD era plugado na protoboard uns 2 segundo após rodar o programa digitemp, ele conseguia ler os dados. Ótimo sinal!

Após verificar o código-fonte, e incluir uma porção de mensagens de debug, notei que o problema acontecia na inicialização da porta serial, talvez por eu estar utilizando um adaptador USB-Serial.

Procurando novamente por uma solução, encontrei no site http://www.felskowski.pl/ uma correção para um problema de inicialização da porta serial. Testei-o e funcionou. O patch de correção é o seguinte:

--- digitemp-3.6.0.old/userial/ds9097/linuxses.c        2007-06-07 23:25:58.000000000 +0200
+++ digitemp-3.6.0/userial/ds9097/linuxses.c    2009-12-24 04:27:25.000000000 +0100
@@ -55,7 +55,7 @@
SMALLINT owAcquire(int portnum, char *port_zstr)
{
/* Open the serial port */
-   if ((fd[portnum] = open(port_zstr, O_RDWR)) == -1)
+   if ((fd[portnum] = open(port_zstr, O_RDWR|O_NONBLOCK)) == -1)
{
OWERROR(OWERROR_GET_SYSTEM_RESOURCE_FAILED);
perror("owAcquire: failed to open device");

A diretiva 0_NONBLOCK instrui o programa para não ler absolutamente nada da porta serial após abrí-la, como teste de abertura.

Informações extras

Como informado antes, utilizei um adaptador USB-Serial PL2303 e um cartão ExpressCard RS232 também por coincidência PL2303. Ambos forneciam a porta /dev/ttyUSB0.

Referências

Muitas sites foram consultados para este projeto. Relaciono-os abaixo:

• Digitemp. http://www.digitemp.com
• FELSKOWSKI.PL. http://www.felskowski.pl/
• Maxim IC. http://www.maxim-ic.com/
• Pontas da madrugada. http://pontasdamadrugada.blogspot.com/2009/06/monitorando-temperatura-externa.html
• Informationen zu den Themen der Elektrischen Messtechnik und des Qualitätsmanagements. DS18S20 Temperature Sensor. http://public.rz.fh-wolfenbuettel.de/~hamannm/general/digitemp.html
• Temperaturmessung mit Linux. http://lena.franken.de/hardware/temperaturmessung.html
• MartyBugs.net - Serial Port Temperature Sensors. http://martybugs.net/electronics/tempsensor/
• Monitor temperatures with Linux, Nagios, and DS1820. http://www.hoppie.nl/tempsens/

Basicamente é necessário 2 transformações:

1. Remove o filtro IR presente na webcam;
2. Colocar outro filtro, que permita a passagem somente de infra-vermelho;

Mostrarei um passo-a-passo de como realizar esta transformação em uma webcam Vtrex 120fps. Fiz em outra webcam também, e os passos são todos iguais. Acredito que o procedimento possa ser realizado em qualquer webcam.

1. Remover a tampa da webcam e retirar os parafusos da placa lógica.

2. Remover a tampa frontal da lente. Basta puxar que ela é encaixada.

3. Remover a placa lógica da carcaça frontal. Desenroscar a lente até sair.

4. Surge o filtro infra-vermelho que deve ser retirado. Geralmente só quebrando.

Eis o que sobrou do filtro IR.

5. Recortar um pedaço de filme de máquina fotográfica que encaixe no lugar do filtro IR.

6. Colocar o pedaço de filme de negativo no lugar do filtro IR.

7. Remontar a webcam.

A partir daí, a webcam só irá capturar imagens em infra-vermelho. A espessura do filme de negativo e se o mesmo é mais escuro ou mais claro vai depender da finalidade do uso da webcam.

No meu caso, quero utilizar leds infra-vermelho apontados diretamente na webcam, por isto o filme deve ser bastante escuro.

Aproveito e mostro um pouco do uso da webcam infra-vermelho nos meus testes com o software CCV.

Leds IR acionáveis por botão de 1 estado.

Leds IR acesos (câmeras digitais "enxergam" infra-vermelho)

Leds nos dedos

Leds nos dedos

Software CCV - Community Core Vision

 E aqui vai uma palhinha do uso do conjunto: Webcam infra-vermelho + leds + CCV:  

Procurando pela web, me deparei com o anúncio de uma webcam de 120fps!  Adquiri a mesma pensando que seria a ideal para o meu projeto. Contudo, após testes, percebi que esta câmera é de ATÉ 120fps! Ou seja, ela PODE atingir 120fps dependendo das condições do ambiente e sua luminosidade. Após preparar a câmera para capturar somente infra-vermelho, consegui somente 18fps em média. Um custo muito alto de fps. Além disto, os 120fps só são alcançados com a resolução mais baixa. Quanto maior a resolução, menos FPS.

Isto se deve ao fato de esta câmera possuir o recurso AUTO EXPOSURE (exposição automática), que ajusta automaticamente a qualidade da imagem de acordo com a quantidade de luz do ambiente. Este ajuste automático custa vários FPS, ou seja, para manter a imagem com uma qualidade boa em baixas condições de luminosidade, ela necessita baixar os FPS. Pena que só fui descobrir isto após me deparar com o problema, mas pesquisa é para isto mesmo.

Infelizmente, nesta câmera, não é possível desabilitar este recurso. Nas configurações da câmera no windows a caixa referente à exposição automática fica desabilitada (cinza escuro) e no Linux (sim, esta câmera funciona no Linux), o comando para desabilitar o auto exposure retorna um erro.

Existem outras câmeras que possuem o FPS fixo, e a possibilidade de desabilitar o recurso de exposição automática. Uma delas é a Philips SPC900NC, que possui 90fps, e é utilizada inclusive para observação astronômica.

Mas para quem ainda planeja adquirir esta webcam para uso trivial (videochat, conferência, youtube, etc…) pode ser uma boa opção. Por isto deixo aqui um review e algumas imagens da câmera.

Características:

• A Webcam possui uma base/clip grande podendo ser apoiada na mesa ou então "clipada" na tela do notebook ou em uma tela de LCD.
• Possui 4 leds brancos que auxiliam na iluminação do ambiente, ligados através de um interruptor localizado atrás da câmera.
• Gira 360 graus horizontais em sua base.
• Funciona em Windows e Linux.
• O chip da webcam é um SUNPLUS SPCA2000A.
• Acompanha software de efeitos especiais. Este programa se diz composto de +4000 efeitos especiais. Mas não se engane, este número é alcançado com combinações de efeitos. Por exemplo: olhos + cabelo + fundo + outros efeitos.
•  Possui microfone embutido.
• Conexão USB e P2 para o microfone.

Caixa da "Super Webcam Vtrex".

Conteúdo da caixa: Webcam, manual e cd.

Webcam sobre a mesa e "clipada" no monitor LCD com os leds acesos.

Conectores USB e P2 do microfone.

Placa lógica e chip SUNPLUS SPCA2000A.

Funcionamento no Windows a 50.1 FPS em 640×480.

Funcionamento no Linux a 47 FPS em 640×480.

Conclusão:

É uma boa câmera para videochat, conferência e pequenos vídeos, mas não serve para obter altos FPS a baixas luminosidades.

Continue lendo os comentários. Há mais informações sobre webcams e contribuições de usuários!

Atualização em 30/04/2010

Como este post teve bastantes comentários, fiz mais uns testes e coloquei alguns vídeos no Youtube, com o máximo de qualidade e velocidade que consegui.

640×480 a 50fps. O máximo em qualidade e velocidade para vídeo

A VTrex só atinge 120fps na resolução 320×240 e com muita iluminação

Video 640×480 a 50fps

Video 640×480 a 50fps com detalhes

Video 320×240 a 120fps #1

Video 320×240 a 120fps #2

Isto ocorreu comigo estes dias, quando eu configurava o menu.lst, e após rodar o comando grub-install eu coloquei /dev/sda3 ao invés de /dev/sda. Resultado: o grub ficou instalado na partição do windows, impedindo de inicializá-lo.

Uma maneira rápida de remover o grub da partição do windows é utilizar o comando dd da seguinte forma:

# dd if=/dev/null of=/dev/sdX bs=446 count=1

 Onde X é a partição do windows.

No meu caso, a partição do windows é /dev/sda3, conforme resultado do fdisk -l:

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sda1               1       26134   209921323+  83  Linux
/dev/sda2           26135       26593     3686917+  82  Linux swap / Solaris
/dev/sda3   *       26594       30401    30587760    7  HPFS ou NTFS

 
Dica retirada de: http://blogs.koolwal.net/2009/06/08/howto-how-to-erase-un-install-grub-from-mbr-to-restore-windowsdos-bootloader/

Atualização de 16/02/2010:

- Quando a versão do Windows instalado for a XP, pode-se utilizar o cd de instalação do Windows para remover o Grub. Logo após o boot pelo CD deve-se escolher a opção referente à "recuperação", apertando F8. No prompt de comando deve-se digitar FDISK /MBR, que o Grub será removido.

O Rafael também deixou uma dica no dia 16/02/2010, quando ele quis remover o Grub instalado indevidamente na partição do Windows 7. Ele possuía mais de um HD no computador e teve de desconectar um deles para que o procedimento funcionasse. Veja mais abaixo nos comentários qual foi a dica dele.

O assunto é FISL X - Décimo Fórum Internacional de Software Livre, que ocorreu na data de 24 a 27 de julho no centro de eventos da PUC-RS.

Para quem não conhece, o FISL - Fórum Internacional de Software Livre é um evento anual que este ano comemorou sua décima edição. O objetivo do fórum é reunir em um local todos aqueles que contribuem de alguma maneira para a comunidade de software livre, seja com desenvolvimento de software, dicas, publicações e até mesmo hardware. O site do evento é http://www.fisl.org.br.

A atração principal do FISL são as palestras, divididas em temas e que ocorrem concomitantemente com mais ou menos uma hora de duração cada uma. Ao total foram cerca de 300 palestras abrangendo os mais diversos assuntos: segurança, programação, administração de sistemas e outros. Os apresentadores das palestras vão desde pequenos usuários (mas com grandes idéias) até grandes empresas, como SUN, Banco do Brasil, Caixa e Petrobras.

Falando em grandes empresas, este ano o fórum contou com a participação da Globo.com. Não sei a respeito dos outros, mas a mim surpreendeu muito. Surpreendeu no sentido de descobrir o quanto que eles utilizam de software livre, e o quanto eles contribuem para as comunidades.

Foram quatro dias de muita movimentação, gente pra todo lado, pois quando uma palestra acabava, tinha-se que andar rápido para entrar em outra e não correr o risco de encontrar a sala lotada e ficar do lado de fora. Sim, apesar das salas serem grandes, algumas palestras lotavam.

Além das personalidades esperadas para o evento, como John Mad Dog Hall e Richard Stallmann, outra figura esperada foi Peter Sunde, um dos fundadores do site de compartilhamento de bittorrent Pirate Bay, condenado junto com os outros fundadores a 2 anos de prisão, mas que ainda aguardavam recurso.

Dos pontos negativos, posso citar a época em que foi realizado, pois no mês de julho já faz bastante frio aqui no sul. Nos outros anos ocorreu em meses mais quentes. Haviam muitas palestras boas ocorrendo ao mesmo tempo, deixando muita gente na dúvida sobre qual palestra participar.

Outro ponto negativo foi em relação à rede WiFi pública do evento. Era muito difícil conseguir uma conexão, o máximo que consegui foi enviar alguns Tweets para o Twitter. Segundo a organização do evento, o problema de conexão era devido à grande quantidade de access points de expositores e também de pessoas que ativavam o WiFi dos seus notebooks com o mesmo SSID da rede pública, talvez por desconhecimento (acho improvável) ou para sacanear os outros.

O cansaço e o frio não deixaram eu ficar até o final, mas com certeza todo o tempo que participei foi bem aproveitado. Consegui até tirar uma foto com Richard Stallmann em uma sessão de fotos. No fórum anterior a foto foi com John Mad Dog Hall

John MadDog Hall no Fisl 9.0                                       Richard Stallmann no Fisl X  

Um abraço a todos e até o próximo FISL.

• Ter que carregar o microfone em separado.
• Não dá para deixar o microfone o tempo todo conectado, pois impede o uso de capas de proteção e carteiras, além de ter que desconectar o microfone para ligar o cabo de sincronismo.
• Fica feio, pois parece um caroço.

Além do microfone externo, algumas pessoas descobriram que é possível instalar um microfone internamente soldando os fios em pontos específicos.

Depois da experiência que tive em trocar a tela digitalizadora do Palm e ver algumas dicas na internet, resolvi instalar o microfone interno.
 
Segui o passo-a-passo deste site (http://www.dominik.chmaj.net/mic/index2.php), e com um pouco de paciência, instalei o microfone sem muita dificuldade.
 
A imagem abaixo mostra como ficou a instalação interna:

 
Consegui o microfone de um MP3 de 512mb que estava guardado e eu não utilizava mais. O tamanho é ideal e cabe perfeitamente no pouco espaço que tem dentro do Palm.
 
Para fios usei um pedaço de fio de telefone:

• O fio branco (mic signal +) fica conectado no primeiro pino do conector (não o pino que fica sozinho). Como é o primeiro pino não é muito difícil soldar.
• O fio azul (terra) ficou conectado no parafuso que prende o conector, que fica parafusado na placa metalica.Esta dica peguei deste vídeo no Youtube.

Coloquei ainda uma fita isolante por cima dos fios e do microfone, pois eles ficam bem embaixo da bateria. Fiz também um furo bem pequeno na carcaça com o ferro de solda para facillitar a passagem do som.
 
O próximo passo é testar algum recurso de voip no palm, como o Articulation.
 
Referências
 

• Palm TX Mic DIY - http://www.dominik.chmaj.net/mic/index2.php
• Palm TX com microfone interno (portugues) - http://www.youtube.com/watch?v=J2Yvj07pwKo
• Manual de desmontagem do Palm TX no site da Palm - http://www.palm.com/us/support/contact/environment/disassem_inst_TX.pdf

Há tempos a tela original do meu Palm estava apresentando o conhecido problema de calibragem. No começo consegui contornar o problema com o PowerDigi do Dmitry, mas com o tempo o problema foi se agravando e não tinha mais jeito. Só trocando a tela.

Algumas assistências técnicas de Palm trocam por uma tela digitalizadora de plástico genérica. Experimentei uma e não gostei, pois elas são flexíveis demais (afundam com a stylus) e criam bolhas de gel (ou óleo) entre as camadas, ficando com a aparência manchada.

Descobri em alguns fóruns que existe à venda telas digitalizadoras de vidro, e que seriam muito superiores em qualidade. A Palm no começo fabricava seus dispositivos com este tipo de tela, mas devido a vários acidentes (palm no bolso de trás da calça, etc), muitas telas acabavam se quebrando, então resolveram fazer uma tela de acrílico, mais difícil de quebrar.

Pois bem, após ler muito sobre a tal tela digitalizadora de vidro, instruções e vídeos de como trocá-la, acabei comprando uma do site Pda parts.

O produto chegou bem embalado, em uma caixa protegida com "bolinhas" de isopor.

Fiz a troca e me surpreendi. A tela possui uma qualidade incrível, e a sensibilidade com a stylus muito superior inclusive comparada à original. Aproveitei e a protegi com uma película antireflexiva. E aqui vai uma dica: Se a stylus não deslizar muito bem, passe uma camada bem fina de creme hidratante, e espalhe bem com um lenço seco.

Vou deixar os vídeos mostrando como abrir o Palm TX e como trocar a tela:

Não é necessário ser um técnico para fazer o reparo. Quem está acostumado a montar e desmontar o seu computador, consegue trocar a tela numa boa. A pior parte é manter longe os fiapos de pó que insistem em pousar no LDC e na tela antes de colocar a película.

segfault at 0 ip b7ec29c8 sp bfadf9dc error 4 in libc-2.7.so[b7e50000+13d000]

…e não deixava o usuário completar o login. A versão do libpam-mount que está no repositório do Debian Lenny é a 0.44-1+lenny3, e para corrigir o problema, é necessário utilizar uma versão mais recente do libpam-mount. Não encontrei uma versão compilada para Lenny, mesmo nos backports. Decidi então baixar os fontes de uma versão mais atual e compilar. Utilizei a versão 1.10 disponível nos repositórios do debian (sid ou squeeze). Baixei o arquivo tar.gz, descompactei e executei o comando

./configure --prefix=/usr

Como dependência, precisei instalar o pacote libhx-dev e libssl-dev (do Lenny mesmo). Após isto, foi só executar make; make install. A partir daí não ocorreu mais erro de segfault. Acredito que este problema foi encontrado por poucas pessoas, pois não encontrei nenhuma solução na Internet, somente as reclamações do erro. Fica aí, portanto, uma solução para este problema.

Correção em 05/09/2009:

• É necessário a versão 2.2 da libHX. A versão do lenny é a 1.18. A versão 2.2 está disponível na página do projeto libHX no Sourceforge. Basta baixar o source da versão 2.2 e compilar sem problemas.
• Também é necessário o pacote libpam0g-dev, mas este está no repositório padrão do Debian.

Encontrei este cenário na empresa onde trabalho: Quando um usuário quer acessar uma pasta compartilhada em um servidor samba, este servidor procura as credenciais deste usuário em todos os AD’s que possuem relação de confiança na rede inteira, ao invés de procurar somente no servidor AD do domínio que o usuário está cadastrado. Algumas vezes leva mais de um minuto para o usuário acessar o serviço de rede, causando frustração.

Obs.: O comando wbinfo -m lista todos os domínios que possuem relação de confiança na rede.

Quando utilizado o comando wbinfo -u para listar os usuários, aparece uma lista de todos os usuários de todos os domínios da rede. O mesmo acontece para listar os grupos (wbinfo -u).

O desejado é que o winbind busque as credenciais do usuário somente no AD do domínio no qual ele está cadastrado.

Procurei duas possíveis formas de corrigir o problema:

1. Colocar o AD do domínio do usuário como primeiro na lista de pesquisa
2. Restringir o domínio de busca.

A primeira opção não trouxe nenhum resultado satisfatório na web, nem nos arquivos de configuração do samba.

Contudo, uma opção no smb.conf chamava a atenção: a opção allow trusted domains. Segundo o man do smb.conf, esta opção serve para restringir a busca pelo usuário somente no domínio onde o serviço está rodando. Por padrão, esta opção é marcada como yes. Contudo, quando configurado para no, nada acontecia, e o comando wbinfo -m continuava listando todos os domínios.

Fazendo mais buscas, encontrei em alguns fórums que a opção allow trusted domains não fazia efeito em algumas versões do Samba.

O servidor da empresa possui instalado a distribuição Centos 5, com a versão 3.0.23 do Samba. Não gosto de utilizar pacotes fora do repositório oficial da distribuição, para não “quebrar” a distribuição e provocar algum “conflito” de pacotes.

Tive duas opções: baixar o fonte do samba e compilar ou então procurar algum repositório com binários do samba atualizados para o Centos 5.

Por uma felicidade, encontrei o repositório SerNet Samba, com binários atualizados do Samba, na versão 3.2.28.

Inseri o repositório na configuração do yum, removi a versão atual do Samba (importante), e instalei a versão do SerNet com suas dependências.

Após iniciar o serviço Samba e Winbind, o comando wbinfo -m passou a listar somente o domínio no qual o servidor estava instalado e configurado, e os comandos wbinfo -u e wbinfo -g retornavam somente os usuários e grupos do domínio local. Os problemas de lentidão acabaram!

Conclusão

Se alguma opção em algum arquivo de configuração não funciona, procure a versão mais atual do programa. Para facilitar a vida do técnico, procure repositórios com pacotes já compilados para sua distribuição, e deixe os gerenciadores tipo Yum e Apt-get fazer o trabalho de resolver e baixar as dependências.