Configurando Ubuntu Linux como media server para Xbox360

Olá!

Já faz algum tempo que eu não posto nada no blog, e o motivo é que realmente não estava com assunto para postar. Porém, agora tem um bom assunto para postar.

XBOX 360Como alguns sabem, tenho vários consoles de videogames, entre eles já citados um Nintendo DS (na verdade agora tenho um Nintendo DSi mais dois Nintendo DS) e um PSP. Como não poderia deixar de ser, tenho meus consoles de mesa: um PS2, um Wii e um XBOX 360.

O último foi uma aquisição que fiz com o objetivo duplo de jogar (obviamente) e de utilizar como Media Center. Mas como tudo que envolve a Microsoft, descobri que existe um trabalho bastante significativo para colocar vídeos para rodar no XBOX 360, quem dirá disponibilizar esse vídeos em modo Media Server (ou seja, de modo que os vídeos estejam no computador caseiro e sejam buscados pelo XBOX via rede)

Em parte isso se deve a problemas de protocolo e em parte a formatos de arquivo. Então iremos dividir o artigo em duas partes. A primeira, sobre como codificar vídeos para o formato do XBOX 360, e a segunda sobre como disponibilizar os vídeos codificados da maneira correta via rede.

Codificando vídeos para o formato do XBOX 360

O XBOX 360 possui formatos muito determinados sobre como os videos devem ser codificados para ele. No caso, adotaremos um enocde para WMV (Windows Media Video), e utilizaremos uma ferramenta gráfica para Linux, o Hyper Video Converter, que nada mais e que um frontend para MPlayer/Mencoder e ffmpeg. Procure e baixe no site o pacote .deb ou .rpm e instale conforme a suia distro. Ele irá criar um ícone no Menu K /Aplicações. Abra o programa. Ao abrir, uma janela como a abaixo irá aparecer.

Primeira coisa: você vai precisar criar um diretório onde você irá jogar seus arquivos encodados. No meu caso: /home/teste/video. Isso será importante no segundo estágio, quando formos disponibilizar os vídeos via rede. Por agora, escolha qualquer pasta. Em encoder, escolha ffmpeg. Iremos trabalhar com ele por enquanto. Clique em “Encoder Settings”. Você receberá uma janela como a seguinte:

No caso, ele já está com todas as informações sobre como o vídeo deve ser codificado, segundo o link apresentado anteriormente.No caso, optamos por encodar o vídeo em formato WMV2 em Video Codec, que é o único que permite encodar vídeos com saída em FullHD para ele. De qualquer modo, utilizaremos a resoloção como 720p, setada em Video Size (perceba que ela foi colocada em Custom e o valor digitado na caixa de texto em baixo). O Aspect foi deixado em 1:1 (acredito que isso permita que o Aspect Ratio original dos vídeos a serem encodados, sem os distorcer). Setamos o Container Format para ASF. Isso é importante pois o formato ASF é o container padrão para o Windows Media Video. O Video Bitrate pode ser definido para qualquer valor, mas acredito que entre 5000 a 10000 kbps é o suficiente. Menor bitrate implica em maior granulação, enquanto um Bitrate menor pode servir apenas para aumentar demais o arquivo (que ficará enorme). Deixe Target em default.pois ele serve apenas para alguns pré-defs relacionados com DVD (portanto, não é uma boa idéia mexer aí). O Audio Format ddverá ser configurado para wma2 (Windows Media Audio versão 2). Audio Bitrate pode ser deixado em qualquer valor, então 128 kbps deve ser um valor adequado (caso encode shows, pode desejar aumentar esse valor, conforme a qualidade das fontes originais). Sample Rate não têm restrições também, então deixamos em 44100 bps, que é o valor padrão para CD ou DVD.

Precisaremos de algumas configurações mais avançada, então clique em Advanced Settings para que a janela pareça com a seguinte:

A única coisa que precisamos deifinir aqui é o Framerate. Clique na caixa correspondente e defina o valor. No caso atual meu, defini como 25 fps. Se desejar, o limite é de 30 fps conforme o link apresentado anteriormente.

Na aba Misc. Video Settings, existem poucas opções interessantes.

Eu uso por costume 2-pass encoding, mas segundo alguns não faz a menor diferença. Se tiver dúvidas, não mexa nessa aba e aceite os padrões, clicando em OK ao terminar. Clique em Open Files para adicionar videos para conversão. Se selecionar mais de um vídeo, selecione a opção convert all input. Mude a Extensão para wmv e clique em Create Command. Ele irá apresentar na caixa de diálogo de baixo a linha de comando a ser executada. Clique em Convert e aguarde.

A conversão demorará significativamente e, além disso, gerará arquivos enormes (700 MB para 20 min), portanto tenha muito HD livre ao tentar isso ou jogue a saída para um pendrive. Na realidade, precisaremos usar um Pendrive depois do vídeo convertido.

Testando o vídeo

Uma vez que você tenha codificado seu vídeo (lembre-se de ter todos os codecs instalados em sua máquina, inclusive – e especialmente – os de WMV), o vídeo será colocado na pasta indicada em Output Directory, com o nome original e extensão definida em Extension (no nosso caso, wmv). Copie o arquivo para um pendrive e leve ao XBOX 360. Conecte o pendrive por uma das entradas USB, seja as traseiras (próximas à entrada de rede) ou as dianteiras (em baixo do botão de força, protegidas por uma tampa). Ligue o XBOX.

No Dashboardo do XBOX 360, escolha a opção “Biblioteca de Vídeo“. Aperte A.

A opção “Dispositivo Portátil” deverá estar acesa. Selecione-a e navegue no conteúdo do pendrive até achar o arquivo codificado. Selecione-o e clique em Executar. Ele deverá ser exibido. Caso não seja, verifique as configurações de vídeo anteriormente citadas e modifique-as até que o resultado final seja de seu agrado.

Para facilitar a vida, o Hyper Video Converter aceita que você salve Profiles de configurações de vídeo. Uma vez que você tenha a opção adequada, salve-a clicando em Save Profile no Encoder Settings e dê um nome ao mesmo na janela que irá aparecer (ele não sobrescreve profiles existentes). Para carregar um profile, clique em Manage Profiles na janela principal.

Escolha o programa utilizado (no nosso caso, ffmpeg) selecione o profile desejado e clique em Load.

Ok… Uma vez que o vídeo esteja funcionando corretamente, você irá se pegar pensando no tamanho do vídeo gerado e em como isso é dose de ter que ser feito o tempo todo. No caso, vamos utilizar o uShare como servidor de mídia (Media Server), por meio do protocolo uPnP A/V.

Cnfigurando o Media Center

Primeiro, instale como padrão o uShare conforme sua distro. A maioria das distros modernas oferecem o uShare a partir de seus repositórios padrão, assim como suas dependências. Use os comandos adequados para instalar o uShare.

Como root (ou usando sudo), abra um editor de arquvios e procure o arquivo /etc/ushare.conf. Será necessárias algumas modificações nesse arquivo para disponibilizar os vídeos via rede. O arquivo irá se parecer com algo como abaixo.

# /etc/ushare.conf
# Edit this file with 'dpkg-reconfigure ushare'
# Configuration file for uShare
# uShare UPnP Friendly Name (default is 'uShare').
USHARE_NAME=hufflepuff
# Interface to listen to (default is eth0)
# Ex : USHARE_IFACE=eth1
USHARE_IFACE=eth1
# Port to listen to (default is random from IANA Dynamic Ports range)
# Ex : USHARE_PORT=49200
USHARE_PORT=
# Port to listen for Telnet connections
# Ex : USHARE_TELNET_PORT=1337
USHARE_TELNET_PORT=
# Directories to be shared (space or CSV list).
# Ex: USHARE_DIR=/dir1,/dir2
USHARE_DIR=/home/teste/videos
# Use to override what happens when iconv fails to parse a file name.
# The default uShare behaviour is to not add the entry in the media list
# This option overrides that behaviour and adds the non-iconv'ed string into
# the media list, with the assumption that the renderer will be able to
# handle it. Devices like Noxon 2 have no problem with strings being passed
# as is. (Umlauts for all!)
#
# Options are TRUE/YES/1 for override and anything else for default behaviour
USHARE_OVERRIDE_ICONV_ERR=yes
# Enable Web interface (yes/no)
USHARE_ENABLE_WEB=yes
# Enable Telnet control interface (yes/no)
USHARE_ENABLE_TELNET=no
# Use XboX 360 compatibility mode (yes/no)
USHARE_ENABLE_XBOX=yes
# Use DLNA profile (yes/no)
# This is needed for PlayStation3 to work (among other devices)
USHARE_ENABLE_DLNA=no

A maior parte das conbfigurações podem ser deixadas no padrão da distro. No caso, vamos falar das configurações que devem ser modificadas.

  • USHARE_NAME=hufflepuff - Essa linha informa o nome pelo qual sua máquina será conhecida como Media Center. Escolha o nome que lhe aprouver;
  • USHARE_IFACE=eth1 - Essa linha indica qual interface de rede será usada como saída para o seu Media Center. A não ser que você tenha várias placas de rede e/ou algum problema com a interface de rede padrão (eth0), pode deixar em branco. Caso contrário, escolha a inferface a ser utilizada, lembrando que o XBOX 360 deve estar conectado fisicamente à estrutura de rede desejada;
  • USHARE_DIR=/home/teste/video - Essa linha é uma das que devem ser obrigatoriamente modificada. Ela indica onde o uShare deverá buscar arquivos de mídia. No meu caso, /home/teste/video. Lembre-se de dar o mesmo caminho dado no Hyper Video Converter, ou então selecionar vários caminhos, separando-os por vírgulas.
  • USHARE_ENABLE_WEB=yes - Essa linha é útli ao administrar os compartlhamentos a serem buscados. Se você ativar essa opção, a janela de administração do uShare estará disponível em http://<servidor&gt;:<porta>/web/ushare.html, onde <servidor> representa o IP ou DNS do servidor uShare (repare que esse nome não precisa ser o mesmo e pode não ter relação com o nome uPnP indicado em USHARE_NAME) e  <porta> é a porta definida pelo uShare para atender (normalmente 49152, modificada em USHARE_PORT);
  • USHARE_ENABLE_TELNET=no - Essa linha tem a mesma funcionalidade e uso da anterior, USHARE_ENABLE_WEB, mas usando Telnet ao invés do navegador. Como isso pode ser um potencial furo de segurança (uma vez que o Telnet não é um protocolo conhecido pela segurança), é recomendável deixar essa opção em no;
  • USHARE_ENABLE_XBOX=yes – Essa opção é a que define o suporte para o XBOX 360 e deve estar obrigatoriamente em yes;
  • USHARE_ENABLE_DLNA=no – Essa opção define o suporte para alguns recursos avançados em uPnP A/V. Essa opção é usada em especial no PS3 e em outros Media Centers, mas usar essa opção no XBOX 360 apenas serve para confundir o sistema. No caso, deixe-a em no se for usar o XBOX 360 como Media Center;

Com isso definimos toda a configuração necessária para o mesmo no Linux. Inicie o servidor conforme a distro (normalmente service ushare start como root). Nota: no Ubuntu por algum motivo o uShare ignora sumariamente a opção USHARE_ENABLE_XBOX=yes, portanto devemos forçar o suporte a XBOX 360. Para isso, inicie o uShare em um terminal ushare -x. Antes disso, pare o servidor uShare (normalmente com sudo service ushare stop). O uShare pode ser iniciado sem obrigatoriedade de superusuário por usar portas TCP altas (acima de 1024). Mantenha o terminal aberto enquanto não estiver o usando. Como opção, pode ser usado o comando nohup ushare -x & para fazer com que o uShare rode em backgroung.

Configuração no XBOX 360:

Primeiro, ligue o XBOX 360 à rede onde o Media Server uShare está ligado (nomralmente conectando um cabo entre o roteador da rede do uShare e o XBOX 360). Em seguida, ligue o XBOX 360 e vá em “Configurações de Sistema“.

Vá em Configurações de Rede.

Selecione Testar Conexão no PC. Ele poderá dar um aviso de desconectar os usuários do videogame. Confirme e aguarde. Ele deverá aparecer uma máquina com o nome dado por voce em USHARE_NAME.

Tudo OK, aperte A e volte para o Dashboard e escolha a opção “Biblioteca de Vídeo“. Aperte A.

Deve ter uma opção com o nome da sua máquina. Escolha-a. Uma lista dos vídeos disponíveis na sua pasta deve aparecer. Atenção: ele não fará distinção de pastas, colocando todo o conteúdo dentro da pasta espalhado. Escolha o vídeo desejado e clique em Reproduzir:

E aproveite os seus vídeos. Utilizar o XBOX 360 como Media Center dá um certo trabalho, mas vale a pena!

PS: As telas do XBOX 360 foram fotografadas com uma câmera FujiFilm FinePix s5100fd com alta qualidade a partir de uma teve LCD 32″ buster 720p.

Leia mais deste post

Anúncios

Por que não me surpreendo? Documentos produzidos no MS Office 2007 NÃO SÃO COMPATÍVEIS com DIS 25900 (OOXML)

Certas coisas, quando você lê, não te surpreende. Não interessa o que, mas certas coisas, ao lê, não te surpreende. No meu caso foi ler que, via Groklaw, que documentos MS Office 2007 não são compatíveis com o ISO 25900, também conhecido como OOXML.
Surpreendente? Calma que a coisa ainda vai fiar pior!!!

Bem, tudo começa quando Alex Brown, um dos pais dessa aberração chamada OOXML, decide fazer um teste após receber os schemas atualizados com as modificações sugeridas no BRM.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

I was excited to receive from Murata Makoto a set of the RELAX NG schemas for the (post-BRM) revision of OOXML, and thought it would be interesting to validate some real-world content against them, to get a rough idea of how non-conformant the standardisation of 29500 had made MS Office 2007.

Not having Office 2007 installed at work (our clients aren’t using it – yet), the first problem is actually getting a reasonable sample for testing. Fortunately, the Ecma 376 specification itself is available for download from Ecma as a .docx file, and this hefty document is a reasonable basis for a smoke test …

Resumindo aqui, uma vez que a tradução seria longa e desenecessária: ele recebeu os novos schemas do OOXML atualizados para considerar as modificações do BRM e decidiu validar algum conteúdo “real” para ter uma idéia de o quão não-padronizado um arquivo .docx produzido pelo MS Office 2007 era. Como ele não tinha nenhum Office 2007 à mão, ele utilizou as próprias especificações do OOXML segundo a ECMA, que foram publicadas em… .docx.
Perceba a fina ironia: o que deveria confirmar o padrão acabou tornando-se um caso de uso negativo contra o mesmo. Acha engraçado? Eu não.

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

The main document (“document.xml”) content for Part 4 of Ecma 376 weighs in at approx. 60MB of XML. (…) So we have a document and a RELAX NG schema. All that’s necessary now it to use jing (or similar) and we can validate (…) The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format’s most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.

Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message.

Traduzindo

Os conteúdos do documento principal (“document.xml”) da Parte 4 do ECMA 376 [a primeira versão do OOXML] tinham algo em torno de 60 MB de XML (…) portanto tinhamos um documento e um schema em formato RELAX NG. Tudo o que precisávamos portanto era usar o jing [validador de documentos segundo schemas RELAX NG feito em Java] ou outros sistemas similares e poderíamos validar o documento (…) O modelo de conformitade STRICT é um tanto diferente do ECMA 376, essencialmente por causa de que os mais notórios recursos (como datas não-ISO, informações de compatibilidade como os do autospacewotnot, VML, etc.) forma removidos. Desse modo a expectativa era de que documentos Office 2007 deveriam estar longe de serem considerado válidos segundo schemas restritos.
Obviamente, o jing retornou algo em torno de 17MB (ou por volta de 122.000) de mensagens de erro enquanto validando o documento nesse cenário. A maior parte deles tem a ver com atributos ou valores de atributos não reconhecidos: imagino que um documento que utilize uma gama maior de recursos provoque uma gama maior de erros.
(Grifos meus)

Note que o próprio autor assume que (1) documentos do MS Office 2007 não estavam longe de serem considerados padrão e (2) que documentos que usassem mais recursos provavelmente gerariam mais mensagans de erro.
Agora, a pergunta é: se o formato foi padronizado, quanto tempo o usuário do Office 2007 deveria esperar para ter documentos DIS-25900 compliant, uma vez que o Office 2007 é a “implementação de referência” do OOXML? Como comparação, o OpenOffice.org é a “implementação de referência” do ODF, e levou apenas duas semanas para que o mesmo gerasse documentos ODF compliant.
No mesmo post, o autor mostra um outro schema, TRANSITIONAL, que é mais “liberal” que o STRICT. Mesmo assim, o documento gerou mensagens de erro relacionadas a uma tag específica. As concluões? O próprio autor coloca:

Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

  • Word documents generated by today’s version of MS Office 2007 do not conform to ISO/IEC 29500
  • Making them conform to the STRICT schema is going to require some surgery to the (de)serialisation code of the application
  • Making them conform to the TRANSITIONAL will require less of the same sort of surgery (since they’re quite close to conformant as-is)

Traduzindo:

  • Documentos do Word gerados pela versão atual do MS Office 2007 não são compatíveis com o ISO/IEC 29500
  • Torná-los compatíveis com o schema STRICT demandaria alguma “cirurgia” nos códigos de (de)serialização de objetos na aplicação
  • Torná-los compatíveis com o schema TRANSITIONAL demandaria menos “cirurgia”, uma verz que ele está mais próximo da compatibilidade como-está;

Para resumir:

  1. Documentos do Word 2007 não são compatíveis com o OOXML;
  2. Torná-los compatíveis fielmente ao padrão OOXML (ISO 29500) demandaria grandes modificações no código do Office 2007;
  3. Torná-los compatíveis ao schema de transição demandaria poucas modificações, uma vez de que este schema está mais próximo do Office 2007;

Será que sou só eu que ainda acredito que isso não passou de um motivo para a MS arrumar um selinho de ISO para seus produtos e ainda assim manter seu lock-in nos documentos?
Além disso, será que a própria Microsoft não irá sabotar esse “padrão ISO” por si? O autor do post que estamos comentando é otimista (talvez de maneira quase Polianística):
Griffin Brown Weblog – OOXML and Office 2007 Conformance: a Smoke Test

Given
Microsoft’s proven ability to tinker with the Office XML file format
between service packs, I am hoping that MS Office will shortly be
brought into line with the 29500 specification, and will stay that way.
Indeed, a strong motivation for approving 29500 as an ISO/IEC standard
was to discourage Microsoft from this kind of file format rug-pulling
stunt in future.

Ou seja

Dada à habilidade da Microsoft de melhorar o formato do Office XML por meio dos service packs, espero que logo o MS Office seja alinhado com as especificações 29500 e assim permaneça. De fato, um dos maiores motivadores para a aprovação do 29500 como um padrão ISO/IEC foi como uma forma de desencorajar a Microsoft quanto a essa atitude de discrepâncias em relação ao padrão no futuro.

Diferentemente do autor do post em questão, sou mais cético: o retrospecto histórico, inclusive durante o processo de padronização do OOXML, da MS joga contra ela. Porém, espero realmente que, caso a MS continue por essa vereda, que ela ao menos alinhe-se ao padrão que, por mais ruim que seja, ela ajudou a criar. Mas até lá, vou continuar atento, observando isso e evitando ao máximo o OOXML.

Office OpenXML (OOXML) e inapto pela ISO 29500

Porque o eeePC pode ser o “Windows Killer”

Pequeno, simples e fácil de usar, o Asus eeePC tem sido recentemente a grande hype do momento. Uma máquina que tem poder de fogo de um computador low end, pequena, durável (não contêm peças móveis) fácil de ser usada e razoavelmente barata (R$ 1500,00 em importadores legais, menos nos Stand Centers da vida), ele vem se tornando o objeto de desejo tanto de geeks quanto de pessoas comuns, pois em suas dimensões e uso ele lembra bastante o XO-1 da iníciativa OLPC. Embora venha com uma versão customizada do Xandros, com diversos aplicativos tradicionais no ambiente Linux (Firefox, Thunderbird, OpenOffice.org), ele tornou-se ainda mais querido por causa dessa sua capacidade de ter aplicações de produtividade já conhecidas, além de ter a capacidade de rodar SOs tradicionais, como Ubuntu e até mesmo o Windows.
Agora, o mais interessante é notar que o eeePC pode ser o “Windows Killer“, porque ele é objetivado para ser uma “ferramenta de produtividade”. Ele não é um notebook para o fã de games ou para um desenvolvedor (ao menos como estação principal), mas para pessoas com poucas exigências computacionais, como jornalistas, advogados e outros, a simplicidade e tamanho podem vir bem a calhar, ainda mais com os conceitos de usabilidade embutidos no eeePC, como a idéia de Documentos em um lugar só, Planilhas em outro, e por aí afora.
E como isso pode preocupar a gigante de Redmond? Vejamos…

Of Microsoft, GNU/Linux and Boiled Asses’ Heads | Linux Journal

(…) the idea of putting Windows Vista on an Eee PC is so ridiculous it’s not even funny. Windows XP was the only option if Microsoft wanted to avoid handing the entire ultramobile sector to GNU/Linux.

Ou seja:

(…) a idéia de usar o Windows Vista em um Eee PC é tão ridícula que não chega sequer a ser engraçada. O Windows XP é a única opção que a Microsoft tem para impedr que todo o setor dos sistemas ultraportáteis caia na mão do GNU/Linux

Podemos perceber aqui que a Microsoft está em uma situação na qual ela não pode matar seu antigo SO, pois se o fizer poderá perder o trem da história e desse modo poder cair no esquecimento. Mas você acha que isso é alguma demanda dos clientes? Pode até ser, mas existe alguma mentira em declarações da Microsoft sobre a idéia de que os consumidores desejem apenas o Windows XP Home nessas máquinas.

Of Microsoft, GNU/Linux and Boiled Asses’ Heads | Linux Journal

Microsoft customers have been begging for all varieties of Windows XP to be available for every device, not just the Home version for ultraportables. Far from any “ongoing commitment to deliver the right version of Windows for new device categories as they emerge”, Microsoft has been desperately trying to stuff Vista onto any machine that has processor – including systems that are woefully underpowered for its inordinate resource demands. Windows XP Home is not “the right version of Windows”, it is simply the only one that was at all plausible.

ou seja

Os consumidores da Microsoft estavam implorando para que todas as  versões do Windows XP ficassem  disponíveis para quaisquer sistemas, e não apenas o Windows XP Home para os ultraportáteis. Diferentemente de qualquer “comprometimento atual de fornecer versões adequadas do Windows para os novos dispositivos que vão surgindo”, o desejo desesperado da Microsoft era o de socar o Vista em qualquer máquina que tenha um processador – inclusive naqueles com poder de fogo muito aquem do necessário para suas demandas de recursos descabidas. O Windows XP Home não é “a versão certa do Windows”, é simplesmenta a única que pode resolver. (grifos meus)

Ou seja: pensar no eeePC rodando Windows Vista ou mesmo o XP Professional é algo não apenas fora de cogitação, mas completamente fora da realidade, o que não chega a ser ruim. O eeePC não é uma máquina voltada a poder de fogo. É uma máquina simples para usos cotidianos, como criar um documento em um processador de texto ou afins.

A coisa toda continua quando o autor do artigo da Linux Journal, Glyn Moody, comenta as declarações de Michael Dix, Gerente Geral da área de Gerenciamento dos Clientes de Produtos Windows: copio a citação em questão.

PressPass: Why are customers asking for Windows on these devices?

Dix: Three benefits are driving this interest in Windows. First, the Windows experience makes it easy for existing PC customers to use these new devices, and it makes these devices easy to learn for customers new to computing. Second, only Windows provides customers access to the widest range of applications, devices and online experiences. Finally, our partners already know how to build and support great systems powered by the Windows platform.

Essa parte não vou traduzir mas se resume à seguinte afirmação: “todos usam Windows; todos desenvolvem para Windows; qualquer coisa usa Windows; então devemos usar Windows.”
Será mesmo? Vejamos o que o autor do artigo do Linux Journal tem a dizer:
Of Microsoft, GNU/Linux and Boiled Asses’ Heads | Linux Journal

One of the surprising things about the Asus Eee PC is that everybody finds it almost trivially easy to use. Indeed, single-handedly it gives the lie to the idea that GNU/Linux is only for geeks. So it’s understandable that Microsoft should want to hammer home the idea that only a Windows-based ultraportable could be easy to use. In fact, the opposite is true: the interface of the Eee PC, with its Firefox-like tabs and big, easy-to-understand icons, is so simple that it makes Windows XP look incredibly complicated when placed side by side. This whole line of reasoning reveals one of Microsoft’s greatest fears for the future: that general users might one day realise they don’t need the crutch of the Windows interface.

ou seja

Uma das coisas mais surpreeendentes no eeePC é que todos acham que ele é extremamente simples, quase trivial, de se usar. Na prática, ele sozinho tem sido o responsável por mostrar a falácia que é afirmar que o GNU/Linux é apenas para geeks. E isso explica o motivo pelo qual a Microsoft deseja tanto empurrar goela abaixo das pessoas a idéia de que apenas um ultraportátil rodando Windows seria usável, quando na verdade o contrário é verdadeiro: a interface em abas similar às do Firefox do eeePC, com ícones grandes e amigáveis e tão simples que torna o Windows XP extremamente complicado se você colocar ambos lado a lado. Tudo isso mostra um dos principais medos que a Microsoft tem do futuro: de que o usuário comum um dia possa perceber que ele não precisa ficar amarrado à interface do Windows.

Isso também prova que o Linux não é complicado como se afirma: embora ele possua suas idiossincrasias por sua base Unix, ele (assim como o Mac OSX) está suficientemente gabaritado em softwares e interfaces para “ocultur” do usuário a maior parte dessas idiossincrasias. Podemos até afirmar que, para usuários totalmente leigos em informática, sem “vícios de Windows”, o Linux é tão simples (ou complexo) quanto o Windows. O eeePC vem comprovando isso. Mas ele também vê como o eeePC pode mostrar as jogadas sujas da Microsoft:
Of Microsoft, GNU/Linux and Boiled Asses’ Heads | Linux Journal

Any Web site that follows open standards will be viewable by any standards-compliant browser. Microsoft’s comment only makes sense in the context of non-standard Web content that is tied to Internet Explorer. Another looming concern of Microsoft, then, is that people might start demanding that sites follow Web standards and thus further decouple the Web server platform from the Web browse.

ou seja:

Qualquer site que siga os padrões abertos [da Web] poderá ser visto em qualquer navegador que siga esses padrões. Os comentários da Microsoft [de que apenas produtos Microsoft são compatíveis com os principais sites] apenas fazem sentido se levarmos em conta os sites que possuem conteúdo não-padrão amarrado ao Internet Explorer. Outra preocupação tremenda da Microsoft, portanto, é que as pessoas comecem a exigir que os sites sigam os padrões da Web de modo a desacomplar a plataforma do servidor Web e a do navegador Web.

Open Standard Compliance” (seguir padrões abertos) é algo extremamente importante. Isso não é desculpa de freetards e open-xiitas para quererem destruir a Microsoft: empresas como IBM vêm tomando essa consciência e percebendo que seguir padrões permite uma disputa de mercado baseada nas qualidades técnicas dos produtos. A IBM vêm fornecendo a um certo tempo sistemas que, embora proprietários, são standard compliant, obtendo conectividade e interoperabilidade real com ambientes de outros fornecedores e até mesmo de concorrentes. Desse modo, o valor passa a ser agregado no âmbito de múltiplas soluções, e não de apenas soluções de um único fornecedor.
Por fim, mais no fim do artigo, Glynn nos dá a principal pista de porque o eeePC pode ser o “Windows Killer”

Of Microsoft, GNU/Linux and Boiled Asses’ Heads | Linux Journal

Once people start using GNU/Linux on systems like the Eee PC, and find it almost trivially easy to use programs like Firefox and OpenOffice.org, they are going to wonder why they should pay the Microsoft tax when they buy a notebook or desktop. Microsoft can’t let that knowledge get out into the general user market, which means that it must offer a Windows product here to plug the gap in the barbed wire that guards the perimeter

ou seja:

Uma vez que as pessoas comecem a usar o GNU/Linux em sistemas como o eeePC e percebam que é bem simples usar programas como o Firefox e o OpenOffice.org, elas irão se perguntar porque é que elas pagam o “imposto Microsoft” quando compram um notebook ou um computador doméstico. A Microsoft não pode permitir que essa idéia chegue ao público em geral, o que significa que ela precisa oferecer um produto Windows aqui para tapar o buraco que ficou na trincheira.

Essa noção é uma noção que a Microsoft não pode deixar passar: a de que existem produtos de software simples e bons o bastante para serem usados e que custam menos que seus produtos, o que pode vir a se tornar a Normandia dos sistemas operacionais.
Eu não sou muito fã do eeePC: como sou meio bruto e tenho mão pesada, acho que esses “notebook lancheira” estilo eeePC ou XO-1 não são para mim. Mas vejo um ambiente promissor para o eeePC, e por tabela ao Linux, uma vez que um eeePC com Linux bem customizado e voltado ao usuário pode ser a solução para a maior parte dos problemas de um usuário cotidiano, de maneira barata e efetiva. E com isso, a popularidade do Linux pode crescer, levando ao desenvolvimento de um mercado cada vez mais ativo e inovador em soluções, principalmente voltadas a open standards e com isso gerar um mercado no qual todos (e talvez, até mesmo a Microsoft) ganham.


Powered by ScribeFire.

OOXML = ISO 29500 – Microsoft Ganha, todos perdemos

Pois é Aconteceu o que temíamos: o OOXML agora é o ISO 29500 (com link apenas para que não achem que isso é um “1° de Abril” atrasado). Com uma série de defeitos técnicos e irregulariedades, e contando com o voto de “importantes países” como Azerbaijão, Costa do Marfim, Casaquistão, e Trinidad e Tobago, a Microsoft conseguiu seu intento e agora OOXML é um “padrão internacional”.
Ou seja: ela ganha, nós perdemos.
Por favor, não me venham dizer aquele positivismo polianista de que tudo está OK e que veremos implementações livres do OOXML logo. Sinceramente, um padrão de 6000 páginas, cheia de problemas técnicos e incertezas jurídicas, sobre os quais eu cansei de falar nesse blog, e que foi comentado por muita, muita gente, apenas fez com que a Microsoft conseguisse uma ferramenta para legitimar seu monopólio e ao mesmo tempo minou completamente a legitimidade da ISO, vítima de suas próprias decisões e da má-fé de Redmond. Mesmo que não houvessem os riscos de “patente submarina” (prefiro o termo “campo minado de Propriedade Intelectual”), a complexidade dos padrões e as questões dos artefatos de implementação complicam e muito o desenvolvimento de uma solução à parte da Microsoft de implementação do OOXML. Essa é a preocupação justamente do pessoal da ODF Alliance:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The process itself brought to the fore OOXML’s deficiencies that will prevent its use by public administrations, chief among them that OOXML remains a “community of one”—undocumented features, IPR restrictions, and features and functionality linked to other Microsoft products that will prevent OOXML’s use in other software products. (…) Nothing about the process will provide governments with any more confidence in OOXML’s openness and interoperability than they had before the vote.

Traduzindo:

O próprio processo [de padronização] trouxe à luz todas as deficiências que irão impedir o uso do OOXML na administração pública, a começar pelo fato de que o OOXML continua sendo uma “comunidade de uma pessoa só” – recursos não documentados, restrições relacionadas a Propriedade Intelectual, e recursos e funcionalidades ligadas a outros produtos Microsoft que o impedirão de ser usado com outros produtos (…) Não houve nada nesse processo que ofereceu aos governos qualquer confiança adicional na abertura e interoperabilidade do OOXML. (Grifos Meus)

Ou seja, qual a confiança que um governo, que possui necessidades críticas em vários sentidos quanto a documentação, possui de adotar o OOXML? Quais as garantias de compatibilidade, interoperabilidade, abertura e transparência do mesmo? Quais são as garantias que, uma vez que um governo crie uma estrutura baseada no OOXML, independente de utilizar produtos Microsoft ou não, ele poderá o fazer sem riscos e sem a possibilidade de processos por patentes ou qualquer outro tipo de infração de propriedade intelectual?
Governos necessitam armazenar documentos por 10, 20, 30, até mesmo 50 anos dependendo o documento, apenas pelo caráter legal. Confiar em um formato onde, a qualquer momento, uma pessoa, não importa qual, pode simplesmente dizer que vai levar a bola para casa e pior, que todo mundo que jogou com ele vai ter que pagar por ter usado a bola, é algo para dizer o mínimo temerário.
Isso é uma coisa que não poderia passar, como não passou e a ODF Alliance comenta:

ODF Alliance Weblog – ODF Alliance Statement on the ISO Vote on OOXML

The vote shined a spotlight on OOXML that will not dim. Only in response to growing public pressure has Microsoft promised to make changes to OOXML, and, to be sure, similar promises have been made on numerous occasions. To avoid any questions concerning the legitimacy of the vote, which included many documented irregularities, Microsoft needs to ensure that these promises made to national standards bodies are actually delivered.

Tradução:

A votação [de padronização da ISO] acendeu um sinal de alerta no OOXML que não irá apagar-se. Foi apenas graças à pressão pública que a Microsoft prometeu fazer mudanças no OOXML, o que, para ser sincero, já aconteceu antes em várias ocasiões. Para evitar questões relacionadas à legitimidade da votação, que inclui muitas irregularidades documentadas, a Microsoft tem que garantir que essas promessas feitas aos órgãos nacionais [de padronização] sejam realmente cumpridas. (Grifos meus)

Agora, será que isso acontecerá? De uma maneira otimista, eu gostaria que sim: gostaria de ver maior interoperabilidade entre os vários produtos. Porém, conhecedor do retrospecto (me sinto tentado a usar o termo karma) da Microsoft, não vejo como ter tais esperanças.
A ISO também sai perdendo nesse processo. Ao deixar que uma série de irregularidades ocorre-se (e perceba que a participação da Microsoft em vários NBs ou de seus Partners não é em si tal coisa), ela comprometeu todos os fundamentos que a tornavam digna de crédito: ao abaixar a cabeça para não ver o que aconteceu em vários países, ela acabou recebendo e aceitando sua parcela de culpa por um processo que, a meu ver, foi feito de maneira completamente errada. E se você acha que isso é blá-blá-blá meu, veja no mapa abaixo o tanto de caveiras que existem no mapa (cada caveira indica um país onde foram constatadas irregulariedades sérias no processo):

Clique para ampliar

Desse modo, o que aconteceu é que a ISO, ao “fechar-se em copas” em relação a essas falhas sérias do OOXML acabou perdendo muita coisa:

R.I.P. International Standards Organization « Adventures in a Perambulator

A failure, on the part of ISO, in so re-evaluating this situation during the next 2 months will result in my calling into question anything considered a standard by ISO. Any government, organization, agency or other that uses ISO as the authority for anything being a standard will be asked to prove that it actually is a standard: ISO authority will not be an acceptable response. It is my opinion that by this action of approving MSOOXML as a standard, ISO has demonstrated that it lacks the qualifications to adequately evaluate technical material and has further shown that its ethical behavior is subject to the highest bidder.

Traduzindo:

Uma falha por parte da ISO em reavaliar essa situação [de considerar padrão qualquer coisa que lhe seja empurrada goela abaixo] nos próximos dois meses me levará a questionar qualquer coisa que a ISO considere padrão. Qualquer governo, organização, órgão ou afim que use a ISO como autoridade para qualquer coisa que seja considerada um padrão deverá se questionar se realmente isso é um padrão: apenas a autoridade da ISO não será mais uma resposta aceitável. Na minha opinião, ao aprovar o MSOOXML como um padrão, a ISO demonstrou ter perdido as qualificações para adequadamente avaliar materiais técnicos e também demostrou que seu comportamento ético é digno de intenso repúdio. (Grifos meus)

Deixando-se penetrar por um processo que, embora tenha seguido (ainda mal-e-mal) a letra da norma, foi corrompido por trás dos panos por uma série de questionamentos, irregulariedades, lobbies e afins, a ISO perdeu (ou ao menos manchou) sua credibilidade. Se tal aprovação viesse de um consenso, seja por Fast-Track ou não, a ISO manteria sua credibilidade. Porém, ao aceitar as pressões de Redmond e não questionar como as coisas ocorreram nos países, aceitando passivamente isso, ela deixou essa credibilidade ser maculada (de maneira permanente, potencialmente) e, desse modo, colocou em xeque TODOS os padrões ISO. Alguns, como ODF, PDF e ISO 9000 escaparam ilesos, uma vez que são reconhecidos não apenas por meio da ISO, mas por suas próprias qualidades. Os demais, porém, passarão a ser questionados cada vez mais.
Eu duvido que em algum momento os questionamentos feitos foram realmente levados a sério. Parece choradeira de mau perdedor, mas se você ler os artigos do meu blog sobre o assunto, você verá que em si não sou contra o OOXML. O que eu sou contra é que, como colocado, o OOXML é uma forma de obter-se um crivo internacional a um monopólio que vem a dar poderes ilimitados apenas a uma empresa.
Não vou continuar repetindo meus entendimentos sobre o OOXML: basta ler aqui no meu blog todos os artigos que escrevi sobre o assunto. Porém, o que vou afirmar é que, a não ser que o processo de padronização do OOXML seja revertido, ninguém mais confiará na ISO e ela irá obter a mesma reputação que a Microsoft (que não é lá muito boa).
Gostaria de citar o desabafo do Jomar, alguém que camelou demais e viu seus esforços por um padrão realmente técnico e correto ser atropelado por um rolo compressor vindo de Redmond:


OpenXML: Eles realmente ganharam ? | void life(void)

Se a decisão é de que problemas são “coisinhas”, ela não foi técnica e portanto ganhamos todos um grande exemplo de onde se chega quando se coloca a boa técnica de lado (ou alguém aí consegue, sem consumir substâncias alucinógenas, acreditar que ter CINCO RECOMENDAÇÕES OFICIAIS PARA SE ESCREVER UMA SIMPLES DATA é algo lógico e natural !!! E que isso ainda irá contribuir para o aumento da interoperabilidade ?). Prá falar a verdade, como fã de Rock’n Roll eu até que vi um bom “revival” da lisergia dos anos 70 nisso tudo (pois só com muito LSD na cabeça eu talvez conseguisse explicar e defender publicamente a tese de que uma só norma internacional é na verdade cinco que na verdade possue duas cláusulas de conformidade que a torna dez sendo ao mesmo tempo uma… fiquei até tonto só de pensar nisso para poder escrever…e olha que eu não tomei nada, heim…).

Ou seja, na realidade, a ISO e todo o processo do Fast-track foi apenas uma forma da Microsoft conseguir um Selinho de ISO para o Office 2007. Sabe, como os selinhos ISO-9000 que qualquer empresa deseja para mostrar que seu produto é o máximo, ainda que ele seja uma porcaria… ainda que seja a mesma porcaria o tempo todo? Como um padrão com redundâncias, discrepâncias, contradições e afins passou pela ISO, que deveria zelar pela qualidade técnica?
E para realmente terminar esse post, deixo as mesmas perguntas do Jomar à Microsoft:

OpenXML: Eles realmente ganharam ? | void life(void)

  1. Quando o Microsoft Office vai suportar a IS 29500 (ele agora suporta apenas o ECMA-376, que é uma especificação diferente) ? E quais delas serão suportadas (IS 29500-1, IS 29500-2, IS 29500-3, IS 29500-4, IS 29500-5) com quais classes de conformidade (viu como agora vai ser bem fácil comprar uma suite de escritório que suporte o OpenXML…) ?
  2. Quando sai o próximo Service Pack do OpenXML ?
  3. Vocês já prepararam algum mecanismo de Auto-Update na ISO ? Vai ser via plug-in ou via backdoor mesmo ?

Por isso, apesar de tudo isso, continuo apoiando o ISO 26300 (ODF) como o verdadeiro formato de documentos padrão.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

A sujeira continua a aparecer no OOXML

A verdade está aparecendo cada vez mais no OOXML, e de como o processo está se tornando não apenas estranho, mas totalmente fora de ordem. Hoje, o Jomar postou algumas informações sobre o que diabos aconteceu realmente no BRM: na realidade, a famosa “Lei do Silêncio” não foi ‘esclarecida’ (perceba a ironia aqui). A questão não é de que havia algum tipo de “Lei de Silêncio”, mas sim de que os participantes deveriam (não seriam obrigados) a permanencer em silêncio quanto a esses eventos… É engraçado que isso tenha sido colocado agora, quando todos ficaram calados, enquanto outras partes interessadas utilizaram-se desses valores para tentar “passar a perna” no debate. Isso mostra como essas coisas são úteis para aqueles que querem trapacear processos ISO.
Como sempre, o Jomar manda muito bem ao esclarecer as coisas: ele se preservou enquanto não tinha a certeza de poder ou não comentar o processo, o que mostra que ele é um cara ético. Agora, porém, ele resolveu “rasgar o verbo”:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Como informado no meu penúltimo post, entrei en contato com a ISO e o IEC (na verdade com o Gabriel Barta do ITTF), e ele me esclareceu que apenas “recomendou” que os detalhes não fossem revelados e que não pode fazer nada contra isso (nem contra a Microsoft, nem contra este pobre delegado). Além disso me disse que eu posso falar o que quiser, mas mantém a recomendação… Tá bom…obrigado pelo conselho…

E vamos ver o que o Jomar tem a dizer:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Para iniciar a história, na reunião de véspera do BRM, os Chefes de Delegação (HoD) foram avisados que na quarta feira teriamos todos que tomar uma decisão sobre o que fazer com as propostas do ECMA que não pudessem ser discutidas.

Vamos entender o que aconteceu: o BRM, que em teoria deveria resolver todos os problemas do padrão em estudo, ao invés de debater todos os problemas do padrão simplesmente fez uma postura de João-Sem-Braço, ignorando a função básica do BRM de alcançar um consenso normativo (como dito anteriormente) ignoraram sumariamente uma massa completa de inconsistências e erros, conforme citado pelo Cezar Taurion da IBM. Desse modo, além de perder-se fundamentalmente o objetivo principal do BRM, fez-se uma espécie de “padronização a toque de caixa” que demonstra que não houve por parte dos principais interessados nesse caso (ECMA e Microsoft) de u debate completo e técnico quanto ao formato.
Continuando, o Jomar explica como é feito o debate das contradições durante o BRM, e mostra uma coisa MUITO interessante:

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

O forma de trabalhar adotada nos dois primeiros dias de reunião (e no papel funciona que é uma beleza), cada um dos países presentes (na verdade os chamados National Bodies ou NBs e se não me engano eram 33) poderiam apresentar para a discussão uma das propostas de seu interesse (ou seja, em ordem alfabética cada um apresentava um problema). O debate então se iniciava e caso fosse muito polêmico, os NBs envolvidos com a discussão eram convidados a discutir “off-line”, colocando o assunto para um backlog. Toda discussão terminava em instruções de alteração para o editor e qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada.
O resultado disso é que até sexta feira, sequer duas rodadas completas foram realizadas (ou seja, houve NB que pode apresentar só uma vez) … explicação: Falta de Tempo (que aliás, explica todas as demais decisões tomadas lá, ok ?). (grifos meus)

Alguns detalhes a ressaltar:

  1. Perceba que cada NB podia apresentar por rodada um único problema. O dilema é: alguns NBs, como o brasileiro, tinham listas enormes de problemas a serem questionados. Mesmo considerando-se a possibilidade de um mesmo problema ser apresentado por vários NBs, como é que todos poderiam ser investigados dessa forma.
  2. O Jomar diz que “qualquer coisa que não contivesse “instruções de alteração para o editor” era simplesmente ignorada“. Ou seja, uma série de fatores que importantes, como a questão do mapeamento de binários entre outros foi simplesmente chutados para escanteio sumariamente. Desse modo, como pode-se alcançar um melhor esclarecimento sobre essas questões? Principalmente em um padrão lotado de artefatos de implementação (wrapLikeWord95 e afins)?

Mas ainda assim as coisas continuam piorando:
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Durante os debates, algumas discussões acabavam se expandindo e abrangendo mais do que uma resposta (ou as vezes as respostas tratavam de temas coligados) e isso explica o elevado grau de itens discutidos (ou como prefiro chamar “tocados”) no BRM (retirado deste documento, o documento final do BRM): 189 respostas ou 18,4 % do total (isso é que é o que se espera de um debate internacional sobre uma norma de tamanha relevância, não é mesmo… Já imaginou se nossa constituição fosse escrita assim, com apenas 18% das leis discutidas e analisadas ?).

Alguém vai falar: “18,4% não é bom?” Não, não é? Isso é um padrão internacional: em um mundo globalizado, a troca de informações (e portanto de documentos) por meios digitais assumirá cada vez mais uma importante função nas empresas de todos os portes e nos governos, e até mesmo nas relações pessoais. Um formato mal-padronizado, com “minas terrestres de patentes”, cheio de furos técnicos, redundante, e simplesmente complexo demais deveria ser aprovado com tão pouco debate em cima do mesmo? Como o Jomar disse: “Isto significa que especialistas do mundo todo foram a Genebra para resolver apenas 18,4 % de um tremendo problema. O resto (81,6%) foi “dado um jeitinho”.
Mas vocês acham que acabou? Não, ainda tem mais!

Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Aliás, me reservo o direito de não comentar aqui o que levou a aprovação desta proposta [da transformação da especificação em uma Multi-Part standard, na qual o Brazil apresentou uma objeção], que na verdade transforma o OpenXML (ou a DIS 29500) em singelas cinco normas internacionais que poderão ter vida própria (única diferença de cinco normas “tradicionais” é a sua numeração compartilhada, DIS 29500-1, DIS 29500-2 … DIS 29500-5). Lindo isso, não ?

Ou seja, existiram coisas tão atrapalhadas (ou intencionalmente manipuladas), que o Jomar se absteve de comentar. Em uma situação como essa, o que leva a pessoa a se abster, senão um processo terrivelmente mal-feito (ou intencionalmente manipulado).
Agora, vem uma parte importante desse post do Jomar e uma resposta para muitas coisas: de onde a Microsoft tirou a questão dos 98% de aprovação dos comentários ao OOXML?!
Finalmente: os detalhes sobre o resultado do BRM | void life(void)

Quando chegou a quarta feira, nos foram apresentadas quatro opções de “destino” às demais respostas (ou seja, 81,6% do total). Eram apenas quatro opções e uma delas deveria ser escolhida (na hora eu me lembrei do filme “A escolha de Sofia”):
1 – Todas rejeitadas.
2 – Todas aprovadas.
3 – O ITTF decide tudo.
4 – Decisão por voto em lote (com a possibilidade de declaração de voto individual para cada resposta e/ou definição de um voto global, do tipo “aceito tudo”).
Evidentemente que a opção menos ridícula era a opção 4 e por isso ela foi aprovada (no documento final existe uma cópia da cédula de votação). Muito foi debatido sobre a possibilidade de que alguns NBs fizessem votos de bloqueio (como votar tudo sim para forçar a aprovação ou tudo não para desaprovar), mas nada poderia ser feito a este respeito…
Houve um protesto muito interessante de uma delegação que disse que não tinha ido até a Suiça para votar, que poderia fazer isso de casa e a resposta: “Paciência… a vida é assim” .
Outro NB protestou dizendo que só recebeu o documento contendo as respostas para seus próprios questionamentos e não tinha tido a oportunidade sequer de analisar as demais respostas. Por isso foi criada a opção “Não quero registrar uma posição” na cédula. O problema apontado ocorreu com outros NBs e portanto, teve NB que votou em propostas que nunca leu !!! (legal isso, né ?).
(…)
Fiz questão de contar isso apenas para que seja pública a explicação aos 98% de aprovação que certas empresas andam utilizando mundialmente.
Viu como agora os 98% não significam absolutamente nada ? E os 18,4%… estes sim merecem ser debatidos (e explicados por alguém).

Repare aqui a questão: houve uma verdadeira “aprovação em massa” de uma série de questões importantíssimas e que foram simplesmente ignoradas pela ISO. Desse modo, como confiar no OOXML? Como desenvolver para isso? Qual a segurança que temos de que os documentos irão abrir corretamente, mesmo no Microsoft Office 2007? Quais são as garantias que o esforço potencial para desenvolver-se sistemas que abram e manipulem tais formatos não será jogado fora ao perceber-se que os documentos resultantes não abrem ou oferecem informações errôneas em outros sistemas compatíveis com esse formato? Pequenas discrepâncias são aceitas (grave um documento no OOo e abra no Lotus Symphony da IBM e você poderá ter isso), mas quais são as garantias?
A postura brasileira de Dizer NÃO ao OOXML está correta por tudo isso: esse formato é simplesmente horrível e não tem condições de fazer NADA ao que se propõe a fazer. Aprovar o OOXML agora é transformar a ISO em um órgão de “ceder selinhos” para empresas, o que desvritualizaria tudo o que a ISO representa. A ISO não é perfeita (X.25 alguém), mas muitos padrões que ela divulgou foram adotados a partir de um consenso e tornaram-se importantes no mercado (os próprios padrões ISO 9000 são exemplos).
Se o OOXML passar agora, vai ser a submissão da ISO à Microsoft e resultará em um lock-in oficializado, uma vez que até agora, à exceção dos produtos Microsoft, não existe nada que abra os documentos OOXML do MS Office 2007 corretamente. Sendo que atualmente ainda é impossível desassociar o OOXML do MS Office (o que acontece com o ODF em relação ao seu “software de referência”, o OpenOffice.org), temos uma situação como nunca foi vista na ISO: uma única empresa poder oficializar um gigantesco monopólio por meio de um padrão “consolidado de um consenso”.
Quem tem a ganhar nesse caso? O Brasil ou a Microsoft? Sua empresa ou a Microsoft? Você ou a Microsoft?
Pense muito nisso…

Office OpenXML (OOXML) e inapto pela ISO 29500


Powered by ScribeFire.

O que a Microsoft e sites pornô têm em comum?

Pode parecer uma pergunta absurda, mas existe uma relação sim, denunciada pelo pessoal do site open… e pelo pessoal do NoOOXML.com: a prática de Cybersquatting, ou seja, a idéia de, segundo a Wikipedia, “registrar, traficar ou usar um nome de domínio com a má intenção de obter lucros com a boa fê de uma marca pertencente a outros“. Em geral, essa prática é normalmente feita por sites pornôs que (a) tentam obter acessos quando a pessoa digita o nome de um site conhecido de maneira errada ou (b) tentam vender posteriormente os domínios aos verdadeiros detentores da marca registrada em questão por rios de dinheiro. Além disso, há também a prática de scam de redirecionamento, quando você digita uma URL e é redirecionada para outra por meio de scripts. Embora não seja sempre um site pornô e seja uma prática que pode ser legítima (com em sites que mudaram de domínio), ela pode ser usada para levar o usuário a locais indesejados.
Agora, você pode se perguntar: “o que a Microsoft tem a ver com tudo isso?
Ontem, dia 26/03, foi comemorado o Document Freedom Day (Dia da Liberdade de Documentos), ou seja, o dia de defender a liberdade de formatos de documentos e independência de ferramenta ao editar documentos. Para divulgar a iniciativa e criar meios para registrar-se grupos que se organizariam para tomar ações, foi registrado o site http://www.documentfreedom.org.
OK: um grupo conhecido como OpenXML Community (sem links para eles pela sacanagem que fizeram), que se apresenta como “uma comunidade de instituições públicas, empresas, profissionais de tecnologia, acadêmicos e desenvolvedores que suportam o ECMA Office Open XML e (…) acreditam na promoção da escolha, interoperabilidade, inovação e excelência técnica nos padrões de documentos” (conforme o próprio site deles), registrou o domínio http://www.documentfreedomday.COM (perceba o top-level domain comercial, oposto ao .org da iniciativa do Document Freedom Day). Ao tentar acessar essa página, a pessoa era redirecionada a um documento chamado “Dispelling Common Myths About Open XML” (o qual ainda pretendo desmitificar…).
Agora, o que há de errado? É um domínio livre, qualquer um pode pagar para o registrar!“, você pode dizer.
O problema é que justamente quando existe toda uma iniciativa para que o OOXML não seja aprovado (e não por ser da Microsoft, mas sim por ser um formato simplesmente horrível, como eu e vários outros estamos falando a bastante tempo) aparece um grupo realmente astroturf (ou seja, embora aparentando ser algo realmente espontâneo ser algo criado por grupos com os mais diversos interesses) vem tentando minar essa iniciativa por meio de uma técnica que pode ser considerada na melhor das hipóteses um jogo baixo.
Isso reflete muitas questões e mostra os verdadeiros objetivos do OOXML. Como disse anteriormente, toda a questão da ISO é baseada em consensos. Em um processo normal, todas as contradições seriam resolvidas, de modo que o consenso fosse atingido e a votação passasse a ser apenas uma formalização desse consenso formado entre todas as partes. Esse consenso não precisa derivar de um formato perfeito, pois mesmo o ODF não o é, e espaço para evoluções são sempre interessantes.
O problema é que cada vez mais fica claro que a Microsoft não tem como objetivo nenhum consenso ou portabilidade. As “minas terrestres de patentes“, as várias contradições não explicadas, e a confusão entre inter e intraoperabilidade, o fato de um produto não estar sendo usado apenas de formato referência, mas como fundamento para manutenção de falhas graves no formato, devido a escolhas específicas de implementação de recursos (o que é conhecido tecnicamente como artefatos de implementação), e os diversos problemas de “inflação dos NBs” e de obstruções e atritos com aqueles que vão contra o formato OOXML mostra que na realidade a iniciativa de transformar o OOXML em um padrão ISO é apenas uma jogada de marketing da Microsoft:

  • Ela passa a posar de boazinha, mas na realidade pode minar completamente qualquer iniciativa livre de desenvolvimento de parsers e conversores do OOXML para outros;
  • Mesmo que seja possível tais sistemas, eles não teriam o mesmo comportamento que o dos produtos da Microsoft, criando a “dependência de DLLs”, o que em resumo quer dizer que qualquer sistema bom deveria recorrer a DLLs ou bibliotecas da mesma;
  • Cria uma verdadeira aberração jurídica, um lock-in oficializado por meio de um “padrão”;

Como já disse em outros posts e pretendo escrever no futuro com mais tempo: eu não sou contra o OOXML. Ser pró-ODF não é o mesmo que ser contra-OOXML, como foi dito pelo Mark Shuttleworth do Ubuntu (e eu traduzi aqui nesse blog). O grande problema é: o OOXML tem muitas, muitas, MUITAS, MUITAS FALHAS! Existe muita coisa, para dizer o mínimo, estranha no OOXML que simplesmente passou no BRM, devido ao curto tempo e ao tamanho monstruoso da documentação. Artefatos de implementação e coisas bizarras como wrapLikeWord95 (que diz que você deve quebrar linhas como Word 95… sem dizer como isso é feito) e documentos que, uma vez validados contra as DFDs do OOXML ainda assim dão erro (ou seja, existe uma inconsistência entre o formato descrito nas especificações e o descrito pelas DFDs).
Enquanto as coisas estiverem nesse pé, e enquanto a ECMA e a Microsoft não ouvirem as contradições todas e realmente as acertar, concordo com o NÃO dado pelo Brasil, e torço para que outros países sigam a mesma iniciativa. Mas como disse o Jomar, “a guerra continua (e o outro lado está levando a sério a expressão VALE TUDO)“.
Espero que você que esteja lendo entende as coisas e tenha realmente entendido os fatos (sim, a “piada” com Get the facts foi intencional).

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.

“Something wicked this way comes…”

Apesar do título, não, esse post não tem nada em absoluto a ver com Harry Potter. Mas como diz a música Double Trouble, “algo sinistro está vindo aí”.
No dia 29 desse mês, haverá a decisão final da ISO sobre a aprovação ou não do formato OOXML como padrão ISO. Como já falei anteriormente, existem coisas que estão extremamente complicadas sobre ele. Já disse também que existe uma série de defeitos técnicos no formato, além de uma série de implicações relacionadas à questão do Open Specification Promise (Promessa de Especificações Abertas) da Microsoft e da Covenant Not to Sue (Acordo Contra Processos) da mesma. Inclusive, recentemente o César Taurion da IBM deixa muito claro isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

Mais, não é só. Também é impossivel alguém dizer que existem 100% de certeza quanto a resolução dos vários problemas de propriedade intelectual que foram encontrados nos documentos Open Specification Promise (OSP) e Covenant Not to Sue da Microsoft. Nestes documentos lêem-se: “claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification”. E “promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification…”.
O que isto signfica na prática? Que a promessa não cobre as especificações que “are not described in detail”, que são muitas; que limita a liberdade de uso à sintaxe da especificação, mas não a “application behavior” que estão espalhados nas suas mais de 6.000 páginas; e não inclui patentes das subsidiárias e afiliadas da Microsoft. E um ponto importantíssimo: a OSP é limitada a atual versão do OpenXML! Fica então a pergunta: o que acontecerá com as próximas e inevitáveis versões da especificação?

Como comentamos anteriormente nesse mesmo blog, e o Taurion ressalta no post dele, é impossível determinar claramente se o OSP e o CNS cobrem software livre. Na realidade, ela já foi considerada insegura pela Software Freedom Law Center para implementações livres do OOXML, e por diversos motivos. Ou seja, como algo que pode ser um verdadeiro “campo minado” de Propriedade Intelectual pode tornar-se um padrão ISO?
Podemos entender isso da seguinte forma. que o Avi Alkalay da IBM apresenta: a Microsoft não está tentando promover interoperabilidade (onde o que importa é o padrão e os produtos disputam entre si para ver qual o melhor), mas sim uma intraoperabilidade (onde o produto é importante e favorecem um produto em detrimento aos demais). Pode parecer uma diferença pequena, mas compare as seguintes imagens que o Avi publicou em seu site:


Esse é um exemplo de Interoperabilidade

Esse é um exemplo de intraoperabilidade

A coisa toda, porém, continua ficando cada vez mais estranha conforme você vai acompanhando os posts. Por exemplo, a Microsoft comemora o fato de que 98% das contradições (problemas) do OOXML tinham sido modificados e aprovados. Até que ponto isso é verdade? E se não foi, por que?

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

(…) Embora alguns digam que a reunião foi um sucesso, com 98% dos comentários sendo resolvidos, indiscutivelmente que a realidade é outra. Cerca de 80% dos comentários não foram sequer analisados e da votação que se seguiu, seis países aceitaram as sugestões do Ecma, quatro foram contra e 18 se abstiveram. Ora 22 países de 26 não votaram a favor da proposta!

E porque? Na minha opinião existem muitos senões que impedem um voto SIM, de forma consciente e profissional. O próprio processo de Fast Track não permitiu que fossem feitas avaliações adequadas da especificação. Para termos uma idéia deste problema, das mais de 6.000 páginas originais (devem ser quase 7.000 agora, depois do BRM…), as entidades de padrões tiveram apenas um curto período de cinco meses para avaliar toda esta massa de documentação. Apesar desta limitação de tempo, foram detetadas 3.522 inconsistências e erros. A Ecma respondeu a estes 3.522 comentários com 1.027 propostas, para serem debatidas nos cinco dias do BRM.
Ora, fazendo uma simples conta, com 6.045 páginas divididas por 1.027, temos um erro a cada 5,8 páginas. Claro que, se houvesse mais tempo, muito mais erros seriam encontrados!

Perceba um fato: essas pessoas que analisaram essa documentação, como o Taurion e o Avi da IBM, o Jomar da ODF Alliance, o Gebara da própria Microsoft, o Deivi Kuhn do SERPRO, nenhum deles é desocupado ou “caiu de paraquedas”. Todos são profissionais competentes, experientes, com dedicação total (ou ampla) para esse estudo. O processo Fast-Track tem sido uma constante dor de cabeça para as pessoas tentarem aprovar esse formato. Você continua ainda assim achando que está tudo OK e que a intraoperabilidade é uma boa idéia? Vejamos o que o Taurion fala sobre isso:

IBM developerWorks : Blogs : Software, Open Source, SOA, Innovation, Open Standards, Trends

A própria proposta da especificação, de produzir um padrão compatível com o Office nos leva a uma situação no mínimo preocupante: uma ferramenta (o Office) definindo um padrão e não o contrário. Imagino como seria se a especificação HTML refletisse as caraterísticas internas do Firefox ou do Explorer…Na minha opinião usar um software específico como modelo de referência obriga a que o padrão seja limitado pelas escolhas técnicas originalmente feitas pelos desenvolvedores do software. O que nem sempre é um bom negócio, principalmente quando o software tem mais de vinte anos de desenho, mantendo dentro de si idéias e algoritmos já ultrapassados pelo tempo…

Ou seja, o que podemos fazer ou deixar de fazer, o que devemos implementar ou não fica restrito por escolhas específicas de uma implementação específica cujo cenário era específico. Por exemplo: como seria uma implementação do OOXML em um ambiente Mainframe? Embarcado? Palms? Nintendo DS? Como seria replicar escolhas específicas feitas em um ambiente Windows para algum desses ambientes? Como proceder para portar recursos?
Mas as coisas continuam piorando:
Segundo o Jomar da ODF Alliance, existe uma espécie de “Lei do Silêncio” cercando os resultados do BRM, o que por si só é estranho, pois ao menos em teoria um processo como esse deveria ser aberto para o público interessado se antenar. Não cabe a mim fazer afirmações de que houve má-fé ou não pois não fui parte em momento nenhum desse processo e estou apenas dando opiniões. Mas percebamos o que o Jomar falou recentemente.

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

Como delegado Brasileiro no BRM do OpenXML, estou me segurando prá não sair por aí contando os detalhes daquela reunião, pois acredito que todos deveriam saber detalhadamente o que aconteceu dentro daquela sala, para poder entender como existem empresas mal intencionadas e sem limite ético nenhum hoje em dia.
Só para citar um exemplo, soube recentemente que foi utilizado em uma apresentação em um NB (ABNT de algum país), um SLIDE que foi inicialmente apresentado na reunião de encerramento do BRM. Apesar de não poder contar os detalhes, como última participação minha no BRM, pedi em nome da delegação brasileira ao responsável pelo ITTF (ISO/IEC) na reunião – Mr Barta – que o texto do slide apresentado fosse corrigido, pois ele distorcia tudo o que havia sido realizado naquela semana. Imediatamente ele determinou ao autor do slide (Mr. Oh, um japonês secretário do SC34) que aquele slide e aqueles números jamais deveriam sair daquela sala, pois eles não representavam o resultado do trabalho do BRM e também não detalhavam o processo utilizado na reunião.
Quando saí da reunião e cheguei no hotel, descobri que um profissional da empresa proponente já havia publicado na web os dados (e logo em seguida retirado… estranho, né). Para quem não sabe do que estou falando, é do absurdo número de 98% dos problemas resolvidos que a Microsoft insiste em utilizar no mundo todo, cometendo um CRIME cada vez que usam ou apresentam este números.

Para entender: perceba que há realmente uma “Lei do Silêncio”, como o Jomar falou anteriormente, mas que uma pessoa quebrou essa norma de sigilo imposta na reunião. Mas isso apenas piora:

Afinal existe ou não SIGILO sobre o BRM ? | void life(void)

O fato concreto é que fui informado por um colega do Chile, que na semana passada este slide (com o nome do Sr. Oh nele) foi utilizado em uma reunião do NB deles. O slide fazia parte de uma apresentação feita pela Microsoft para demonstrar como tudo estava resolvido no OpenXML. Isto é um CRIME DE VIOLAÇÃO DE SIGILO OU NÃO ?

Ou seja, até que ponto valem essas normas de sigilo? Isso tudo está criando um precedente muito sério, que pode inviabilizar totalmente a credibilidade da ISO. É como a Red Hat publicou recentemente:

Red Hat Magazine | ISO approval: A good process gone bad

For a standards body to have credibility, the procedures it follows need to be credible. ISO’s JTC-1 directives say that the “objective in the development of International Standards should be the achievement of consensus between those concerned rather than a decision based on counting votes.” Clearly, there has been no achievement of consensus regarding the adoption of OOXML as a standard, and therefore ISO has turned to a voting process.

We believe that the flaws in the ISO voting process for OOXML are so serious that they must be addressed in order to maintain ISO’s credibility as a standards body. For a standards body to review a proposal adequately and achieve consensus, the participants need to be involved in the entire review process, not merely show up to cast a vote.

Para aqueles não proficientes no idioma inglês, a tradução:

Para um órgão de padronização ter credibilidade, os procedimentos que ele segue devem ser dignos de credibilidade. As diretivas do comitê JTC-1 da ISO definem que “o objetivo do desenvolvimento de Padrões Internacionais deve ser alcançar o consenso entre todos aqueles que estão envolvidos ao invés de meramente basear tudo na contagem de votos”. Mas claramente não houve nenhum consenso quanto à adoção do OOXML como um padrão, e portanto a ISO tornou-o [a padronização do OOXML] em um processo de votação.
Nós [da Red Hat] acreditamos que o processo de votação da ISO para o OOXML foi algo tão sério que deveria ser questionado de modo a manter a credibilidade da ISO como um órgão de padronização. Para que um órgão de padronização veja uma proposta adequadamente, de modo a alcançar consenso, os participantes devem se envolver no processo como um todo, e não apenas ir lá para votar.
(grifos meus)

Isso tudo vem sendo mostrado a tempos: vários países receberam incentivos da Microsoft para irem lá e simplesmente votarem a favor do OOXML, sem um estudo prévio da proposta. A própria idéia do Fast-Track foi mal executada. Apesar de executivos da Microsoft terem criticado aqueles que criticam isso, lembrando de casos como os do MPEG, é importante lembrar que o MPEG já vinha passando por estudos a muito tempo, de modo que o Fast-Track foi mais uma formalização de um consenso já adquirido fora da ISO (tanto que recebeu bem menos contradições que o OOXML). Além do mais, existe toda uma questão estatística que impede a pessoa de ler um documento como esse, de 6000 páginas, para um padrão novo, pouco conhecido e debatido e extremamente amarrado a um produto específico, com uma série de exigências voltadas especificamente a esse produto, de ser analisado em tão pouco tempo.
Existe toda uma série de paradoxos sobre quais são os objetivos do OOXML, como exemplo, cito dois e dou recursos para uma leitura detalhada sobre eles:

  • Interoperabilidade: existe uma questão relacionada com a falta do mapeamento de binários. Já tratei rapidamente desse assunto no meu blog, mas acho melhor que você vá direto à fonte e entenda melhor essa questão.
  • Customização do formato: aqui o assunto se torna mais sério. Em resumo, a Microsoft afirma que o OOXML permite a expansão do formato por meio do conceito de Custom XML, onde em teoria você poderia implementar suas próprias tags. Até aqui sem problemas, exceto que o pessoal do OOXML is defective by Design descobriu que isso simplesmente não funciona, e que pode chegar a criar um pesadelo de segurança de dados, pois “eventually, confidential information from the corporate databases will end up there, and a PR disaster automatically follows“, ou seja, pode-se fazer inadvertivamente que dados importantes de bases corporativas vazem para dentro desses Custom XML, criando falhas de segurança simplemente grotescas. Recomendo a leitura do artigo para um maior esclarecimento sobre os perigos e problemas do Custom XML.
Simplesmente, as coisas foram feitas de uma forma extremamente arbitrárias, “socando goela abaixo” um formato que é enorme, inchado, voltado a um produto específico, sendo que já existe um bom formato para esse mesmo tipo de aplciação, que é o ODF. Alegações de “temos HTML, XML, PDF, etc…” não colam, pois esses formatos possuem outros objetivos (ou alguém acredita que HTML seja a melhor forma de editar-se documentos de texto?)
Existe um risco monstruoso de que o OOXML possa passar, ainda mais com a pressão que a Microsoft vem fazendo no plano político para que os órgãos nacionais de normatização (NBs) votem a favor. Realmente espero que isso não passe, mas o que posso fazer é assistir e esperar.
Vejamos os próximos lances.

Office OpenXML (OOXML) e inapto pela ISO 29500

Powered by ScribeFire.