g_list_copy_deep and g_slist_copy_deep in GLib

If you have in your code things like that:

copy = g_slist_copy (list);
g_slist_foreach (copy, g_object_ref, NULL);

In GLib 2.34 (to be released soon) you can do:

copy = g_slist_copy_deep (list, g_object_ref, NULL);

Thus eliminating another loop in the list (one loop is done when copying the list).

In other words, there’s now a function to do a deep (full) copy of a GList and GSList. It accepts, besides the list to be cloned, a function as a second argument, and a user data as the third argument. That function will be called for each element in the list.

To free the new list, use g_list_free_full().

Programmatically managing iptables rules in C: IPTC

Sometimes we need to manage iptables rules from inside our own programs. The recommended solution given by iptables developers is to spawn the iptables command with execl() or system(). It’s explicitly stated that there’s no stable/public API to do that: http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5

However, if you have control of your box, including kernel, iptables, and all related packages, it’s safe to use IPTC to programmatically manage iptables rules.

IPTC is an internal iptables library that actually inserts/removes the rules. It’s used by the iptables (xtables-multi, iptables-save, iptables-restore) binaries. Depending on how iptables was compiled, there might be a shared libiptc.so object and/or a static libiptc.a object.

You should check that in order to correctly build your application. In Debian/Ubuntu, which this post is based, it’s enough to install the iptables-dev package. It will install the shared libraries, the header files and the pkg-config facility.

So, let’s take a look at a complete function that adds a rule to iptables:

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <libiptc/libiptc.h>

static int
insert_rule (const char *table,
             const char *chain, 
             unsigned int src,
             int inverted_src,
             unsigned int dest,
             int inverted_dst,
             const char *target)
      struct ipt_entry entry;
      struct xt_standard_target target;
    } entry;
  struct xtc_handle *h;
  int ret = 1;

  h = iptc_init (table);
  if (!h)
      fprintf (stderr, "Could not init IPTC library: %s\n", iptc_strerror (errno));
      goto out;

  memset (&entry, 0, sizeof (entry));

  /* target */
  entry.target.target.u.user.target_size = XT_ALIGN (sizeof (struct xt_standard_target));
  strncpy (entry.target.target.u.user.name, target, sizeof (entry.target.target.u.user.name));

  /* entry */
  entry.entry.target_offset = sizeof (struct ipt_entry);
  entry.entry.next_offset = entry.entry.target_offset + entry.target.target.u.user.target_size;
  if (src)
      entry.entry.ip.src.s_addr  = src;
      entry.entry.ip.smsk.s_addr = 0xFFFFFFFF;
      if (inverted_src)
        entry.entry.ip.invflags |= IPT_INV_SRCIP;

  if (dest)
      entry.entry.ip.dst.s_addr  = dest;
      entry.entry.ip.dmsk.s_addr = 0xFFFFFFFF;
      if (inverted_dst)
        entry.entry.ip.invflags |= IPT_INV_DSTIP;

  if (!iptc_append_entry (chain, (struct ipt_entry *) &entry, h))
      fprintf (stderr, "Could not insert a rule in iptables (table %s): %s\n", table, iptc_strerror (errno));
      goto out;

  if (!iptc_commit (h))
      fprintf (stderr, "Could not commit changes in iptables (table %s): %s\n", table, iptc_strerror (errno));
      goto out;

  ret = 0;
  if (h)
    iptc_free (h);

  return ret;

int main (int argc, char **argv)
  unsigned int a, b;

  inet_pton (AF_INET, "", &a);
  inet_pton (AF_INET, "", &b);

  insert_rule ("filter",
  return 0;

Note: The code above was compiled and tested against the 1.4.13 version of iptables.
To compile:

cc `pkg-config –cflags –libs libiptc` source-file.c -o test-iptc

So, the code in main() above does the equivalent of:

iptables -t filter -A INPUT -s ! -d -j DROP

The main functions used were iptc_init, iptc_append_entry and iptc_commit. There are functions to remove a rule (iptc_delete_num_entry), to iterate over all the rules (iptc_first_rule, iptc_next_rule) and to clear all rules (iptc_flush_entries).

You can check the header file libiptc/libiptc.h to see all available functions and their descriptions. I can post some more examples here in the future if there’s demand to it.

Again, remember that there’s no API stability in IPTC, so, it can change in each new version of iptables.

Hope it’s useful to someone. Feel free to ask anything or to report any issues you have. See you!

Linux firewall: Mac filtering – iptables and arptables|Firewall no Linux: filtro por mac – iptables e arptables


It’s common: you don’t want just filter the access by IP address, but also by the MAC address. The solution can be quite simple: use the MAC module of iptables:

iptables -A INPUT -s -m mac ! –mac-source aa:bb:cc:dd:ee:ff -j DROP

The command above says: Drop every packet with source ip address and its MAC address is NOT aa:bb:cc:dd:ee:ff. Thus you’re forcing the origin of the packet to be the desired one.

However there is a minor issue with that approach: iptables manages packets at the network (IP) layer, which is above the link (MAC) layer. What does that mean? Simple: Once the packet arrives at the network interface, it’s handled by the MAC layer and then it’s forwarded to the IP layer. That’s where iptables filter it. Again, what’s the problem? At this pointer, the ARP table of the kernel was touched, meaning that (using the example above), if a packet with source IP and source MAC 00:00:00:00:00:01 arrives, it will change the ARP entry in the kernel table to point the IP to that wrong MAC address. After that, the packet is forwarded to the above layer, which is then dropped by iptables from go on over the network. Even if the packet is dropped, which is what you want, your ARP table is messed up right now.

That’s where arptables command comes in. It works just like iptables, but it filters packets at MAC layer, preventing the kernel ARP table being touched by wrong packets. Its syntax is very similar to iptables (in fact, it’s a copy of iptables adapted to work in the lower level). The same command (iptables) above could be better implemented with arptables:

arptables -A IN -s ! –source-hw aa:bb:cc:dd:ee:ff -j DROP

You just need this rule, it’s not necessary to have the iptables rules anymore. arptables needs a kernel with support built in, which I guess most distros do, just like they do with iptables.

Take a look at the arptables man page, it has some examples. Its similarity with iptables facilitates our lives.


É uma situação comum: você não quer apenas filtrar o acesso por endereço IP, mas também pelo endereço MAC. A solução pode ser bastante simples: usar o módulo MAC do iptables:

iptables -A INPUT -s -m mac ! –mac-source aa:bb:cc:dd:ee:ff -j DROP

O comando acima diz: Descarte todos os pacotes com o endereço IP de origem e cujo endereço MAC não é aa:bb:cc:dd:ee:ff. Assim, você está forçando a origem do pacote a ser a desejada.

No entanto, há um pequeno problema com essa abordagem: o iptables gerencia pacotes na camada de rede (IP), que é acima da camada de enlace (MAC). O que significa isso? Simples: Quando o pacote chega na interface da rede, ele é tratado pela camada MAC e depois é encaminhado para a camada IP. É onde iptables o filtra. Novamente, qual é o problema? Neste ponto, a tabela ARP do kernel foi alterada, o que significa que (usando o exemplo acima), se um pacote com o IP origem e MAC 00:00:00:00:00:01 chega, ele vai mudar a entrada na tabela ARP do kernel para apontar o IP para o endereço MAC errado. Depois disso, o pacote é encaminhado para a camada superior, que é então descartado pelo iptables de continuar na rede. Mesmo o pacote sendo descartado, que é o que você deseja, sua tabela ARP está uma bagunça agora.

É aí que o comando arptables entra. Ele funciona exatamente como o iptables, mas filtra os pacotes na camada MAC, evitando que a tabela ARP do kernel seja alterada por pacotes errados. Sua sintaxe é muito semelhante ao iptables (na verdade, é uma cópia do iptables adaptado para trabalhar num nível mais baixo). O mesmo comando (iptables) acima poderia ser melhor implementado com arptables:

arptables -A IN -s ! –source-hw aa:bb:cc:dd:ee:ff -j DROP

Você só precisa dessa regra, não é necessário ter as regras de iptables mais. o arptables precisa que o kernel tenha suporte, o que eu acho que a maioria das distribuições já fazem, assim como eles fazem com o iptables.

Dê uma olhada no man do arptables, lá tem alguns exemplos. Sua semelhança com o iptables facilita nossas vidas.

free() inconsistencies|inconsistências no free()

Hi, folks!

Last week I was porting a program from uClibc to glibc. Everything went fine, until I found a crash to always happen in a certain part of it. The failure was in a call to the free() function. First thing that came in my head: Why the hell is it crashing now, while it used to run fine on uClibc? I made a simple program that simulates the problem:

Oi gente!

Semana passada tava portando um código compilado em cima da uClibc para glibc. Tudo tranquilo, até que certa parte do programa dava crash. Investigando, vi que a falha acontecia em uma chamada à função free(). Primeira coisa que veio à minha cabeça: porque raios tá dando crash aqui se o mesmo programa, compilado na uClibc roda perfeito? Fiz um programa simples que simula a situação:

#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

typedef struct {
  char *field1;
} s_test;

s_test test = {
  .field1 = NULL

int main (int argc, char **argv) {
  s_test *t;

  t = &amp;test;
  free (t);
  t = &amp;test;
  t-&gt;field1 = "bug";
  printf ("%s\n", t-&gt;field1);

  return 0;

Look at line 16. I’m executing a free() in a pointer to a static variable, instead of a pointer in the heap (previously allocated with malloc() or similar). It’s expected a crash here, right? Maybe! Yes, if you’re using glibc. No if you’re using uClibc. The above code works like [not] expected. Weird! Everything we learned at the programming school is ruined now 😀 !

So, we have a similar code here that have been worked for a long time, exactly because it was compiled and run on top of uClibc. I’ve seen this and other behavior differences between uClibc and glibc. The solution? Change the code to make it portable, not only to make it compile, but also so that it have the same behavior on every platform.

I thought it was a bug in uClibc, but I was told it doesn’t break the standards. In fact, standards say, in that case, the behavior is “undefined”. Ah, standards 🙂 … So, in order to avoid surprises like that, here is what I learned: Always code in the right way, even if it comes with a harder job. Don’t say: “hey, it’s working, let’s deploy it!”.

See you!

Preste atenção na linha 16. Estou executando um free() num ponteiro que aponta para uma variável estática, ao invés de uma variável que foi alocada com malloc() ou similar. Um crash é esperado aqui, certo? Em partes! Usando a glibc, sim. Já com a uclibc, não! O código acima funciona como [não] esperado! Estranho, não? Tudo o que aprendemos na escola de programação vai por água abaixo aqui hehehe.

Então, o que acontece é que temos um código similar aqui e que sempre funcionou, justamente por ser compilado na uclibc. Já vi essa e outras diferenças de comportamento entre a uclibc e a glibc. A solução? Mudar o código para torná-lo portável, não só para que compile corretamente, mas para que tenha os mesmos resultados, independente da plataforma.

A princípio, achei que isso era um bug na uclibc, mas fui apontado que isso não fere “os padrões”. De fato, os padrões dizem que nesse caso, o comportamento é “indefinido”. Ah, padrões 🙂 … Para evitar surpresas do tipo, fica aqui a lição aprendida: programar da forma certa, mesmo que dê um pouco mais de trabalho. Não se acomodar dizendo: “ah, testei aqui e funciona, deixa assim mesmo!” 😉

Bons códigos!

New challenges|Novos desafios


Hi, folks!

This is a small post, just to share the news with you: I moved to São Paulo (the biggest Brazilian city) to work with what I like the most: linux development! It’s indeed a big step in my career, I’m too excited about my new job: embedded linux developer!

I hope to learn a lot in this new job, and, at the right time, I want to contribute back to FLOSS community, since we use a lot of free software here.

See you!


Oi gente, tudo bom?

Este é um post rápido, quero compartilhar uma novidade com vocês: Estou dando um grande passo na minha carreira profissional. Me mudei para São Paulo e estou trabalhando na Vex/OI como desenvolvedor linux embarcado.

Foram pouco mais de 6 anos no meu último emprego, numa usina de açúcar e álcool em Alagoas. Fiz muitos amigos e aprendi bastante lá. Foi uma ótima empresa de se trabalhar. Infelizmente lá eu não trabalhava com o que eu gosto: linux. Por isso estou de mudança.

Espero aprender bastante nesse novo emprego e, no tempo certo, contribuir de volta com a comunidade FLOSS, visto que usamos muita tecnologia livre aqui.

Por enquanto estou só, procurando lugar pra morar. A família vem no final do ano. Quem quiser nos visitar em Sampa, pode entrar em contato, será um prazer receber os amigos!

Software livre, ajude a fazer

Este post é direcionado a programadores. Repasse-o pra todos os programadores que você conhece. O software livre agradece!

Oi gente, esse é um assunto que sempre menciono nos eventos que vou, e que me incomoda bastante. Por estes dias tava com vontade de fazer um post simples e prático sobre o assunto. Felizmente aconteceram 3 coisas que me motivaram a escrevê-lo:

  1. Depois de ter aberto um bug no ano passado, ainda sem solução, resolvi escrever um pequeno patch que foi aceito, com modificações;
  2. Li isso: http://www.dicas-l.com.br/arquivo/yad_yet_another_dialog.php;
  3. Jomar escreveu um ótimo artigo exatamente sobre esse tema: http://www.trezentos.blog.br/?p=5907

Por que as pessoas se referem ao software livre sempre na terceira pessoa: “Eles”? É comum a gente ouvir:

– Quando o software X implementar a feature Y eu migro.
– Software X? Ah, ele tem muitos bugs, prefiro esperar ficar redondo.
– Não gostei da versão nova do software X. Vou ficar na atual ou testar uma alternativa.
– O pessoal do projeto X é devagar demais.

Gente, quando é que vai cair a ficha que o software é livre e que nós podemos mudá-lo? Vocês já pararam pra pensar que podem tornar o software X um software melhor? Não tô entrando aqui no mérito da liberdade de escolha, você é livre pra usar o software que quiser. O recado aqui é para programadores, que querem ao mesmo tempo ganhar experiência e contribuir para um mundo melhor.

Contribuir com código não é um bicho de 7 cabeças. Software é software em todo lugar do mundo, e software livre é a melhor forma de espalhar e receber conhecimento. Vejam aqui um exemplo muito simples, porém prático de como você pode fazer a coisa acontecer, ao invés de simplesmente esperar “eles” resolverem o bug (explicação do item 1 lá de cima):

  • Ano: 2008. Senti a falta de um conversor de moedas no GNOME. Reportei meu desejo no bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=533690. Pouco mais de 1 ano depois esse recurso foi implementado.
  • Ano: 2010. Usando o recurso acima, senti a falta de um botão pra trocar de moedas. Da mesma forma, reportei meu desejo: https://bugzilla.gnome.org/show_bug.cgi?id=633193.
  • Ano: 2011. 7 meses depois, usando muito o recurso e sentindo realmente falta do tal botão, resolvi dar uma olhada no fonte e ver se seria fácil sua implementação. E foi. Submeti um patch, que no mesmo dia foi aceito, com algumas modificações feitas pelo mantenedor. Na próxima versão, a calculadora do GNOME virá com esse recurso.

O que quero mostrar com isso? Que o software livre basicamente é movido por empresas e voluntários. Se uma empresa não tem interesse em determinado recurso (a ponto de alocar um funcionário para implementá-lo), o recurso tem que ser implementado por algum voluntário. Então, ao invés de ficar dizendo “Eles não ligam pra minha opinião, reportei o bug há mais de um ano e nada até agora…”, simplesmente tente resolver você mesmo! Algumas considerações:

  • Mesmo que o seu patch não esteja correto, não tenha medo de enviá-lo. Dependendo do grau de complexidade, o desenvolvedor pode sugerir algumas modificações, explicar porque tá errado, onde tá errado e tal e pedir pra você corrigir e reenviar… ou ele pode simplesmente modificar e seu patch e aplicá-lo diretamente (foi o que aconteceu comigo acima).
  • Há sempre a possibilidade de entrar em contato direto com o desenvolvedor/mantenedor, via email, irc, jabber, etc. Assim, você pode tirar dúvidas, pedir um direcionamento, e coisas do tipo, antes de efetivamente enviar seu patch para avaliação.

Quanto ao item 2 lá em cima, até mencionei minha “indignação” nos microblogs, e algumas pessoas me perguntaram o por quê. Deixa eu explicar: Minha indignação, neste caso, não é com a pessoa do Júlio. Não quero nem discutir isso. É que tô cansado de ver empresas e pessoas que ganham a vida com software livre, seja usando em seu trabalho, seja escrevendo livros, seja dando aulas, enfim, você captou a ideia, e que são aptas a escrever (ou pagar alguém que escreva) código livre mas não o fazem. Neste caso específico, o Júlio citou no post:

“Sempre esperei que a qualquer momento o gnome lançaria uma nova versão deste software […] Estava enganado, acompanhei o lançamento de diversas revisões do software mas elas simplesmente tratavam bugs e apresentação. Infelizmente nada de inovação. Porém um dia descobri o YAD.”

Veja que o gnome está sendo tratado na terceira pessoa. “Eles”. Segue o mesmo raciocínio que usei acima. Tanto para o Júlio como para os criadores do YAD. Se o zenity não tava atendendo as expectativas, por que não ajuda-lo? Por que não implementar os recursos tão desejados?

Quanto ao item 3 lá de cima, não tenho muito o que falar. Leiam o texto do Jomar, é muito bom!

Enfim, esse “desabafo” é uma forma de mostrar pra vocês que o software livre é nosso! Vamos colaborar mais (com código). Afinal de contas, já recebemos tanto, de tantos desenvolvedores espalhados pelo mundo, o que custa doar um pouco do nosso tempo e conhecimento como uma forma de retribuição?

Então, esse lance de falar na terceira pessoa (“eles”, “o gnome”, “o pessoal do kde”, etc), deixa para os leigos, meros usuários de software. Na próxima vez que for criticar algum software livre, tome ele para si e pense em uma forma de ajudar, beleza? 🙂

Looking for new maintainers

Hi, folks. Vino and Vinagre are an one-person projects. Since I hadn’t have been much time to improve them, I decided to look for new blood, new maintainers. Perhaps this will be a hard task, since nobody seems to care much about these two GNOME modules.

Anyway, if you are interested, send me an email.

7º Brazilian GNOME Forum|7º Fórum GNOME

E aí gente? Quanto tempo hein?

É com um prazer imenso que anuncio que esse ano teremos mais uma edição do Fórum GNOME. É aquela época do ano onde reunimos GNOMErs de todos os lugares para nos divertir!

Eu disse divertir? Iapois! A gente reencontra amigos, conhece face-a-face amigos de internet, discute sobre GNOME, divulga-o pra um monte de gente. Isso não é diversão?

E quem sabe sobra um tempo pra outras diversões também! 🙂

Este ano o fórum vai acontecer em Natal, Rio Grande do Norte, nordestão do Brasil, junto com o Encontro Nordestino de Software Livre, ENSL. Vai fazer o que nos dias 5 e 6 de novembro? Tá de bobeira? Aproveita aí uma promoção aérea e vai pra Natal! Ou então faz como eu, vai de carro com a família!

Você pode conferir a grade do fórum diretamente no site do ENSL. Em breve você poderá ver também o resumo das palestras. O mini cv dos palestrantes também tá no site. Além dos brasucas, contamos com a presença ilustre de Frédéric Peters, um cara pau-pra-toda-obra no GNOME! Confira informações sobre ele lá na página de palestrantes.

Também vai acontecer no fórum a reunião anual do GNOME Brasil. Vamos conversar sobre a nossa comunidade, nossas atividades, nossas metas. Se você tem alguma sugestão, ou quer fazer parte dessa turma, ou quer apenas saber o que tá se passando, você é muito bem vindo! Apareça lá!

Ah, o GNOME 3, próxima versão do GNOME, a ser lançado em Abril será um tema de destaque nesse fórum. Se você quer ficar por dentro das novidades, ou até mesmo quer ajudar no seu desenvolvimento, não perca o fórum. Confira a programação!

Hello folks. It’s a pleasure to announce the 7th edition of the Brazilian GNOME Forum, that part of the year where we put together GNOMErs from all parts of Brazil to have fun!

This year the Forum will take place in Natal, a greatest city in Northeast Brazil, as part of the main event, ENSL – Northeast Free Software Conference, on 5 and 6th November.

This edition, besides the usual Brazilians, will have the presence of Frédéric Peters, a great hacker of the Release Team! Also, we will have the annual Brazilian meeting, where we, the Brazilian team discuss our activities, our community and our goals.

GNOME 3, the next version of GNOME will be widely discussed there. We will be discussing its news as well showing how to contribute in practice with its development.

Gostaria de agradecer a turma do ENSL e a GNOME Foundation, que tornarão o fórum possível! Você já fez sua doação à GNOME Foundation hoje? 🙂

Espero vocês lá! Abração!

Hopefully we are going to have a lot of fun there! 🙂

I would like to thank the ENSL team and the GNOME Foundation. They made the forum possible. Have you donated to GNOME today? 🙂


Late post about GUADEC… well, everybody is doing that, right? 🙂

Post atrasado sobre a GUADEC… mas todo mundo tá fazendo isso né? 🙂

So, all I wanted to say is that this GUADEC edition was terrific! Great people, great organization, great venue, everything was so great! It was the best GUADEC I ever attended.

Bem, eu só queria dizer que esta edição do GUADEC foi fantástica! Ótima organização, ótima localização, pessoas ótimas, tudo foi bem massa mesmo! Foi o melhor GUADEC que já fui.

Algumas notas aleatórias:

Some random notes:

  • FreeFA soccer match was amazing. Bastien and others complained because I was cheating by staying in an off-side position. Well, I made some goals and we won, that’s what matters, isn’t it? 😀O torneio de futebol FreeFA foi massa. Bastien e outras pessoas reclamaram porque eu trapaceei, ficando só na “banheira” (posição de impedimento). Bom, o que importa é que fiz alguns gols e ganhamos a partida né mesmo? 😀
  • Pizza of raw meat is not one of our favorites:Pizza de carne crua não é uma das nossas favoritas:
  • Definitely hackers do not know how to make a barbecue (actually we prefer just to eat, not to cook :)):Definitivamente hackers não sabem fazer churrasco (na verdade a gente prefere comer, não cozinhar :))
  • After the announcement that GNOME 3 was postponed to March 2011 (wise decision!), I’ve decided to not release Vinagre 2.32. Instead, I’ll release a 3.0 beta, which is already using 3.0 technologies and features RDP support.
  • Also, it will feature a new interface, more GNOME-ish brought to you by the famous Vinicius Depizzol.
  • After GUADEC (which was held in The Hague), I visited Amsterdam and London. I liked the Netherlands. Amsterdam is the new Sodom. London is great and quite expensive. Had a lunch with Lucas there.
  • My talk about GNOME in Brazil went fine. I hope to have shared my experience with other teams. Feel free to get in touch with me for more details.
  • Finally, thanks to GNOME Foundation for the sponsorship of my travel!
  • Depois que foi anunciado o adiamento do GNOME 3 para março de 2011 (sábia decisão!), decidi não lançar o Vinagre 2.32. Em vez disso, vou lançar o 3.0 beta, que usa tecnologia do GNOME 3 e vem com suporte ao protocolo RDP.
  • Ah, ele também virá com uma interface mais GNOMEzada, graças ao fantástico Vinicius Depizzol.
  • Depois da GUADEC (que aconteceu em Haia), visitei Amsterdã e Londres. Gostei da Holanda. Amsterdã é a nova Sodoma. Londres é ótima, mas bem carinha. Almoçei com Lucas lá.
  • Minha palestra sobre o GNOME Brasil rolou legal. Espero ter compartilhado minha experiência com outros grupos regionais.
  • Finalmente, meu obrigado à Fundação GNOME por patrocinar minha viagem!

I’m going to GUADEC!|GUADEC, aí vou eu!

Hello, folks. Thanks to GNOME Foundation, I’ll attend one more GUADEC edition, this time in the Netherlands!

Oi gente! Graças a Fundação GNOME estou indo mais uma vez para GUADEC – conferência anual dos GNOMErs! Desta vez vai ser na Holanda!

Hackers going to FreeFA soccer match!

Here are my answers to the meme:

1) Who are you and what do you do?

My name is Jonh Wendell, 30 years old, from Brazil. I work for a sugar factory as software developer. In my daily job I do nothing related to GNOME at all. In GNOME, I contribute by maintaining 2 modules, vino and vinagre, both related to remote access. Also, I do translations and I spread GNOME in my country.

2) How did you get into GNOME?

After some time using GNOME, and having developer skills, I wrote a patch, back in 2006, that fixed a bug in vino, the GNOME VNC server. Atfer that patch get committed, I went ahead writing others and others patches, until I got the maintainer hat for vino. After realizing how easy was to contribute to GNOME, I always give talks about that, inviting people to not be afraid of submitting patches to GNOME 😉

3) Why are you coming to GUADEC?

I’ll give a joint talk with Emily Chen about GNOME communities in Brazil and Asia. What’s the state of GNOME in our countries and what we are doing to increase our community.
I’ll be showing a little use case in Stormy’s GTD in GNOME lightning talks.
Also I’ll be hosting a BoF about the state of Remote Desktop stack in GNOME. It’s a great opportunity for us to share our ideas about the ongoing development of vino/vinagre. Also, we lack people taking care of this area in GNOME, so, if you are interested in contribute to GNOME, come up!
Of course, I’m looking forward to meet the amazing GNOME folks again and play some game…

4) In 1 sentence, describe what your most favorite recent GNOME project has been. (Doesn’t have to be yours!)

The whole GObject introspection work.

5) Will this be your first time visiting the Netherlands?

Yes, I’m looking forward to be there!

Este ano estarei com três atividades “formais” lá: Uma palestra junto com Emily Chen sobre o GNOME no Brasil/Ásia, uma palestra relâmpago no slot da Stormy sobre “Get things done” in GNOME, e finalmente uma sessão BoF sobre acesso remoto no GNOME.

Quanto às informais, bem, aí vem o tradicional jogo de futebol, campeonato de sorvete, festas com direito a jam sessions, e por aí vai… Vai ser muito bom encontrar toda a turma de novo!

Já que vou falar sobre GNOME Brasil lá, se você tem alguma sugestão, comentário, ou quer que eu leve algum assunto pra lá, entre em contato comigo!