My experience with GNOME 3 so far

You know, GNOME Shell and I are not really strangers to each other for a long time now. I have been using it almost daily as my main desktop since late 2009, when I started shipping it to Debian experimental. That means that I had ample opportunity to both get used to it and witness the huge improvements it had with every new release.

My general feeling towards GNOME 3 is this: ♥. Yes, I love it! I love the new themes, I love the window borders, I love the top panel, the overview, the dynamic workspaces, I love the Me menu, I love the clock and the calendar, the system indicators with the beautiful symbolic icons, being able to search for applications in such a nice way, the window animations, the multi-screen support, the new nautilus, the dash, looking glass. It’s hard for me to even express how thankful I am and how much admiration I have for the awesome folks who helped bring this to life. Thanks so much!

My GNOME3 desktop
My GNOME 3 desktop

After all this time, there are only two things I can say I dislike about GNOME3, apart from some minor wishlists: the alt-tab behaviour and the message tray. Let me expand on those.

Message Tray

Of the very few things I dislike, there is only 1 I hate and cannot see myself living with: the accordion animation in the message tray. No, really, it’s such a terrible, terrible idea. Every single time I try to use that thing I overshoot while moving the mouse to the left, then overshoot again moving the mouse to the right because the frigging icon has moved. It’s no good knowing that I can click in the text or in the empty area to its right, it feels wrong. It’s terrible that my actual target is moving at all. Every single time I use it is a small frustration for me – it’s as if the message tray was playing games with me, laughing at me for not having good enough mouse pointer driving skills – even more than the infamous sub-menus used to. And I had to go through that penance whenever I wanted to find the person I was chating with to resume the conversation.

I wrote an extension that disables the accordion animation by simply not showing the title at all when you hover the icon, and I patched GNOME Shell’s CSS to make the icons a bit bigger, so that it’s easier for me to hit them with the mouse. It’s clearly not ideal, and you still have to click the various “people” icons to figure out which of your friends who were lazy enough to not add a picture to their IM profiles is that one, but it’s still much better than chasing the (smaller) ones around to figure that out. Perhaps we should have the icons be bigger and always have the title bellow them? I don’t know, I trust the awesome designers who designed the awesomess that’s everywhere else will come up with a great idea.

My Message Tray
My message tray with bigger icons and no accordion animation.

Alt Tab

The number 1 feature of workspaces for me has always been locality – being able to not see all of the other applications and windows that are open elsewhere. This lowers the amount of noise when I’m trying to find something. The overview is very nice in this matter – only windows in the current workspace are shown, and even when you have an extra screen, the windows in there appear in that screen.

The alt-tab behaviour, on the other hand, of showing all windows and apps, even with the separator, bothers me. It’s really useful to have when you want to go to a specific window no matter where it is (I usually use the dash for that, though), but it adds noise when you want to go to a specific window _in this_ workspace, which is the most common use case for my usage. So I copied the alt-tab code over to an extension and modified it so that only windows in the current workspace would be considered.

In addition to that, with the windows in the extra screen always being there no matter what workspace you’re in (which I think is an awesome idea), they are effectively in all workspaces, so they add constant noise even with my extension. It’s also weird to have to look at the main screen to switch to a window in the extra screen. There’s a huge discontinuity. What I would prefer is having alt-tab to follow the mouse regarding screens – only show windows in the extra screen if you hit alt-tab in there, making sure the selector thing appears in there as well.

“Porque eu aprendi na faculdade que alocar memória é caro”

Mais um exemplo interessante a respeito daquilo que falei num post anterior. Recentemente uma pessoa que começou a trabalhar em um projeto em que eu trabalho há algum tempo me pediu que opinasse a respeito de um patch dele. O patch original dele havia sido revisado por um colega de projeto e além de umas bobagenzinhas de estilo havia uma única preocupação: “por quê você quer fazer essa mudança?” A mudança era bastante simples: evitava que uma variável fosse liberada e realocada em alguns casos específicos.

Nesse projeto uma das coisas que as pessoas menos gostam é de otimizações cegas. Se você faz uma mudança, essa mudança tem chances de introduzir bugs e de aumentar a complexidade do código. Se você vai incorrer nesse risco, é melhor saber que está de fato fazendo alguma diferença. Por isso, otimizações em geral só são bem-vindas se forem acompanhadas de um teste de desempenho que mostra melhoria. Se não melhora nada, pra que mudar? É claro que há excessões à regra e algumas mudanças acabam simplificando o código e são bem-vindas mesmo se o único resultado for não piorar o desempenho.

Quando eu falei que não é legal fazer otimizações cegas ele me disse: “Cega ou não, estou fazendo a mudança porque aprendi na faculdade que alocações são caras, principalmente porque causam chamadas de sistema e por isso devem ser evitadas”. Opa. Alocações de memória de fato envolvem o kernel, mas será que todas as alocações de memória causam chamadas de sistema e a consequente (e cara) troca de contexto para modo kernel?

Fácil testar isso. Se for verdade que cada alocação gera uma chamada de sistema o seguinte programa vai exibir 100 milhões de chamadas de sistema quando o executarmos através do strace:


#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv)
{
    int i;
    char* data;

    printf("START\n");
    for (i = 0; i < 100000000; i++)
        data = malloc(10);
    printf("END\n");

    return 0;
}

Vejamos:

[...]
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbe62175000
write(1, "START\n", 6START
)                  = 6
brk(0)                                  = 0x1b83000
brk(0x1ba4000)                          = 0x1ba4000
write(1, "END\n", 4END
)                    = 4
exit_group(0)                           = ?

Mas hein? Duas chamadas de sistema entre os dois writes? Pois é. Acontece que o pessoal que escreveu a malloc() já sabe que pedir memória pro kernel é caro e fizeram a libc pré-alocar uma quantidade maior de memória de uma vez e ir entregando pedaços dessa memória conforme a aplicação pede. Isso significa que alocação de memória não é cara? Não. É razoavelmente cara mesmo que não haja troca de contexto, afinal de contas a libc precisa fazer um tanto de trabalho pra saber quanto tem alocado e saber qual o tamanho de cada pedaço de memória que foi alocado para poder liberar depois com free(). Se ao invés de fazer malloc 100 milhões de vezes eu fizer uma só e fizer 100 milhões de memset() o programinha fica 10 vezes mais rápido.

Isso significa que nós devemos evitar qualquer alocação que seja possível evitar? Depende. Pra começo de conversa esse é um teste extremo, não uma carga de trabalho real. Testes são sempre melhores em cargas reais (ou mais parecidas com algo real). Mas principalmente, se for pra piorar muito a legibilidade do código, torná-lo mais complexo, manter memória comprometida por mais tempo que o necessário, é importante que haja um ganho em desempenho para contrabalancear. E esse ganho tem que ser medido, não imaginado =).

Scale Fail

Hoje foi publicado no site Linux Weekly News um artigo de Josh Berkus chamado Scale Fail (part 1) é preciso ser assinante da LWN ou esperar uma semana para que o artigo seja tornado público, mas enquanto isso você pode assistir a uma apresentação que o Josh Berkus fez aqui. O assunto não só é interessante como tem muito a ver com o tema de que eu tratei no meu último post =). O Josh Berkus é um dos principais desenvolvedores do PostgreSQL e também fez uma palestra muito interessante na Linux Foundation Collaboration Summit do ano passado sobre como evitar que seu projeto gere uma comunidade. Recomendo fortemente. Se interessar, também recomendo a palestra seguinte, do Chris DiBona do Android.

Mesa redonda

Anos atrás trabalhei num ambiente em que todos os usuários praticamente conheciam o hostname do servidor de arquivos. Usuários saberem hostnames de servidores de arquivos quase nunca é um bom sinal. Todos reclamavam constantemente do tal servidor, falando sempre de como era lento o acesso aos arquivos. Assim que entrei me informaram das medidas que já haviam sido tomadas: sempre que a reclamação ficava muito grande o administrador de rede colocava uma placa de rede de 100Mbps nova no servidor, mas isso parecia pouco resolver.

Alguns anos mais tarde trabalhei em outro lugar em que havia uma aplicação web acessada por um número bastante grande de usuários de todo o Brasil. Havia um grande porém. Apesar de eu fazer parte da equipe de infraestrutura, todo o ambiente de produção dessa instituição ficava sob a responsabilidade de uma outra empresa. A tal aplicação começou a exibir graves problemas de desempenho e como havia prazos relacionados ao preenchimento de dados na aplicação, cada dia que passava sem que muitos usuários conseguissem fazer qualquer coisa no sistema gerava um aumento considerável na preocupação dos gestores.

Ao contrário do administrador do primeiro lugar a solução da equipe responsável pela TI dessa segunda instituição era menos mão-na-massa: fazíamos reuniões em torno de uma mesa em que eram debatidas as diversas possibilidades e sugeridas possíveis soluções. Alguns achavam que o problema era que a aplicação era lenta, outros que o servidor web estava mal configurado, outros que era falta de banda. Houve quem sugerisse que se substituísse a aplicação web por uma aplicação que rodasse na máquina dos usuários, com acesso direto ao banco de dados, o que supostamente reduziria o uso de banda.

O que há de errado em ambas as histórias? Ninguém nunca havia pensado em coletar dados, medir, saber o que havia de errado para depois atacar o problema. Eles preferiam fazer o pior tipo de tratamento de problemas de desempenho: imaginar qual seria o problema e chutar soluções que pudessem saná-los.

No primeiro caso, logo depois que entramos eu e um colega, a primeira coisa que esse colega fez foi instalar um monitoramento razoavelmente completo de indicadores de desempenho de todo o ambiente de rede com o cacti. Não demorou muito para que nós descobríssemos que o problema do nosso querido servidor de arquivos estava longe de ser banda. A carga de transferência de dados nunca passava dos 30Mbps, o que é muito menos que os 100Mbps que uma única placa de rede comum à época conseguiria de desempenho nominal. Adicionar placas de rede não adiantava absolutamente nada. Nem me lembro exatamente qual era o problema, provavelmente uma soma de fatores que incluíam uma configuração pra lá de absurda do Samba e uma configuração de raid que não fazia sentido, mas isso não vem ao caso. O importante dessa história é que o remédio que estava sendo dado para nosso paciente não ajudava em nada a melhorar a doença que ele tinha ;).

O segundo caso é um pouco mais triste: depois de algumas semanas tentando brigar com a estrutura burocrática para nos permitir acessar os servidores e saber o que estava acontecendo chegamos a um indicador bastante interessante: a carga média de 1 minuto do servidor de banco de dados estava em torno de 70. A máquina se não me engano tinha somente um processador. A carga média no Linux indica o número de processos que estão na fila para usar o processador ou bloqueados por espera de I/O, em médias de 1, 5 e 15 minutos. Como nós já havíamos investigado (e até tomado o controle) dos servidores de aplicação, nossa investigação sobre qual era o gargalo naquele momento parecia ter chegado a uma conclusão: o banco de dados e/ou o que a aplicação pedia dele precisava de amor e carinho. Acontece que não adiantou nada nós termos descoberto isso: continuamos por mais algumas semanas com todo mundo correndo em círculos como galinhas sem cabeça e sem ninguém com conhecimentos adequados chegar perto de analizar o banco de dados e as consultas feitas, até que finalmente alguém mais de cima decidiu mandar todos os nossos chefes embora e fazer uma intervenção.

Depois de algumas semanas batendo cabeça do mesmo jeito, com mais reuniões inúteis em torno de mesas (mas dessa vez com outros personagens) finalmente conseguimos que alguém com poder de agir nos escutasse e consertasse o banco de dados, embora nossa demanda por melhorias na aplicação (que nossas pesquisas paralelas e sem nenhuma ajuda do DBA indicaram colocar mais peso no banco do que o necessário) tenham caído em ouvidos surdos. As mudanças feitas no banco (otimização de queries, criação de índices e views materializadas, essencialmente, pelo que minha leiguice captou) acabaram dando gás para que o sistema sobrevivesse mais algum tempo sem uma intervenção mais estrutural, que acabamos fazendo quando finalmente assumimos o controle do servidor de banco de dados também, mas essa já é uma história pra outro post de blog.

Problemas de desempenho e otimizações são aquele tipo de coisa em que a pior coisa que você pode fazer é sentar em volta de uma mesa e tentar tirar qual o problema do ar. Agir com soluções de senso comum também só dá certo se você for sortudo. Esse assunto me interessa e por isso estou pensando em fazer alguns posts falando de problemas de desempenho e otimizações prematuras que demonstram que nem sempre o que é intuitivo é a realidade e que mesmo que você tenha uma hipótese bastante plausível é melhor investigar antes de torná-la uma crença. Alguém tem histórias interessantes pra compartilhar? =)

Nota: essa é uma obra de ficção baseada em fatos reais; algumas simplificações foram feitas sem prejuízo do caso em geral

A resposta do Ministério da Saúde

Ontem eu falei de como não conseguia mandar minha pergunta ao Ministério da Saúde. Como eu não desisto fácil, usei o email que achei para uso de imprensa para mandar minha pergunta e acabei recebendo resposta. Acompanhe a conversa:

Eu:

Recebi um email de dengue@combatadengeu.com.br com uma mensagem sobre a campanha e alguns links. Essa mensagem partiu do Ministério? Onde/como meu email foi obtido?

Saúde:

De: Andréa da Cunha Rocha
Para: gustavo@noronha.eti.br
Cc: COMUNICAÇÃO INTERATIVA
Assunto: Dúvida sobre dengue
Enviada em: Wed, 23 Feb 2011 18:57:08 +0000 (02/23/2011 03:57:08 PM)

Gustavo,

O Ministério da Saúde realiza ações nas redes sociais, incentivando parceria com blogueiros e internautas. Mas a mensagem a qual você se refere não foi enviada pelo Ministério. Pode ser algum spam. Agradecemos o alerta e averiguaremos a procedência de tal e-mail.

Continuamos à disposição para o esclarecimento de quaisquer dúvidas sobre saúde!

Att.,

Saúde

De: Andréa da Cunha Rocha
Para: gustavo@noronha.eti.br
Cc: COMUNICAÇÃO INTERATIVA
Assunto: Cancelar: Dúvida sobre dengue
Enviada em: Wed, 23 Feb 2011 19:14:44 +0000 (02/23/2011 04:14:44 PM)

Andréa da Cunha Rocha deseja cancelar a mensagem “Dúvida sobre dengue”.

Saúde:

De: Andréa da Cunha Rocha
Para: Andréa da Cunha Rocha , gustavo@noronha.eti.br
Cc: COMUNICAÇÃO INTERATIVA
Assunto: RES: Dúvida sobre dengue
Enviada em: Wed, 23 Feb 2011 19:36:54 +0000 (02/23/2011 04:36:54 PM)

Gustavo,

Desculpe-nos, houve um equívoco na informação. Realmente, o e-mail que você recebeu foi enviado pelo Ministério da Saúde. Esta é uma ação de combate à dengue que está sendo realiza em todas as redes sociais.

Estamos à disposição!

Att.,

Eu:

De: Gustavo Noronha Silva [mailto:gustavo@noronha.eti.br]
Enviada em: quarta-feira, 23 de fevereiro de 2011 18:50
Para: Andréa da Cunha Rocha
Cc: COMUNICAÇÃO INTERATIVA
Assunto: Re: RES: Dúvida sobre dengue

Oi Andréa,

Obrigado pela atenção! Você sabe me dizer de onde meu e-mail foi obtido?
Eu não me lembro de ter-me cadastrado em nenhuma lista de correio do
Ministério da Saúde.

Eu me cadastrei no site da campanha Dilma, no entanto, no ano passado. A
mensagem de email que eu recebi tinha alguns links que apontavam para o
domínio dilma.com.br, inclusive o link que poderia ser clicado para não
receber mais os emails. É possível que tenha vindo do banco de dados
deles o meu endereço de email?

Obrigado,

Saúde:

De: Andréa da Cunha Rocha
Para: Gustavo Noronha Silva
Cc: COMUNICAÇÃO INTERATIVA
Assunto: RES: RES: Dúvida sobre dengue
Enviada em: Wed, 23 Feb 2011 22:29:03 +0000 (02/23/2011 07:29:03 PM)

Prezado Gustavo,

Não sabemos lhe informar sobre isto, pois o envio de e-mail marketing já está incluso no contrato da agência licitada para prestar o serviço.

Continuamos à disposição para o esclarecimento de dúvidas sobre saúde.

Att.,

Ah, então tá, né…

Fico muito mais tranquilo que tenha sido só o Ministério que contratou uma empresa de “e-mail marketing” que obteve meu endereço de email de sabe-se lá onde. Vocês não? Não?

Governo Federal e a Internet. Tá me zoando, né?

Em uma nova tentativa de demonstrar que o apoio aos padrões abertos e ao software livre pelo Governo Federal está mais no discurso que nas ações o Blog do Planalto publica transcrições dos discursos da presidente em documentos no formato binário proprietário gerado pelo Microsoft Word (exemplo).

Ao tentar registrar minha sugestão de que não faz sentido isso já que discursos não passam de texto simples e poderiam muito bem ser publicados em um formato muito mais conveniente (como, tcharãn, HTML, que é usado no próprio blog) sempre me deparo com a seguinte mensagem:

Falha ao enviar sua mensagem. Por favor tente mais tarde ou contacte o administrador de outra forma.

Muito bem. Qual exatamente é a outra forma? Já que eu não achei uma, vai em forma de blog e mensagem no (argh) twitter, imagino.
Blog do Planalto me ajudando.
Como se eu já não estivesse chateado o suficiente com a forma como o governo se relaciona comigo pela Internet (estou olhando pra você também IRPF), recebo hoje um email:

From: Ministério da Saúde
To: gustavo@noronha.eti.br
Subject: Dengue. Se você agir, podemos evitar.
Date: Wed, 23 Feb 2011 01:00:22 +0000 (02/22/2011 10:00:22 PM)

Nham. O email é da campanha contra a dengue, mas vários links apontam para URLs no domínio dilma.com.br, como você pode ver na cópia do email que eu coloquei aqui. Eles de fato levam pra página da campanha, mas não é estranho? Exemplo:

<p>Caso não queira mais receber e-mails, clique <a href=”http://dilma.com.br/page/m/3ef9c647/5f18969f/7fea378b/25000d2e/1178116369/VEsE/”>aqui</a>.</p>

E o domínio é de fato registrado para a pessoa física Dilma Vana Rousseff:

kov@couve:~$ whois dilma.com.br | head -n 13 | tail -n 4
domain: dilma.com.br
owner: DILMA VANA ROUSSEFF
ownerid: 133.267.246-91
country: BR

Tendo em vista que eu não me cadastrei em lugar nenhum para receber emails do Ministério e que é muito estranho o domínio pessoal da Dilma ser usado na campanha da dengue do Ministério, eu quis contactar o Ministério da Saúde a respeito. Aí eu fui no lugar óbvio: Fale conosco do site do Ministério. Isso nos leva para uma página onde se pode registrar uma mensagem, depois de clicar uns links sobre ter entendido os termos. Acontece que essa é a página:
Site de fale conosco da saúde me ajudando muito.
*clap* *clap* *clap*

A clutter port of WebKit

In case you missed the news on webkit-dev, Collabora has been working on developing a clutter port of WebKit. It shares the build system with EFL, and most of the backend code comes from the GTK+ port. That means networking is handled by soup, drawing by cairo, multimedia by GStreamer, and so on.

If you’d like to give it a try, you can clone the repository from gitorious:

$ git clone git://gitorious.org/webkit-clutter/webkit-clutter.git

Then to build it you use cmake. From inside the source code directory do this:

$ mkdir build
$ cd build
$ cmake .. -DPORT=Clutter -DSHARED_CORE=1 -DBUILD_MX_LIB=1
$ make

The BUILD_MX_LIB option is optional – it will build what we call the “Mx toolkit library” in addition to the vanilla one. Then you can test that the library is built and working by running the programs inside the “Programs” directory. Enjoy!

A Claro, o CMI, a justiça e eu

Há alguns meses o pessoal do Centro de Mídia Independente (CMI) começou a receber relatos de usuários que não conseguiam acessar seu site. Os administradores de sistema do CMI tentaram localizar algum problema na infraestrutura do site mas não parecia haver nada de errado. Não demorou muito para identificar um padrão nos usuários que reclamavam: eles eram usuários da NET e da Claro 3G.

Muitos usuários ligaram e reclamaram, é claro, mas tanto NET quanto Claro negavam qualquer tipo de bloqueio e diziam aos usuários que o problema era com o site do CMI. Depois de muita insistência e de uma notificação extra-judicial enviada pelos advogados do CMI à Claro ficamos sabendo do real motivo:

Trata-se de um processo movido pela Associação dos Magistrados da Justiça do Trabalho ontra a Associação dos Rodoviários Aposentados e Pensionistas de Minas Gerais e o Sindicato dos Trabalhadores em Transportes Rodoviários de Belo Horizonte. Você deve estar se perguntando onde entram o CMI, NET e Claro nisso né? Aparentemente o juíz decidiu que uma matéria publicada no CMI tinha que ser retirada do ar e decidiu que quem devia retirar do ar a matéria eram as empresas de comunicação! O CMI não chegou sequer a ser comunicado dessa decisão.

Olhando por esse lado Claro e NET são vítimas da estupidez da Justiça brasileira, é verdade. Mais uma decisão vergonhosa da Justiça brasileira – bloquear um site para todos os brasileiros já seria ridículo, mas bloquear para usuários de algumas operadoras é a coisa mais absurda que eu já ouvi falar. Eu troquei de operadora de celular de qualquer forma e vou explicar por quê: em primeiro lugar não há nenhum sinal de que as operadoras tenham recorrido dessa decisão para guardar seus interesses e os de seus clientes. Em segundo lugar elas estão fazendo um péssimo trabalho de informar os clientes corretamente a respeito do problema.

Quando eu liguei na ouvidoria da Claro para registrar a razão da minha saída da operadora a atendente que conversou comigo me pediu o endereço do site e tentou acessar, juntamente com seu chefe e me disse: “Aqui não funciona esse site; tem certeza de que o endereço está certo? O site deve estar caído.” Ao que eu revidei: “É óbvio que vocês não vão conseguir acessar. Vocês estão dentro da rede da Claro, que bloqueou o acesso ao site, como eu já disse. Se vocês tentarem de algumas outras operadoras vocês vão conseguir.”. Depois de muito custo e só porque eu já tinha avisado que ia cancelar o serviço a atendente chegou na informação correta: o processo judicial que obriga a Claro a bloquear o site inteiro se precisar.

Eu expliquei que esse comportamento não é aceitável pra mim, que a Claro devia ter pelo menos feito um trabalho muito melhor de informar os clientes do problema real (redirecionando o endereço para uma página com as informações, por exemplo), já que até para os funcionários da Claro, como eles puderam ver, o que parecia era que o site estava fora do ar – o que não era verdade. Todos os relatos que eu vi de contato tanto com a NET quanto com a claro tiveram esse mesmo desenlace, com muitos deles não chegando à informação verdadeira.

Hoje eu consigo acessar o CMI de todas as minha conexões com a Internet de novo e recomendo a quem não estiver ainda conseguindo a trocar de operadora/serviço de Internet. É fácil com a portabilidade e serve como protesto contra essa estupidez. Não deixe de registrar na ouvidoria o motivo!

WebKitGTK+ hackfest 2010!

Last week I attended the WebKitGTK+ 2010 hackfest. It was a great opportunity to meet up with the other developers, discuss some plans for the future, hack away at WebKitGTK+. But, most importantly, play Street Figher 2 =). Thanks to Collabora and Igalia for sponsoring the hackfest, Igalia for hosting and organizing it (well done!), and the GNOME foundation for having sponsored my trip to Coruña!

Unlike last year we didn’t find any big design issues hurting our work (page cache, I’m looking at you!) on new futures. I also didn’t have any huge plans for new API, although we did manage to get some new stuff in there, like the plugins management API Xan created, and the further work done by Dan in soup. This meant, from my point of view the hackfest has been a great oportunity to look at refactorings that we could do to further simplify understanding the code, changing it, and even sharing it =). Besides pushing the debian packaging of the 1.3.x series a bit further.

Coruña was great as always, and I enjoyed going around, eating and hacking there, although I got a cold on the last days which kinda hindered my ability to stare at the screen for too long, some times. Now that I’m at the hot brazilian summer again I’ll hopefully get better soon =)

Cheers \o/

Sponsored by the GNOME Foundation