Month: June 2008

E o projeto do Azeredo?

Posted by – 26/06/2008

Caso alguém mais esteja interessado no que está acontecendo com o Projeto de Lei Substitutivo ao PL da Câmara nº 89, de 2003, e PLs do Senado nº 137, de 2000, e nº 76, de 2000 (aquele apresentado pelo Senador Eduardo Azeredo que pretendia dar poder de polícia aos provedores de Internet e que deu o que falar), resolvi checar a página de acompanhamento da SaferNet e, para minha surpresa, descobri que o negócio ainda está rolando.

De acordo com a página do senado, ontem ele se tornou disponível “durante cinco dias úteis a fim de receber emendas, nos termos do art. 235, II, “d”, do RISF. À SCLSF.”. Se alguém souber o que isso quer dizer, por favor me avise.

Exciting new World

Posted by – 25/06/2008

I’ve just tested the improvements in the performance of Javascript in Firefox 3 and WOW! Javascript in FF3 is really fast. While googling about it I just ran across a recent interview with Brendan Eich about the future of Javascript and I got excited about two things about this future.

First was what we already have, still in the beginning, but with a lot of potential: HotRuby. Really interesting to script a webpage in Ruby (which is my favorite language) and, while it’s not embedded the way Javascript is, it gets “compiled” in the server side with YARV (the new bytecode compiler for the next version of Ruby, 1.9), and then served to the browser in the form of JSON objects, so it can be interpreted by the Javascript engine in it. All this is transparent and work with XMLHttpRequest. It’s not a coincidence that Eich mentions it as being a form of ARAX (changing the J in AJAX for R – from Ruby).

I already do a lot of coding in Ruby… not having to deal with Javascript anymore is surely a plus. ITOH, Eich is talking about improvements in Javascript that would render it as a real programming language… Maybe coding in it would not be so painful anymore by then 😉

The whole interview have to do with this Project Tamarin, a “high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification” [ ECMAScript 4 is the same thing as Javascript 2 ] by the Mozilla developers. And this is the second thing I got excited for: they’ve planned to glue IronRuby (Ruby compiler for argh! .NET) to it via IronMonkey.

So… exciting news! Either via Tamarin or via HotRuby, we’ll get Ruby browser scripting. My “free mind” tends to favor HotRuby instead of IronRuby/IronMonkey/Tamarin… But in the end what matters is that all those people now cursed by Javascript will finally have a taste of what a real programming language feels like.. Who knows! They might even like it ;-D

Financiamento de projetos de Software Livre

Posted by – 24/06/2008

Realmente um dos desafios dos projetos de Software Livre e correlatos é como manter o financiamento. Recentemente, durante o episódio da vulnerabilidade do SSH no Debian, Ben Laurie deixou bem claro que o projeto OpenSSL (sim, aquele que TODOS usam para TUDO relativo a criptografia) tem pouco dinheiro. Tenho certeza que, assim como o OpenSSL, outros projetos funcionam mais pelo amor que seus principais desenvolvedores tem por ele do que por financiamento privado.

A Wikipedia com certeza encaixa nessa categoria. Apesar de não ser um projeto de software (o software chama-se MediaWiki), é provavelmente o projeto que mais tenha difundido os valores do Software Livre para fora do campo da Informática. No final de 2005 a wikipedia passou por problemas de caixa, que levaram seu fundador, Jimmy Wales, a fazer um apelo pessoal por doações para o projeto.

A Wikipedia salvou-se naquela época, graças a difusão do apelo de Jimmy os quatro cantos… No entanto, não adianta deixar esses projetos cairem a ponto de reerguerem-se apenas com apelos. É preciso que campanhas contínuas sejam feitas. E é por isso que eu aderi a campanha do Augusto Campos desse ano (claro que se puder ganhar um dos brindes que ele vai sortear, também não fico nada insatisfeito 🙂 ). Aqui está o texto obrigatório:

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe – quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Agora o meu apelo pessoal… A doação do Augusto será 50% para a Wikipedia e 50% para o projeto mais votado: se você for participar desta campanha, por favor, Vote OpenSSH!

Ruby security advisory and fix

Posted by – 24/06/2008

Debian 4.0 version of Ruby is open to the, now widely known, Ruby security vulnerabilities. The bug is reported as 487238 in Debian’s BTS, and is closed, since the version now in sid (version is already fixed. Users of stable can apply the patch provided by Daniel Franke (it doesn’t seem to fix all, but goes a long way).

Apparently, this brought up (again) the rants over full disclosure. Indeed, what is vulnerable is not that hard to find, as Zed Shaw showed us, so, why not talk about it in a plain and bold form? Why just provide the CVE numbers and ask for everybody to upgrade? Zed goes more deep about the quality of C code, but that is not the issue I want to talk about…

As a Free and Open Source Software supporter (and developer), I can see the benefits of full disclosure. As a not-full-time webmaster, I can see the benefits of not having a “proof-of-concept” piece of code attached to the vulnerability report. Of course, there’s a lot of things a webmaster can do to prevent having a machine completely compromised in case a security advisory is published with a proof-of-concept code in it (think about chrooting, randomized memory protection, security libraries, grsecurity, SELinux, etc) – and my machines, although vulnerable to the bug, would not be fully compromised if exploited.

I guess one should be prepared to whatever comes from the Internet… Full disclosure, in this sense, have more pros than cons, IMHO. For instance it was not clear if Debian 4.0 were vulnerable… There were no security advisory coming from Debian (and there’s still not), and it is not promptly obvious if the version packaged is affected. I know that at least I wanted to run a proof-of-concept to check if my server is vulnerable or not before going all the way into packaging a fix (or backporting the sid version), and it was not until I read Matasano Chargen Blog that I could test older versions. But different people have different ideas…


Posted by – 23/06/2008

I was curious to get to Rhodes. That is near Turkey (my cellphone actually kept switching from Greece to Turkey and back all the time), and, since it held one of the Seven Wonders of the Ancient World it all added up to be a good place to visit.

Our first disappointment while in Greece. The hotel the travel agency had chosen was not a very good one (so far we were very lucky). This lead us to remain there as little as possible. It was too close to the airport and too close to one of the main roads… The surroundings of the hotel, ITOH, were not that bad. It was the beach of Ixia, a really beautiful one (although very windy). Hilton Resort was just around the corner and we were tempted to check-in there instead of our hotel… (Yeah… like we had money to…).

Anyway, we decided to get on with the trip and went straight to the Colossus site. Actually they have doubts of where it standed, but the traditional spot would be in the old harbour where one can see two obeliscs on the place they think Colossus’ legs were spread:

We visited also the Cassino, which is mainly comprised of slot machines. Not really interesting (and charging a non-refundable fee of EUR 15 just to get in!)… Just near the Cassino we can see one of the many beaches in Rhodes, with the two-colored sea (we were told that it was like that for the stone platform keeps the sea shallow for some meters, before diving acutelly):

Maybe the most interesting was our walking into the Old Town. Rhodes have a surrounded area that was a medieval town… but we’re not talking about ruins anymore: the city is alive and they have all kinds of shops and cafes in there. The oldest street in the Old Town is called, nowadays, Socratic Street, and we found a lot of interesting places along it.

While we were there, there was a medieval festival going on, and we saw people dressed as medieval countryman, playing typical instruments, walking around the place…

The Old Town surely is a place that deserves to be explored more than we did… But those were the last days of our trip, and we were rather tired by then. So we spent the time just going where we couldn’t avoid and preparing ourselves to the return trip (which meant meditating under the sun of the Ixia beach and packing our shopping stuff in our already stuffed suitcases).

Thanks for following my posts of this trip. Now we can go back to the usual subject of this blog…. 🙂


Posted by – 23/06/2008

We’ve heard Santorini have the most famous sunset in the world, and that the best part of the island to watch is from the city of Oia, north of the island. So we got a hotel (actually a “traditional house” – rooms digged in the rock of the cliff) there.

What a beautiful place. Everywhere we went gave us a new view for a picture, and we took lots of them. Oia is a beautiful village with great places to eat or to shop handcrafted things. Everywhere we went, the ever blue sea greeted us in a different angle.

For completeness sake, we visited Thira, the “capital” of the island. Also a beautiful place, but too crowded and not really any better than Oia. From our “cave” balcony we watched the sunset all three days we were there:

The night also gave us the best night pictures so far. We visited every corner of Oia and everywhere we went people were kind and willing to help. We got lost sometimes, but I hardly can think of that as an annoyance (and it led us to find some “hidden” places with typical restaurants).

To the south of the island is the famous beach of Perivolos. It’s a beach of dark sand with a stone platform that can be rather slippery. Surprisingly there were not many people there, what made our experience very confortable (for crowded beaches I would have stayed in Brazil). Beware of the sun… We wore fps30 lotion and we still got our skin a little sunburned.

Mykonos and Delos

Posted by – 22/06/2008

One of the best places to rest during our trip was Mykonos. In general, a flat island (not needed to climb as often), we got a hotel near the port, with a beautiful view and really relaxing setting. All the hotel staff seem to be doing their best so we could do nothing. That was a first time in our trip.

Great views, great restaurants along the shore, Mykonos is also famous for its parties (although we haven’t gone to any), but don’t be fooled: all this come with a price. Mykonos is also the most expensive place we’ve been in this trip… So be prepared.

Following the shore we found some windmills. We’re told some still work, but not those we saw: small stores are run in there.

The water was cold, and we found no one willing to dive in it, anyway it was a relaxing view. We took our time to read and enjoy ourselves.

Near Mykonos is the ancient and sacred island of Delos. That was an impressive visit. So much history that island have seem and many interesting details: they managed to have a political and religious agnostic island that welcome everyone and had a free harbour by 800 B.C.! It’s a shame so little have remained (like the “Lions” you can see in the picture)…

We’re told that by 700 B.C., Delos, whose land could not be owned by anyone (allegelly it was owned by the god Apollo and godess Artemis), despite so many rich people living and trading there, had no organized army (or any defense system whatsoever). A king that wanted to promote his own free harbour, in a short time, invaded and destroyed Delos, killing almost everyone living there. Since then Delos is abandoned. What a pity… I wonder what could Delos developed to be if allowed to endure.

OOXML put on hold

Posted by – 11/06/2008

Officially known as ISO/IEC DIS 29500, Microsoft’s office document standards (or OOXML format) was put on hold by ISO on account of the four appeals that emerged from national bodies (including Brazil), against it.

I am sorry for the people following this blog who expected to see the last posts of my trip (they are ready, but I just haven’t got the time to upload the pictures yet), and for those reading it in english, but I had to translate Brazil’s appeal so it could be appreciated by our portuguese-speaking fellows (since I couldn’t find an official version). If you want an english version, please refer to Standards Blog.

Here is the pt-BR free translation:

Caros Senhores,

A Associação Brasileira de Normas Técnicas (ABNT), como membro P da ISO/IEC/JTC1/SC34, gostaria de apresentar, à ISO/IEC/JTC1 e à ISO/IEC/JTC1/SC34, este apelo para reconsideração do resultado final da ISO/IEC DIS 29500.

Este apelo é baseado em duas principais considerações:

  1. O Brasil considera que a BRM foi inconclusiva.
  2. O Brasil considera que a versão final do texto da ISO/IEC DIS 29500 deve ser liberado imediatamente.

1. Sobre a BRM

Na BRM, a delegação Brasileira não teve permissão para apresentar uma proposta importante sobre o mapeamento de binários legados. Essa proposta era uma parte complementar a da delegação dos Estados Unidos sobre a nova organização da
ISO/IEC DIS 29500. Ela também complementa a proposta de mudança de escopo aprovada na BRM.

O Brasil tentou apresentar essa proposta durante os debates, no primeiro dia da reunião e, atendendo a pedido feito pelo organizador, o Brasil começou discussões paralelas com os Estados Unidos e outras delegações preparando sua proposta para ser apresentada na sexta-feira, durante a apresentação dos Estados Unidos. Na sexta-feira, quando os Estados Unidos concluiu a sua parte da apresentação e solicitaram ao Brasil que apresentasse a sua, o organizador negou essa oportunidade à delegação Brasileira.

Várias delegações protestaram contra aquela decisão arbitrária, mas os apelos foram em vão e até o final da BRM, a delegação Brasileira não pôde apresentar sua proposta. A principal razão alegada pelo organizador foi “falta de tempo”. A proposta aqui mencionada é aquela disponível no arquivo “Br_Multipart_Proposal.ppt” disponível para todos os membros da BRM no website da ISO/IEC/JTC1/SC34 pelo menos desde o quarto dia da reunião.

O Brasil também notou que a maioria das decisões tomada durante a BRM foi baseada no argumento da “falta de tempo”, e nós acreditamos que isso é completamente incompatível com o tipo de decisões que deveriam ter sido tomadas naquela reunião.

Durante a BRM, algumas decisões também foram tomadas baseadas no argumento de que “nós precisamos dar respostas aos jornalistas”, e nós acreditamos que a cobertura da mídia não era tão importante quanto o resultado da reunião, a ponto de ter sido utilizado como critério para tomada de decisões. Mesmo com a “falta de tempo” alegada, alguns membros da delegação da ECMA, e não membros de quaisquer NB, tiveram permissão para fazer discursos de meia-hora durante os dois primeiros dias da reunião.

As regras de votação daquela reunião não foram seguidas conforme a subcláusula 9.1.4 das diretivas da ISO/IEC/JTC1. O Brasil também notou que a ISO/IEC DIS 29500 foi votada sob a ISO/IEC/JTC1 mas a BRM foi organizada pela ISO/IEC/JTC1/SC34. Mesmo se houvesse intenção de usar a subcláusula 9.1.4 das diretivas, o Brasil não pode entender se o status de membro P considerado deveria ser o da ISO/IEC/JTC1 ou o da ISO/IEC/JTC1/SC34.

O Brasil também considera que se a maior parte das questões eram para ser decididas por votação, sem qualquer tipo de discussão permitida. [essa parte da tradução não fez muito sentido]

Sobre o mesmo assunto, o Brasil considera que o “critério padrão de votação” escolhido somente foi eleito por ser o critério “menos ruim” que poderia ser analisado, e nós não consideramos que essa decisão de votação represente a intenção da vasta maioria dos delegados da BRM. Eles foram lá para discutir as propostas técnicas.

Analisando o documento “SC 34 N 990EDITED NOTES OF THE MEETING, na página 7, nós encontramos registro da objeção de BR à decisão de divisão multi-part mas analisando o documento “SC 34 N 989RESOLUTIONS OF THE MEETING nós não encontramos aquela objeção registrada.

Durante a BRM, as delegações foram solicitadas a votar em bloco pela rejeição de um conjunto de respostas que foi considerada pelo organizador como “respostas sem quaisquer instruções de edição”. Aquelas respostas listadas no arquivo “dis29500-nochange.txt”, disponível no website da SC34 durante a BRM e, tanto quanto os delegados Brasileiros lembram, esse conjunto de respostas foi “rejeitado em bloco” conforme solicitado.

Quando nós analisamos os documentos N989 e N990 não vimos nenhuma referência àquela decisão e também no documento da ISO/IEC/JTC1/SC34 intitulado “Result of Proposed disposition of comments (SC 34 N 980)”, que apresenta uma tabela com o status de cada resposta, algumas das “respostas rejeitadas em bloco” aparecem como aceitas (por exemplo, respostas 3, 5, 10 e 11, entre outras).

Para finalizar nossas considerações sobre a BRM, analisando o documento N989, nós encontramos que a BRM pode ser resumida por:

  • Total de respostas disponíveis para discussão: 1027 – 100 %
  • Total de respostas abordadas na BRM: 189 – 18,4 %
  • Total de respostas decididas por voto “padrão”: 838 – 81,6 %

Nós usamos o termo “respostas abordadas na BRM” acima porque a maioria daquelas respostas foi decidida por votação em bloco, sem qualquer discussão na BRM.

Pelas razões acima mencionadas, o Brasil considera que a BRM ISO/IEC DIS 29500 foi inconclusiva.

2. Sobre a versão final do texto da ISO/IEC DIS 29500

De acordo com o item 13.12 da diretiva, a versão final do texto da ISO/IEC DIS 29500 deve ser distribuído em não mais de um mês após o final da BRM.

Visto que quase três meses se passaram depois do final da BRM, sem qualquer versão final do texto ser publicada ou distribuída, e baseado na subcláusula 13.12 da diretiva, o Brasil solicita a distribuição do texto final da ISO/IEC DIS 29500.

Por todas as razões apresentadas, o Brasil gentilmente solicita que o resultado da ISO/IEC DIS 29500 seja reconsiderado pelas ISO/IEC/JTC1 e ISO/IEC/JTC1/SC34.


Marcia Cristina de Oliveira

ABNT – Gerente de Processo de Padronização