Misunderstanding the Free Software Philosophy

This will probably be one of those controversial posts, but I really cannot just be silent about a behaviour that I am constantly seeing around me.

Since my childhood, I am fascinated by the power of the words. I always liked reading a lot, and despite not knowing the grammar rules (either in pt_BR or en_US, the former being my native language, the latter being the only idiom I can consider myself fluent in), I am deeply interested in what words (and their infinite meanings) can do to us. (If you can read in portuguese, and if you also like to study or admire in this subject, I strongly recommend a romance by José Saramago called “O Homem Duplicado”). So now, what I am seeing everywhere is that people are being as careless as ever with words, their meanings, and specially their implications.

The problem I am seeing, and it is a serious problem in my opinion, is the constant use of the term “free software” when “open source” should be used. This is obviously not a recent problem, and I really cannot recall when was the first time I noticed this happening. But maybe because I am much more involved with (real) free software movements now, I have the strong impression that this “confusion” is starting to grow out of control. So here I am, trying to convince some people to be a little more coherent.

When you create a group to talk about free software, or when you join a group whose goal is to promote free software ideas, you should really do that. First of all, you should understand what free software is about. It is not about open source, for starters. It is also a political movement, not only a technical one.

I was part of a group in my former university which had “Free Software” in its name. For a long time, I believed the group really was about free software, even after receiving e-mails with heavy negative critics about my opinions when I defended something related to the free software ideology (e.g., when I suggested that we should not have a Facebook page, which had been created for the group by one of its members). Well, when I really could not hide the truth from myself anymore, I packed my things and left the group (this was actually the start of a new free software group that I founded with other friends in Brazil).

I also like a lot to go to events. And not only because of the presentations, but mostly because I really like to talk to people. Brazilians are fortunately very warm and talkative, so events here are really a fertile soil for my social skills :-). However, even when the event has “free software” in its name and description, it is very hard to find someone who really understands the philosophy behind the term. And I’m not just talking about the attendees: the event staff is also usually ignorant (and prefer to remain like this)! I feel really depressed when I start to defend the (real) free software, and people start looking at me and saying “You’re radical.”. It’s like going in a “Debugger Conference” and feel ridicularized when you start talking about GDB! I cannot understand this…

But the worst part of all this is that newcomers are learning that “free software” is “Linux”, or something which is not free software. This is definitely not a good thing, because people should be aware that the world is not just about software development: there are serious issues, including privacy and freedom menaces by Facebook/Google/Apple/etc, which we should fight against. Free software is about that as well. Awareness should be raised, actions should be taken, and people should refuse those impositions.

So, to finish what I want to say, if you do not consider yourself a free software activist, please consider becoming one. And if, after giving it a thought, you decided that you really do not want to be a free software activist, then do not use the name “free software” in your event/group/whatever, unless you really intend to talk about it and not open source.. In other words, if you don’t want to help, please don’t spread confusion.


[ANÚNCIO] Criação do grupo LibrePlanet São Paulo!

Olá a todos!

Finalmente consegui um pouco de tempo na minha agenda, e resolvi escrever no blog para anunciar a criação do grupo LibrePlanet São Paulo!

O que é o LibrePlanet

O projeto LibrePlanet teve início em 2006, durante a reunião de membros da FSF (a Free Software Foundation). Ele foi criado para ajudar a organizar maneiras de levar o movimento de Software Livre ao conhecimento da população em geral.

Os grupos são organizados geograficamente, e cada um é responsável por definir metas e estratégias visando fomentar o Software Livre na região. É importante deixar claro: o objetivo é trabalhar em prol do Software Livre, e não do open source. Para saber mais a respeito da definição de Software Livre, recomendo que leia este artigo.

O surgimento do LibrePlanet São Paulo

Essa história é um pouco longa, mas vou tentar resumir :-).

Tudo começou quando eu, Ricardo Panaggio, Ivan S. Freitas e Raniere Gaia Silva começamos a trocar alguns e-mails sobre assuntos como privacidade, software livre, soluções e serviços livres, etc. Eu e o Panaggio já estávamos nos sentindo muito insatisfeitos com os rumos que um grupo local, teoricamente “pró software livre”, estava tomando (como quase tudo hoje em dia, o nome “software livre” está lá simplesmente porque ninguém se tocou de que devia ser “open source” ainda…). E essa insatisfação já vinha nos fazendo querer criar um novo grupo, fiel à ideologia do Software Livre, no qual pudéssemos dar nossas opiniões sem medo de sermos esmagados por uma maioria que não se importa com “essas coisas”.

Bem, começamos a conversar, e logo o Ivan e o Raniere deram sinais de que eles topariam participar do grupo, sem problemas. Portanto, o solo já estava fértil para novas idéias :-).

Um dia, eu acordei e vi na minha INBOX uma mensagem do Raniere dizendo que havia encontrado algo sobre um projeto interessante, o LibrePlanet, na Internet. Foi a faísca que faltava pra começar a movimentação! Recordei-me de que eu já havia conversado com o Matt Lee, também da FSF, sobre o LibrePlanet, e depois de uma rápida busca na wiki do projeto, vi que ainda não havia nenhum grupo brasileiro. Então, depois de alguma conversa interna, decidimos criar um grupo para o Estado de São Paulo.

Hoje, pouco mais de 2 semanas depois da criação, contamos com 10 membros cadastrados na Wiki, e aproximadamente 7 membros ativos no nosso canal de IRC. Também temos uma lista de discussão, e já estamos começando a conversar sobre possíveis projetos para 2013.

Como você pode fazer parte do grupo?

É simples! Siga os seguintes passos:

  1. Entre na nossa Wiki, e leia todas as informações presentes lá antes de qualquer coisa!
  2. Depois disso, efetue a criação de seu usuário na FSF, indo até este link de cadastro e preenchendo as informações. Repare que você não precisa tornar-se membro da FSF (os membros são pessoas que contribuem financeiramente com a Fundação), mas se você puder, iria ser bem legal :-).
  3. Ok, agora que você já possui um usuário, efetue o login na Wiki do LibrePlanet, e crie sua página pessoal lá. Para isso, vá até este link, clique no link Edit, e insira algumas informações sobre lá. Se quiser, utilize minha página pessoal como exemplo. É importante que você insira, no final de todo o conteúdo, a seguinte linha: {{user SP}}. Ele faz com que você passe a pertencer ao grupo LibrePlanet de São Paulo.
  4. Agora, é importante que você também efetue sua inscrição na nossa lista de discussão. Vá até esta página de inscrição e preencha as informações necessárias! Também recomendamos fortemente que você envie uma mensagem de apresentação para a lista. Nada formal, só para termos uma idéia do tamanho do grupo!
  5. Ufa, último passo! Se você utiliza IRC e frequenta a rede Freenode, entre no nosso canal: #lp-br-sp! É lá que a maior parte das discussões acontece, então seria muito legal se você também pudesse participar delas!

Acho que é isso :-). Se você ainda tiver alguma dúvida sobre qualquer assunto tratado neste post (objetivos do grupo, inscrição, etc), ou se quiser fazer algum comentário, sinta-se à vontade!

Saudações livres!


Relato da Apresentação sobre o GDB no SoLiSC 2012

Nesta última sexta-feira, dia 30/11/2012, estive presente na sétima edição do SoLiSC 2012, em Florianópolis, para apresentar uma palestra introdutória sobre o GDB. Este é um relato sobre minha particição no evento :-).

Impressões sobre o evento

Foi a primeira vez que fui ao SoLiSC. Já tive vontade de ir em anos anteriores, mas infelizmente sempre havia algo para atrapalhar. No entanto, nesse ano felizmente tudo correu bem, e inclusive tive uma palestra aceita! Ou seja, um ótimo motivo para visitar Floripa e rever o mar :-D.

Peguei um vôo saindo às 6h de Campinas, e cheguei lá às 7h10min. Estava bastante cansado, pois não havia dormido de quinta pra sexta, só que a ansiedade estava conseguindo me deixar ligado :-).

O evento aconteceu Universidade Estácio de Sá, que fica em São José. Cheguei por lá às 8h, e fui bem recebido pelo pessoal do evento. Já tentei me enturmar, e conheci algumas pessoas que também iam palestrar no evento. Como minha palestra estava marcada para começar às 14h, resolvi ficar batendo papo e de olho na grade de palestras.

Por coincidência (ou não!), acabei ficando na sala onde aconteceria o primeiro LibreOffice Hack Day no Brasil. Acabei ficando na sala o dia todo, ajudando o pessoal a resolver alguns problemas chatos com o firewall da Universidade, e depois com git. Foi uma experiência muito legal, nunca tinha participado de um Hack Day antes, e foi uma honra poder presenciar e ajudar no primeiro evento do tipo que o pessoal do LibreOffice fez no Brasil :-). Aliás, foi muito interessante conhecer um pouco mais sobre um projeto tão grande e complexo quanto o LibreOffice, e inclusive fiz um “jabá” sobre o GDB para eles :-).

No final, também conheci algumas pessoas muito interessadas em contribuir com projetos de software livre, o que é sempre bom! Isso me ajuda a ter mais motivação para continuar a fazer esse trabalho de divulgação. Você pode ler uma descrição mais detalhada sobre o LibreOffice Hack Day (inclusive com fotos) aqui.

Apresentação “GDB Crash Course”

Eu já estava esperando pouca gente na palestra, até porque falar sobre o GDB está ficando cada vez mais complicado… As pessoas em geral não sabem (e nem se interessam) pelo software, então é normal ficar meio “de escanteio” nesses eventos :-). Quem sabe um dia eu não escreva um post sobre isso?

Bem, mas mesmo com pouco público, creio que palestra correu bem. Dessa vez, meu amigo Edjunior não foi, então levei a palestra sozinho :-). Existem vantagens e desvantagens nisso, mas de modo geral acho que a palestra ficou um pouco mais rápida.

Adicionei alguns slides extras para falar sobre a Red Hat, e sobre o que estamos fazendo pelas comunidades de software livre por aí – não só na do GDB, mas também em muitas outras. Essa parte da apresentação realmente foi bacana, porque o orgulho de se trabalhar nessa empresa é grande!

Depois que terminei minha palestra e voltei à sala do LibreOffice Hack Day, alguns desenvolvedores que estavam por lá me perguntaram como foi, e disseram que tinham se arrependido de não ter ido… Sabe como é, preferiram ficar fazendo patches, então eu entendo :-P. Bem, pra não deixar ninguém insatisfeito, acabei fazendo uma segunda rodada da palestra dentro do Hack Day, e também foi muito bacana :-).

Várias pessoas me pediram os slides, então aqui estão eles:

Conclusão

Gostaria de agradecer especialmente à Eliane Domingos, ao David Jourdain e ao Olivier Hallot, todos membros da TDF e contribuidores do LibreOffice, pelos momentos prazerosos e pelas conversas divertidas que tivemos durante todo o evento!

Também gostaria de agradecer à organização do SoLiSC pela oportunidade de participar de um evento tão bacana! O Klaibson Ribeiro foi a pessoa com quem troquei alguns e-mails antes do evento, então um “muito obrigado” a ele também :-).

Nos vemos no próximo SoLiSC!


HEADS UP: Comment system is offline temporarily

Hi there. This little post is just a heads about an issue that I am facing with the comment system that I run. Unfortunately, you will not be able to post comments on the blog until, at least, next Wednesday (November 21).

For those of you wondering which comment system I use, it is called Juvia. Due to privacy concerns, I chose not to use anything like Disqus because it tracks you and your comments (read their privacy policy if you want more details). On the other hand, Juvia runs on my private personal server, and does not collect any kind of personal information when you make a comment. The cons of this approach is that when my personal server is down (like now), the blog doesn’t have comments. But that’s a minor price to pay for the respect of privacy, I think.

Anyway, I hope to have the comments back online next week. Until there, I plan to continue making posts here, so save your comments for some time!

Thanks!


GDB and SystemTap Probes -- part 3

Hi everybody :-).

I finally got some time to finish this series of posts, and I hope you like the overall result. For those of you who are reading this blog for the first time, you can access the first post here, and the second here.

My goal with this third post is to talk a little bit about how you can use the SDT probes with tracepoints inside GDB. Maybe this particular feature will not be so helpful to you, but I recommend reading the post either way. I will also give a brief explanation about how the SDT probes are laid out inside the binary. So, let’s start!

Complementary information

In my last post, I forgot to mention that the SDT probe support present on older versions of Fedora GDB is not exactly as the way I described here. This is because Fedora GDB adopted this feature much earlier than upstream GDB itself, so while this has a great positive aspect in terms of how the distro’s philosophy works (i.e., Fedora contains leading-edge features, so if you want to know how to FLOSS community will be in a few months, use it!), it also has the downside of delivering older/different versions of features in older Fedoras. But of course, this SDT feature will be fully available on Fedora 18, to be announced soon.

My suggestion is that if you use a not-so-recent Fedora (like Fedora 16, 15, etc), please upgrade it to the last version, or compile your own version of GDB yourself (it’s not that hard, I will make a post about it in the next days/weeks!).

With that said, let’s move on to our main topic here.

SDT Probes and Tracepoint

Before anything else, let me explain what a tracepoint is. Think of it as a breakpoint which doesn’t stop the program’s execution when it hits. In fact, it’s a bit more than that: you can define actions associated with a tracepoint, and those actions will be performed when the tracepoint is hit. Neat, huh? :-)

There is a nice description of what a tracepoint in the GDB documentation, I recommend you give it a reading to understand the concept.

Ok, so now we have to learn how to put tracepoints in our code, and how to define actions for them. But before that, let’s remember our example program:

#include <sys/sdt.h>

int
main (int argc, char *argv[])
{
  int a = 10;

  STAP_PROBE1 (test_program, my_probe, a);

  return 0;
}

Very simple, isn’t it? Ok, to the tracepoints now, my friends.

Using tracepoints inside GDB

In order to properly use tracepoints inside GDB, you will need to use gdbserver, a tiny version of GDB suitable for debugging programs remotely, over the net or serial line. In short, this is because GDB cannot put tracepoints on a program running directly under it, so we have to run it inside gdbserver and then connect GDB to it.

Running our program inside gdbserver

In our case, we will just start gdbserver in our machine, order it to listen to some high port, and connect to it through localhost, so there will be no need to have access to another computer or device.

First of all, make sure you have gdbserver installed. If you use Fedora, the package name you will have to install is gdb-gdbserver. If you have it installed, you can do:

$ gdbserver :3001 ./test_program
Process ./test_program created; pid = 17793
Listening on port 3001

The second argument passed to gdbserver instructs it to listen on the port 3001 of your loopback interface, a.k.a. localhost.

You will notice that gdbserver will stay there indefinitely, waiting for new connections to arrive. Don’t worry, we will connect to it soon!

Connecting an instance of GDB to gdbserver

Now, go to another terminal and start GDB with our program:

$ gdb ./test_program
...
(gdb) target remote :3001
Remote debugging using :3001
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2

The command you have to use inside GDB is target remote. It takes as an argument the host and the port to which you want to connect. In our case, we just want it to connect to localhost, port 3001. If you saw an output like the above, great, things are working for you (don’t pay attention to the messages about glibc debug information). If you didn’t see it, please check to see if you’re connecting to the right port, and if no other service is using it.

Ok, so now it is time to start our trace experiment!

Creating the tracepoints

Every command should be issued on GDB, not on gdbserver!

In your GDB prompt, put a tracepoint in the probe named my_probe:

(gdb) trace -probe-stap my_probe
Tracepoint 1 at 0x4005a9

As you can see, the trace command takes exactly the same arguments as the break command. Thus, you need to use the -probe-stap modified in order to instruct GDB to put the tracepoint in the probe.

And now, let’s define the actions associated with this tracepoint. To do that, we use the actions command, which is an interactive command inside GDB. It takes some specific keywords, and if you want to learn more about it, please take a look at this link. For this example, we will use only the collect keyword, which tells GDB to… hm… collect something :-). In our case, it will collect the probe’s first argument, or $_probe_arg0, as you may remember.

(gdb) actions 
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $_probe_arg0
>end
(gdb)

Simple as that. Finally, we have to define a breakpoint in the last instruction of our program, because it is necessary to keep it running on gdbserver in order to examine the tracepoints later. If we didn’t put this breakpoint, our program would finish and gdbserver would not be able to provide information about what happened with our tracepoints. In our case, we will simply put a breakpoint on line 10, i.e., on the return 0;:

Running the trace experiment

Ok, time to run our trace experiment. First, we must issue a tstart to tell GDB to start monitoring the tracepoints. And then, we can continue our program normally.

(gdb) tstart 
(gdb) continue
Continuing.

Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
10        return 0;
(gdb) tstop
(gdb)

Remember, GDB is not going to stop your program, because tracepoints are designed to not interfere with the execution of it. Also notice that we have also stopped the trace experiment after the breakpoint hit, by using the tstop command.

Now, we will be able to examine what the tracepoint has collected. First, we will the tfind command to make sure the tracepoint has hit, and then we can inspect what we ordered it to collect:

(gdb) tfind start
Found trace frame 0, tracepoint 1
8         STAP_PROBE1 (test_program, my_probe, a);
(gdb) p $_probe_arg0
$1 = 10

And it works! Notice that we are printing the probe argument using the same notation as with breakpoints, even though we are not exactly executing the STAP_PROBE1 instruction. What does it mean? Well, with the tfind start command we tell GDB to actually use the trace frame collected during the program’s execution, which, in this case, is the probe argument. If you know GDB, think of it as if we were using the frame command to jump back to a specific frame, where we would have access to its state.

This is a very simple example of how to use the SDT probe support in GDB with tracepoints. There is much more you can do, but I hope I could explain the basics so that you can start playing with this feature.

How the SDT probe is laid out in the binary

You might be interested in learning how the probes are created inside the binary. Other than reading the source code of /usr/include/sys/sdt.h, which is the heart of the whole feature, I also recommend this page, which explains in detail what’s going on under the hood. I also recommend that you study a little about how the ELF format works, specifically about notes in the ELF file.

Conclusion

After this series of blog posts, I expect that you will now be able to use the not-so-new feature of SDT probe support on GDB. Of course, if you find some bug while using this, please feel free to report it using our bugzilla. And if you have some question, use the comment system below and I will answer ASAP :-).

See ya, and thanks for reading!