A vida em Dallas, EUA, não é fácil: a cada dia somos tentados pelas belezas da tecnologia e por seus preços tentadores. Não resistindo a tais tentações, sucumbi com meu cartão de crédito em tudo quanto é traquitana eletrônica com led (se o led pisca então...).
O resultado disso pode ser visto na figura. Entre viagens à China e EUA, pude adquirir, somente nesse ano:
O fato de algumas coisas não funcionarem como deviam me deixa irritado às vezes, mas basta ver alguns leds piscando que esqueço tudo e volto a gastar. Para minha sorte as vendas de PS3 esgotaram mais rápido do que eu pude gastar. Só me resta ficar com meus brinquedos caros e ficar tentando descobrir como corrigir os endereçamentos de memória para poder funcionar no meu FreeBSD 6.0 bonitinho.
Antes de algum espertão perguntar o motivo pelo qual eu só testei alguns dos equipamentos, como placas PCMCIA, somente em FreeBSD: no meu laptop só tem o mesmo. No windows, no Linux, no fear. Just BSD.
Dica retirada de http://www.network-theory.co.uk/docs/cvsmanual/cvs_53.html.
Em alguns trabalhos cooperativos, sempre que baixo uma versão específica do cvs, utilizando algo como "cvs checkout -r1.1 programa", acabou com um erro de "sticky tag" ao fazer o novo commit.
Pelo link acima vi que basta usar um "cvs update -A" para resolver isso.
Nesse domingo de feriadão, fui saudado com uma alteração no horário de verão de minhas máquinas. Eu já sabia que isso iria acontecer algum dia, já que o governou alterou o início do mesmo para seguir o calendário eleitoral.
Porém eu aguardava algum arquivo de zona lançado oficialmente por alguma entidade como o CAIS. Como isso não ocorreu, criei meu próprio arquivo de zona, baseado em um modelo de 2005, chamado hverao2006.zic, e coloquei a data de início, 00:00 horas de 05 de novembro, e a data final, 00:00 horas de 25 de fevereiro de 2007:
Rule Brazil 2006 only - Nov 05 00:00 1 D Rule Brazil 2007 only - Feb 25 00:00 0 S Zone America/Sao_Paulo -3:00 Brazil BR%sT Zone Brazil/East -3:00 Brazil BR%sT
Verifiquei se meu /etc/localtime apontava como link simbólico para /usr/share/zoneinfo/Brazil/East ou /usr/share/zoneinfo/America/Sao_Paulo(ambos são corrigidos pelo arquivo acima) e simplesmente atualizei a informação de timezone:
zic hverao2006.zic
Hoje me deparei com mais um problema estranho, daqueles que vemos nos momentos mais indesejados durante as tarefas mais corriqueiras.
Copiei minha imagem de Windão do meu laptop, FreeBSD 6.1, para meu desktop de casa, Ubuntu 6.06.1 (LTS). Minha idéia é usar a imagem do Windão para levantar uma conexão VPN à empresa. Como o aplicativo só roda em Windão... nada resta além de instalar no gateway de casa e começar a debugar a conexão (acho que é só um IPsec, mas....).
Fiz a conexão remote via ssh com o parâmetro "-X". Qual foi minha surpresa quando recebi o seguinte erro:
helio@picasso tmp> qemu -hda windows.img
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 25 (X_SendEvent)
Resource id in failed request: 0x44
Serial number of failed request: 12
Current serial number in output stream: 17
Cara de "ué?!" e alguns momentos de leitura da manpage me deram a seguinte alternativa:
helio@picasso tmp> qemu -hda windows.img -std-vga
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 25 (X_SendEvent)
Resource id in failed request: 0x44
Serial number of failed request: 12
Current serial number in output stream: 17
A cara de "ué?!" passou para um rosto de "saco...". Testei a conexão com um simples "xclock" que funcionou perfeitamente. Fiquei mais perdido ainda. Não restando muita opção, busquei ajuda no google. Felizmente achei exatamente o que queria:
O grande macete foi reiniciar a conexão ssh com o parâmetro "-Y". Funcionou!!!! VPN debugging, aqui vou eu!!!!!!!!!
Após meses de Ubuntu instalado em minha máquina em casa, minha filha reclamou que o som estava "quicando". Fui dar uma olhada e qual não foi minha surpresa: o som estava realmente quicando.
Como a nova geração de kernels 2.6 não dispõe mais da facilidade de patch para low latency, o que permite uma funcionalidade multimídia muito boa no sistema (evita esses "pulos" durante a execução de uma música), resolvi utilizar uma dica que havia lido na LinuxMagazine do Brasil.
Infelizmente eu havia doado a revista para futuras leituras. Busquei o mesmo artigo no bom e velho google e.... nada! Procurei na Linux Magazine, Brasil, e... nada! Em pleno desespero comecei a procurar por tudo no Google: "multimedia", "multimedia priority", "multimedia priority scheduling", "multimedia priority scheduling ubuntu",e assim fui. Felizmente, entre os vários chutes, acertei o artigo:
http://www.linux-magazine.com/issue/65/Realtime_Computing_With_Multimedia_Apps.pdf
O excelente artigo, de Oliver Frommel, descreve as alternativas para melhorar a prioridade de som nos kernels atuais. Uma das alternativas, que não exige re-compilação de kernel nem aplicação de patches é através do uso de RTLIMITS. Tão simples que basta somente alterar o arquivo /etc/security/limits.confe adicionar as seguintes linhas:
@audio hard rt_priority 80 @audio hard nice -10
Simples, rápido e eficaz. Ainda não entendi o motivo pelo qual isso já não vem configurado como padrão....
Não sou fã de Windows, já faz uns 10 anos, mas invariavelmente preciso verificar algum documento ou rodar um programa da empresa nele. Para isso instalei no qemu uma imagem do Windows 2000.
Como parte de minha displicência pelos sistema de Bill (Unix: live free or die), eu sempre acabo esqueçendo a senha do administrador. Na rede é possível usar a image do programa abaixo:
Baseado em Linux, faz todo o serviço para reinicializar (recovery) de senha. Muito útil.
Depois de fazer isso, lembre-se de se benzer contra o "Exu tranca sistemas" e voltar a usar o bom e velho (mas sempre moderno) Unix.
Brincando com qemu, um emulador que permite rodar vários sistemas operacionais a partir de um sistema nativo, resolvi instalar o Windows2000 (padrão da empresa) sobre o FreeBSD 6.1 que tenho no laptop. Para ganhar performance, ainda compilei e instalei o módulo kqemuque aumenta a performance do sistema emulado. Fiz uma instalação sobre uma partição de 5 GB criada da seguinte forma:
musashi# dd if=/dev/zero of=/usr/local/tmp/windows.img bs=1024k count=5000
O parâmetro bs=1024k descreve blocos de 1 Kbytes enquanto que count=5000faz 5000 iterações sobre esse valor (5000 * 1 Kbytes = 5 GBytes).
Para utilizar a instalação a partir de um cd, basta seguir a seqüência de comandos abaixo:
helio@musashi: tmp$ kdesu "qemu -hda windows.img \
-win2k-hack \
-net nic \
-net tap \
-usb \
-localtime \
-cdrom /dev/acd0 \
-boot d \
-soundhw all" &
Com kdesu é possível rodar a aplicação como root, o que permite o uso da interface de rede. Já o parâmetro -win2k-hack, é descrito como um workaround para um problema que apareçe na instalação do Windows 200x e XP. Já os parâmetros -net nic -net tap habilitam o uso da interface de rede tap0 (FreeBSD, lembra?). O -usb seria para utilizar os dispositivos usb do sistema, mas não funcionou comigo. -localtime destina-se a utilizar o horário do sistema nativo no emulado, o que evita distorções de tempo. Finalmente, -soundhw allpossibilita o uso de som no sistema emulado.
Com tudo em mão, basta seguir com a instalação normal do Windão.
Se você, assim como eu, notar que o mouse simplesmente não funciona, indo sempre parar no canto esquerdo: não se desespere. Isso é somente um parâmetro de SDL que pode ser resolvido da seguinte forma:
helio@musashi: tmp$ env SDL_VIDEO_X11_DGAMOUSE=0 kdesu "qemu \
-hda windows.img \
-win2k-hack \
-net nic \
-net tap \
-usb \
-localtime \
-cdrom /dev/acd0 \
-boot d \
-soundhw all" &
SDL_VIDEO_X11_DGAMOUSE=0faz todo o serviço necessário.
Se tudo ocorreu sem demais problemas, você verá uma bela tela como essa abaixo:
Mas não se anime muito com o fato de rodar o Windows sobre outro sistema: os defeitos e lentidões continuarão o mesmo...
É interessante quando pessoas não versadas sobre a arte zen da computação (sim, é uma arte) usam os sistemas que para nós são parte de nosso dia-à-dia. Coisas bizarras e inusitadas simplesmente não funcionam ou você, ao contrário, nota que alguém usa aquilo para alguma coisa.
Com a dança de cadeiras de máquina, fiquei com os seguintes equipamentos:
Voltando à questão do som, minha esposa veio reclamar da última máquina descrita: o som não funcionava. Eu, como não a utilizo muito (não via prompt, somente remotamente), nunca tinha notado isso. Fui verificar o que havia ocorrido já que o som funcionava perfeitamente na "era Debian" e eu não havia formatado a máquina, apenas realizado um "aptitude dist-upgrade" para Ubuntu (não foi tão fácil assim, mas também não foi tão difícil...).
Primeiramente verifiquei qual interface de som eu tinha instalado (somente lembrava que era on-board em uma placa ASUS A7V8X-X:
picasso:etc# lspci | grep -i multimedia
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
Notei que vários módulos inúteis estavam carregados no kernel, inclusive um redirecionando o som para interface dummy, o que estava causando a "falta de som". Removi os módulos desnecessários e carreguei o módulo snd-via82xx. Para minha surpresa, o som não funcionou...
Escarafunchando pelo google a fora encontrei uma dicas místicas de pessoas que usaram o controle de som do Gnome para configurar a placa. Segui a mesma receita e dessa vez o som funcionou. Verifiquei o que havia alterado e notei que o módulo ad1889 havia sido carregado, o que permitiu que o som funcionasse. Uma vez carregado, pode-se verificar se tudo está corretamente assim:
picasso:etc# cat /dev/sndstat
Sound Driver:3.8.1a-980706 (ALSA v1.0.10rc3 emulation code)
Kernel: Linux picasso 2.6.15-23-k7 #1 SMP PREEMPT Tue May 23 14:20:54 UTC 2006 i686
Config options: 0
Installed drivers:
Type 10: ALSA emulation
Card config: VIA 8235 with AD1980 at 0xe000, irq 201
Audio devices: 0: VIA 8235 (DUPLEX)
Synth devices: NOT ENABLED IN CONFIG
Midi devices: NOT ENABLED IN CONFIG
Timers: 7: system timer
Mixers: 0: Analog Devices AD1980
Depois inclui os módulos necessários para que carregassem no boot assim:
picasso:etc# echo snd-via82xx >> /etc/modules
picasso:etc# echo snd-ad1889 >> /etc/modules
Para evitar que o sistema leia outros módulos e não os que defini, simplesmente renomeei o diretório /etc/modprobe.d para /etc/modprobe.d.sai_seu_feio. Não é uma solução das mais bonitas, mas um dia eu arrumo isso...
Novo trabalho, novos desafios. Umas das primeiras coisas que fiz foi livrar meu laptop dos grilhões que o prendiam e instalar o bom e velho FreeBSD, release 6.1. Bom sistema, tudo funcionando (ou quase tudo). Eis que resolvi recuperar alguns dados que gravei em um DVD:
musashi# ls -skh /cdrom/
ls: Backup-musashi_Win2k-2005-04-17.tar: Value too large to be stored in data type
total 227 227
Backup-musashi_Win2k-2005-04-17.toc.gz
Fora o fato bizarro de eu estar tentando acessar um backup de Windows, achei sacal o problema de não conseguir ler a mídia. Buscando na rede, descobri que existe uma limitação no driver cd9660 para ler arquivos maiores de 2GB.
Uma busca árdua no google me levou ao link:
Apliquei a alteração:
--- sys/isofs/cd9660/cd9660_node.h.org Wed Mar 16 09:09:52 2005
+++ sys/isofs/cd9660/cd9660_node.h Sun Jan 8 00:14:54 2006
@@ -69,7 +69,7 @@
ino_t i_ino; /* inode number of found directory */
long iso_extent; /* extent of file */
- long i_size;
+ u_long i_size;
long iso_start; /* actual start of data of file (may be different */
/* from iso_extent, if file has extended attributes) */
ISO_RRIP_INODE inode;
Ao invés de patch, editei o arquivo não mão, já que alteração era de long para u_long somente. Vamos ver se funciona....
Após um período utilizando o Java 1.5.0 que baixei da IBM, verifiquei que alguns aplicativos não estavam funcionando de acordo. Podendo ou não ser problema da versão do Java, resolvi utilizar a versão anterior: 1.4.2.
Para quem tem um iBook, arquitetura PPC (ou PowerPC), rodando Linux como o meu, sabe que não tem coisa mais chata que buscar alguns aplicativos como Java, Flash, Acroread, etc... Felizmente, no caso do Java, existe um suporte da IBM. Mesmo assim é necessário entrar no site da mesma, registrar-se, e somente aí baixar o aplicativo.
Buscando no respositório não oficial da Debian, encontrei uma alma caridosa que já disponibilizou o pacote pronto:
É possível buscar para todos os releases (atuais) de Debian. Great Work Dude!
Essa visista à Dallas, na verdade Plano, no Texas, EUA, tem sido bastante interessante, além de uma grande tentação. Os aparatos tecnológicos à disposição atraem pelas funcionalidades e pelo preço. Graças à isso, o xuxu já sofreu um belo upgrade de memória (troquei o pente de 256MB para 512MB), uma nova bateria com 2 horas de duração e uma nova fonte de alimentação.
helio@xuxu:~$ uname -a
Linux xuxu 2.6.15-26-powerpc #1 Mon Jul 17 19:51:43 UTC 2006 ppc GNU/Linux
helio@xuxu:~$ cat /proc/meminfo | head -7
MemTotal: 643808 kB
MemFree: 72396 kB
Buffers: 127376 kB
Cached: 206272 kB
SwapCached: 0 kB
Active: 360200 kB
Inactive: 183444 kB
Não bastasse isso, ainda comprei um adaptador de rede USB da Linksys (Linksys USB200M), que não funcionou de cara. No caso, tenho que usar USB pois o meu iBook não tem entrada PCMCIA (isso é chato de vez em quando). Não demorou muito para encontrar alguns links na rede:
Em ambos, aparentemente o módulo asix faria todo o suporte como driver porém:
root@xuxu:~# lsusb
Bus 001 Device 005: ID 13b1:0018 Linksys USB200M 10/100 Ethernet Adapter
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 003: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse
Bus 002 Device 001: ID 0000:0000
root@xuxu:~# modprobe asix
root@xuxu:~# ifconfig usb0
usb0: error fetching interface information: Device not found
root@xuxu:~# dmesg | tail
[ 698.129138] usb 1-1: new full speed USB device using ohci_hcd and address 3
[ 1000.127664] usbcore: deregistering driver asix
[ 1013.215179] usbcore: registered new driver asix
[ 1048.105175] usb 1-1: USB disconnect, address 3
[ 1064.537063] usb 1-1: new full speed USB device using ohci_hcd and address 4
[ 1242.490754] usbcore: registered new driver rtusb
[ 4600.045112] usb 1-1: USB disconnect, address 4
[ 4604.633132] usb 1-1: new full speed USB device using ohci_hcd and address 5
[ 4608.154937] usbcore: deregistering driver asix
[ 4624.399026] usbcore: registered new driver asix
O sistema não chegou a reconhecer. Mas como parece existir um horizonte de possibilidade, vou continuar tentando (mesmo porque o preço fui muito compensador: USD$ 29.99).
Outro brinquedo que me chamou a atenção, mais pelo preço que por funcionalidade (também saiu por USD$ 29.99), foi um Wireless G USB Network Adapter da Belkin. Apesar de também ser uma compra no escuro, sem idéia se iria funcionar ou não em Linux e FreeBSD, resolvi arriscar. Após uma rápida busca na rede, encontrei alguns links muito bons:
A última referência, o HOWTO, é excelente. De cara já vi que é um chip da ralink, o mesmo utilizado no DWL-G122 da D-Link. Ainda não fiz funcionar, mas já decidi que também não vou devolver. Agora é arregaçar as mangas e mandar ver.
Compro ou não compro?
O preço é atrativo e aparentemente funciona com Linux:
Mas será que realmente funciona? E com FreeBSD? Mesmo assim, o preço é muito tentador.
Aparentemente a Telefonica mudou de opinião sobre a politica de bloqueio das portas dentro do range dos "well know services". Recentemente realizei um teste por acaso e descobri minha porta 80, 443 e outras completamente disponíveis na rede. Verificando os logs via webalizer, vi que a quantidade de acessos aumento significante. Olhando cuidadosamente os logs, verifiquei que os ataques também. Mas entre os ataques e a portas liberadas, eu prefiro a segunda alternativa.
Page 33 of 35
