Não vou escrever sobre vídeos de pornografia ou de pessoas xingando, nada disso. Vou falar de novo dos "padrões Microsoft". Não é de hoje que a Microsoft cria aplicativos não padronizados e que fazem questão de não funcionar em outros sistemas além do Windows.
Num desses dias me deparei com um danado de um arquivo de vídeo, WMV, que não funcionava de jeito nenhum.
helio@shibboleet:tmp$ mplayer sound_of_music.wmv
mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing sound_of_music.wmv.
ASF file format detected.
[asfheader] Video stream found, -vid 1
[asfheader] Audio stream found, -aid 2
VIDEO: [WMV3] 352x264 24bpp 1000.000 fps 336.0 kbps (41.0 kbyte/s)
Load subtitles in ./
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: Permission denied.
[VO_3DFX] Unable to open /dev/3dfx.
NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [dmo] DMO video codecs
DMO dll supports VO Optimizations 0 1
DMO dll might use previous sample when requested
MPlayer interrupted by signal 11 in module: init_video_codec
Não é a primeira vez que pego desses arquivos WMV que morrem com essa mensagem "MPlayer interr'upted by signal 11 in module: init_video_codec". Aliás o sinal 11 de saída significa, de acordo com o /usr/include/asm-generic/errno-base.h":
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* Interrupted system call */
#define EIO 5 /* I/O error */
#define ENXIO 6 /* No such device or address */
#define E2BIG 7 /* Argument list too long */
#define ENOEXEC 8 /* Exec format error */
#define EBADF 9 /* Bad file number */
#define ECHILD 10 /* No child processes */
#define EAGAIN 11 /* Try again */
#define ENOMEM 12 /* Out of memory */
#define EACCES 13 /* Permission denied */
#define EFAULT 14 /* Bad address */
o que não quer dizer nada para mim. Aliás quem criou esse código de erro de saída tava trollando, com certeza.
Mas voltando ao vídeo, que eu queria assistir de qualquer jeito, consegui resolver depois de um Googlada profunda. Foi difícil achar referências, mas encontrei um alternativa pra assistir o vídeo, lá no launchpad. Estava no bug descrito como "mplayer crashes opening wmv files encoded with DMO codec".
A solução foi usar o parâmetro "-vc ffwmv3". Com isso pude assistir ao vídeo que fizeram durante a Mobile World Congress, em Barcelona. Muito bonitinho por sinal.
helio@shibboleet:tmp$ mplayer -vc ffwmv3 sound_of_music.wmv
mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing sound_of_music.wmv.
ASF file format detected.
[asfheader] Video stream found, -vid 1
[asfheader] Audio stream found, -aid 2
VIDEO: [WMV3] 352x264 24bpp 1000.000 fps 336.0 kbps (41.0 kbyte/s)
Load subtitles in ./
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: Permission denied.
[VO_3DFX] Unable to open /dev/3dfx.
NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Forced video codec: ffwmv3
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 61
Unsupported PixelFormat 53
[wmv3 @ 0xb657c180]Extra data: 8 bits left, value: 0
Selected video codec: [ffwmv3] vfm: ffmpeg (FFmpeg WMV3/WMV9)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8003->176400)
Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))
==========================================================================
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 352x264 => 352x264 Planar YV12
A: 7.2 V: 7.2 A-V: -0.000 ct: -0.046 108/108 9% 1% 0.3% 4 0
Nota: Antes que perguntem, não posso publicar o vídeo. Não é nada de tão sério ou secreto, mas uma vez que envolve a marca da empresa e foi feito por outras pessoas, eu preciso que elas primeiro publiquem no Youtube, ou algum outro site, pra depois publicar aqui. E não vou pagar nada pro ECAD.
Não tem nada mais chato que sistema lento. Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.
Pois é exatamente o que tem acontecido e muito em Linux. Não sei de outras distribuições, mas especificamente em Ubuntu.
Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado. Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).
Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados. Isso não ajuda muito na ampla adoção do mesmo. Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil. Apenas adicionei prioridade de tempo real ao processo init.
chrt -r -p 1 1
Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1.
A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:
SCHED_OTHER política padrão de round-robin baseado em compartilhamento de tempo
SCHED_RR política round-robin
Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.
Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado. Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.
Faz alguns dias, comecei a ter o prazer de assistir os vídeos do YouTube em cor-de-rosa:
Principalmente no recente instalado Ubuntu 64 bits. A princípio achei que era um dos tão mencionados problemas de flash em Linux 64, mas pude ver em alguns fóruns que isso tem afetado todos as versões de Linux pra Intel, tanto de 32 quanto 64 bits.
Consegui amenizar um pouco o problema com as dicas que encontrei aqui:
http://www.webupd8.org/2011/03/fix-pinkred-youtube-videos-bug-using.html
Mas o problema persiste. Mais uma boa razão pra abandonar logo o flash, que é proprietário e depende unicamente da Adobe pra corrigir.
Já faz algum tempo que comprei uma máquina da STI, Semp Toshiba, do tipo "computador popular". Comprei pelo preço baixo e pelo fato de vir com Linux instalado (um é causa o outro, efeito, mas não sei qual é qual). Isso uns 3 anos atrás. Nunca fui muito adepto de equipamento pré-montado, mas nessa época já estava meio cansado de ficar entrando em boca-de-hardware na Santa Ifigênia pra montar um computador decente.
A grande surpresa foi a qualidade do acabamento do computador: teclado excelente e macio, mouse ótico, entradas de leitor pra cartões de memória (todos os tipos até onde testei), caixas de som com amplificador energizado via USB, 2 GB de RAM, 250 GB de disco SATA e drive gravador de DVD. Realmente um hardware legal (lembre-se que isso foi há 3 anos atrás).
Na época veio com Insigne Linux instalado. Acho que durou uns 5 minutos rodando, o tempo de olhar a cara do sistema, até eu instalar um Ubuntu por cima. Desde então tenho usado o mesmo com Linux 32 bits.
No final do ano passado, por volta de meados de dezembro, só então notei uma mensagem de hardware no boot: EM64T. Sabia que era um Core 2 duo, mas achei que era só isso. Com algumas mensagens no Twitter, algums amigos confirmaram que a CPU era mesmo 64 bits, mas recebi muitas críticas negativas sobre o mesmo em Linux, principalmente em relação à crashes de aplicativos, principalmente em sites com flash. Resolvi então manter os 32 bits.
Recentemente li um artigo dizendo que o Linux fracassou miseravelmente na arquitetura 64 bits. O texto realmente está certo na abordagem do Linux em relação à nova arquitetura: dizia-se que o Windows estava fadado ao esquecimento dos 32 bits e que Linux iria dominar o desktop pois sua migração era tão fácil quanto a instalação em uma torradeira. E o que vemos atualmente é exatamente o oposto disso: várias recomendações pra se manter Linux em 32 bits por questões de estabilidade. No ponto em que li essa frase, confesso que senti uma pontada de culpa, pra não dizer vergonha.
Por um problema com um aplicativo de VPN da empresa, não posso migrar meu laptop pra 64 bits (processador Intel Core i3) e tenho de continuar envergonhado, mas
já o meu desktop... resolvi arregaçar as mangas e instalar. Parti pra instalação do Ubuntu 10.10 em arquitetura AMD64.
Como sempre, dpkg salvou o dia com a lista de aplicativos previamente instalados (dpkg --get-selections >myselections). A migração, ou reinstalação, ocorreu sem demais problemas. Um backup do /etc, bases do mysql e do diretório /root e rapidamente tive o sistema restaurado, e em 64 bits.
Para batizar a *nova* máquina dei o nome de goosfraba, em homenagem ao filme do "tratamento de choque" com Jack Nicholson e Adam Sandler (final meio infeliz, mas em geral é engraçado).
Até o momento a goosfraba tem funcionado melhor que na arquitetura 32 bits: mais rápido. Tenho a sensação de que estava dirigindo uma Audi A3 turbo, mas que antes só colocava até a 4a marcha. E agora vou até a 7a. Mas espero problemas com o Flash Player, pois sei que apesar do Linux não ter fracassado em 64 bits, também não foi o sucesso desejado.
Referências:
[1] What happened to "World Domination 201"? (ou Linux fracassou miseravelmente em 64 bits)
Hoje, no meio das minhas férias, dei uma conectada na rede da empresa pra verificar uns mails (de uns amigos perdidos que mandaram pro endereço errado).
Por lá o comunicador oficial é o Lotus Sametime, da IBM. Sempre conectei utilizando o Pidgin, um dos melhores clientes multi-serviço para IMs que conheço, e utilizando o módulo meanwhile pra conectar no servidor de sametime. Qual não foi minha surpresa ao descobrir que o mesmo não funcionava mais. Apenas recebia uma mensagem de "Version Mismatch" no rodapé do Pidgin e a conexão se encerrava.
Felizmente encontrei fácil uma solução no site do Pidgin, no TT#12623. A solução sugere que o meanwhile seja configurado pra esconder sua identificação (hide), o que já era feito. Então editei o arquivo ~/.purple/accounts.xml e adicionei somente uma linha com a informação abaixo:
<settings>
<setting name='fake_client_id' type='bool'>1</setting>
<setting name='client_minor' type='int'>8511</setting>
<setting name='port' type='int'>1533</setting>
<setting name='force_login' type='bool'>1</setting>
<setting name='server' type='string'>sametime.internal.server.com</setting>
</settings>
Funcionou xuxu beleza. Reiniciei o Pidgin e imediatamente conectei e pude ver os contatos online.
