QtWebKit is no more, what now?

Driven by the technical choices of some of our early clients, QtWebKit was one of the first web engines Collabora worked on, building the initial support for NPAPI plugins and more. Since then we had kept in touch with the project from time to time when helping clients with specific issues, hardware or software integration, and particularly GStreamer-related work.

With Google forking Blink off WebKit, a decision had to be made by all vendors of browsers and platform APIs based on WebKit on whether to stay or follow Google instead. After quite a bit of consideration and prototyping, the Qt team decided to take the second option and build the QtWebEngine library to replace QtWebKit.

The main advantage of WebKit over Blink for engine vendors is the ability to implement custom platform support. That meant QtWebKit was able to use Qt graphics and networking APIs and other Qt technologies for all of the platform-integration needs. It also enjoyed the great flexibility of using GStreamer to implement HTML5 media. GStreamer brings hardware-acceleration capabilities, support for several media formats and the ability to expand that support without having to change the engine itself.

People who are using QtWebKit because of its being Gstreamer-powered will probably be better served by switching to one of the remaining GStreamer-based ports, such as WebKitGTK+. Those who don’t care about the underlying technologies but really need or want to use Qt APIs will be better served by porting to the new QtWebEngine.

It’s important to note though that QtWebEngine drops support for Android and iOS as well as several features that allowed tight integration with the Qt platform, such as DOM manipulation through the QWebElement APIs, making QObject instances available to web applications, and the ability to set the QNetworkAccessManager used for downloading resources, which allowed for fine-grained control of the requests and sharing of cookies and cache.

It might also make sense to go Chromium/Blink, either by using the Chrome Content API, or switching to one its siblings (QtWebEngine included) if the goal is to make a browser which needs no integration with existing toolkits or environments. You will be limited to the formats supported by Chrome and the hardware platforms targeted by Google. Blink does not allow multiple implementations of the platform support layer, so you are stuck with what upstream decides to ship, or with a fork to maintain.

It is a good alternative when Android itself is the main target. That is the technology used to build its main browser. The main advantage here is you get to follow Chrome’s fast-paced development and great support for the targeted hardware out of the box. If you need to support custom hardware or to be flexible on the kinds of media you would like to support, then WebKit still makes more sense in the long run, since that support can be maintained upstream.

At Collabora we’ve dealt with several WebKit ports over the years, and still actively maintain the custom WebKit Clutter port out of tree for clients. We have also done quite a bit of work on Chromium-powered projects. Some of the decisions you have to make are not easy and we believe we can help. Not sure what to do next? If you have that on your plate, get in touch!

Entenda o systemd vs upstart

Originalmente publicado no PoliGNU.

Por quê mudar?

Recentemente o projeto Debian passou por um intenso debate para decidir que sistema de inicialização deveria substituir o venerável (porém antiquado) system v como padrão do sistema para a próxima release, codename jessie.
A razão para mudar pode não parecer óbvia, especialmente para os muito apegados à ideia de “UNIX” ou que simplesmente estão acostumados a como as coisas funcionam hoje, mas fica clara quando se analisa os principais problemas enfrentados por sistemas que ainda usam sistemas de init system v. Pra começo de conversa, o init não conhece muitas das novidades tecnológicas que apareceram nas últimas décadas.
Peguemos como exemplo o controle de hardware: um daemon que precise ser iniciado quando um determinado tipo de hardware é plugado não será executado automaticamente pelo init se for plugado, o que exige que além de ter lógica para tratar o caso no boot, também se tenha que ter outros mecanismos para reagir ao hot-plugging.
Ser um conjunto de scripts shell também causa uma infinidade de problemas. Como cada script deve reinventar a inicialização do daemon que controla, é bastante comum que eles não sejam 100% resilientes a problemas como deixar processos (principais ou filhos) para trás quando quem administra o servidor pede que o serviço seja parado. Isso acaba exigindo intervenção de quem administra, matando manualmente os processos.
O desempenho também é um problema que passou muito tempo sem solução. Com o aparecimento de computadores com múltiplas CPUs e com espera de rede se tornando um problema foi inventado um sistema de paralelizar a execução dos scripts de inicialização, o que trouxe consigo a enorme complexidade de ter que estabelecer dependências entre os scripts, para garantir que só sejam executados em paralelo scripts que possam sê-lo. Mas isso também é muito mais complexo do que parece – as dependências em sistemas modernos são muito mais sutis e variáveis do que pode parecer em primeira análise. Além disso, executar cada script desse gera um overhead não desprezível.
Por último, o diagnóstico de falhas de inicialização de serviços é absurdamente complexo; raramente se sabe em que arquivo de log estarão as mensagens relevantes e com alguma frequência sequer haverá logs da falha propriamente dita em algum lugar, restando a quem administra executar o serviço manualmente e ver o que acontece.
Para resolver alguns ou todos esses problemas vieram os novos sistemas de init. Na verdade o Mac OS X saiu na frente com o launchd, mas essa é história pra uma outra oportunidade, comecemos pelo upstart, que nasceu no Ubuntu há alguns anos atrás.

Upstart

O upstart surgiu quando a principal preocupação das pessoas estava em melhorar o desempenho do boot através de paralelismo. A ideia é substituir a necessidade de estabelecer dependência entre os serviços de forma declarativa e ao invés disso estabelecer condições para que um serviço esteja “pronto” para ser executado.
No sistema de dependências inventado para o system v começa pelo objetivo: preciso rodar rodar o procedimento que monta sistemas de arquivo remotos, pra isso preciso rodar as dependências dele que são montar os sistemas de arquivo locais e estabelecer conexão de rede. O upstart inverte essa lógica e começa dos procedimentos que tem nenhuma dependência, o que vai tornando outros procedimentos “prontos” e os executa a partir daí.
A ideia é que o sistema de init reage a eventos, que podem ser um serviço estar estabelecido mas também podem ser de outra natureza: um hardware ser plugado, por exemplo. Isso resolve o problema do desempenho, em certa medida e cria um framework que permite ao sistema de init continuar cuidando do sistema enquanto ele estiver ligado, iniciando e parando serviços conforme as condições do sistema mudam.
Há alguns poréns a respeito dessa estratégia, que quem tiver curiosidade achará com facilidade nos frequentes debates travados entre Lennart Poettering e os proponentes do upstart, mas eu queria chamar a atenção para um em particular: usando eventos não existe garantia de que um serviço esteja de fato em execução plena quando o seu procedimento de inicialização conhecido pelo upstart termina – anote isso mentalmente.
Finalmente, o upstart acaba não resolvendo os problemas de diagnóstico, nem de processos perdidos sendo deixados pelo sistema (embora uma solução que adota a ideia do systemd para isso esteja sendo criada), principalmente por as receitas de init usadas pelo upstart serem ainda scripts shell customizados.

Systemd

O systemd é criação de Lennart Poettering, que é funcionário da Red Hat e contribuidor do Fedora. Daí muita gente atribuir o systemd à Red Hat, no que se enganam: embora hoje a Red Hat tenha inúmeros projetos com o systemd no centro, a ideia original e o esforço original foram feitos por Lennart em seu próprio tempo e não como um projeto da empresa.
A motivação para sua criação é bem mais ambiciosa que a que originou o upstart: a ideia é que há inúmeras funcionalidades que o kernel Linux que são incríveis e extremamente avançadas e que acabam não sendo usadas a não ser em ambientes muito específicos, porque não há infra-estrutura comum no espaço de usuário para fazer uso da funcionalidade e disponibilizá-la para o resto do sistema.
Um exemplo: cgroups. Os Control Groups são formas de juntar processos em uma embalagem que permite tratar esse grupo de processos como um todo. Esses grupos podem ser usados por exemplo para limitar que partes do sistema os processos que o compõe podem ver, criando uma visão virtual mais limitada do sistema de arquivos, por exemplo, ou limitando as interfaces de rede que os processos podem ver. Também podem ser usados para tornar o agendamento de tempo das tarefas no processador mais adequado ao sistema, ou impor limites de uso de memória, de operações de I/O e assim por diante.
Uma das primeiras funcionalidades trazidas pelo systemd foi exatamente o uso de Control Groups. Cada serviço iniciado pelo systemd o é dentro de um cgroup próprio, o que significa por exemplo que todos os processos criados por aquele serviço podem ser – com certeza – terminados quando o serviço é parado. Também significa que apesar de seu apache estar consumindo muito CPU ou memória, seu servidor SSH ainda tem um naco suficiente do tempo de CPU para aceitar sua conexão que será usada para tratar do problema, já que o Linux tenta ser justo com os diferentes cgroups.
Além de tudo isso, o uso de cgroups ainda dá ao systemd a capacidade de garantir que não fiquem processos pra trás quando um serviço é parada: como processos criados por processos que foram colocados num control group também são colocados nesse control group, basta terminar todos os processos do control group para que não sobre nenhum. O pessoal do upstart pensou em adotar essa ideia.
Mas o systemd também atacou o problema do desempenho, de duas formas: a primeira foi a ideia de remover completamente scripts shell da jogada. Cada serviço é especificados num arquivo de configuração chamado “unit”, que descreve todas as informações que o init precisa para iniciar e cuidar do processo. Isso retira da equação a necessidade de iniciar um interpretador shell e de executar os complexos scripts usados atualmente com system v.
A segunda foi dando uma solução um pouco mais inusitada à questão das dependências. A ideia é simples: a maioria dos serviços abre sockets de algum tipo para receber pedidos de seus clientes. O X, por exemplo, cria um socket UNIX em forma de arquivo no /tmp. O que o systemd faz é criar todos os sockets dos serviços que controla (eles estão descritos nos arquivos unit) e, quando recebe uma conexão, inicia o serviço e passa pra ele o socket.
O interessante dessa solução é que ela 1) estabelece a relação de dependência na vida real: o serviço é iniciado quando alguém pede e 2) garante que os clientes que forem iniciados vão ter seu primeiro request atendido, não há mais o problema de não saber quando o serviço está plenamente ativo (lembra da nota mental no caso do upstart?).
Para completar, o systemd controla as saídas padrão e de erro dos serviços que inicia e pode facilmente mostrar as últimas linhas de log de um serviço quando sua execução falha, tornando muito simples o diagnóstico:
kov@melancia ~> systemctl status mariadb.service
mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled)
Active: active (running) since Seg 2014-02-03 23:00:59 BRST; 1 weeks 3 days ago
Process: 6461 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=0/SUCCESS)
Process: 6431 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Main PID: 6460 (mysqld_safe)
CGroup: /system.slice/mariadb.service
        ├─6460 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
        └─6650 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plug...
	Fev 03 23:00:57 melancia mysqld_safe[6460]: 140203 23:00:57 mysqld_safe Logging to /var/log/mariadb/mariadb.log.
	Fev 03 23:00:57 melancia mysqld_safe[6460]: 140203 23:00:57 mysqld_safe Starting mysqld daemon with databas...mysql
	Fev 03 23:00:59 melancia systemd[1]: Started MariaDB database server.
	Hint: Some lines were ellipsized, use -l to show in full.

A questão de licenciamento

De extrema importância quando falamos de Software Livre são a questão de licença e de copyright do código. O systemd é licenciado sob a LGPL versão 2.1 ou superior, o que permite que programas proprietários sejam linkados com suas bibliotecas. O copyright das contribuições feitas ao código é mantido pelos colaboradores. Um projeto de software livre bastante comum desse ponto de vista.
Já o Upstart, sendo criação da Canonical segue o que tem sido sua política há algum tempo: usa uma licença GPL (versão 2) e exige que contribuidores assinem um Contributor License Agreement compartilhando os direitos de copyright com a Canonical. Com isso, a Canonical fica sendo a única dona do copyright do conjunto e pode fazer por exemplo alterações de licença, ou lançar uma versão proprietária se entender que deve.
Em primeira análise isso não parece ser um problema: de fato, há várias licenças mais permissivas usadas por outros softwares, como as licenças BSD, que permitem às pessoas fecharem o código. A grande questão aqui é que com esse modelo não é qualquer pessoa que pode fazer isso, só a Canonical pode. Essa acaba sendo uma forma de desnivelar as oportunidades artificialmente, criando um monopólio do privilégio de lançar versões proprietárias.

Futuro

Atualmente dois sistemas importantes usam upstart: Ubuntu e Red Hat Enterprise Linux 6, que é a versão atual suportada da Red Hat. O systemd foi adotado inicialmente pelo Fedora, o que significa que a futura RHEL 7 também estará usando systemd. Algumas outras distribuições passaram a usar systemd ou como padrão ou como opção bem suportada, como o SuSE e o Arch Linux, por exemplo.
Com a adoção dele pelo Debian como padrão, todas as grandes distribuições base passarão a ser baseadas no systemd. Para surpresa de muitos (minha inclusive), Mark Shuttleworth anunciou que dada a decisão do projeto Debian, o Ubuntu também passaria a adotar systemd por padrão, aceitando graciosamente a derrota, em suas próprias palavras.
Com essa mudança é muito improvável que o upstart tenha um futuro depois de sua aposentadoria nas versões estáveis do RHEL e Ubuntu LTS, a menos que alguma outra distribuição se apresente para assumir sua manutenção.
Vida longa ao systemd!

 

Nota: ao tratar do CLA exigido pela Canonical o texto anteriormente usava a expressão “transferindo o copyright” , que dá a entender que o autor original da contribuição perdia os direitos, o que não é verdade e foi corrigido.

WebKitGTK+ hackfest 5.0 (2013)!

For the fifth year in a row the fearless WebKitGTK+ hackers have gathered in A Coruña to bring GNOME and the web closer. Igalia has organized and hosted it as usual, welcoming a record 30 people to its office. The GNOME foundation has sponsored my trip allowing me to fly the cool 18 seats propeller airplane from Lisbon to A Coruña, which is a nice adventure, and have pulpo a feira for dinner, which I simply love! That in addition to enjoying the company of so many great hackers.

Web with wider tabs and the new prefs dialog

Web with wider tabs and the new prefs dialog

The goals for the hackfest have been ambitious, as usual, but we made good headway on them. Web the browser (AKA Epiphany) has seen a ton of little improvements, with Carlos splitting the shell search provider to a separate binary, which allowed us to remove some hacks from the session management code from the browser. It also makes testing changes to Web more convenient again. Jon McCan has been pounding at Web’s UI making it more sleek, with tabs that expand to make better use of available horizontal space in the tab bar, new dialogs for preferences, cookies and password handling. I have made my tiny contribution by making it not keep tabs that were created just for what turned out to be a download around. For this last day of hackfest I plan to also fix an issue with text encoding detection and help track down a hang that happens upon page load.

Martin Robinson and Dan Winship hack

Martin Robinson and Dan Winship hack

Martin Robinson and myself have as usual dived into the more disgusting and wide-reaching maintainership tasks that we have lots of trouble pushing forward on our day-to-day lives. Porting our build system to CMake has been one of these long-term goals, not because we love CMake (we don’t) or because we hate autotools (we do), but because it should make people’s lives easier when adding new files to the build, and should also make our build less hacky and quicker – it is sad to see how slow our build can be when compared to something like Chromium, and we think a big part of the problem lies on how complex and dumb autotools and make can be. We have picked up a few of our old branches, brought them up-to-date and landed, which now lets us build the main WebKit2GTK+ library through cmake in trunk. This is an important first step, but there’s plenty to do.

Hackers take advantage of the icecream network for faster builds

Hackers take advantage of the icecream network for faster builds

Under the hood, Dan Winship has been pushing HTTP2 support for libsoup forward, with a dead-tree version of the spec by his side. He is refactoring libsoup internals to accomodate the new code paths. Still on the HTTP front, I have been updating soup’s MIME type sniffing support to match the newest living specification, which includes specification for several new types and a new security feature introduced by Internet Explorer and later adopted by other browsers. The huge task of preparing the ground for a one process per tab (or other kinds of process separation, this will still be topic for discussion for a while) has been pushed forward by several hackers, with Carlos Garcia and Andy Wingo leading the charge.

Jon and Guillaume battling code

Jon and Guillaume battling code

Other than that I have been putting in some more work on improving the integration of the new Web Inspector with WebKitGTK+. Carlos has reviewed the patch to allow attaching the inspector to the right side of the window, but we have decided to split it in two, one providing the functionality and one the API that will allow browsers to customize how that is done. There’s a lot of work to be done here, I plan to land at least this first patch durign the hackfest. I have also fought one more battle in the never-ending User-Agent sniffing war, in which we cannot win, it looks like.

Hackers chillin' at A Coruña

Hackers chillin’ at A Coruña

I am very happy to be here for the fifth year in a row, and I hope we will be meeting here for many more years to come! Thanks a lot to Igalia for sponsoring and hosting the hackfest, and to the GNOME foundation for making it possible for me to attend! See you in 2014!


II Encontro Nacional de Dados Abertos

Semana passada ficou curta, deixei de fazer um bocado de coisa que queria e apertei o passo em outras pra conseguir passar os dois últimos dias da semana em Brasília no II Encontro Nacional de Dados Abertos, organizado pela SLTI do Ministério do Planejamento e pelo escritório brasileiro da W3C. Valeu à pena!

Em 2010 eu comecei pra coçar uma coceira pessoal com um projeto para coletar e dar melhor visibilidade ao gasto dos parlamentares mineiros com as chamadas verbas indenizatórias. O resultado foi o softwae com nome-código “Montanha”, que era composto de duas partes: 1) um web scraper que entrava em cada uma das milhares de páginas que tinham os dados com uma grande granularidade e os colocava num banco de dados 2) uma aplicação web que exibia os dados em tabelas e gráficos para facilitar a leitura.

Mais pra frente resolvi renomear o projeto para ‘Olho Neles!’ pra ficar mais amigável e registrei um domínio* (http://olhoneles.org/). Em razão desse trabalho eu fui convidado para falar no primeiro ENDA, que aconteceu em 2011, mas infelizmente não deu certo a viagem para Brasília e eu acabei sendo representado pelo Marcelo “metal” Vieira, contribuidor do projeto, que por sorte estava por lá. Fui novamente convidado agora e dessa vez deu certo!

Eu apresentando o olhoneles

Eu apresentando o Olho Neles! foto da Raquel Camargo

A abertura foi muito boa e contou com o presidente da ESAF – Escola de Administração Fazendária, onde aconteceu o evento – que fez um primeiro discurso com um alto grau de auto-crítica governamental. Começou por falar que governo bom é governo que apanha de manhã, de tarde e de noite – o que ele acha que é essencial para manter a administração pública constantemente preocupada com a melhoria e para o quê os dados abertos tem muito a contribuir. Depois afirmou que a Receita Federal é uma instituição de excelência, que recolhe impostos muito bem, mas que falta muita qualidade no gasto dos recursos angariados por ela; “não podemos passar a conta das nossas ineficiências para a sociedade sempre”, disse ele, dando um tapa de luva no próprio governo.

Depois fomos para o evento. Eu confesso que inicialmente suspeitava que o evento seria uma série de palestras falando de projetos com lançamento no futuro, mas fui positivamente surpreso: muitas pessoas estava lá para mostrar suas iniciativas já em funcionamento, com dados já disponibilizados, até mesmo seguindo um princípio de não perseguir o ótimo que é inimigo do bom. Mais de uma apresentação teve um slide com uma variação de “publish early, publish often”, claramente inspirado no “release early, release often” d’A Catedral e o Bazaar, que é uma das pedras fundamentais do pensamento hacker. Alguns citaram o primeiro Encontro Nacional de Dados Abertos como marco inicial das suas iniciativas.

Outra coisa que eu senti é que a maioria das iniciativas não foi algo fortemente institucional – algum tipo de planejameto e definição estratégica sempre era citado, é verdade, e a adequação à Lei de Acesso à Informação certamente teve um papel importante, mas as iniciativas que iam além da mera compliance me deram a clara impessão de terem partido das áreas de tecnologia, com vontade fazer acontecer. Nunca é demais ser lembrado que no serviço público há muitas dessas pessoas que amam fazer acontecer, sou feliz de ter conhecido várias até hoje =).

E conhecer gente foi como sempre o ponto alto do evento pra mim. Apesar de eu não ter feito tudo que queria – acabei deixando de contribuir com a ideia de uma cryptoparty durante o evento, acabei ficando sem assistir à BR080 no final das contas e perdi alguns debates que eu achava importantes – não fiquei muito tempo sem estar com pessoas interessantes, com boas ideias e papo que acrescentou muito pra mim. Tive mais contato com o pessoal do ônibus hacker, do grupo transparência hacker, o que foi muito interessante e proveitoso pra mim.

A minha apresentação (slides em PDF, slides em ODP) correu sem maiores problemas, tirando que eu fiz a apresentação sem meus óculos que estão sem uma das asinhas – fiquei com medo de ninguém conseguir prestar atenção no que eu estava falando por ficar incomodado com os óculos tortos. Fiquei um pouco mais nervoso que o normal de não conseguir sentir o que as pessoas estavam pensando =P.

A recepção foi boa, fiquei feliz de saber que o representante da ALMG gostou de ter um projeto utilizando o trabalho deles de expor os dados através de web services (o que simplificou muito o código do coletor da ALMG no olho neles). Também fiquei feliz de saber que a Câmara Municipal de SP já tem web services para as verbas indenizatórias – taí uma tarefa fácil pra contribuir com o Olho Neles! ;)

Durante a apresentação do representante do Senado, que parece ter uma relação bem estabelecida com o grupo Transparência Hacker, inclusive, fiquei sabendo um pouco mais sobre LexML e sobre as ferramentas que tem sido usadas para ajudar a automatizar o processo legislativo, como o LexEdit, e torná-lo mais transparente. O Jean Ferri, que foi o moderador da sessão me deu alguns detalhes de como funciona a coisa toda e eu fiquei bem impressionado, não achei que estivesse tão avançado assim.

Enfim, fiquei muito feliz de ter sido convidado e de ter participado, muito obrigado à SLTI do Ministério do Planejamento e ao escritório brasileiro do W3C pela iniciativa, keep ‘em coming!

* .org sem .br porque nossas políticas de registro de domínio são blergh e exigem que você seja uma organização formalmente registrada para registrar org.br

Discussões sobre a Petrobrás

Assim que a Petrobrás divulgou os resultados do ano calendário de 2012 houve um sem número de controvérsias a respeito. Eu participei de algumas discussões e fiquei animado pra escrever um post explicando de forma mais detida minhas opiniões a respeito. Vou tentar abordar cada um dos argumentos usados nas discussões de que participei.

Está tudo bem, compre Petrobrás!

Vou começar tratando de um post do Paulo Henrique Amorim. O teor do post pode ser dividido em 2 partes: a primeira parte é uma nota oficial da Petrobrás em que ela diz o seguinte:

Em 2012, o lucro líquido foi 36% inferior ao apurado em 2011, refletindo os efeitos da depreciação cambial, maior participação de derivados importados no volume de vendas e aumento das despesas operacionais com maiores baixas de poços secos e subcomerciais;A segunda parte é um comentário feito pelo jornalista em que ele dá a entender que os jornais O Globo, Folha e Estadão deram um viés de má notícia em suas manchetes (que focam na queda de lucro recorde), enquanto a “publicação especializada” InfoMoney dá uma manchete que cita o valor auferido em lucros e indicando que o lucro superou as estimativas. Ele termina sugerindo ao leitor que compre ações da Petrobrás.

Eu considero esse post do Paulo Henrique Amorim uma tentativa pífia de dar um giro positivo numa notícia que não tem nada de positiva. O fato é que o lucro da Petrobrás caiu em 36% – mais que um terço! – em relação a 2011. As expectativas em relação ao lucro da Petrobrás estavam baixas por várias razões (algumas até listadas no texto da Petrobrás, acima) e o fato de o lucro ter superado essas expectativas não ajuda muito.

Valor das ações da Petrobrás de 2008 a início de 2013

As expectativas em relação à saúde financeira da Petrobrás e ao nível de interferência política sofrida pela empresa não é coisa nova. A Petrobrás perdeu mais de 66% do seu valor de mercado desde 2008, como se pode ver no gráfico acima, obtido no Yahoo! Finance. Isso significa que alguém que comprou 100 reais em ações da Petrobrás em 2008 hoje não vende as mesmas ações por mais do que 34 reais. Faz sentido, então, recomendar a compra, como fez PHA? Antes, vamos tentar entender as razões por trás da queda.

E por quê essa perda gigantesca?

As intervenções do governo e as mágicas fiscais

Em 2010 a Petrobrás fez o que o ex-presidente Lula chamou (com razão) de a maior capitalização da história do capitalismo mundial. O que foi isso? A Petrobrás precisava de dinheiro em caixa pra fazer investimentos na extração do pré-sal. Para conseguir esse dinheiro, a Petrobrás aumentou o número de ações que a compõe e as ofereceu na bolsa. Trabalhadores brasileiros puderam usar o dinheiro do FGTS para adquirir ações – e muitos fizeram isso!

Como parte do processo a União fez o que se chamou de cessão onerosa de 5 bilhões de barris de petróleo que se encontravam em lotes do pré-sal. O petróleo que está em território brasileiro é do Estado brasileiro, para que seja extraído de lá e usado comercialmente, a União faz leilões de concessão. Na capitalização a União concedeu, com antecedência, à Petrobrás os direitos sobre esses 5 bilhões de barris e ganhou, em troca, R$ 74,8 bilhões. Desses, R$ 42,9 bilhões foram usados para compra de ações da capitalização da Petrobrás, aumentando a participação da União na empresa. Note que até hoje esses barris estão lá embaixo da terra. O que foi feito foi uma transação sobre direitos futuros.

Com que propósito isso foi feito? Em primeiro lugar para viabilizar a capitalização, claro, mas em segundo lugar, esses bilhões foram usados para fazer o superávit primário de 2010. Esse é um dos exemplos de como o governo tem usado a Petrobrás politicamente, para fingir que cumpre as metas que define para si mesmo. Esse foi um dos fatores que levaram as ações da Petrobrás a continuarem em queda, mesmo depois de ter feito a maior capitalização da história. Vamos falar de outra: o subsídio à gasolina.

O subsídio à gasolina

Outra das razões para a queda do valor de mercado está na nota da Petrobrás citada acima: “maior participação de derivados importados no volume de vendas”. Em 2006, ano eleitoral, Lula foi a um campo de exploração de petróleo da Petrobrás pintar as mãos de preto e anunciar a nossa auto-suficiência em petróleo. Os mais atentos também devem se lembrar de como Lula fazia discursos ufanistas quando falava do etanol brasileiro, de como era o mais eficiente do mundo e coisa e tal.

Acontece que demanda por combustíveis aumentou consideravelmente desde então, em parte impulsionada pelo subsídio dado pelo governo para venda de automóveis, através da redução do IPI, e o setor produtivo brasileiro simplesmente não teve condições de atender à demanda. Resultado: milhões e milhões de barris importados tanto de etanol quanto de gasolina. A auto-suficiência durou bem pouco.

Por si só, o fato de termos que importar etanol e gasolina não seria tão problemático. Acontece que o governo, através da Petrobrás, adotou uma postura de não repassar ao preço local da gasolina os ajustes sofridos pelo preço do petróleo no mercado internacional. Essa postura funcionava quando a auto-suficiência em petróleo era um fato, mas a partir do momento em que nós começamos a importar, a Petrobrás estava pagando muito mais pela gasolina que comprava do que cobrava pela gasolina que vendia, o que levou a uma situação inusitada: quanto mais gasolina vende, mais a Petrobrás perde dinheiro! Como pode ser visto no post linkado, calcula-se que depois do reajuste da gasolina dado no começo de 2013 a Petrobrás está perdendo 1,2 bilhões de reais por mês. Essa é nossa situação atual.

Mas o subsídio à gasolina é do interesse nacional!

Assumindo que faça sentido a Petrobrás destruir sua saúde financeira para estabelecer um subsídio de interesse do país (falo disso mais adiante), resta somente a questão de se é interesse do país o subsídio à gasolina. Será que é? Eu acho difícil decidir sobre uma coisa complexa dessas assim de supetão; Uma das questões que servem como base pra essa é se é do interesse do país o subsídio ao IPI, dado anteriormente, e que levou à alta da demanda.

A redução de IPI para automóveis foi uma medida adotada pelo governo para aquecer a economia e impedir que a crise de 2008 nos atinge com mais força, reduzindo o emprego e a renda. É louvável essa tentativa, mas por quê a indústria automobilística? Uma das razões é possivelmente que essa é uma indústria que emprega muito e que tradicionalmente trabalhou com o governo para evitar reduções de postos de trabalho. OK, até aqui tudo bem. Mas será que não existem diversas outras indústrias que poderiam absorver os trabalhadores que perdessem o emprego nas montadoras? Quem dirá os serviços e indústrias de suporte que certamente surgirão em volta de empreendimentos desse porte?

Além de pensar sobre isso, temos que pensar também nos outros resultados que advem de uma política dessas. Uma delas é óbvia: a quantidade de carros nas cidades aumentou vertiginosamente, aumentando a poluição e os engarrafamentos. Essas são o que a economia chama de externalidades negativas. Imagine se ao invés de incentivar a compra de carros o governo federal tivesse iniciado investimentos consistentes em obras de mobilidade urbana em todo o território brasileiro. Canteiros de obra para metrôs, BRTs, trens poderiam não só absorver os trabalhadores que eventualmente fossem demitidos nas montadoras, mas gerariam uma externalidade positiva significativa. Melhoria na qualidade de vida das pessoas.

Do meu ponto de vista, o incentivo à compra de carros foi um erro. Mas suponhamos que tenha sido uma boa ideia. Voltemos à questão do subsídio à gasolina: o subsídio vem da Petrobrás, que é uma empresa de capital misto, o que significa que parte dela é do Estado brasileiro, parte de entes privados e indivíduos. Por isso mesmo, parte do dinheiro investido nesse subsídio é público. Ou seja, é dinheiro da pessoa pobre que recebe Bolsa Família, meu e seu.

Faz sentido usar esse dinheiro para beneficiar quem usa carros a gasolina? Eu consigo ver o benefício pra mim, que tenho carro e uso gasolina, mas que benefício à sociedade esse subsídio dá, que justifique usar dinheiro da pessoa pobre que recebe Bolsa Família pra me ajudar? Os argumentos que eu ouvi são de que um aumento na gasolina acarreta aumento de custo e portanto um aumento de preços em cascata no resto da cadeia produtiva. Será? Caminhões e ônibus usam diesel, por exemplo, então não vejo como o custo de transporte de cargas e passageiros seria afetado. Quem tiver alguma ideia, poste aí nos comentários.

A Petrobrás é uma empresa estatal/pública e portanto tem o dever de proteger os interesses nacionais!

Eu argumentei antes que o subsídio à gasolina não é necessariamente do interesse nacional. Acho o mesmo quando se trata de usar mágica contábil… mas vamos supor que fossem interesses nacionais. A Petrobrás tem o dever de protegê-los? Gostaria de voltar à questão da capitalização. Os mais atentos lembrarão que a Petrobrás é uma empresa de capital misto, ou seja, a União é um dos acionistas, mas há outros. Quem são esses outros? Grandes capitalistas que especulam na bolsa? Certamente há. Mas os mais atentos lembrarão que também há inúmeros trabalhadores, que usaram seu rico dinheirinho do FGTS para comprar ações da capitalização. São mais de 70 mil trabalhadores que tem mais de 2 bilhões aplicados na oferta original em 2000 ou na capitalização de 2010. Sem contar investidores individuais, que podemos ser eu e você. Quem comprou 100 reais em ações em 2010 hoje vende por 70. E não há sinal de que a trajetória de queda vai mudar.

É justo a Petrobrás tocar o foda-se para União, trabalhadores e outros acionistas e perseguir o que alguém tirou do Cadastro Único ser do interesse nacional? Eu diria que não. Se for o caso, e acho que, como qualquer outra política pública, o mérito dessa tem sim que ser avaliado, o ideal é fechar o capital da empresa, ou seja, tirá-la da bolsa de valores e trazer o orçamento da empresa pra dentro do orçamento geral da União. Por quê? Porque se vamos usar dinheiro público para fazer subsídio de interesse nacional é essencial que fique claro e transparente para todos que esse subsídio é feito ao invés de outros investimentos. O dinheiro que iria para subsidiar a gasolina poderia talvez ser melhor gasto na educação, por que não?

Conclusão

Respondendo à pergunta original: e aí, faz sentido recomendar a compra de Petrobrás? Do jeito que a coisa está hoje, não acho que faça sentido. É necessário que a empresa e o governo demonstrem que a Petrobrás será gerida como uma empresa séria de novo antes que seja possível confiar nela. Mas eu sou otimista e acho que a Graça Foster foi colocada lá com essa condição: de que ela poderia colocar a empresa nos trilhos. O aumento da gasolina do começo de 2013, apesar de não acabar com a defasagem do preço, é um passo na direção certa. Se você acredita que as intervenções políticas vão acabar e que a empresa vai parar de tomar decisões estúpidas como a de subsidiar a gasolina, compre. Se não acha, não faz sentido comprar.

Atualização (3 de março de 2013)

Só no primeiro bimestre de 2013 o valor de mercado da Petrobrás caiu mais do que em todo o ano de 2012. O aumento insuficiente para corrigir a distorção do preço da gasolina é uma provável explicação.

WebKitGTK+ Debian packaging repository changes

For a while now the git repository used for packaging WebKitGTK+ has been broken. Broken as in nobody was able to clone it. In addition to that, the packaging workflow had been changing over time, from a track-upstream-git/patches applied one to a import-orig-only/patches-not-applied one.

After spending some more time trying to unbreak the repository for the third time I decided it might be a good time for a clean up. I created a new repository, imported all upstream versions for series 1.2.x (which is in squeeze), 1.6.x (unstable), and 1.7.x (experimental). I also imported packaging-related commis for those versions using git format-patch and black magic.

One of the good things about doing this move, and which should make hacking the WebKitGTK+ debian package more pleasant and accessible can be seen here:


kov@goiaba ~/s/debian-webkit> du -sh webkit/.git webkit.old/.git
27M webkit/.git
1.6G webkit.old/.git

If you care about the old repository, it’s on git.debian.org still, named old-webkit.git. Enjoy!

Montanha: agora de olho nos vereadores de BH e alguns comentários sobre contribuições

Alguns dos leitores talvez saibam que eu escrevi no meio de 2010 um programa chamado ‘Montanha’. A ideia original do programa era me ajudar a escolher um candidato a deputado estadual me dando uma ideia geral de como os deputados da época gastavam os recursos da verba indenizatória. O site da Assembléia Legislativa de Minas Gerais publica essas informações, mas de uma forma muito inconveniente, tornando absolutamente impossível ter uma idea geral de como os deputados gastam a bufunfa. Obviamente botei o código online e subi uma instância pública para que outras pessoas pudessem fazer o mesmo. Depois disso o grande tevaum se juntou ao time e já adicionamos uma instância para a nova legislatura, que tomou posse em 2011.

Nos últimos dias decidi que com os belorizontinos prestando atenção nos vereadores, dada a polêmica sobre o aumento de salários e o veto pelo prefeito, seria um bom momento para criar o coletor e subir uma instância nova do Montanha, pra observar os gastos dos vereadores. Quem olhar vai notar rapidamente que o projeto ainda está pela metade: ainda faltam informações de partido dos vereadores, os links falam em ‘deputados’ e por aí vai, mas sou fiel ao princípio de release early, release often, então não quis esperar – quando os dados começaram a encher o banco botei o projeto pra fora.

Agora alguns comentários sobre questões que as pessoas me colocam:

Bacana! Se precisar de ajuda tamos aí!

Obrigado! Esse é um projeto de software livre – o código está sob a Affero GPL3 e sua contribuição é bem-vinda. Eu acredito firmemente em outro princípio: talk is cheap; show me the code. Eu não pretendo organizar/coordenar os esforços de outras pessoas, então não espere que eu peça ajuda para algo específico ou pegue na mão, sinta-se à vontade para clonar o projeto, fazer as modificações que achar que devem ser feitas e propô-las, não posso garantir que alguma coisa será incorporada ao meu branch, mas estou disposto a discutir questões de design/planos e responder dúvidas sobre o código – no canal #linux-bh da freenode, principalmente =).

Quais os planos pro futuro?

O meu TODO imediato é (e sinta-se à vontade pra roubar qualquer um e fazer):

  • colocar os dados de partido nos dados da Câmara Municipal de BH
  • mudar a interface do montanha para não falar em ‘deputados’, mas em ‘parlamentares’
  • escrever um coletor para os dados anteriores a março de 2010 da CMBH
  • melhorar a linkabilidade das pesquisas – deixar que você envie um link da visão de todos os gastos, por exemplo, com uma busca já feita
  • escrever alguns posts no Observador Político e no Trezentos chamando a atenção para algumas informações expostas pelo montanha
  • adicionar mais gráficos – gasto sobre tempo, por exemplo
  • melhorar a informação que o sistema dá a respeito do período coberto pelos dados
  • aumentar a quantidade de trivia exibida na página de detalhes de parlamentar
  • criar uma página com detalhes e trivia para fornecedores

Por que você não coloca esse projeto no Transparência Hacker (ou outro grupo)?

A minha resposta para esse tipo de pergunta tem sido ‘por quê eu deveria’? Não é que eu seja um lobo solitário, mas eu acho que só faz sentido participar de um projeto específico se houver alguma razão para tal. Visibilidade não me preocupa muito – a mensagem sempre acaba chegando em quem se interessa e em quem me interessa que ela chegue.

Eu não acredito que participar de um grupo – qualquer grupo – seja garantia de contribuidores, também; como eu disse, talk is cheap e disso eu tenho certeza de que acharia muito num grupo, mas acredito que as pessoas que quiserem contribuir vão contribuir independente de estar dentro de um grupo (como o Estêvão faz). Se um pedaço grande da contribuição vier de pessoas que fazem parte de um grupo e fizer sentido discutir o projeto dentro dele, aí sim eu veria sentido, por exemplo.

Uma última preocupação, essa específica com o thack, é que o foco do grupo me parece muito diferente do meu. Meu objetivo é que a sociedade tenha uma ferramenta para observar seus parlamentares. Para que isso aconteça é preciso que a ferramenta tenha uma vida mais longa e seja mantida. Os dados sobre a legislatura passada da ALMG, por exemplo, já foram retiradas do site da ALMG, mas o Montanha continua lá, a sociedade continua tendo acesso não só a todos dados, como a uma visualização mais razoável deles. Eu não estou prometendo que vou manter pra sempre, claro, principalmente porque faço isso no meu tempo vago (em que eu também trabalho pro Debian, GNOME, como, durmo e me divirto), mas a minha ideia é focar nesse um problema e ter uma boa solução razoavelmente perene.

A maioria das coisas que eu vi do thack são hacks muito bacanas, mas sua vida parece ser muito curta – assim que um hack está pronto outra ideia legal aparece e aquela é deixada para trás; essa bola já foi levantada por outras pessoas, inclusive, como exemplo de por quê grupos como o thack não são a solução definitiva para o problema de dados abertos e de por quê concursos de criação de app não substituem um trabalho sério dentro do governo; não é incomum achar coisas com dados de anos atrás ou que sequer continuam funcionando. Note que eu não tenho nada contra o thack, per se, muito menos contra as pessoas que o compõe – eu os considero colegas e amigos, eu só acho que nós surfamos ondas diferentes e isso me faz achar que eu não agregaria valor ao grupo e vice-versa. Obviamente posso ser convencido do contrário eventualmente =)

The Blocks C extension and GIO asynchronous calls

So, I intended to be completely away from my computer during my vacations, but hey. I have been interested in this new extension Apple added to the C language a little while ago which introduces the equivalent of closures to C. Today I spent a few minutes looking into it and writing a few tests with the help of clang.

Here’s something I came up with, to use a block as the callback for a GIO asynchronous call:

[sourcecode language="cpp"]
#include <Block.h>
#include <gio/gio.h>

typedef void (^Block)();

static void async_result_cb(GObject* source,
GAsyncResult* res,
gpointer data)
{
Block block = (Block)data;
block(res);
}

int main(int argc, char** argv)
{
g_type_init();

if (argc != 2) {
g_error("Blah.");
return 1;
}

GMainLoop* loop = g_main_loop_new(NULL, TRUE);
GFile* file = g_file_new_for_path(argv[1]);

g_file_query_info_async(file,
G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE,
G_FILE_QUERY_INFO_NONE, G_PRIORITY_DEFAULT,
NULL, async_result_cb, (gpointer) ^ (GAsyncResult* res) {
GError* error = NULL;
GFileInfo* info = g_file_query_info_finish(file, res, &error);

if (error) {
g_error("Failed: %s", error->message);
g_error_free(error);
return;
}

g_message("Content Type: %s",
g_file_info_get_attribute_string(info, G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE));

g_object_unref(info);
g_main_loop_quit(loop);
});

g_main_loop_run(loop);
g_object_unref(file);

return 0;
}
[/sourcecode]

Pretty neat, don’t you think? To build you need to use clang and have the blocks runtime installed (libblocksruntime-dev in Debian). Here’s the command I use:

$ clang -fblocks -o gio gio.c -lBlocksRuntime `pkg-config --cflags --libs gio-2.0`

AIClass and vacations

One of my side projects for these last months was to enroll on the online Introduction to AI class, with Peter Norvig and Sebastian Thrun, professors at Stanford. Through it I also learned about the Kahn Academy. I must say that getting to know these efforts made me feel similar to when I found Free Software: it’s hard to believe that such great things exist!

I learned some really cool stuff, and was also introduced to the amazing work of Sebastian Thrun with self-driving cars, it was an awesome experience! Last weekend I took the final exam, and today I got the certificate of accomplishment. It was delivered as a signed PDF which can be checked with a certificate they provided, pretty neat. I’m very happy, and motivated to enroll on more such courses in the future =). Now it’s time to cool down, though. My vacations start today, and on the weekend I’ll travel to the sunny Fortaleza, in northeastern Brazil, to enjoy some nice beaches and get some tan. See you next year!

Statement of Accomplishment - AIClass 2011

Statement of Accomplishment - AIClass 2011

WebKitGTK+ hackfest \o/

It’s been a couple days since I returned from this year’s WebKitGTK+ hackfest in A Coruña, Spain. The weather was very nice, not too cold and not too rainy, we had great food, great drinks and I got to meet new people, and hang out with old friends, which is always great!

Hackfest black board, photo by Mario

I think this was a very productive hackfest, and as usual a very well organized one! Thanks to the GNOME Foundation for the travel sponsorship, to our friends at Igalia for doing an awesome job at making it happen, and to Collabora for sponsoring it and granting me the time to go there! We got a lot done, and although, as usual, our goals list had many items not crossed, we did cross a few very important ones. I took part in discussions about the new WebKit2 APIs, got to know the new design for GNOME’s Web application, which looks great, discussed about Accelerated Compositing along with Joone, Alex, Nayan and Martin Robinson, hacked libsoup a bit to port the multipart/x-mixed-replace patch I wrote to the awesome gio-based infrastructure Dan Winship is building, and some random misc.

The biggest chunk of time, though, ended up being devoted to a very uninteresting (to outsiders, at least), but very important task: making it possible to more easily reproduce our test results. TL;DR? We made our bots’ and development builds use jhbuild to automatically install dependencies; if you’re using tarballs, don’t worry, your usual autogen/configure/make/make install have not been touched. Now to the more verbose version!

The need

Our three build slaves reporting a few failures

For a couple years now we have supported an increasingly complex and very demanding automated testing infrastructure. We have three buildbot slaves, one provided by Collabora (which I maintain), and two provided by Igalia (maintained by their WebKitGTK+ folks). Those bots build as many check ins as possible with 3 different configurations: 32 bits release, 64 bits release, and 64 bits debug.

In addition to those, we have another bot called the EWS, or Early Warning System. There are two of those at this moment: one VM provided by Collabora and my desktop, provided by myself. These bots build every patch uploaded to the bugzilla, and report build failures or passes (you can see the green bubbles). They are very important to our development process because if the patch causes a build failure for our port people can often know that before landing, and try fixes by uploading them to bugzilla instead of doing additional commits. And people are usually very receptive to waiting for EWS output and acting on it, except when they take way too long. You can have an idea of what the life of an EWS bot looks like by looking at the recent status for the WebKitGTK+ bots.

Maintaining all of those bots is at times a rather daunting task. The tests require a very specific set of packages, fonts, themes and icons to always report the same size for objects in a render. Upgrades, for instance, had to be synchronized, and usually involve generating new baselines for a large number of tests. You can see in these instructions, for instance, how strict the environment requirements are – yes, we need specific versions of fonts, because they often cause layouts to change in size! At one point we had tests fail after a compiler upgrade, which made rounding act a bit different!

So stability was a very important aspect of maintaining these bots. All of them have the same version of Debian, and most of the packages are pinned to the same version. On the other hand, and in direct contradition to the stability requirement, we often require bleeding edge versions of some libraries we rely on, such as libsoup. Since we started pushing WebKitGTK+ to be libsoup-only, its own progress has been pretty much driven by WebKitGTK+’s requirements, and Dan Winship has made it possible to make our soup backend much, much simpler and way more featureful. That meant, though, requiring very recent versions of soup.

To top it off, for anyone not running Debian testing and tracking the exact same versions of packages as the bots it was virtually impossible to get the tests to pass, which made it very difficult for even ourselves to make sure all patches were still passing before committing something. Wow, what a mess.

The explosion^Wsolution

So a few weeks back Martin Robinson came up with a proposed solution, which, as he says, is the “nuclear bomb” solution. We would have a jhbuild environment which would build and install all of the dependencies necessary for reproducing the test expectations the bots have. So over the first three days of the hackfest Martin and myself hacked away in building scripts, buildmaster integration, a jhbuild configuration, a jhbuild modules file, setting up tarballs, and wiring it all in a way that makes it convenient for the contributors to get along with. You’ll notice that our buildslaves now have a step just before compiling called “updated gtk dependencies” (gtk is the name we use for our port in the context of WebKit), which runs jhbuild to install any new dependencies or version bumps we added. You can also see that those instructions I mentioned above became a tad simpler.

It took us way more time than we thought for the dust to settle, but it eventually began to. The great thing of doing it during the hackfest was that we could find and fix issues with weird configurations on the spot! Oh, you build with AR_FLAGS=cruT and something doesn’t like it? OK, we fix it so that the jhbuild modules are not affected by that variable. Oh, turns out we missed a dependency, no problem, we add it to the modules file or install them on the bots, and then document the dependency. I set up a very clean chroot which we could use for trying out changes so as to not disrupt the tree too much for the other hackfest participants, and I think overall we did good.

The aftermath

By the time we were done our colleagues who ran other distributions such as Fedora were already being able to get a substantial improvements to the number of tests passing, and so did we! Also, the ability to seamlessly upgrade all the bots with a simple commit made it possible for us to very easily land a change that required a very recent (as in unreleased) version of soup which made our networking backend way simpler. All that red looks great, doesn’t it? And we aren’t done yet, we’ll certainly be making more tweaks to this infrastructure to make it more transparent and more helpful to the users (contributors and other people interested in running the tests).

If you’ve been hit by the instability we caused, sorry about that, poke mrobinson or myself in the #webkitgtk+ IRC channel on FreeNode, and we’ll help you out or fix any issues. If you haven’t, we hope you enjoy all the goodness that a reproducible testing suite has to offer! That’s it for now, folks, I’ll have more to report on follow-up work started at the hackfest soon enough, hopefully =).