Ativando a câmera Microdia do Mirax mm6100 no Debian Linux

Olá!

Se vocês acompanham esse blog a um certo tempo, devem se lembrar de quando falei sobre a instalação do Debian no meu notebook Mirax mm6100, e de como na época falei que a Webcam não funcionava. De boa, nunca senti muita falta da Webcam, mas é muito chato você ficar com um hardware parado no seu notebook. Então, a algum tempo atrás, o Silveira Neto divulgou no Br-Linux.org como instalar um driver alternativo para as Webcam Microdia como a do meu notebook.
Bem, para ser um pouco repetitivo, vou colocar os passos aqui também, embora nos links anteriores tenha-se um passo a passo mais detalhado:

Baixando e compilando:

Você irá precisar instalar pacotes básicos de compilação (build-essentials), os cabeçalhos do kernel (kernel-header) que você tá rodando e o git. Para isso, como root ou usando sudo, digite (no Debian/Ubuntu):

apt-get install kernel-header-`uname -r`kernel-package git-core gitk git-gui git-doc curl ctags build-essential

Com esse comando, você já estará instalando todo o necessário para compilar o driver alternativo. PS: Se você estiver usando o driver gspca, pode ser interessante, ainda que não obrigatório, a remoção ou desabilitação do mesmo. Para desabilitar nos testes, como root digite rmmod gspca. Para remover o driver, digite dpkg -r gspca-module-`uname -r`.
Primeiro, vamos obter os sources do driver. Ele ainda não possui um tarball para distribuição, portanto vamos ter que buscar o driver no repositório git do mesmo. Para isso, digite:

git clone http://repo.or.cz/r/microdia.git

Esse comando não exige root, portanto não exige sudo ou su.
Uma vez terminado a cópia dos arquivos, você terá um diretório microdia dentro do diretório onde você estava. Entre nesse diretório e dispare o comando make. Esse comando também não precisa de root, portanto não se preocupe. A compilação é rápida e não demanda nada de especial (alguns problemas podem aparecer em casos específicos, sendo que sugiro que procure o site do projeto no Google Groups para maiores informações).
Se você não recebeu nenhum erro, então você deverá ter nesse diretório microdia um arquivo com o nome microdia.ko. Esse é o driver que você irá usar… Mas calma, antes de instalá-lo para valer vamos dar uma checada e ver se está tudo OK.

Testando o driver:

Bem, agora que você compilou o driver e já tem um arquivo microdia.ko, é hora de testar o driver e vê se está OK. Acione a kill switch da Webcam e dê uma checada no dmesg para ver se o dispositivo foi localizado. Uma vez localizado podemos testar a Webcam. Ela deve se apresentar como USB2.0 Webcam ou similar, mas pode ser que varie conforme o caso. O importante é ler o dmesg e ver se o hardware foi localizado. Calma que isso só será “necessário” dessa vez (embora dar uma olhada no caso de problemas seja altamente recomendável).
Ativada a kill switch, podemos carregar o driver com o comando (como root, pois estamos adicionando um módulo no kernel, o que demanda poderes de super-usuário):

insmod ./microdia.ko

Caso esteja tudo OK, seu dmesg terá as seguintes linhas (ou similares):

microdia: Microdia USB2.0 webcam driver startup
microdia: Microdia USB2.0 Webcam - Product ID 6260.
microdia: Release: 0100
microdia: Number of interfaces : 1
microdia: Microdia USB2.0 Camera is now controlling video device /dev/video0
usbcore: registered new interface driver usb_microdia_driver
microdia: v0.0.0 : Microdia USB Video Camera

Pode ser que seu driver não rode e dê a seguinte mensagem:

insmod: error inserting 'microdia.ko': -1 Unknown symbol in module

Não precisa se desesperar – é que está faltando alguns módulos que são dependências do microdia.ko. Basta então adicioná-los com

modprobe videodev
modprobe compat-ioctl32


E tentar novamente a carga do driver. Existem outros problemas que podem ocorrer. Caso ocorram, dê uma consultada no processo de instalação no site do projeto Microdia no Google Groups.
Agora, vamos ao teste propriamente dito. Tudo feito, a câmera não apresentando nada no insmod (o que é bom), execute o mplayer com:

mplayer tv:// -tv driver=v4l2:width=640:height=480:fps=25:device=/dev/video0 -vo x11


Se tudo correu bem, você deve estar vendo sua própria imagem de frente corretamente. Se não estiver vendo nada, feche o mplayer (CTRL+C no terminal resolve), acione novamente a kill switch e tente novamente carregar o mplayer. Caso ainda assim não funcione, provavelmente você deverá dar uma olhada no site do projeto no Google Groups.
Pode acontecer de a imagem aparecer de cabeça para baixo… Não se preocupe, falaremos disso logo. No momento, considere que está tudo bem. Eu mesmo na primeira compilação desse driver tive problemas de imagem aparecendo de cabeça para baixo. Por enquanto, simplesmente ignore esse fato e vamos para a instalação do driver.

Instalando o driver:

A instalação do driver é razoavelmente simples e opcional, mas acho interessante se você não quiser ter que levantar esse driver toda vez após rebootar sua máquina. Como root, digite os seguintes comandos:

strip -g microdia.ko
cp microdia.ko /lib/modules/`uname -r`/kernel/drivers/media/video/usbvideo/
depmod -a

O comando strip pode ser dado sem root, portanto se você tiver usando sudo (como no Ubuntu), não há nenhum problema em deixar o comando sem sudo. Esses comandos apenas limpam o driver de símbolos de depuração, diminuindo seu tamanho e necessidade de memória, copiam o driver para o local apropriado dentro da estrutura de drivers do kernel e remapeia a estrutura do kernel para localizá-lo como parte da estrutura de drivers do kernel, de modo que os comandos de drivers (módulos) sejam apropriadamente usados.
Com isso, o driver deve estar instalado e funcionando normalmente…

Corrigindo a imagem de cabeça para baixo:

Ok… Disse anteriormente que pode acontecer de a imagem da Webcam aparecer de cabeça para baixo. Na realidade, é exatamente isso o que acontece com esse driver no Mirax mm6100. Antes de você se descabelar, vamos com calma: na lista de discussão do suporte a esse driver encontrei uma thread que dizia exatamente o que fazer nesse caso.
As versões mais atuais desse driver possuem três parâmetros que podem ser setados em 0 (desligado) e 1 (ligado), que são vflip (espelhamento vertical), hflip (espelhamento horizontal) e flip_detect (detecção da rotação da Webcam do notebook). No Mirax mm6100 a opção flip_detect não funcionou, portanto pode ser ignorada.
Se você instalou o driver, utilize o comando a seguir para fazer o teste do driver para ver se os parâmetros em questão ajudam.

modprobe microdia vflip=1 hflip=1

Se não instalou ainda o driver (o que é recomendável), utilize o comando a seguir, dentro do diretório microdia:

./insmod microdia.ko vflip=1 hflip=1

Pode ser necessário (na verdade sugere-se) o uso de rmmod microdia antes de tentar qualquer um dos comandos anteriores. Lembrando que todos esses comandos, incluindo o rmmod, demandam root.
Faça novamente o teste com o mplayer e verifique se a imagem está correta. Caso não esteja, vá setando os parâmetros apresentados até alcançar o ajuste adequado ao seu hardware. Lembre-se de usar rmmod antes de cada tentativa, de modo a “limpar” os ajustes anteriores ao descarregar o driver.
Assim que alcançar o ajuste ideal a sua Webcam, será necessário apenas editar um arquivo para que esses parâmetros sejam “gravados” no seu sistema para sempre serem adotados. Para isso, como root, abra seu editor de texto favoritos e abra o arquivo /etc/modprobe.d/aliases (ou, em algumas distros, o /etc/modprobe.conf) e acrescente ao final do mesmo o comando:

options microdia vflip=1 hflip=1

substituindo vflip=1 hflip=1 pelos ajustes adequados à sua Webcam.
Com isso, toda vez que você rebootar sua máquina, sua Webcam deverá estar corretamente configurada sempre que for usada.
A Webcam pode ser usada em qualquer programa que utilize a API Video4Linux (v4l), como o mplayer, cheese (para fotos e vídeos), amsn (mensageiro instantâneo) e afins. Cada programa possui seus ajustes, mas uma vez o driver esteja corretamente configurado, é tudo questão de ajustar corretamente as opções do programa.
Como nota final, em vários locais, inclusive nas documentações do site do projeto no Google Groups foi sugerido o uso do comando module-assistant install,prepare (m-a install,prepare para os íntimos) no Debian/Ubuntu. Não utilizei esse comando (desconhecia essa parte do processo) mas não tive problema. O uso ou não desse comando fica a seu critério, lembrando que esse comando exige root, pois manipula arquivos do kernel.

Powered by ScribeFire.

Conectando o Nokia 6085 no Linux: Cartão de Memória e Memória Interna

O celular Nokia 6085 foi um dos melhores celulares que a Nokia colocou em venda. Segundo a Nokia, algumas especificações são:

• Flip com antena interna
• GSM/EDGE 850/900/1800/1900 MHz
• Display principal: LCD passivo CSTN de 128 x 160, 262 mil cores
• Display externo: 96 x 68 FSTN, 2 cores Preto e Branco com LEDs azuis
• Interface de usuário S40 com 3 teclas programáveis, deslizador de 4 direções, teclado ITU-T, teclas de volume e tecla de câmera
• Viva-voz integrado
• Câmera VGA com zoom digital de 4x
• Rádio FM
• 3 MB de memória livre do usuário, leitor de cartão de memória MicroSD com hot-swapping
• Interface de carga de 2 mm
• Conector Pop-PortTM (USB 1.1)
• Standby ativo e interface de usuário aprimorada (Cher UI)
• Bluetooth
• Filmadora e reprodutor de vídeo
• Reprodutor de música (MP3, MP4 AAC, AAC+, eAAC+)
• Navegador XHTML sobre TCP/IP
• MMS
• Mensagens instantâneas
• Comandos/ discagem de voz aprimorados (SIND)
• Jogos e aplicativos Java MIDP2.0 pré-instalados
• Streaming 3GPP
• Sincronização local e remota (SyncML)
• Temas que incluem papéis de parede & protetores de tela animados, esquemas de cor e toques
• Teclas programáveis configuráveis pelo usuário
• Calendário, lista de tarefas, notas
• Despertador, Cronômetro de contagem regressiva

Comprei esse celular no final do ano passado (2007) com um preço bastante interessante e recursos versáteis. Possui compatibilidade Java MIDP 2.0, o que permite usar programas como o AnyRemote (controlador de computador via Bluetooth para Linux) e BarSnap (programa que permite a “leitura” de QR-Codes – códigos de barra bidimensionais usados para passar informações, como URLs, pequenos textos e afins) e seus recursos de áudio são razoáveis (seu maior problema é que a bateria vai para o ralo rapidamente se usar como MP3 Player). Como aceita toques em MP3, fica fácil configurar um toque simples e a transferência de dados via Bluetooth é muito interessante (já transmiti informações de e para meu Palm e meu notebook sem problemas).
Porém, um problema que eu tive foi que o mesmo não veio com o cabo, o que nunca me deu dor de cabeça. Mas, para facilitar as coisas, decidi comprar um cabo e investigar como conectar o Nokia 6085 ao notebook via cabo, usando Linux. Tudo aqui foi testado no Debian Lenny, mas deve funcionar no Ubuntu Gutsy e em qualquer boa distro atualizada.
Primeiro, cuidado ao comprar o cabo: em alguns casos tentarão de empurrar o cabo dos celulares Samsung. Fuja! Mesmo se for comprar um cabo genérico, procure pelos cabos CA-53 e CA-70 (que foi o que eu comprei). Se você tiver o fone de ouvido do 6085, o conector inferior é praticamente idêntico. Em alguns casos, ao encaixar o cabo pela primeira vez pode ser necessário forçar um pouquinho. Basta ter cuidado que ele encaixa normalmente.
Uma vez que o celular seja conectado ao cabo, ele irá mostrar uma tela perguntando o modo de conexão, com três opções: Transferência de Dados, Impressora e Fax e Modo Nokia. No caso, falaremos do primeiro e do último modo, que são os mais relacionados à transferência de arquivos de e para o celular.
O primeiro modo é o mais simples: basta selecionar o modo no celular que automaticamente o Linux irá reconhecer o celular como uma pendrive. No caso, esse modo é usado para transferir os dados de e para o cartão de memória MicroSD (TransFlash – seja lá o que isso quer dizer). A transferência é simples e pode ser feita como a cópia de dados normal de qualquer gerenciador. Ao terminar, lembre-se de utilizar uma opção de desmontagem do dispositivo (como a “Remover de Modo Seguro” do Konqueror / Dolphin no KDE 4.0).
O último modo é um pouco mais complexo, pois acessa a memória interna do celular (3 MB), que deveria ser acessível apenas via Bluetooth ou com o uso de um programa da Nokia para Windows. No caso, porém, alguma investigada e você descobre que na verdade existe um modo do Bluetooth chamado OBEX, que é usado para as transferências de dados, e que justamente esse modo é usado pelo programa da Nokia para se conectar ao celular via cabo. Então, procurando algumas informações na Net, cheguei a alguns tutoriais, que basicamente resumem o processo a (tudo deverá ser feito como root):

• Instale os pacotes obex, obexfs e obxftp. Se desejar, também instale gnome-vfs-obexftp. No caso do Debian/Ubuntu, o comando é: sudo apt-get install obex obextool obexpushd obexfs obexftp gnome-vfs-obexftp;
• Uma vez instalado os pacotes, crie um diretório /nokia (ou qualquer outro). Esse será o ponto de montagem da memória interna do celular;
• Agora, carregue o módulo do FUSE (File User Space Environment) com modprobe fuse;
• Monte a memória interna do celular com obexfs -u 0 /nokia/ (obs.: o parâmetro é um zero e não um O);
• Depois, todos os processos de transferência de dados serão executados normalmente, usando os comandos de shell, como cp, rm, mv e afins. Após o término, desmonte o dispositivo com umount /nokia normalmente;
• Atenção: não sei se é um bug no obexfs ou algo similar, mas se o seu filesystem estiver com locales para  UTF-8 (como no caso do Debian Lenny), você terá problemas com diretórios e arquivos que contenham acentos na memória do celular, uma ves que ela se encontra em Latin-1. Não sei como resolver esse problema ainda;

Para mais informações sobre esse tipo de processo, dê uma olhada no Janelas Quebradas e no De Tudo um Pouco.

Update: Esses truques funcionam normalmente com o celular Nokia N73

Powered by ScribeFire.

AnyRemote – Controlando seu PC pelo Celular

Olá!

Fale a verdade, você já se pegou em situações onde um bom controle remoto para o computador seria uma ótima idéia, como em uma apresentação, ou quando você está usando seu PC para ouvir música e está lavando louça e quer ouvir uma música em especial qualquer (bem, no meu caso foi Get Over, da trilha sonora do anime Hikaru no Go… ). De qualquer modo, é um momento onde tudo o que você quer é controlar seu PC sem ter que chegar perto do seu teclado ou mouse.
Pois bem, para apresentações existem alguns controles remotos que conseguem “substituir” um mouse, mas são caros.
Pois bem: tem um celular com suporte a bluetooth e J2ME? Usa Linux? Então sem problemas!
Existe um software chamado AnyRemote que transforma um celular Bluetooth em controle remoto por meio de um cliente J2ME que deve ser enviado para o celular. É importante que a JVM J2ME do celular suporte Bluetooth por meio de JSR (Java Specification Request) 82. No meu caso, o teste foi feito com um celular Nokia 6085 e funcionou perfeitamente. No site do AnyRemote existe uma lista dos celulares suportados.
OK, então mão na massa.
Primeiro, tenha certeza de ter as dependências do mesmo instalado: você precisará de pacotes de bluettoth (libbluez, obex e libbluetooth), além de python e PyKDE (python e python-kde) ou Gtk Python. Se você já fez alguma operação Bluetooth com o seu celular em Linux, provavelmente terá tudo o que é necessário. Caso contrário, existem muitos tutorias na Internet sobre como configurar corretamente seu dongle (chaveiro USB) de Bluetooth no Linux.
Embora a maior parte das distribuições contem com o AnyRemote nos repositórios, vamos fazer a instalação a partir dos pacotes oferecidos no site do AnyRemote, pois eles são mais atualizados com arquivos para controle de aplicações e afins. No site do AnyRemote, clique em Download e baixe os seguintes pacotes (obviamente, no formato compatível com sua distribuição – no meu caso, como Debianista, os arquivos são .deb):

• Cliente em Linha de Comando:
• anyremote_4.9-2_i386.deb – Pacote Principal;
• anyremote-data_4.9-2_i386.deb – Pacote de dados do AnyRemote (contem os arquivos .cfg que controlam as aplicações, portanto deve ser baixado);
• anyremote-doc_4.9-2_i386.deb – (opcional) documentação do AnyRemote;
• Cliente Gráfico – aqui utilizaremos o kAnyRemote para o KDE. Existe também o gAnyRemote para o GNOME, mas não comentaremos ele aqui:
• kanyremote_5.3-2_all.deb
• Cliente J2ME – ele pode ser baixado também via WAP, mas o próprio kAnyRemote ao detectar o celular permite que o cliente J2ME seja enviado para o celular via Bluetooth:
• anyremote-j2me-client_4.9-2_all.deb – Infelizmente, esse foi o pacote mais atual com o cliente J2ME, ainda que não seja o mais atual como um todo;

Baixado tudo isso e instalado as dependências, conecte seu dongle Bluetooth. Caso necessário, faça todas as configurações exigidas para a comunicação entre seu celular e o computador via Bluetooth. É fundamental que todos esses recursos estejam corretamente configurados antes da instalação, pois o AnyRemote (e o kAnyRemote) utiliza-se da estrutura Bluetooth do Linux. Em distribuições mais atuais, tudo resume-se a espetar o dongle que ele é auto-identificado. Instale os arquivos baixados conforme a sua distribuição. Ligue o seu Celular e ative a função Bluetooth do mesmo.
Abra então o kAnyRemote. Ele irá jogar na System Tray (Bandeja do Sistema) um pequeno ícone o identificando. Clique com o botão direito em cima dele e você terá um menu como o exibido ao lado. Clique em Start e você irá ativar o serviço do AnyRemote. PS: perceba que também deve ter na System Tray um ícone com o símbolo do Bluetooth, que indica que tem um adaptador Bluetooth conectado e reconhecido. Ele não precisa estar azul nesse momento, pois não há operações nele.
Agora, vamos trabalhar o AnyRemote. Dê dois cliques no ícone do kAnyRemote ou então clique com o botão direito do mouse e escolha Restore. Você irá receber uma janela igual à do lado (clique para ampliar). Essa é a janela principal do kAnyRemote, por onde você configura quais programas podem ou não serem controlados pelo AnyRemote. Existem várias opções para configurar aqui: iremos mexer apenas nos clientes cujo modo for Server (servidor). O outro modo, AT, é um modo que utiliza comandos AT (de modem) via WiFi ou infravermelho para controlar o computador, mas não falaremos dele aqui. O Modo Server é o modo que utiliza Bluetooth (e em alguns dispositivos, infravermelho). Existe ainda o Bemused, sobre o qual também não falaremos.
Ele é dividido em três Estados: Disponível (o programa a ser controlado está instalado, mas o agente do AnyRemote não está ativo para ele), Gerenciado (o agente está ativo) e Não-Disponível (o programa a ser controlado não está instalado). No caso, temos vários agentes Disponíveis, mas apenas um Gerenciado, que é o All_in_1, que funciona como “controle remoto universal”. Sugiro que deixe apenas esse em Gerenciado. Para desativar os demais, selecione qualquer um que esteja como Gerenciado e clique em “Parar”.

Tudo OK, é hora de enviarmos o cliente J2ME ao celular. Clique em Setup | Devices. Ele irá abrir uma janela que irá investigar todos os seus dispositivos Bluetooth. Espere um pouco e ele deve mostrar o seu dispositivo. No meu caso, é o “Nokia Fábio” ao lado. Selecione-o e clique duas vezes.
Agora, já indicamos ao AnyRemote que esse dispositivo pode acessar o computador, mas ainda ele  não o fará pois não tem o cliente J2ME instalado. Para fazer o deploy desse cliente, você também pode, caso a solução do envio automatizado não funcio, enviar o arquivo normalmente por OBEX File Transfer do Linux ou então por download do mesmo via WAP (lembrando que você precisará enviar dois arquivos, um .JAR e um .JAD). Mas vamos ao envio automatizado.

Ao clicar duas vezes, você receberá uma janela para fazer os ajustes das configurações para aquele celular. Primeiro, clique em Ping para verificar se está tudo OK e a comunicação é efetiva. O Celular pode perguntar se deseja aceitar comunicação e ou pareamento do mesmo com o computador. Confirme e, caso necessário, forneça a senha de pareamento (normalmente o computador pede para definir uma. Apenas escolha uma senha que você considere adequada e confirme a mesma senha no celular). Tudo OK, basta clicar em “Enviar Java”. Confirme o alerta que seu Celular deverá dar para o envio do arquivo. Tudo OK, clique em OK para sair. Uma configuração avançada é fazer com que uma determinada configuração do AnyRemote seja carregada de imediato no Celular uma vez que ele conecte-se ao AnyRemote. Para isso, clique em “Escolher” e escolha o arquivo .cfg correspondente.
Tudo bem… Agora é a hora da verdade: abra seu celular e vá ao menu de Aplicações do mesmo. Lá deverá estar listado o AnyRemote. Escolha-o. Pode ser que o celular pergunte se você deseja a aplicação usar recursos de conectividade. Permita, pois é justamente o acesso ao Bluetooth. Tudo correndo bem, o cliente irá automaticamente identificar uma conexão, à qual você irá se ligar. Você entrará no menu do All_in_1 (imaginando que ele esteja ativo). Escolha o programa que você deseja controlar. Em alguns casos na tela irá parecer com a imagem ao lado. Nesse caso, cada um dos símbolos representa a tecla do teclado do celular que deve ser pressionada para fazer a função ser ativada. Por exemplo, para suprimir o som na tecla ao lado, digite 2. Para fechar o programa, tecle 8 e para parar a música tecle 0. Em outros casos irá aparecer outros layouts. Nesses casos, utilize as teclas direcionais do celular para mover até a opção desejada e aperte o botão central do celular (o que normalmente fica dentro do direcional) para executar a opção.

Para terminar, existe formas de configurar o comportamento tanto do AnyRemote quanto do kAnyRemote. Vá em Setup | Preferences. Você receberá uma janela como a da imagem ao lado (clique para ampliar). Existe uma série de ajustes que você pode configurar, mas os mais interessantes são o Auto-Startup (para fazer com que o kAnyRemote seja carregado ao iniciar o KDE/GNOME) e as opções de Show in List, que filtram quais configurações devem ser apresentadas pelo kAnyRemote. Sugiro que se desmarque as configurações de Modo AT (uma vez que não as usaremos) e que marque-se a opção Custom Made, que indica que configurações não relacionadas a Aplicativos também devam ser apresentadas. Entre tais configurações consta a All_in_1 que citamos aqui.
Na realidade, existe muito mais para se falar sobre o AnyRemote, pois ele é poderoso o bastante para, em conjunto com as aplicações Linux que possuam algum tipo de chamada distribuída (como o DCOP do KDE ou mesmo disparos por linha de comando), ser customizada para controle remoto de praticamente qualquer aplicação. Basta apenas estudar a documentação disponível no site do AnyRemote.
Em tempo: para o pessoal que desejar saber mais sobre o AnyRemote, em especial sobre o uso do gAnyRemote, veja esse artigo do Blog do Venilton.

Powered by ScribeFire.

KDE 4.1 no Debian Lenny via Backports

Olá!

Faz já um certo tempo que não posto nada relacionado a Linux, então vamos nessa.
Fazia algum tempo que vinha experando o lançamento do KDE 4.0 para o Debian Lenny. OK, sei que existe no Debian Sid, mas não tenho coragem para fazer os ajustes necessários de priorização de pacotes, pois sei que um pequeno erro e você zoa completamente o seu ambiente.
Porém, recentemente o pessoal do Debian que cuida de backports divulgou recentemente o KDE 4.1 para Lenny sem necessidade de adicionar os pacotes experimentais e manipular priorizações e outros detalhes.
OK… Vamos ao que interessa: como colocar a bodega no ar.
Primeiro de tudo, adicione a seguinte linha no seu /etc/apt/sources.list:

deb http://kde4.debian.net/ lenny main

Adicionada essa linha, basta então dar o comando apt-get update para atualizar sua lista de pacotes do sistema.
Uma vez essa lista atualizada, você tem duas opções indicadas pelo pessoal do backport do KDE 4.1:

1. Instalação miníma: apt-get install kde4-minimal;
2. Instalação completa: apt-get install kde4. Essa opção é desaconselhada pelo pessoal do backports, pois pode ocorrer a quebra de pacotes. Não verifiquei nenhum problema nessa opção quando testei a instalação, mas para todos os efeitos;

Em ambos os casos, após a instalação, é altamente recomendável dar apt-get install kde-l10n-ptbr para instalar os pacotes de internacionalização do KDE 4.1 para o português brasileiro (para os gajos lusitanos que por acaso venham a ler este, o pacote deve ser kde-l10n-pt).
Atenção: o KDE 4.1, principalmente na instalação completa, poderá desinstalar o KDM. É aconselhável que você faça isso via linha de comando, pois uma desinstalação forçada do KDM pode resultar em queda da interface gráfica.
E quais são as impressões?
O novo KDE ficou muito bonito e elegante, além de até o presente momento parecer bastante performático em relação ao KDE 3.5. Ainda sinto falta de plasmas para indicação de performance de CPU e rede, mas nada demais. Outra coisa que sinto falta é a possibilidade de criar um Painel com os ícones de aplicações mais usadas (talvez tenha que brincar mais com o KDE 4.1 para entender melhor como ele faz isso). Entre os plasmas testados, destaque (infelizmente negativo) ao plasma para uso do Twitter: ele poderia oferecer uma rolagem dos últimos X tweets, e não apenas mostrar os últimos X tweets, o que tornaria-o mais útil (continuo com o TwitterFox).
Pelo que percebi (talvez esteja errado), o KDE 4.1 possui uma série de efeitos do Compiz Fusion em seu código, sem recorrer a ele, o que permite manter vários dos recursos do Compiz Fusion sem seu peso (e potencial para travamentos), o que resulta em um Desktop elegante com o WOW! (a piada com o Vista foi meramente proposital )
Seguem abaixo alguns snapshots do KDE 4.1 no meu notebook:

• Processador: Intel® Core™ 2 Duo T5500 1,66
• Memória RAM: 1GB DDR2 533 MHz
• HD de 80GB
• Drive óptico: DVD-RW (gravador e leitor de CD e DVD) Dual Layer
• Debian Lenny (Testing)
• Hostname: hufflepuff

Alt-Tab no melhor estilo iPhone

Desktop como ficou – principal diferença é que as pastas de Desktop utilizam o plasma
FolderView. Com transparência fica elegante.
Papel de parede Foxkeg Setembro de 2008.

Mesmo sem o Compiz Fusion, alguns efeitos ficam ativos. É importante deixar o OpenGL ativo, mesmo sem o Compiz Fusion.

Escurecimento da tela quando uma janela modal aparece. Efeito antigo mas muito interessante no KDE 4.1. Perceba no Snapshot que, embora o Oxygen seja o novo tema padrão, o velho e bom Keramik ainda está aí.

Fonte original: Ana’s blog

Powered by ScribeFire.

Rápida: Renomeando pendrives no Linux

Via Vinícius Cordeiro e Viva O Linux:
Uma das coisas mais difíceis de se fazer no Linux, por incrível que possa parecer, é renomear pendrives. Na realidade, existem dois pacotes básicos que o usuário deve instalar para poder renomear uma pendrive: o mtools (MS-DOS tools) e o nftsprogs (para NTFS). Iremos mostrar aqui o passo-a-passo para renomear pendrives Esse procedimento deve funcionar não apenas também com HDs externos, cartões de memória, MP3-Players e outros dispositivos similares.
O primeiro passo é descobrir onde está seu pendrive. Na linha de comando, digite mount (assim mesmo, sem parâmetros), ou pode ser também dmesg (se você souber detalhes sobre seu pendrive). Vamos usar o mount. Procure a linha onde está seu pendrive e anote o device usado (é o item da primeira coluna, normalmente será /dev/sdXY, onde X é uma letra seqüêncial representando o dispositivo e Y é um número seqüêncial que indica a partição dentro do dispositivo.)
Em seguida iremos “desmontar” o pendrive. Para isso, vá na linha de comando e, como root, digite umount /onde/está/meu/pendrive. Como sugestão, no KDE, abra o Konqueror e digite na barra de localização /media:. Clique com o botão direito do mouse e escolha “Desmontar”. Atenção: se usar esse método, não escolha a opção “Remover de Modo Seguro”, pois ela não apenas desmonta o pendrive, como também “remove” o device desejado.
OK… Agora que sabemos qual é o device e temos o pendrive “desmontado”, podemos nos preparar. Esse procedimento muda se o pendrive (ou partição do pendrive) estiver formatado em FAT ou NTFS.
No caso dos dispositivos NTFS basta usar, como root, o comando ntfslabel <device> <nome>, onde <device> é o dispositivo (ou partição) que se deseja renomear. Se deixar sem nome, o comando retorna o nome atual do pendrive.
No caso dos FAT, primeiro devemos fazer ver se ele faz uma checagem de problemas. Para isso, executamos o comando mlabel -i <device> -s :: , onde <device> é o dispositivo (ou partição) que se deseja renomear, que irá apresentar o nome atual do pendrive. Se você receber a mensagem Total number of sectors (7831520) not a multiple of sectors per track (63)!, você pode tranqüilamente ignorar esse problema usando o comando echo mtools_skip_check=1 >> ~/.mtoolsrc.
Agora, basta renomear o pendrive usando o comando mlabel -i <device> ::<label>, onde <device> é o dispositivo (ou partição) que se deseja renomear. Atenção: nos comandos mlabel apresentados anteriormente, não remova os ::. Eles indicam que iremos usar o dispositivo indicado ali. Caso contrário, seria necessário mapear esses dispositivos no arquivo .mtoolsrc.
Fonte original: RenameUSBDrive – Community Ubuntu Documentation

Dica: Gravando conversas do Skype no Debian

Bem, precisei procurar um programa em Linux que gravasse conversas de Skype, pois no futuro estarei gravando (tudo dando certo) alguns Podcasts com um pessoal aí (não sobre Linux, mas sobre RPG). Procurando na Net, descobri algumas dicas de como redirecionar o sinal do ALSA para um arquivo usando SOX e afins, mas nenhumas delas funcionou comigo.
Então consegui encontrar um programinha opensource chamado Skype Call Recorder (SCR), que faz exatamente isso de maneira extremamente funcional. Além do Source possui pacotes para Xandros/eeePC, Ubuntu Hardy Heron (exige o repositório multiverse) e Debian Lenny.
A instalação é razoavelmente simples: copie o pacote para Debian (ou para Ubuntu conforme o caso – aqui me focarei no Debian) para o seu computador e abra um terminal. Instale antes a liblame, libid3 e a libvorbis (dependências do mesmo) via apt-get (se você ouve OGG Vorbis e MP3, normalmente já terá esses codecs instalados). Passe para root com o comando ‘su‘ e utilize o dpkg para instalar o pacote. Normalmente o comando será dpkg -i /onde/baixei/o/arquivo/skype-call-recorder-debian_0.5_i386.deb. Isso basta para instalar o pacote.
Um ícone para o mesmo será criado no menu Utilitários. Basta ativá-lo e um ícone será criado na System Tray do seu ambiente. Clique com o botão direito nele e você receberá uma opção de configuração que permite escolher onde você deseja guardar as chamadas gravadas, o formato desejado, o nome a ser dado e se você deseja receber uma caixa de confirmação de se deseja ou não gravar aquela chamada ou se as chamadas serão gravadas automaticamente.
Após ajustar as configurações, basta abrir seu Skype e realizar a chamada. Automaticamente uma caixa de confirmação será aberta solicitando se deseja gravar aquela chamada. O ideal é confirmar rapidamente. O resto é falar e dexiar o sistema trabalhar.

Rápida: encodando vídeos para MP5 Player no Linux

A quase um ano atrás, escrevi um post sobre um MP4 que eu tinha e sobre como usá-lo com o Linux. Bem, a verdade é que ele acabou pifando e tive que comprar um outro para assistir meus animes (dá para fazer isso também usando o Nintendo DS que eu comprei, mas falarei sobre isso em uma outra oportunidade). No caso, acabei adquirindo um MP5 desses mais genéricos, que você compra nesses camelódromos e outlets no Brasil (no caso, a Sogo Plaza). Bonitinho, aceita cartões de memória e usa vários tipos de vídeos, entre eles o MP4 (provavelmente na formatação do iPod) e AVI (DivX), além do nativo 3GP (no qual ele também filma).

Na realidade, comprei esse MP5 mais pela simplicidade. De qualquer modo, gostei dele pois é simples operar ele no Linux. Ele monta automaticamente e os dispositivos são reconhecidos sem necessidades de hacks como o do meu antigo RockChip. Ele possui um conjunto de diretórios onde você deve dispor seus arquivos:

• audio – Aqui você deve colocar seus arquivos de áudio em MP3. Arquivos gravados com o recurso de gravação de voz virão para cá em formato .WAV;
• ebook – Aqui você pode colocar seus ebooks em TXT;
• game – Nesse local você pode colocar ROMs de jogos de Nintendo 8 bits para jogar no MP5;
• picture – Aqui ficam suas imagens, tanto as que você subiu quanto quaisquer fotos que você tirar com a câmera VGA do mesmo;
• video – Aqui você guarda seus vídeos. Vídeos gravados com o recurso de filmagem do mesmo são salvos aqui em formato 3GP;

E para encodar vídeos? Os formatos utilizados são MP4, 3GP e AVI (DivX). Como sugestão pela facilidade, utilize o script zepo_encode (disponível nesse site). Esse script depende apenas do MPlayer e converte de qualquer formato aceito pelo MPlayer para AVI especialmente preparado para o MP5. Para usar o script, utilize o comando:

$ ./zepo_encode [entrada] [saída]

Onde saída recebe extensão automaticamente. Lembre-se de colocar o zepo_encode em um diretório do $PATH do ambiente e definir permissões de execução para o mesmo. Após converter, basta copiar o arquivo resultante para dentro do diretório video do MP5 ou de um cartão de memória. Com esse script e algum hack de Shell você pode encodar vários vídeos e colocá-los no MP5 enquanto você vai dormir…
Para que você tenha uma idéia de se essa dica lhe é útil, abaixo segue a saida do lsusb -v para ele:

Bus 002 Device 003: ID 04fc:5563 Sunplus Technology Co., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0×04fc Sunplus Technology Co., Ltd
idProduct 0×5563
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 1

Dica rápida: Restaurando o ícone da Lixeira no KDE

Olá!

Às vezes acontece de você entrar no KDE e estar sem o ícone de Lixeira. Embora o acesso via Konqueror (trash:/) ajude, ele não tem todos os recursos que você precisa. Uma solução é a seguinte: abra o seu editor de texto predileto (no meu caso é o EMACS, mas fica a seu critério) e escreva o seguinte código nele:

[Desktop Entry]
Type=Link
URL=trash:/
Encoding=UTF-8
Icon=trashcan_full
EmptyIcon=trashcan_empty
Name=Trash
Name[pt_BR]=Lixo
Comment=Contains removed files
Comment[pt_BR]=Contém arquivos removidos
OnlyShowIn=KDE

Salve esse documento em ~/Desktop/trash.desktop. Isso deve resolver o problema.
Via VivaOLinux.

As coisas se complicam para o OOXML

Bem, desculpem o hiato: as minhas novas atividades de serviço exigiram um tempo meu especial, onde precisei me focar mais nele e abandonei um pouco o blog.
Nesse meio tempo, ocorreu o Ballot Resolution Meeting (BRM) para a aprovação ou não do Office Open XML. Basicamente, esse é o momento onde todas as contradições (ou comentários) aplicados ao mesmo quando ele não foi aprovado, em uma tentativa de resolver os problemas e com isso aprovar o formato.
Antes que se pense que isso é mais um empurrão da nossa “amiga de Redmond”, na realidade isso é parte do processo de Fast track da ISO, portanto não há nada de errado nesse processo. Muito pelo contrário, ele é completamente válido na medida em que é parte de um processo já validado dentro de uma organização como a ISO.
Os problemas vão surgindo, porém, quando você entende o que está acontecendo por trás dos panos.
Como já comentei anteriormente nesse mesmo blog, existem uma série de problemas sobre como o formato está sendo publicado na ISO. Esse é inclusive o motivador do Ballot Resolution Meeting (BRM): estudar e chegar a um consenso sobre como serão corrigidos os problemas no mesmo. Mas como chegar a um consenso sendo que o formato possui mais de 6000 páginas de documentação técnica com coisas específicas para emular a formatação do Word 95 (?!) ou do Wordperfect (?!)?
Mas isso ainda não é o pior do que está acontecendo sobe o Ballot Resolution Meeting (BRM). Existem coisas ainda piores ocorrendo.
O Jomar, do Homembit e da ODF Alliance Brasil, é um dos representantes da ABNT no comitê JTC1 da ISO, responsável pelo OOXML (DIS 29000), sendo que os outros foram o Deivi Kuhn do SERPRO e o Fernando Gebara, da Microsoft, dois profissionais respeitados na área. Ele é uma fonte de referência para saber o que se passa nesse processo. Além dele, recomendo a leitura do blog do César Taurion, da IBM, também bastante respeitado, que vêm falando bastante do ODF e do OOXML. Eles foram para Genebra participar do BRM como representantes brasileiros. E as coisas começaram a aparecer, apesar da “lei de silêncio” envolvendo o BRM:
Comecemos pelo post do Jomar onde ele esclarece uma proposta do Brasil para facilitar a aceitação do OOXML, principalmente quanto à questão das famosas questões de retrocompatibilidade (lineWrapLikeWord6), que era a possibilidade de um mapeamento de formatos binários (como o .doc) para o OOXML (.docx).
Bem, vamos deixar que ele fale:

Afinal: O que fomos fazer em Genebra ? | void life(void)

Não posso contar os detalhes da reunião, mas posso contar uma conversa que tivemos (eu e mais um delegado brasileiro) com uma pessoa no início da pausa para o almoço de sexta feira. Vou divulgar esta conversa pois nosso interlocutor se identificou como sendo membro do ECMA, membro de uma delegação nacional presente no BRM mas não disse que estava falando em nome de ninguém (como é o protocolo lá), e por isso entendo que esta foi uma conversa que não está coberta pela escandalosa “Lei do Silêncio” imposta a todos nós.
Esta pessoa nos procurou dizendo que considera que não deveríamos apresentar nossa proposta que pedia o mapeamento, pois não havia tempo hábil na reunião (pouco mais de três horas) para escrevermos o documento. Nós dissemos que nossa proposta partia da premissa de que o ECMA já tinha este documento, pois, se justifica a necessidade do OOXML por causa do suporte ao binário e se afirma ainda que existem coisas que não podem ser traduzidas (deprecated), eles devem ter estudado aprofundadamente esta situação e no mínimo ter feito o mapeamento.
Eu nunca vi uma pessoa tão nervosa e envergonhada na minha vida… Ele disse que a Microsoft deve ter este mapeamento e se nós quisermos, podemos pedir à Microsoft mas não pedir ao ECMA. Disse que o ECMA só foi responsável por criar o novo schema XML e que não têm esta documentação.
Como nossa conversa não ia a lugar nenhum, eu lhe expliquei que o que iriamos propor era o resultado do trabalho de um comitê no Brasil e que infelizmente se ele não pudesse voltar ao tempo e vir ao Brasil contar esta história toda, que teríamos que insistir com nossa proposta.
Fiz questão de contar isso aqui, pois não deixaram o Brasil apresentar a proposta…

OK… Pode parecer correto o que a pessoa disse. Mas vejamos o que diz outro profissional envolvido, o Avi Alkalay, da IBM:

OOXML: Está rolando um barraco na ISO :: Avi Alkalay

Só pra lembrar qual é o propósito do OOXML, extraido (em livre tradução) de sua especificação:

O objetivo deste padrão [OOXML] é […] representar fielmente o corpo de documentos existentes […]

Os tais “documentos existentes” são no caso todos os documentos em formato binário legado do MS Office (.doc, ,ppt, .xls), algo fora do escopo do OOXML.
Se esse mapeamento não fizer parte da especificação OOXML, seu objetivo primordial é inválido. A especificação é inválida. E a delegação brasileira queria levantar essa bola: cadê o mapeamento ?

Sem um mapeamento, é praticamente impossível obter a total fidelidade no corpo de documentos existentes e transpor isso ao OOXML, mesmo recorrendo-se a engenharia reversa. Qualquer um que tenha aberto um arquivo .DOC no BrOffice.org ou exportado um documento do BrOffice.org para .DOC sabe disso. Sem esse mapeamento, o resultado prático é que características estranhas dos documentos, principalmente .DOC, não poderão ser representados adequadamente em um OOXML. E é justamente isso que questiona Rob Weir, que é parte da representação americana no OOXML:

An Antic Disposition: The Carolino Effect

The scope of OOXML, as amended by the BRM is stated as:

This International Standard defines a set of XML vocabularies for representing word-processing documents, spreadsheets and presentations. The goal of this standard is, on the one hand, to represent faithfully the existing corpus of word-processing documents, spreadsheets and presentations that have been produced by Microsoft Office applications (from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also specifies requirements for Office Open XML consumers and producers , and on the other hand, to facilitate extensibility and interoperability by enabling implementations by multiple vendors and on multiple platforms.

Faithful representation of Microsoft Office 97-2008. I’ve learned it is rarely polite to ask a man what he means by “faithful”, but let me make an exception here. We have now the binary Office format specifications, not part of the standard, but posted by Microsoft. And we have OOXML specification. In what way does the OOXML “represent faithfully” the “existing corpus” of legacy documents?
Does OOXML tell you how to translate a binary document into OOXML? No. Does it tell you how to map the features of legacy documents in OOXML? No. Does it give an implementor any guidance whatsoever on how to “represent faithfully” legacy documents? No. So it is both odd and unsatisfactory that primary goal of the OOXML standard is so tenuously supported by its text.
Now, certainly, someone using the binary formats specifications, and using the OOXML specification, could string them together and attempt a translation, but the results will not be consistent or satisfactory. (…). Knowing the two endpoints is not the same as knowing how to correctly map between them. A faithful mapping requires knowledge not only of the two vocabularies, but also the interactions.

Uma tradução livre desse trecho é a seguinte:

O Escopo do OOXML, como foi corrigido no BRM é definido como:

Esse padrão internacional define um conjunto de vocabulários XML para a representação de documentos de processamento de texto, planilhas e apresentações eletrônicas. O objetivo desse padrão é, por um lado, representar fielmente a formatação existente de documentos de processamento de texto, planilhas e apresentações eletrônicas produzidas por aplicações do Microsoft Office (do Microsoft Office 97 ao Microsoft Office 2008, inclusive). Também especifica requisitos para consumidores e produtores de documentos Office Open XML e, por outro lado, facilita a extensibilidade e a interoperabilidade ao permitir implementações por vários desenvolvedores e em várias plataformas.

Representação fiel de documentos do Microsoft Office 97 ao 2008. Aprendi que raramente é polido perguntar a alguém o que ele quer dizer com “fiel”, mas aqui há uma exceção. Nós temos agora as especificações do formato dos arquivos binários do Office, não incluídos como parte do padrão, mas sim fornecidos pela Microsoft; e temos a especificação do OOXML. Como é que o OOXML “representar fielmente a formatação existente” dos documentos legados?
O OOXML nos diz como traduzir um documento binário em OOXML? Não. Diz como mapear as features dos documentos legados para OOXML? Não. Oferece um caminho para o desenvolvedor “representar fielmente”, seja lá o que queira isso dizer, os documentos legados? Não. Portanto é ao mesmo estranho e insatisfatório que o objetivo principal do OOXML seja tão tenazmente definido por esse texto.
Na verdade, alguém que queira tentar uma tradução usando as especificações dos formatos binários e do OOXML poderia amarrá-los e tentar seguir em frente, mas os resultados não serão consistentes ou satisfatórios. (…) Saber os pontos de chegada e partida não significa saber o caminho entre eles. Um mapeamento fiel exige não apenas o conhecimento das duas especificações, mas também das interações entre elas. (Grifo meu)

Perceba aqui o problema: não é possível saber como “representar fielmente” os documentos em questão. O máximo que um desenvolvedor pode fazer é “ir no chute”, mas “os resultados não serão consistentes ou satisfatórios“. Como disse, basta tentar abrir um arquivo do Word em qualquer outro editor e ver que isso é uma verdade. O resultado nunca é o mesmo. Mesmo quando o formato é conhecido, existem leves diferenças na implementação (quem nunca desconfigurou a formatação de um documento ao abrir ele na versão mais atual de um editor?). Problemas entre formatos é obviamente uma realidade.
E isso é apenas a ponta do Iceberg.
No dia que eu escrevo isso, o Avi Alkalay publicou em seu blog um post falando sobre uma das “features” que serão exigidas no OOXML. No caso, cito a fonte do mesmo, novamente o Rob Weir:

An Antic Disposition: A Leap Back

(…) in 1582 Pope Gregory XIII promulgated a new way of calculating leap years, saying that years divisible by 100 would be leap years only if they were also evenly divisible by 400. So, the year 1600 and 2000 were leap years, but 1700, 1800 and 1900 were not leap years. This Gregorian calendar was initial adopted by Catholic nations like Spain, Italy, France, etc. Protestant nations pretty much had adopted it by 1752, and Orthodox countries later, Russia after their 1918 revolution and Greece in 1923.

traduzindo (desculpem, o post vai se tornar longo, mas tenho a prática de citar a fonte “as is” e as traduzir a posteriori quando isso pode ser relevante):

(…) em 1582 o Papa Gregório XIII promulgou uma nova forma de calcular-se anos bissextos, determinando que os anos divisíveis por 100 só seriam bissextos se fossem divisíveis também por 400. Portanto, 1600 e 2000 foram anos bissextos, mas 1700, 1800 e 1900 não. Esse calendário gregoriano foi inicialmente adotado em nações católicas como a Espanha, Itália, França, etc… As nações protestantes o adotaram em 1752, e as nações ortodoxas mais tarde: a Rússia após a revolução de 1918 e a Grécia em 1923.

OK… Um pouco de história? Qual é o problema?
O problema é a seguinte imagem:

O que foi feito aqui?
Quando se formata uma casa do Excel como data, ela conta a partir de 01/01/1900. Ou seja, se quero representar o dia de hoje, eu somo o número de dias que passou entre 01/01/1900 e hoje (um princípio básico da computação que é adotado em diversos formatos, com leves diferenças entre unidades e “ponto zero” adotados). Isso facilita a computação para fórmulas, principalmente envolvendo datas. Pensando assim, e lembrando o que foi dito anteriormento, o Avi definiu que o valor da data como a primeira data do escopo (01/01/1900) + os trinta dias seguintes (ou seja, levaria até 31/01/1900) e somou mais 29 dias em seguida. O resultado seria 29 dias após o dia 31/01/1900. Como não é bissexto (como o Rob explicou anteriormente), o resultado adequado seria 01/03/1900. A imagem comprova que o resultado foi 29/02/1900 (também conhecido como dia de São Nunca).
Agora, você pergunta: “Qual é o problema?”
Lembra a questão de “‘representar fielmente a formatação existente‘ dos documentos legados”? Bem, isso quer dizer representar inclusive os bugs!!! Pode-se alegar que é um bug inconveniente, mas não é, e mesmo que fosse isso não é desculpa. E a questão é a seguinte: se um erro bobo como esse passa (lembrando que esses documentos legados podem estar por aí em 2100, que também não é um ano bissexto), imagina detalhes mais complexos?
E as coisas não acabaram:
As pessoas que estão acompanhando esse processo do OOXML sabem que a Microsoft prometeu liberar totalmente de royalties o OOXML, atraves do que ela chama de “Microsoft Open Specification Promise” (OSP). Basicamente, ela afirma por meio disso que está não irá processar ninguém por usar ou desenvolver em cima dessas patentes. Porém, o pessoal do Software Freedom Law Center, que estuda licenças de software para analisar sua compatibilidade com o Software Livre, procurou analisar a OSP e verificar sua compatibilidade com as licenças livres, como a GPL, a Artistic (do Apache) ou a CDDL (Sun/OpenOffice.org). O resultado é:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…), we publicly conclude that the OSP provides no assurance to GPL developers and that it is unsafe to rely upon the OSP for any free software implementation, whether under the GPL or another free software license.

traduzindo:

(…), concluímos publicamente que a OSP não oferece nenhuma segurança para desenvolvedores que usem a GPL e que não é seguro se basear na OSP para qualquer implementação livre [do OOXML], seja segundo a GPL ou segundo qualquer outra licença de software livre. (grifos meus)

Você pode se perguntar: “o que mais esses open-xiitas querem? Não basta as especificações da ECMA?“
Não basta! Tanto não basta que a própria ISO não aceita padrões que possuam patentes, a não ser que essas patentes estejam para acesso a qualquer um sem cobrança de royalties. A pergunta então pode ser: “qual é o problema?” Bem, vamos aos fatos:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

Microsoft makes its promise “irrevocably,” but upon careful reading of the entire OSP, this promise is weakened considerably in the definition of Covered Specifications. In that provision, Microsoft clarifies that:

New versions of previously covered specifications will be separately considered for addition to the list.

Because of this narrow definition of the covered specifications, no future versions of any of the specifications are guaranteed to be covered under the OSP. Each new version is subject to Microsoft’s ongoing discretion on a case by case basis. In other words, every time a specification changes, Microsoft can effectively revoke the OSP as it had applied to previous versions of that same specification. Microsoft states that it will commit to renewal of the promise for future versions of specifications subject to standardizing activity “to the extent that Microsoft is participating in those efforts,” which means that Microsoft reserves the right to cancel the promise with respect even to standardized specifications, by merely withdrawing from the relevant standard-setting workgroup or activity. While technically an irrevocable promise, in practice the OSP is good only for today.

tradução:

A Microsoft torna sua promessa “irrevogável”, mas se lemos a OSP completamente, percebemos que essa promessa é enfraquecida sensivelmente pela definição de Especificações Cobertas pela mesma. Nessa provisão, a Microsoft deixa claro que:

Novas versões de especificações anteriormente cobertas pela mesma poderão ser consideradas separadamente para serem adicionadas à lista [de especificações].

Devido à essa definição ampla de Especificações Cobertas, nenhuma versão futura de nenhuma dessas especificações estarão seguramente cobertas pela OSP. Cada nova versão é alvo da decisão da Microsoft em uma situação caso-a-caso. Em outras palavras, cada vez que uma especificação mudar, a Microsoft pode efetivamente revogar a OSP do modo como ela se aplica às versões anteriores da mesma especificação. A Microsoft determinou que irá renovar a promessa para futuras versões das especificações sujeitas à atividade de padronização “enquanto a Microsoft participar desses esforços”, o que na prática quer dizer que a Microsoft se reserva no direito de cancelar a promessa até mesmo para as especificações que passaram por padronização, simplesmente abandonando os grupos de trabalho ou atividades relevantes. Embora tecnicamente ela seja irrevogável, na prática a OSP só funcionaria de imediato. (grifos meus)

Atentemos aos grifos: por eles, compreendemos que, ao bel-prazer, a Microsoft pode, mesmo após aprovado o padrão, revogar sua OSP e sair processando todo mundo, criando uma patente submarina potencial, uma vez que, pelos termos citados, ao revogar sua OSP, todo usuário potencial da OSP estaria infringindo direitos de patente e, com isso, sendo alvo potencial de processos. Sem sombra de dúvidas, uma forma capciosa de implementar minas-terrestres de Propriedade Intelectual contra os usuários.
Mas não acabou: você não poderia incorporar código de implementações do OOXML em qualquer coisa que não envolva implementação OOXML. Vejamos o que a SFLC tem a dizer sobre isso:

Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

(…) any code written in reliance on the OSP is covered by the promise only so long as it is not copied into a program that does something other than implement the specification. This is true even if the code has not otherwise been modified, and code that conforms to the specification cannot be modified if the resulting modified code does not conform.

Traduzindo:

(…) qualquer código que tenha sido escrito em observância à OSP estará coberto pela promessa enquanto ele não for incorporado a qualquer programa que faça qualquer outra coisa que imp,ementar a especificação. Isso é verdadeiro mesmo se o código não for modificado, e o código que estiver seguindo a especificação não pode ser modificado se o código modificado resultante não estiver em observância.

O que isso quer dizer? Basicamente, não temos um uso livre para incorporação em qualquer situação, o que é definido pela Liberdade 2 da Free Software Foundation e que é parte do princípio por trás da GPL. Embora possa-se alegar que uma biblioteca poderia rodar segundo LGPL e assim trabalhar em conjunto com software GPL, ainda assim não pode-se afirmar que esse seja um uso livre ou mesmo seguro do mesmo.
O pior é que, segundo a Microsoft, a culpa é da GPL:
Microsoft’s Open Specification Promise: No Assurance for GPL – Software Freedom Law Center

In its FAQ regarding the OSP, Microsoft confuses the issue further, saying:

Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).

While not attempting to clarify the text of the OSP to indicate compatibility with the GPL or provide a safe harbor through its guidance materials, Microsoft wrongly blames the free software legal community for Microsoft’s failure to present a promise that satisfies the requirements of the GPL. It is true that a broad audience of developers could implement the specifications, but they would be unable to be certain that implementations based on the latest versions of the specifications would be safe from attack. They would also be unable to distribute their code for any type of use, as is integral to the GPL and to all free software.

traduzindo:

Em sua FAQ relacionada à OSP, a Microsoft distorce essa questão [do licienciamento segundo a GPL] dizendo que:

Uma vez que a Licença Pública Geral (GPL) não é universalmente interpretada da mesma forma por todos, não podemos dar uma opinião legal sobre como nosso texto se relaciona à GPL e a outras licenças de software livre ou aberto, mas baseado no feedback que recebemos da comunidade do software aberto acreditamos que uma ampla gama de desenvolvedores pode implementar a(s) especificação(ões).

Além de não tornar claro o texto da OSP para indicar compatibilidade com a GPL ou oferecer um porto seguro por meio de eus materiais, a Microsoft erroneamente culpa a comunidade jurídica relacionada ao software livre por sua incapacidade de oferecer uma promessa que satisfaça as condições da GPL. É verdade que uma ampla gama de desenvolvedores poderá implementar as especificações [segundo a OSP], mas eles não terão certeza de que implementações baseadas nas versões mais recentes estarão seguras contra litígios. Eles também não terão garantias de que poderão distribuir tais códigos para serem usados como necessário, o que é uma parte fundamental da GPL e de qualquer software livre. (Grifos meus)

Perceba que citei anteriormente a possibilidade de adotar-se a LGPL. O problema é que pela primeira questão levantada (a possibilidade de revogação da OSP), não há garantias de que, mesmo sob LGPL, o software continue legalmente sendo aceito, devido às patentes.
Pretendo comentar mais sobre essa questão, uma vez que em alguns dias haverá a decisão final sobre a padronização do OOXML. Mas é importante ficarmos com a orelha em pé: não sabe-se o que pode acontecer.

MP4 xingling (chip RockChip) no Ubuntu/Debian

Olá!

Alguns de vocês, como eu, devem ter comprado um MP4 xingling, baseado em RockChip (como o da foto ao lado) e percebido que, assim que você conecta ele no Linux, ele detecta, monta, mas logo em seguida desmonta com mensagens de remoção insegura. O mais estranho é que, se você tentar usar o mesmo em distros antigas, como Ubuntu Dapper Drake e Fedora Core 2, eles funcionam normalmente.
Bem, depois de muito xingar o bendito vendedor de MP4 xingling, resolvi usar a cabeça e o Google, até que cheguei nesse site, onde ele explica como montar esse MP4 no Linux. O problema é com o UDEV, e um ajuste no máximo de setores do dispositivo que tem que ser feito no Linux para que o dispositivo seja reconhecido normalmente. No caso, a solução proposta é a criação de um arquivo /etc/udev/rules.d com a seguinte linha:

BUS==”scsi”, SYSFS{vendor}==”RockChip”, RUN+=”/bin/sh -c ‘/bin/echo 128 > /sys/block/%k/device/max_sectors’”

Com isso, o problema de montar e desmontar o dispositivo passa.
Como dica adicional, em vários MP4s que usam AVI (XviD), você deve converter previamente os arquivos de vídeo para o formato adequado. Para isso, utilize o comando:

mencoder <origem> -ofps 22 -vf-add scale=320:240 -vf-add expand=320:240:-1:-1:1 -srate 44100 -ovc xvid -xvidencopts bitrate=550:max_bframes=0:quant_type=h263:me_quality=4 -oac lavc -lavcopts acodec=mp2:abitrate=128 -o <destino>

Perceba as opções de scale e expand. Ajuste para o tamanho de imagem adequado. Além disso, corrija as opções de áudio em acodec e abitrate. Normalmente todo MP4 trás um vídeo de exemplo. Clique com o botão direito no mesmo e anote as opções de vídeo do mesmo.

Powered by ScribeFire.