Number of shlibs</th>	128</th>	256</th>	512</th>	1024</th>	2048</th>	4096</th></tr></thead>
Old interface</td>	> 0</td>	> 1</td>	> 4</td>	> 12</td>	> 47</td>	> 185</td></tr>
New interface</td>	> 0</td>	> 0</td>	> 2</td>	> 4</td>	> 10</td>	> 36</td></tr> </tbody></table> Impressive, isn't it?</p> Conclusion</h2> This is one the things I like most in Free Software projects: the possibility of extending and improving things by using what others did before. When I hacked GDB to implement the integration between itself and SystemTap, I had absolutely no idea that this could be used for improving the interface between the linker and the debugger (though I am almost sure that Tom was already thinking ahead!). And I can say it is a pleasure and I feel proud when I see such things happening. It just makes me feel more and more certain that Free Software is the way to go :-).</p> So long, Ambassadors... 2013-05-16T00:00:00-05:00 No, I am not leaving the Fedora Project</strong>, I am just leaving (or taking a break, depending on how you look) its Ambassadors</a> program. I am still the co-maintainer of the GDB</a> package, and will contribute to the development of the distribution since it is also my job. However, after a few months trying to become more involved with the Fedora community (specifically with the Brazilian/LATAM community), I became so disappointed that the only logical action for me now is to step back.</p> My brief history</h2> I joined the Ambassadors program on October, 2012. After having used the system heavily for almost 3 years, I decided that it was about time to pay something back to the community too. Since I live in Brazil, I joined the the brazilian team of Ambassadors (which meant that I was also part of the Latin America team). Thanks to my friend Leonardo Vaz (from Red Hat), I talked to Daniel Bruno who then became responsible for "mentoring" me.</p> The brazilian community was (and still is) very inactive (compared to others, and to itself a few years ago), but I was very excited and decided to try to revive it. And the first task that I assigned myself was to regain control of the brazilian</a> and LATAM</a> domains.</p> The domains</h2> Alejandro Perez, a very nice guy from Panamá responsible for LATAM's money, asked me to talk to Rodrigo Padula, an inactive Fedora Ambassador from Brazil, about the domains. Padula was a very active member of the brazilian community since 2006 if I'm not mistaken, but due to reasons beyond my knowledge is inactive in the Fedora community for quite some time now (he's still very active in the Mozilla community, however). And he owns both domains.</p> Alejandro was worried because the LATAM domain had suffered some sort of outage during some days, which is obviously bad for the project. He was also concerned (and I totally agreed with him on this) because those domains shouldn't be owned by a person (rather, it should be registered on behalf of the Fedora Project or, ultimately, Red Hat), specially if this person is now inactive.</p> To make a long story short, I spent more than 1 month doing the indirection and talking to both guys about this issue. Padula initially said he could transfer the domains without problem, but then changed his mind and said he wouldn't do it. On the other side, Alejandro was getting upset because Padula did not want to make the transfer, and the LATAM community was pressuring him. In the end, I totally gave up, and the LATAM guys registered yet another domain</a>, but right now are still using the old domain. Yes, a mess.</p> Working with LATAM</h2> Anyway, after this episode, and after witnessing how active the LATAM community was in contrast with the brazilian community, I decided to work directly with them. I wanted to do something, and I was eager to start working as a real ambassador, spreading the word about Fedora everywhere. And my friends from Panamá, Argentina, México, Venezuela, etc., seemed the right people to work with.</p> So I started attending the weekly meetings on `#fedora-latam</code>, at Freenode, every Wednesday night. It is a well-organized meeting (run by Alejandro), whose main goal is to vote tickets from LATAM ambassadors (including brazilians). Tickets are basically requests made through aTrac</a> instance</a>, and are used to ask for swags, media, sponsorship for travels, etc. The Fedora Project has a budget, and the LATAM region gets a fraction of this budget for annual expenses, so our job as ambassadors was to vote those tickets and decide whether they deserve to be approved or not, according to some rules inside the project</a>.</p>` `Keep in mind: we are dealing with money here</strong>. It's not yours nor mine, but it's still money that should be used to promote a project that embraces open source initiatives (unfortunately, I cannot say Fedora is Free Software, but that is a topic for another post).</p>` So, after some weeks working with the LATAM guys, I became the default owner of Trac tickets from brazilian ambassadors. And a few more weeks down the road Alejandro asked me to produce media (Fedora DVDs) and be resposible for distributing them in Brazil. I spent a lot of time ordering the medias (I had to travel to São Paulo in order to make sure everything was OK), and every time an ambassador requests Fedora DVDs I go through a series of steps</a> (link in pt_br, portugues) to guarantee that she gets her media and I get my reimbursement.</p> `I also like to give talks and presentations about the project, and so I've attended some events (or organized them) just to be able to do that. I have posted some reports about them in this blog, you can find them in the archives (if you can read in pt_BR).</p>` `So, enough of self-promotion: why I am leaving the ambassador's program after all?</p>` Disappointment</h2> A few things started to happen:</p> During the weekly LATAM meetings, it bothered me to see that the tickets were being approved without any kind of serious discussion. Everyone (including myself!) was just giving "+1" to everything!</li> FISL</a>, the biggest open source (no, it is not about Free Software</strong>!!) event in LATAM, is going to happen on July. Suddenly, new brazilian ambassadors were popping out of nowhere, and inactive ambassadors were pretending to do something.</li> As a consequence, we received 9 sponsorship requests in our Trac. Some from active people, some not.</li> </ul> Something that I should have noticed before became crystal clear to me: some people are there just to take advantages for their own. They are not interested in the project, in the philosophy (yes, you can laugh at my face now...), in the promotion of the ideals, etc. They just want free lunch. And they get it...</p> During the last meeting I attended, two weeks ago, we were going to vote the FISL tickets. A few days before the meeting, I sent the following message to the LATAM Ambassadors list:</p> Hi there,</p> This message is just to let you know that we will be discussing several FISL tickets in our next meeting, May 8th. You can take a look at the meeting agenda by going to:</p> https://fedorahosted.org/fedora-latam/report/9</a></p> I would like to ask everyone to read the requests and make your decision based on merits</em>, please. In my opinion, only active ambassadors should receive the honor of being sponsored by Fedora to go to FISL14. Let's not spend money unnecessarily, so try to avoid the "+1" wave when voting for the tickets.</p> Thanks a lot,</p> --Sergio.</p> </blockquote> As I said, some tickets were filed by inactive ambassadors, and I wanted us to at least discuss the matter with him/her, showing that we were not happy with his/her conduct. It is one thing when you have personal problems and have to step away from the project for a while; it is another different thing when you disappear without saying a word and then comes back to request sponsorship for travel.</p> We began the meeting by discussing tickets filed by active members, and approving them without thinking much about it. However, eventually we got to the problematic ones. There is this specific guy, whose name I will not mention here, who was very absent since I started in the project, and I felt the need to point that out. I told him I hadn't seen him in quite a while, and explained that there were many ambassadors doing things for Fedora. He's a long term contributor to the project, as he himself told me in a not-so-friendly tone during the meeting. But that was not the subject of the discussion, and while he kept saying how hard he worked for the project in the last 5 years, or how much he's done for this or that, I remained silent and began to think: what the hell am I doing? Why am I wasting my time in a Wednesday night to convince a group that someone maybe doesn't deserve the credit he's asking for?</em> Well, the only reasonable answer was: because I feel it is the right thing to do.</em> But nobody said a word during this discussion, and I started to feel something else. I felt that people were not interested</strong> in evaluating how much this guy (or anybody else, for that matter) really did for the project! And the feeling was corroborated when someone else said: "Hey, let's just approve the ticket now, we can continue the discussion later</em>". WHAT????</strong></em>. Let me see if I get it: we are here to discuss, reach a consensus, and vote. You want to approve, maybe discuss, fuck the consensus. Well...</p> I left before the end of the meeting, but I still managed to see this behaviour explained by some people: there was enough money to approve all tickets, so the meeting was just a formality needed to explain the expenses later. I was at least fully convinced that I did not belong there.</p> Not my place</h2> If you are part of a team and you disagree with its members, I believe you have two choices most of the time: you can either (a) discuss with them, try to understand their reasons for being different, try to explain yours, see what you can do to overcome this, or (b) leave it. Sometimes I choose one, sometimes another. This is the time for (b). I don't want to spend more time and energy into something that doesn't work the way I think it should. I don't feel motivated to fight against the tide, because I am not so strong and the tide keeps getting bigger and bigger. And I also don't want to stop people from doing what they think is right, honestly. In the end of the day, I still want to believe that everyone has a conscience and knows what's correct...</p> But I am not going to cross my arms and sit. Some friends and I decided to create our own group, called LibrePlanet São Paulo</a> (link in pt_br, portugues), and focus on the real important thing: Free Software</a>. I really hope we can make a difference with our local community, and we have started with the right foot already: we organized the Document Freedom Day in our city this year!</p> As for Fedora, as I said, I still intend to continue contributing to it. I'm still subscribed to the fedora-devel mailing list, and I still follow the project's decisions, partly because it is part of my job, partly because I strongly believe you have to give back what you take for free -- as in freedom -- from the community. I also have some DVDs and I intend to distribute them. But my time as a Fedora Ambassador is coming to an end. It was a good experience, I met good people, had a great time doing talks and presentations, and most of all, did what I felt right at the right time.</p> So, as Douglas Adams said, "...thanks for all the fish!".</p> Document Freedom Day 2013 in Campinas -- São Paulo -- Brazil 2013-04-12T00:00:00-05:00 Hi, there! This is the report of the Document Freedom Day</a> event that took place in Campinas</a>, São Paulo state</a>, Brazil</a>. I will talk a little bit about how we (keep reading to know who "we" are!) organized it, and the conclusions that can be drawn to help for the next edition.</p> Organization</h2> The DFD (or D</em>ocument F</em>reedom D</em>ay) 2013 in Campinas was organized by the LibrePlanet São Paulo</a> (link in pt_BR) group. If you follow this blog, and if you speak portuguese, then you have probably read the announcement of the group</a> that I made last year. If you haven't: LibrePlanet São Paulo is part of the LibrePlanet</a> project (sponsored by the Free Software Foundation</a>), and "... is a global network of free software activists and teams working together to help further the ideals of software freedom by advocating and contributing to free software."</em>.</p> The DFD 2013 was an important event to us because it was the first serious event that we organized as a group. Despite some mistakes and errors, I believe we did fine and were able to learn some great lessons for the next events that we plan to do. By the way, if you want to see the official page which we used to promote the event (and organize it too), take a look here</a>. The page is in pt_br, portugues.</p> Basically, we should have: (a)</em> focused more on defining the venue as soon as possible, because that would have made it possible to (b)</em> start sending announcements about the event earlier. We also should have contacted the Document Freedom organization and asked swags and banners earlier, because when we did it was too late for the shipment to arrive in time. And last but not least, we should really have taken pictures!! Unfortunately, I have absolutely no pictures to post here, so you will have to believe just in the words I write...</p> But well, nothing is perfect, and hey, the event happened</strong>!. So let's talk it :-).</p> The Event</h2> DFD 2013 occurred on Wednesday, March 27th. After some discussion, we decided to schedule the event from 13h (1 p.m.) to 17h (5 p.m.), with 4 presentations of 50 minutes each, approximately. The venue chosen was CCUEC</a>, the Center of Computing at the University of Campinas, UNICAMP</a>. This center has some great people working on it who are involved with Free Software since the beginning of the movement, particularly Rubens Queiroz de Almeida</a>, a very nice guy (very famous in the Brazilian Free Software scene) who helped us a lot</strong> with the organization of this event.</p> We understand that doing the event on a Wednesday afternoon was something that made it very hard for most people to attend, and that is probably the main reason for the low attendance: only 8 people in the audience. I have to say I was a little frustrated in the beginning, but hey, what really matters is that we spread the word about Free Software to 8 brave souls there, who will hopefully spread the word again to more people, and so on :-). So, it was time for the show to begin!</p> Our schedule was (presentation titles translated):</p> "What is Free Software?</strong>", by me</li> "Free Documents or the End of the World</strong>", by Rubens Queiroz de Almeida</li> "HTML5: all the faces of the new standard</strong>", by Ricardo Panaggio</li> "EPUB3: The book in the XXI century</strong>", by Raniere Silva</li> </ol> So my presentation was scheduled to be the first one, and I really liked it (surprise!). It was virtually the first time I gave a "philosophical" talk, and a very important one: a general presentation about Free Software, its history, the present, and a little bit of the future. In my opinion, what I liked about my talk is that I focused less on the "freedom" part, and more on the "respect" part of the philosophy. This is something I did because I wanted to use a different argument that was on my head for a long time: that the main thing behing the Free Software is the respect towards others, and only with that one can achieve freedom.</p> I watched Rubens too, who gave an excelent presentation about why we need free documents and standards. Rubens is very talkative and warm, which makes the audience feel relaxed. People liked his presentation a lot, from what I noticed.</p> Unfortunately, Ricardo Panaggio had a problem with his computer before his presentation, so we decided to switch: Raniere Silva would take his place as the third presenter, while Ricardo tried to fix the problem. I helped him with his problems, and because of this I was unable to watch Raniere's talk. In the end, we could not solve Ricardo's problem and he decided to give his presentation without any slides. In my opinion, he managed to catch everyone's attention (also because HTML5 is such a hot topic today), so I guess the missing slides were not so important after all!</p> At 17h o'clock, we declared DFD 2013 finished. I still had time to distribute some Free Software stickers (from FSF), and talk a little with two or three people there, who were satisfied with the presentations! It made my day, of course :-). And just because of that I now feel motivated to organized another DFD next year!</p> Acknowledgements</h2> I would like to thank Rubens Queiroz for helping with the promotion, the location, and the presentation during the event. DFD 2013 would have been impossible without his help. Thanks, Rubens!</p> The LibrePlanet São Paulo team, specially Ricardo Panaggio, were also deeply involved with me in the organization. And I hope we manage to make a bigger event next year!</p> Finally, I would like to thank everyone who attended the event, even for watch only one talk. Your presence there was really, really</strong> important to all of us. See you all next year!</p> Relato dos Install Fests na UNESP de Rio Claro/SP e na UNICAMP/SP 2013-04-01T00:00:00-05:00 E... Aqui estamos (estou?) com mais um relato sobre duas atividades envolvendo o Projeto Fedora</a>! Ele contempla, respectivamente, os Install Fests ocorridos na UNESP de Rio Claro/SP</a> e na UNICAMP</a>. Foram atividades que envolveram diversas pessoas, tiveram vitórias e derrotas, alegrias e tristezas, mas acima de tudo um sentimento de impotência (principalmente no Install Fest ocorrido na UNICAMP) em relação às novas "tecnologias" de boot, principalemente ao Secure Boot</a>.</p> Install Fest: missão UNESP de Rio Claro/SP</h2> Este foi o Install Fest mais tranquilo. Ele começou a ser organizado logo depois da minha participação na Semana da Computação da UNESP de Rio Claro</a>, e a intenção inicial era realizá-lo no dia da matrícula dos alunos ingressantes na Universidade. No final das contas, decidimos postergar a data, e isso foi uma boa escolha.</p> O Install Fest aconteceu no dia 06 de março de 2013, em um auditório da Biblioteca do campus, e começou com uma palestra minha sobre o Projeto Fedora. Foi basicamente a mesma palestra que eu havia apresentado na Semana da Computação, mas de uma maneira mais sucinta porque tínhamos pouco tempo. Creio que a palestra foi bem recebida, porque o público demonstrou interesse em contribuir com o Projeto Fedora depois que eu expliquei os meios para isso :-). Além disso, apesar do número pequeno de pessoas (aproximadamente 12 participantes), todos estavam bastante interessados no conteúdo, o que é uma motivação extra!</p> Bem, após a palestra era hora de começar a instalar os sistemas. Levei vários DVDs do Fedora, em basicamente 2 versões: LiveDVDs, que permitem o boot e a utilização de um sistema Fedora sem a necessidade de instalar nada na máquina, e InstallDVDs, que não oferecem a opção de "experimentar" o sistema, mas já possuem todos os pacotes necessários para fazer uma instalação completa. Expliquei a todos os presentes algumas regras básicas de todo Install Fest: é preciso reparticionar o disco rígido caso se queira manter o Microsoft (R) Windows (R), quem organiza o Install Fest não pode assumir responsabilidade por nenhuma falha na instalação (apesar de elas serem raras), e também não pode assumir responsabilidade caso o usuário torne-se viciado no GNU/Linux :-). Dito isso, começamos a colocar as mãos na GNU/massa.</p> O primeiro desafio (e, até então, único!) dos Install Fests recentes é imposto pelos próprios fabricantes de notebooks. Um disco rígido que ainda utilize MBR</a> (a maioria) suporta apenas 4 partições primárias. Antigamente, os fabricantes criavam apenas uma partição para o Microsoft (R) Windows (R), e às vezes chegavam a criar outra partição de "recuperação", mas paravam por aí. Atualmente, não é raro encontrar computadores com 4 partições primárias já criadas. Eu inclusive já cheguei a ver notebooks com discos de 1 TB com uma partição primária de pouco mais de 1 MB! É uma prática totalmente absurda, e a meu ver é feita com má-fé, visando dificultar a instalação de outros sistemas operacionais. Além disso, pra piorar ainda mais, alguns fabricantes (HP me vem à cabeça, mas existem outros) dão um jeito de invalidar</strong> a garantia caso o esquema de particionamento seja alterado!!!</p> Felizmente, vários computadores no Install Fest possuíam apenas 3 partições (ou até menos!), e aqueles que possuíam 4 partições ou usavam um outro boot sector</em> (chamado GPT</a>), ou já estavam fora da garantia do fabricante e podiam ter seus esquemas de particionamento alterados. O próprio Microsoft (R) Windows (R), a partir da versão 7 (se não me engano), oferece uma ferramenta específica para redimensionar e reparticionar o disco, portanto essa primeira etapa foi concluída com sucesso em todas as máquinas (por favor, se você participou do Install Fest e se lembra de alguma máquina na qual não foi possível efetuar o reparticionamento, por favor contate-me <about> para que eu corrija o post!).</p> Depois de reparticionar, era hora de começar a instalação. Quase todos preferiram utilizar o InstallDVD, porque a instalação pela internet iria demorar muito. Após o boot, deparamo-nos com a interface do instalador do Fedora 18. Depois de ter lido diversas críticas sobre ele, pude finalmente confirmar que, infelizmente, quase todas condizem. Confesso que fiquei confuso no início, principalmente na tela de particionamento e seleção de disco, que não é nem um pouco intuitiva. Sei que o instalador foi reescrito, e que ele foi um dos principais motivos do atraso no lançamento do Fedora 18, então espero muito que as melhorias para o Fedora 19 contemplem, principalmente, essa parte de interface com o usuário. Após apanhar um pouco, acabei me acostumando com ele e as outras instalações foram mais tranquilas.</p> Conforme as instalações foram acabando, os sistemas começaram a ser configurados. Se minha memória não falha, todos optaram por instalar o GNOME 3, que é o desktop padrão do Fedora 18. Eu particularmente não gosto dele, e também tive algumas dificuldades (principalmente ao tentar encontrar modos de alterar opções mais avançadas), mas algumas pessoas gostaram do visual.</p> No final, esqueci de contar quantas máquinas foram instaladas, mas creio que chegamos perto de 11. Todas as instalações foram bem sucedidas, até onde minha memória alcança :-). E novamente eu fiquei bastante satisfeito com minha ida à UNESP de Rio Claro!</p> Entretanto, nuvens negras estavam se aproximando, e minha alegria duraria pouco...</p> Install Fest: missão UNICAMP</h2> Há alguns anos começaram a surgir notícias sobre um novo sistema que substituiria a BIOS</a>, permitindo muito mais flexibilidade durante o boot e inclusive adicionando camadas de segurança que protegeriam o usuário de vírus e outras ameaças. Esse sistema chama-se UEFI</a> (e uma das tais "camadas de segurança" chama-se Secure Boot</a>), e no ano passado ele ganhou muita notoriedade porque a Microsoft (R) anunciou que seu então novo sistema, o Windows (R) 8, só poderia ser utilizado em máquinas com UEFI</a>. Isso causou uma corrida dos fabricantes de computador para adaptar-se a esse novo modelo (e ganhar o famigerado selo de compatibilidade da Microsoft (R)), e gerou incoformismo em boa parte das comunidades envolvidas com Software Livre e/ou Open Source.</p> Resumindo, o grande problema desse novo esquema é a necessidade de uma chave criptográfica assinada por uma autoridade certificadora para que o sistema operacional seja iniciado. Essa é a segurança que o Secure Boot</a> provê, e o único jeito de obter uma chave assinada é... (tambores)... pagando à Microsoft (R)!</p> Até onde eu sei, o Microsoft (R) Windows (R) 8 não funciona</strong> caso o Secure Boot</a> esteja desabilitado (um meio perfeitamente válido de instalar uma distribuição GNU/Linux que não possui a tal chave criptográfica), então a distribuição é obrigada a compactuar com esse esquema caso queira oferecer a opção de dual-boot ao usuário. E atualmente, as duas únicas distribuições que oferecem isso são o Fedora e o Ubuntu.</p> Bem, depois dessa sucinta explicação, começa aqui meu relato sobre o que aconteceu no Install Fest. No dia 13 de março de 2013, quarta-feira, nos reunimos no Instituto de Computação</a> da UNICAMP para realizarmos a instalação de distribuições GNU/Linux. Novamente, eu levei vários DVDs do Fedora para serem utilizados pelos alunos ingressantes nos cursos de Ciência e Engenharia de Computação. Dessa vez não houve palestra introdutória sobre o Projeto Fedora, mas eu resolvi pegar 10 minutos e explicar as "regras" de um Install Fest. Também comentei sobre a má prática que algumas fabricantes de notebooks têm quando decidem entregar um disco rígido todo particionado e sem a possibilidade de adição de novas partições primárias. Dito isso, começamos a instalar.</p> Infelizmente, devido a diversos fatores como inexperiência, tempo curto para organização do evento, e erro na estimativa de quantas pessoas iriam ao evento, acabamos ficando com muita gente pra instalar e pouca gente pra ajudar. Não chegamos a fazer uma contagem oficial, mas eu suponho que pelo menos 20 pessoas estavam na sala querendo instalar o Fedora. E a grande maioria delas estava com notebooks novos, com Microsoft (R) Windows (R) 8, i.e., com UEFI e Secure Boot habilitados.</p> Conforme íamos reparticionando os discos e bootando os DVDs do Fedora, começamos a perceber que havia algo errado. Depois de terminar a instalação em algumas máquinas, notávamos que o sistema não iniciava. O que tínhamos que fazer, em alguns casos, era desabilitar o Secure Boot (mesmo assim, sem sucesso em alguns casos). E depois disso, o Fedora finalmente era iniciado, mas o Microsoft (R) Windows (R) 8 não aparecia na lista de sistemas operacionais do GRUB! Ou seja, era impossível fazer com que os dois sistemas convivessem na mesma máquina.</p> Tivemos alguns casos um pouco mais graves, mas que no fim foram resolvidos. E antes que você me pergunte qual foi a solução, eu respondo: reabilitamos o Secure Boot, e praticamente desfizemos a instalação do Fedora. Ou seja, a esmagadora maioria dos alunos presentes no Install Fest voltou pra casa com uma máquina sem Fedora ou qualquer outra distro GNU/Linux. Eu pessoalmente vi apenas 2 instalações bem sucedidas, apesar de que depois do Install Fest fiquei sabendo de mais.</p> Saí do evento bastante chateado, achando que a culpa havia sido nossa, e que os alunos nunca mais iriam querer instalar GNU/Linux nas suas máquinas. Mas depois de um tempo, coloquei as idéias em ordem e resolvi escrever este post. Não estou eximindo ninguém da culpa, creio que devíamos ter planejado o Install Fest um pouco melhor, e com certeza aprendemos com os erros que cometemos. Mas acho muito importante apontar alguns dedos</strong> e dizer o que realmente aconteceu.</p> Conclusões</h2> A conclusão principal não poderia ser outra. É preciso tomar muito cuidado com essas novas tecnologias de boot</strong>. Quando for comprar uma máquina nova, é preciso prestar muita</strong> atenção a isso, pois essas novas tecnologias nada mais são do que armadilhas para tirar a sua liberdade de escolher o que quer executar na sua máquina. É preciso lutar contra essas imposições que as empresas fazem (não seja inocente pensando que é só a Microsoft (R) que está por trás disso...), e é preciso tomar conta da sua liberdade. Se quiser demonstrar ainda mais seu apoio contra essas imposições (e entender mais do porquê delas existirem), clique aqui e leia a página da Free Software Foundation sobre o assunto (e assine a petição também!)</a>.</p> Conclusões secundárias: um Install Fest (ou qualquer evento, na verdade) precisa ser organizado com antecedência, e precisa ter bastante gente disposta a ajudar nas instalações. Só assim as coisas fluem.</p> Agradecimentos</h2> Não posso deixar de agradecer o Ricardo Panaggio</a> por me ajudar indo até a UNESP de Rio Claro comigo! Ele também ajudou bastante no Install Fest da UNICAMP.</p> Também gostaria de agradecer ao Marcel Godoy e ao Centro Acadêmico da Computação da UNESP de Rio Claro pela organização e divulgação do Install Fest lá. Muito obrigado!</p> O Install Fest da UNICAMP só foi possível com a ajuda do Grupo Pró-Software Livre</a> da UNICAMP, em especial ao Gabriel Krisman. O Ivan S. Freitas</a> e o Raniere Gaia Silva</a> também ajudaram no apoio logístico do Install Fest.</p> Por fim, gostaria de agradecer à comunidade Fedora pelo apoio com os DVDs. Obrigado a todos!</p> Misunderstanding the Free Software Philosophy 2012-12-17T00:00:00-05:00 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.</p> 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</em>"). So now, what I am seeing everywhere is that people are being as careless as ever with words, their meanings, and specially their implications.</p> The problem I am seeing, and it is a serious problem in my opinion, is the constant use of the term "free software</strong>" when "open source</strong>" 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.</p> 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</strong>. First of all, you should understand what free software is about</a>. It is not about</strong> open source, for starters. It is also a political movement, not only a technical one.</p> 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).</p> 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</strong> 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...</p> But the worst part of all this is that newcomers are learning that "free software" is "Linux", or something which is not</strong> 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.</p> 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</strong>, 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.</p> [ANÚNCIO] Criação do grupo LibrePlanet São Paulo! 2012-12-15T00:00:00-05:00 Olá a todos!</p> 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</a>!</p> O que é o LibrePlanet</h2> O projeto LibrePlanet</a> teve início em 2006, durante a reunião de membros da FSF</a> (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.</p> 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</strong>, e não</strong> do open source. Para saber mais a respeito da definição de Software Livre, recomendo que leia este artigo</a>.</p> O surgimento do LibrePlanet São Paulo</h2> Essa história é um pouco longa, mas vou tentar resumir :-).</p> Tudo começou quando eu, Ricardo Panaggio</a>, Ivan S. Freitas</a> e Raniere Gaia Silva</a> 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".</p> 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 :-).</p> 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</a>, 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.</p> 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.</p> Como você pode fazer parte do grupo?</h2> É simples! Siga os seguintes passos:</p> Entre na nossa Wiki</a>, e leia todas as informações presentes lá antes de qualquer coisa!</li> Depois disso, efetue a criação de seu usuário na FSF, indo até este link de cadastro</a> e preenchendo as informações. Repare que você não</strong> 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 :-).</li> 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</a>, clique no link Edit</strong>, e insira algumas informações sobre lá. Se quiser, utilize minha página pessoal</a> como exemplo. É importante que você insira, no final de todo o conteúdo, a seguinte linha: {% raw %}{{user SP}}{% endraw %}</code>. Ele faz com que você passe a pertencer ao grupo LibrePlanet de São Paulo.</li> Agora, é importante que você também efetue sua inscrição na nossa lista de discussão. Vá até esta página de inscrição</a> 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!</li> Ufa, último passo! Se você utiliza IRC e frequenta a rede Freenode, entre no nosso canal: #lp-br-sp</code>! É lá que a maior parte das discussões acontece, então seria muito legal se você também pudesse participar delas!</li> </ol> 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!</p> Saudações livres!</p> Relato da Apresentação sobre o GDB no SoLiSC 2012 2012-12-01T00:00:00-05:00 Nesta última sexta-feira, dia 30/11/2012, estive presente na sétima edição do SoLiSC 2012</a>, em Florianópolis, para apresentar uma palestra introdutória sobre o GDB</a>. Este é um relato sobre minha particição no evento :-).</p> Impressões sobre o evento</h2> 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.</p> 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 :-).</p> O evento aconteceu Universidade Estácio de Sá</a>, 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.</p> Por coincidência (ou não!), acabei ficando na sala onde aconteceria o primeiro LibreOffice Hack Day</a> 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</code>. 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</a> 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 :-).</p> 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</a>.</p> Apresentação "GDB Crash Course"</h2> 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?</p> Bem, mas mesmo com pouco público, creio que palestra correu bem. Dessa vez, meu amigo Edjunior</a> 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.</p> 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!</p> 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</em>, 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 :-).</p> Várias pessoas me pediram os slides, então aqui estão eles:</p> https://github.com/sergiodj/gdb-unicamp2011</a> (fonte, em Beamer/LaTeX)</li> http://fedorapeople.org/~sergiodj/presentations/2012/SoLiSC/</a> (PDF)</li> </ul> Conclusão</h2> Gostaria de agradecer especialmente à Eliane Domingos</a>, ao David Jourdain e ao Olivier Hallot</a>, todos membros da TDF</a> e contribuidores do LibreOffice, pelos momentos prazerosos e pelas conversas divertidas que tivemos durante todo o evento!</p> Também gostaria de agradecer à organização do SoLiSC pela oportunidade de participar de um evento tão bacana! O Klaibson Ribeiro</a> foi a pessoa com quem troquei alguns e-mails antes do evento, então um "muito obrigado" a ele também :-).</p> Nos vemos no próximo SoLiSC!</p> GDB and SystemTap Probes -- part 3 2012-11-02T00:00:00-05:00 Hi everybody :-).</p> 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</a>, and the second here</a>.</p> My goal with this third post is to talk a little bit about how you can use the SDT</code> probes with tracepoints</code> inside GDB</code>. 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</code> probes are laid out inside the binary. So, let's start!</p> Complementary information</h2> In my last post, I forgot to mention that the SDT</code> probe support present on older versions of Fedora GDB</code> is not exactly as the way I described here. This is because Fedora GDB</code> adopted this feature much earlier than upstream GDB</code> 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</code> feature will be fully available on Fedora 18, to be announced soon.</p> 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</code> yourself (it's not that hard, I will make a post about it in the next days/weeks!).</p> With that said, let's move on to our main topic here.</p> SDT Probes and Tracepoint</h2> Before anything else, let me explain what a tracepoint</code> is. Think of it as a breakpoint which doesn't stop the program's execution when it hits</em>. In fact, it's a bit more than that: you can define actions</strong> associated with a tracepoint</code>, and those actions will be performed when the tracepoint</code> is hit. Neat, huh? :-)</p> There is a nice description of what a tracepoint</code> in the GDB documentation</a>, I recommend you give it a reading to understand the concept.</p> Ok, so now we have to learn how to put tracepoints</code> in our code, and how to define actions for them. But before that, let's remember our example program:</p> #include</span> <sys/sdt.h></span></span> </span> int</span></span> main</span> (</span>int</span> argc</span>,</span> char </span>argv</span>[]</span>)</span></span> {</span></span> int</span> a </span>=</span> 10</span>;</span></span> </span> STAP_PROBE1</span> (test_program, my_probe, a);</span></span> </span> return</span> 0</span>;</span></span> }</span></span></code></pre> Very simple, isn't it? Ok, to the tracepoints</code> now, my friends.</p> Using tracepoints</code> inside GDB</code></h2> In order to properly use tracepoints</code> inside GDB</code>, you will need to use gdbserver</code>, a tiny version of GDB</code> suitable for debugging programs remotely, over the net or serial line. In short, this is because GDB</code> cannot put tracepoints on a program running directly under it, so we have to run it inside gdbserver</code> and then connect GDB</code> to it.</p> Running our program inside gdbserver</code></h3> In our case, we will just start gdbserver</code> in our machine, order it to listen to some high port, and connect to it through localhost</code>, so there will be no need to have access to another computer or device.</p> First of all, make sure you have gdbserver</code> installed. If you use Fedora, the package name you will have to install is gdb-gdbserver</code>. If you have it installed, you can do:</p> $ gdbserver :3001 ./test_program</span></span> Process ./test_program created; pid = 17793</span></span> Listening on port 3001</span></span></code></pre> The second argument passed to gdbserver</code> instructs it to listen on the port 3001 of your loopback interface, a.k.a. localhost</code>.</p> You will notice that gdbserver</code> will stay there indefinitely, waiting for new connections to arrive. Don't worry, we will connect to it soon!</p> Connecting an instance of GDB</code> to gdbserver</code></h3> Now, go to another terminal and start GDB</code> with our program:</p> $ gdb ./test_program</span></span> ...</span></span> (gdb) target remote :3001</span></span> Remote debugging using :3001</span></span> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.</span></span> Loaded symbols for /lib64/ld-linux-x86-64.so.2</span></span> 0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2</span></span></code></pre> The command you have to use inside GDB</code> is target remote</code>. 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</code>, 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</em>). 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.</p> Ok, so now it is time to start our trace experiment</em>!</p> Creating the tracepoints</code></h3> Every command should be issued on GDB, not on gdbserver!</strong></p> In your GDB</code> prompt, put a tracepoint</code> in the probe named my_probe</code>:</p> (gdb) trace -probe-stap my_probe</span></span> Tracepoint 1 at 0x4005a9</span></span></code></pre> As you can see, the trace</code> command takes exactly the same arguments as the break</code> command. Thus, you need to use the -probe-stap</code> modified in order to instruct GDB</code> to put the tracepoint</code> in the probe.</p> And now, let's define the actions</strong> associated with this tracepoint</code>. To do that, we use the actions</code> command, which is an interactive command inside GDB</code>. It takes some specific keywords, and if you want to learn more about it, please take a look at this link</a>. For this example, we will use only the collect</code> keyword, which tells GDB</code> to... hm... collect something :-). In our case, it will collect the probe's first argument, or $_probe_arg0</code>, as you may remember.</p> (gdb) actions </span></span> Enter actions for tracepoint 1, one per line.</span></span> End with a line saying just "end".</span></span> >collect $_probe_arg0</span></span> >end</span></span> (gdb)</span></span></code></pre> Simple as that. Finally, we have to define a breakpoint</code> in the last instruction of our program, because it is necessary to keep it running on gdbserver</code> in order to examine the tracepoints</code> later. If we didn't put this breakpoint</code>, our program would finish and gdbserver</code> would not be able to provide information about what happened with our tracepoints</code>. In our case, we will simply put a breakpoint</code> on line 10, i.e., on the return 0;</code>:</p> Running the trace experiment</h3> Ok, time to run our trace experiment. First, we must issue a tstart</code> to tell GDB</code> to start monitoring the tracepoints</code>. And then, we can continue our program normally.</p> (gdb) tstart </span></span> (gdb) continue</span></span> Continuing.</span></span> </span> Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10</span></span> 10 return 0;</span></span> (gdb) tstop</span></span> (gdb)</span></span></code></pre> Remember, GDB</code> is not</strong> going to stop your program, because tracepoints</code> are designed to not interfere with the execution of it. Also notice that we have also stopped the trace experiment after the breakpoint</code> hit, by using the tstop</code> command.</p> Now, we will be able to examine what the tracepoint</code> has collected. First, we will the tfind</code> command to make sure the tracepoint</code> has hit, and then we can inspect what we ordered it to collect:</p> (gdb) tfind start</span></span> Found trace frame 0, tracepoint 1</span></span> 8 STAP_PROBE1 (test_program, my_probe, a);</span></span> (gdb) p $_probe_arg0</span></span> $1 = 10</span></span></code></pre> And it works! Notice that we are printing the probe argument using the same notation as with breakpoints</code>, even though we are not exactly executing the STAP_PROBE1</code> instruction. What does it mean? Well, with the tfind start</code> command we tell GDB</code> to actually use the trace frame collected during the program's execution, which, in this case, is the probe argument. If you know GDB</code>, think of it as if we were using the frame</code> command to jump back to a specific frame, where we would have access to its state.</p> This is a very simple example of how to use the SDT</code> probe support in GDB</code> with tracepoints</code>. There is much more you can do, but I hope I could explain the basics so that you can start playing with this feature.</p> How the SDT</code> probe is laid out in the binary</h2> 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</code>, which is the heart of the whole feature, I also recommend this page</a>, 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.</p> Conclusion</h2> After this series of blog posts, I expect that you will now be able to use the not-so-new feature of SDT</code> probe support on GDB</code>. Of course, if you find some bug while using this, please feel free to report it using our bugzilla</a>. And if you have some question, use the comment system below and I will answer ASAP :-).</p> See ya, and thanks for reading!</p> GDB and SystemTap Probes -- part 2 2012-10-27T00:00:00-05:00 I tell you this: it is depressing when you realize that you spent more time struggling with blog engines than writing posts on your blog!</p> It's been a long time since I wrote the first post</a> about this subject, and since then the patches have been accepted upstream, and GDB 7.5</a> now has official support for userspace SystemTap probes :-). Yay!</p> Well, but enough of cheap talk, let's get to the business!</p> Errata for my last post</h2> Frank Ch. Eigler</a>, one of SystemTap's maintainers, kindly mentioned something that I should say about SystemTap userspace probes.</p> Basically, it should be clear that SDT</code> probes are not the only kind of userspace probing one can do with SystemTap. There is yet another kind of probe (maybe even more powerful, depending on the goals): DWARF-based function/statement probes</strong>. SystemTap supports this kind of probing mechanism for quite a while now.</p> It is not the goal of this post to explain it in detail, but you might want to give it a try by compiling your binary with debuginfo support (use the -g</code> flag on GCC</code>), and do something like:</p> $ stap -e </span>'probe process("/bin/foo").function("name") { log($$parms) }'</span> -c /bin/foo</span></span> $ stap -e </span>'probe process("/bin/foo").statement("@file.c:443") { log($$vars) }'</span> -c /bin/foo</span></span></code></pre> And that's it. You can read SystemTap's documentation, or this</a> guide to learn how to add userspace probes.</p> Using GDB with SystemTap SDT Probes</h2> Well, now let's get to the interesting part. It is time to make GDB</code> work with the SDT</code> probe that we have put in our example code. Let's remember it:</p> #include</span> <sys/sdt.h></span></span> </span> int</span></span> main</span> (</span>int</span> argc</span>,</span> char </span>argv</span>[]</span>)</span></span> {</span></span> int</span> a </span>=</span> 10</span>;</span></span> </span> STAP_PROBE1</span> (test_program, my_probe, a);</span></span> </span> return</span> 0</span>;</span></span> }</span></span></code></pre> It is a very simple example, and we will have to extend it later in order to show more features. But for now, it will do.</p> The first thing to do is to open GDB</code> (with SystemTap support, of course!), and check to see if it can actually see probe inserted in our example.</p> $ gdb ./test_program</span></span> GNU gdb (GDB) 7.5.50.20121014-cvs</span></span> Copyright (C) 2012 Free Software Foundation, Inc.</span></span> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html></span></span> ...</span></span> (gdb) info probes</span></span> Provider Name Where Semaphore Object</span></span> test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program</span></span></code></pre> Wow, it actually works! :-)</p> If you have seen something like the above, it means your GDB</code> is correctly recognizing SDT</code> probes. If you see an error, or if your GDB</code> doesn't have the info probes</code> command, then you'd better make sure you have a recent version of GDB</code> otherwise you won't be able to use the SDT</code> support.</p> Putting breakpoints in the code</h3> Anyway, now it is time to start using this support. The first thing I want to show you is how to put a breakpoint in a probe.</p> (gdb) break -probe-stap my_probe</span></span> Breakpoint 1 at 0x4004ae</span></span></code></pre> That's all! We have chosen to extend the break</code> command in order to support the new -probe-stap</code> parameter. If you're wondering ... why the -probe prefix?</em>, it is because I was asked to implement a complete abstraction layer inside GDB</code> in order to allow more types of probes to be added in the future. So, for example, if someone implements support for an hypothetical type of probe called xyz</code>, you would have break -probe-xyz</code>. It took me a little more time to implement this layer, but it is worth the effort.</p> Anyway, as you have see above, GDB</code> recognize the probe's name and correctly put a breakpoint in it. You can also confirm that it has done the right thing by matching the address reported by info probes</code> with the one reported by break</code>: they should be the same.</p> Ok, so now, with our breakpoint</code> in place, let's run the program and see what happens.</p> (gdb) run</span></span> Starting program: /home/sergio/work/src/git/build/gdb/test_program</span></span> </span> Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8</span></span> 8 STAP_PROBE1 (test_program, my_probe, a);</span></span></code></pre> As you can see, GDB</code> stopped at the exact location of the probe. Therefore, you are now able to put marks (i.e., probes) in your source code which are location-independent</strong>. It means that it doesn't really matter where in the source code your probe is, and it also doesn't matter if you change the code around it, changing the line numbers, or even moving it to another file. GDB</code> will always find your probe, and always stop at the right location. Neat!</p> Examining probes' arguments</h3> But wait, there's more! Remember when I told you that you could also inspect the probe's arguments? Yes, let's do it now!</p> Just remember that, in SDT</code>'s parlance, the current probe's argument is a</code>. So let's print its value.</p> (gdb) p $_probe_arg0</span></span> $1 = 10</span></span> (gdb) p a</span></span> $2 = 10</span></span></code></pre> "Hey, captain, it seems the boat really floats!"</em></p> Check the source code above, and convince yourself that a</code>'s value is 10</code> :-). As you might have seen, I have used a fairly strange way of printing it. It is because the probe's arguments are available inside GDB</code> by means of convenience variables</strong>. You can see a list of them here</a>.</p> Since SDT</code> probes can have up to 12 arguments (i.e., you can use STAP_PROBE1</code> ... STAP_PROBE12</code>), we have created inside GDB</code> 12 convenience variables, named $_probe_arg0</code> until $_probe_arg11</code>. I know, it is not an easy name to remember, and even the relation between SDT</code> naming and GDB</code> naming is not direct (i.e., you have to subtract 1 from the SDT</code> probe number). If you are not satisfied with this, please open a bug in our bugzilla</a> and I promise we will discuss other options.</p> I would like to emphasize something here: just as you don't need debuginfo support for dealing with probes inside GDB</code>, you also don't need debuginfo support for dealing with their arguments as well. It means that you can actually compile your code without debuginfo support, but still have access to some important variables/expressions when debugging it. Depending on how GCC</code> optimizes your code, you may experience some difficulties with argument printing, but so far I haven't heard of anything like that.</p> More to come</h2> Ok, now we have covered more things about the SDT</code> probe support inside GDB</code>, and I hope you understood all the concepts. It is not hard to get things going with this, specially because you don't need extra libraries to make it work.</p> In the next post, I intend to finish this series by explaining how to use tracepoints</code> with SDT</code> probes. Also, as I said in the previous post of this series, maybe I will talk a little bit about how the SDT</code> probes are organized within the binary.</p> See you soon!</p> Relato das Apresentações na UNESP de Rio Claro/SP 2012-10-24T00:00:00-05:00 Conforme eu havia comentado no post anterior</a>, segue o relato sobre as apresentações que fiz na Semana da Computação</a> da UNESP de Rio Claro</a>.</p> TL;DR:</strong> Gostei de ter tido a oportunidade de dar as apresentações, e principalmente de ter feito minha primeira palestra como Embaixador</a> do Projeto Fedora</a> no Brasil. Sobre a palestra a respeito do GDB</a>, também gostei do jeito que ela foi conduzida. Notei algumas falhas que precisam ser corrigidas, mas no geral a experiência foi muito boa.</em></p> Apresentação "O Projeto Fedora"</h2> Foi a primeira apresentação da noite, de acordo com a grade de programação. Começou meia hora atrasada, pois a organização pediu para esperarmos mais pessoas chegarem (estava chovendo bastante no momento, o que dificultou a locomoção).</p> Comecei a palestra falando um pouco sobre o Projeto Fedora. Acabei passando rapidamente pelas origens do projeto, uma falha que pretendo corrigir em próximas ocasiões. Dei muita ênfase na definição de comunidade</strong> e no que isso significa quando lidamos com software livre. Confesso que fiz algumas comparações com o Ubuntu, o que talvez não tenha sido uma boa idéia (de acordo com os guidelines</em> do Projeto Fedora para Embaixadores). De qualquer modo, a mensagem foi passada e notei que algumas pessoas se interessaram em conhecer mais a respeito do projeto e da filosofia.</p> Pontos positivos</strong>: Creio ter conseguido informar as pessoas a respeito do projeto, com a ajuda dos ótimos slides do Paul W. Frields</a>. É sempre gratificante dar palestras, mesmo que apenas uma ou duas pessoas no final acabem se interessando de verdade. Além disso, me senti bem por estar divulgando um projeto que respeita as liberdades dos usuários (ou pelo menos tenta fazer isso ao máximo), e que eu realmente uso e gosto.</p> Pontos a serem melhorados</strong>: Fazer uma palestra um pouco menos "pessoal". É muito difícil conseguir isso, mas tenho a forte impressão de que minha orientação totalmente pró-software-livre acaba (às vezes) afastando algumas pessoas, que vêem no entusiasta por software livre uma pessoa "radical" e "xiita". Preciso pensar um pouco a respeito do assunto...</p> A conclusão é que fiquei bastante satisfeito com o resultado da palestra. Percebi que, depois dela, algumas pessoas vieram comentar que estavam utilizando Fedora, ou que já andavam pensando em trocar de distribuição, que agora o Fedora era uma opção. O objetivo foi cumprido :-).</p> Apresentação "GDB Crash Course"</h2> Creio que essa já é a quarta vez que apresento essa palestra, e a terceira vez junto com meu amigo Edjunior</a>. Sempre que ela termina, fico(amos) com a impressão de que ainda não acertamos no ponto, e dessa vez não foi diferente.</p> A palestra começou em ponto, às 21h, e decidimos tentar uma abordagem um pouco diferente. A última vez que apresentamos a palestra foi no evento da Semana Integrada</a> da PUC Campinas</a>. Naquela ocasião, tínhamos optado por começar falando mais sobre os comandos do GDB</code>, e depois mostrarmos como a coisa funciona, estilo hands-on</em>. Dessa vez, resolvemos ir mostrando a prática junto com a teoria. Ficou melhor, e acho que a apresentação ficou mais fluida, mas ainda assim esbarramos no velho problema da interdependência dos comandos: quando íamos falar sobre breakpoints</code>, precisávamos ter mostrado algum outro comando que só iria ser explicado mais à frente, que por sua vez iria precisar de outro comando, que iria precisar de breakpoints</code>, etc. Enfim, no final acabamos sendo obrigados a pular alguns comandos, e a adiantar a explicação de outros, quebrando um pouco o fluxo dos slides.</p> Notei que algumas pessoas estavam bastante interessadas no GDB</code>, talvez por já programarem há algum tempo. As outras, aparentemente, ainda não conseguiam ver muita utilidade para um depurador, mas mesmo assim tentavam aprender algo que talvez fosse lhes servir no futuro.</p> Já era de se esperar, mas mesmo assim não deixo de me surpreender quando vejo que uma palestra técnica consegue atrair muito mais atenção do que uma palestra "filosófica", como foi a do Projeto Fedora. Talvez seja reflexo da sociedade em que vivemos, ou talvez seja apenas uma impressão errônea da minha parte.</p> A conclusão, finalmente, é que a palestra parece ter sido útil para algumas pessoas (mesmo que poucas), e isso nos dá ainda mais fôlego pra continuarmos tentando divulgar esse projeto pouco conhecido (mas muito útil) que é o GDB</code>.</p> Agradecimentos</h2> Não poderia deixar de agradecer primeiramente à organização da SECCOMP da UNESP de Rio Claro pelo ótimo evento. Fiquei surpreso com a infra-estrutura e, principalmente, com a receptividade das pessoas. Gostei muito do ambiente descontraído, e espero não ter decepcionado muita gente por lá com meus comentários informais e caipiras durante as palestras :-).</p> Também agradeço ao meu amigo Edjunior por ter me acompanhado até sua alma matter</em> para me ajudar na realização da palestra sobre o GDB</code>.</p> Até a próxima!</p> Apresentação na UNESP de Rio Claro/SP 2012-10-23T00:00:00-05:00 Hoje, dia 23/10/2012, estarei na UNESP de Rio Claro</a> para dar duas apresentações na Semana da Computação</a>.</p> A primeira palestra será sobre o Projeto Fedora</a>. Vai ser a primeira vez que falarei sobre o projeto depois de ter me tornado Embaixador</a> do Fedora no Brasil. Confesso que estou um pouco apreensivo, mas escolhi slides muito bons feitos pelo Paul W. Frields</a>, ex-líder do Projeto e bastante competente em suas apresentações. Pretendo fazer um relato sobre a palestra na quarta-feira.</p> A segunda apresentação será sobre o GDB</a>. Essa apresentação vai ser mais um crash course</em> sobre como utilizar a ferramenta, e os slides estão disponíveis em https://github.com/sergiodj/gdb-unicamp2011</a>.</p> Espero que ambas as palestras sejam bem recebidas pelo público! Volto depois pra contar como foi :-).</p> Abraços.</p> GDB and SystemTap probes -- part 1 2012-03-29T00:00:00-05:00 After a long time, here we are again :-).</p> With this post I will start to talk about the integration between GDB and SystemTap. This is something that Tom Tromey</a> and I did during the last year. The patch is being reviewed as I write this post, and I expect to see it checked-in in the next few days/weeks. But let's get our hands dirty...</p> SystemTap Userspace Probes</h2> You probably use (or have at least heard of) SystemTap, and maybe you think the tool is only useful for kernel inspections. If that's your case, I have a good news: you're wrong! You can actually use SystemTap to inspect userspace applications too, by using what we call SDT probes</strong>, or S</em>tatic D</em>efined T</em>racing probes. This is a very cheap and easy way to include probes in your application, and you can even specify arguments to those probes.</p> In order to use the probes (see an example below), you must include the <sys/sdt.h></code> header file in your source code. If you are using Fedora systems, you can obtain this header file by installing the package systemtap-sdt-devel</code>, version equal or greater than 1.4</code>.</p> Here's a simple example of an application with a one-argument probe:</p> #include</span> <sys/sdt.h></span></span> </span> int</span></span> main</span> (</span>int</span> argc</span>,</span> char </span>argv</span>[]</span>)</span></span> {</span></span> int</span> a </span>=</span> 10</span>;</span></span> </span> STAP_PROBE1</span> (test_program, my_probe, a);</span></span> </span> return</span> 0</span>;</span></span> }</span></span></code></pre> As you can see, this is a very simple program with one probe, which contains one argument. You can now compile the program:</p> $ gcc test_program.c -o test_program</span></span></code></pre> Now you must be thinking: "Wait, wait... Didn't you just forget to link this program against some SystemTap-specific library or something?</em>" And my answer is no</strong>. One of the spetacular things about this <sys/sdt.h></code> header is that it does not have any dependencies at all! As Tom said in his blog post</a>, this is "a virtuoso display of ELF and GCC asm wizardy</em>".</p> If you want to make sure your probe was inserted in the binary, you can use readelf</code> command:</p> $ readelf -x .note.stapsdt ./test_program</span></span> </span> Hex dump of section '.note.stapsdt':</span></span> 0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap</span></span> 0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.</span></span> 0x00000020 00000000 00000000 00000000 74657374 ............test</span></span> 0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob</span></span> 0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...</span></span></code></pre> (I will think about writing an explanation on how the probes are laid out on the binary, but for now you just have to care if you actually see an output from this</em> readelf</code> command.)</em></p> You can also use SystemTap to perform this verification:</p> $ stap -L </span>'process("./test_program").mark("*")'</span></span> process("./test_program").mark("my_probe") $arg1:long</span></span></code></pre> So far, so good. If you see an output like the one above, it means your probe is correctly inserted. You could obviously use SystemTap to inspect this probe, but I won't do this right now because this is not the purpose of this post.</p> For now, we have learned how to:</p> Include an SDT probe</code> in our source code, and compile it;</li> Verify if the probe was correctly inserted.</li> </ol> In the next post, I will talk about the GDB support that allows you to inspect, print arguments, and gather other information about SDT probes</code>. I hope you like it!</p> My workflow with GDB and git -- part 1 2011-11-29T00:00:00-05:00 This post is actually a "reply" to Gary Benson's Working on gdb</a> post.</p> I have been working with GDB</a> for quite some time now, and even though the project officially uses CVS</a> (yes, you read it correctly, it is CVS</strong> indeed!) as its version control system, fortunately we also have a git</a> mirror. In the end, what happens is that almost every developer uses the git mirror and just goes to CVS to commit something. But this is another discussion. Aside of this git mirror, we also have the Archer</a> repository (which uses git by default).</p> My plan here is to show you how I do my daily work with GDB. The workflow is pretty simple, but maybe you will see something here that might help you.</p> Checking out the code</h2> The first thing to do is to check out the code. I only have one GDB repository here, and I make branches out of it whenever I want to hack. So, to check out (or clone</em>, in git's parlance) the code, I do (or did):</p> With this, we have just cloned the GDB repository, and also added another remote (i.e., repository). This is useful because we might want to hack on a branch which is on Archer, but use GDB's master</strong> branch as a base.</p> Create a new branch for your work</h2> So, now it's time to create a new branch for you. Here I use one of my little "tricks" (taught to me by my friend Dodji</a>), which is the command git-new-workdir</code>. This is a nice command because it creates a new working directory for your project!</p> Maybe you're wondering why this is so cool. Well, if you ever worked with git, and more specifically, if you ever used more than one branch at a time, then maybe you will understand my excitement. In this scenario, having to constantly switch between the branches is not something rare. When you have uncommited work in your tree you can always use git stash</code>, but that is not the ideal solution (for me). Sometimes I would forget what was on the stash, and later when I checked it, it was full of crap. Also, I like to have a separate directory for every project I am working on.</p> It is also important to mention that git-new-workdir</code> is under the directory /usr/share/doc/git-VERSION/contrib/workdir/</code>, so I created an alias that will automagically call the script for me:</p> So, after setting up the script, here is what I do:</p> Build GDB</h2> In order to build the project, I create a build-64</code> directory inside my project directory (which, in the example above, is work/lazy-debuginfo-reading</code>).</p> GDB fortunately supports VPATH building (i.e., build the project outside of the source tree). I strongly recommend you to use it.</p> As you may have noticed, I use -g3</code> (include debuginfo) and -O0</code> (do not optimize the code) in CFLAGS</code>. Also, since some of the features I work on may affect code in other architectures, I use --enable-targets=all</code>. It will tell configure to compile everything related to all architectures (not only x86_64</code>, for example). At last, I specify a separate debug directory which GDB should use to search for debuginfo files.</p> Finalizing (for now)</h2> After that, you will have a fresh GDB binary compiled in the build-64</code> directory. But that is not enough yet, since you will also want to test GDB and make sure you didn't insert a bug while hacking on it. In my next post, I will explain what is my "testflow". I hope it will be useful for someone :-).</p> Stay tuned!</p>

Fedora on an Acer C720P Chromebook

2014-09-26T00:00:00-05:00

Yes, you are reading correctly: I decided to buy a freacking Chromebook. I really needed a lightweight notebook with me for my daily hackings while waiting for my subway station, and this one seemed to be the best option available when comparing models and prices. To be fair, and before you throw me rocks, I visited the LibreBoot X60's website</a> for some time, because I was strongly considering buying one (even considering its weight); however, they did not have it in stock, and I did not want to wait anymore, so...

Anyway, as one might expect, configuring GNU/Linux on notebooks is becoming harder as time goes by, either because the infamous Secure Boot</a> (anti-)feature, or because they come with more and more devices that demand proprietary crap to be loaded. But fortunately, it is still possible to overcome most of those problems and still get a GNU/Linux distro running.

References</h2>

For main reference, I used the following websites:

Chromebook</a>, a wiki page from Arch[GNU/]Linux.</li> </ul>

I also used other references for small problems that I had during the configuration, and I will list them when needed.

Backing up ChromeOS</h2>
The first thing you will probably want to do is to make a recovery image of the ChromeOS that comes pre-installed in the machine, in case things go wrong. Unfortunately, to do that you need to have a Google account, otherwise the system will fail to record the image. So, if you want to let Google know that you bought a Chromebook, login into the system, open Chrome, and go to the special URL `chrome://imageburner</code>. You will need a 4 GiB pendrive/sdcard. It should be pretty straightforward to do the recording from there.`

Screw the screw</h2>

Now comes the hard part. This notebook comes with a write-protect
screw</a>.
You might be thinking: what is the purpose of this screw?</p>
Well, the thing is: Chromebooks come with their own boot scheme, which
unfortunately doesn't work to boot Linux. However, newer models also
offer a “legacy boot” option
(SeaBIOS</a>), and this</strong> can boot
Linux. So far, so good, but...</p>
When you switch to SeaBIOS (details below), the system will complain
that it cannot find ChromeOS, and will ask if you want to reinstall the
system. This will happen every time</strong> you boot the machine, because
the system is still entering the default BIOS. In order to activate
SeaBIOS, you have to press CTRL-L (Control + L) every time you boot</strong>!
And this is where the screw comes into play.</p>
If you remove the write-protect screw, you will be able to make the
system use SeaBIOS by default, and therefore will not need to worry
about pressing CTRL-L every time. Sounds good? Maybe not so much...</p>
The first thing to consider is that you will lose your warranty the
moment you open the notebook case. As I was not very concerned about it,
I decided to try to remove the screw, and guess what happened? I
stripped the screw! I am still not sure why that happened, because I was
using the correct screw driver for the job, but when I tried to remove
the screw, it seemed like butter and started to “decompose”!</p>
Anyway, after spending many hours trying to figure out a way to remove
the screw, I gave up. My intention is to always suspend the system, so I
rarely need to press CTRL-L anyway...</p>
Well, that's all I have to say about this screwed screw. If you decide
to try removing it, keep in mind that I cannot help you in any way, and
that you are entirely responsible for what happens.</p>
Now, let's install the system :-).</p>
Enable Developer Mode</h2>
You need to enable the Developer Mode in order to be able to enable
SeaBIOS. To do that, follow these
steps</a>
from the Arch[GNU/]Linux wiki page.</p>
I don't remember if this step works if you don't have activated the
ChromeOS (i.e., if you don't have a Google account associated with the
device). For my use, I just created a fake account to be able to
proceed.</p>
Accessing the superuser shell inside ChromeOS</h2>
Now, you will need to access the superuser (root</code>) shell inside
ChromeOS, to enable SeaBIOS. Follow the steps described in the
Arch[GNU/]Linux wiki page</a>.
For this specific step, you don't need to login, which is good.</p>
Enabling SeaBIOS</h2>
We're almost there! The last step before you boot your Fedora LiveUSB is
to actually enable SeaBIOS. Just go inside your superuser shell (from
the previous step) and type:</p>
> crossystem dev_boot_usb</span>=</span>1</span> dev_boot_legacy</span>=</span>1</span></span></code></pre>
And that's it!</p>
If you managed to successfuly remove the write-protect screw, you may
also want to enable booting SeaBIOS by default. To do that, there is a
guide</a>,
again on Arch[GNU/]Linux wiki. DO NOT DO THAT IF YOU DID NOT REMOVE
THE WRITE-PROTECT SCREW!!!!</strong></p>
Booting Fedora</h2>
Now, we should finally be able to boot Fedora! Remember, you will have
to press CTRL-L after you reboot (if you have not removed the
write-protect screw), otherwise the system will just complain and not
boot into SeaBIOS. So, press CTRL-L, choose the boot order (you will
probably want to boot from USB first, if your Fedora is on a USB stick),
choose to boot the live Fedora image, and... bum!! You will probably see
a message complaining that there was not enough memory to boot (the
message is “Not enough memory to load specified image”).</p>
You can solve that by passing the mem</code> parameter to Linux. So, when
GRUB complains that it was unable to load the specified image, it will
give you a command prompt (boot:</code>), and you just need to type:</p>
boot: linux mem=1980M</span></span></code></pre>
And that's it, things should work.</p>
Installing the system</h2>
I won't guide you through the installation process; I just want to
remember you that you have a 32 GiB SSD drive, so think carefully before
you decide how you want to set up the partitions. What I did was to
reserve 1 GB for my swap, and take all the rest to the root partition
(i.e., I did not create a separate /home</code> partition).</p>
You will also notice that the touchpad does not work (neither does the
touchscreen). So you will have to do the installation using a USB mouse
for now.</p>
Getting the touchpad to work</h2>
I strongly recommend you to read this Fedora
bug</a>, which is
mostly about the touchpad/touchscreen support, but also covers other
interesting topics as well.</p>
Anyway, the bug is still being constantly updated, because the proposed
patches to make the touchpad/touchscreen work were not fully integrated
into Linux yet. So, depending on the version of Linux that you are
running, you will probably need to run a different version of the
scripts that are being kindly provided in the bug.</p>
As of this writing, I am running Linux 3.16.2-201.fc20, and the script
that does the job for me is this
one</a>. If you are
like me, you will never run a script without looking at what it does, so
go there and do it, I will wait :-).</p>
OK, now that you are confident, run the script (as root</code>, of course),
and confirm that it actually installs the necessary drivers to make the
devices work. In my case, I only got the touchpad working, even though
the touchscreen is also covered by this script. However, since I don't
want the touchscreen, I did not investigate this further.</p>
After the installation, reboot your system and at least your touchpad
should be working :-). Or kind of...</p>
What happened to me was that I was getting strange behaviors with the
touchpad. Sometimes (randomly), its sensitivity became weird, and it was
very hard to move the pointer or to click on things. Fortunately, I
found the solution in the same bug, in this comment by Yannick
Defais</a>. After
creating this X11 configuration file, everything worked fine.</p>
Getting suspend to work</h2>
Now comes the hard part. My next challenge was to get suspend to work,
because (as I said above) I don't want to poweroff/poweron every time.</p>
My first obvious attempt was to try to suspend using the current
configuration that came with Fedora. The notebook actually suspended,
but then it resumed 1 second later, and the system froze (i.e., I had to
force the shutdown by holding the power button for a few seconds). Hmm,
it smelled like this would take some effort, and my nose was right.</p>
After a lot of search (and asking in the
bug</a>), I found
out about a few Linux flags that I could provide in boot time. To save
you time, this is what I have now in my /etc/default/grub</code> file:</p>
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."</span></span></code></pre>
The final ...</code> means that you should keep whatever was there before you
included those parameters, of course. Also, after you edit this file,
you need to regenerate the GRUB configuration file on /boot</code>. Run the
following command as root</code>:</p>
> grub2-mkconfig -o /boot/grub2/grub.cfg</span></span></code></pre>
Then, after I rebooted the system, I found that only adding those flags
was still not enough. I saw a bunch of errors on dmesg</code>, which showed
me that there was some problem with EHCI and xHCI. After a few more
research, I found the this
comment</a>
on an Arch[GNU/]Linux forum. Just follow the steps there (i.e., create
the necessary files, especially the
/usr/lib/systemd/system-sleep/cros-sound-suspend.sh</code>), and things
should start to get better. But not yet...</p>
Now, you will see that suspend/resume work OK, but when you suspend, the
system will still resume after 1 second or so. Basically, this happens
because the system is using the touchpad and the touchscreen to
determine whether it should resume from suspend or not. So basically
what you have to do is to disable those sources of events:</p>
echo TPAD > /proc/acpi/wakeup</span></span>
echo TSCR > /proc/acpi/wakeup</span></span></code></pre>
And voilà! Now everything should work as expected :-). You might want to
issue those commands every time you boot the system, in order to get
suspend to work every time, of course. To do that, you can create a
/etc/rc.d/rc.local</code>, which gets executed when the system starts:</p>
> cat /etc/rc.d/rc.local</span></span>
#!/bin/bash</span></span>
</span>
suspend_tricks()</span></span>
{</span></span>
  echo TPAD > /proc/acpi/wakeup</span></span>
  echo TSCR > /proc/acpi/wakeup</span></span>
}</span></span>
</span>
suspend_tricks</span></span>
</span>
exit 0</span></span></code></pre>
Don't forget to make this file executable:</p>
> chmod +x /etc/rc.d/rc.local</span></span></code></pre>Conclusion</h2>
Overall, I am happy with the machine. I still haven't tried installing
Linux-libre</a>
on it, so I am not sure if it can work without binary blobs and
proprietary craps.</p>
I found the keyboard comfortable, and the touchpad OK. The only extra
issue I had was using the Canadian/French/whatever keyboard that comes
with it, because it lacks some useful keys for me, like Page Up/Down,
Insert, and a few others. So far, I am working around this issue by
using xbindkeys</code> and xvkdb</code>.</p>
I do not recommend this machine if you are not tech-savvy enough to
follow the steps listed in this post. If that is the case, then consider
buying a machine that can easily run GNU/Linux, because you feel much
more comfortable configuring it!</p>

GDB and SystemTap integration improving linker-debugger interface

2013-05-28T00:00:00-05:00

It is really nice to see something you did in a project influence in future features and developments. I always feel happy and proud when I notice such scenarios happening, and this time was no different. Gary Benson</a>, a colleague at Red Hat who works in the GDB team as well, has implemented a way of improving the interface between the linker and the debugger, and one of the things he used to achieve this is the GDB <-> SystemTap integration that I implemented with Tom Tromey</a> 2 years ago. Neat!

The problem</h2>
You can read a detailed description of the problem in the message Gary sent to the gdb-patches mailing list</a>, but to summarize: GDB needs to interface with the linker in order to identify which shared libraries were loaded during the inferior's (i.e., program being debugged) life.
Nowadays, what GDB does is to put a breakpoint in `_dl_debug_state</code>, which is an empty function called by the linker every time a shared library is loaded (the linker calls it twice, once before modifying the list of loaded shlibs, and once after). But GDB has no way to know what has changed in the list of loaded shlibs, and therefore it needs to load the entire list every time something happens. You can imagine how bad this is for performance...`

The solution</h2> What Gary did was to put SDT probes strategically on the linker, so that GDB could make use of them when examining for changes in the list of loaded shlibs. It improves performance a lot, because now GDB doesn't need to stop twice every time a shlib is loaded (it just needs to do that when stop-on-solib-events</code> is set); it just needs to stop at the right probe, which will inform the address of the link-map entry of the first newly added library. It means GDB also won't need to walk through the list of shlibs and identify what has changed: you get that for free by examining the probe's argument. Gary also mentions a discrepancy that happened on Solaris libc, which has also been solved by his patch. And now, the most impressing thing: the numbers! Take a look at this table, which displays the huge improvement in the performance when using lots of shlibs (the time is in seconds): Number of shlibs</th> 128</th> 256</th> 512</th> 1024</th> 2048</th> 4096</th></tr></thead> Old interface</td> > 0</td> > 1</td> > 4</td> > 12</td> > 47</td> > 185</td></tr> New interface</td> > 0</td> > 0</td> > 2</td> > 4</td> > 10</td> > 36</td></tr> </tbody></table> Impressive, isn't it? Conclusion</h2> This is one the things I like most in Free Software projects: the possibility of extending and improving things by using what others did before. When I hacked GDB to implement the integration between itself and SystemTap, I had absolutely no idea that this could be used for improving the interface between the linker and the debugger (though I am almost sure that Tom was already thinking ahead!). And I can say it is a pleasure and I feel proud when I see such things happening. It just makes me feel more and more certain that Free Software is the way to go :-). So long, Ambassadors... 2013-05-16T00:00:00-05:00 No, I am not leaving the Fedora Project, I am just leaving (or taking a break, depending on how you look) its Ambassadors</a> program. I am still the co-maintainer of the GDB</a> package, and will contribute to the development of the distribution since it is also my job. However, after a few months trying to become more involved with the Fedora community (specifically with the Brazilian/LATAM community), I became so disappointed that the only logical action for me now is to step back. My brief history</h2> I joined the Ambassadors program on October, 2012. After having used the system heavily for almost 3 years, I decided that it was about time to pay something back to the community too. Since I live in Brazil, I joined the the brazilian team of Ambassadors (which meant that I was also part of the Latin America team). Thanks to my friend Leonardo Vaz (from Red Hat), I talked to Daniel Bruno who then became responsible for "mentoring" me. The brazilian community was (and still is) very inactive (compared to others, and to itself a few years ago), but I was very excited and decided to try to revive it. And the first task that I assigned myself was to regain control of the brazilian</a> and LATAM</a> domains. The domains</h2> Alejandro Perez, a very nice guy from Panamá responsible for LATAM's money, asked me to talk to Rodrigo Padula, an inactive Fedora Ambassador from Brazil, about the domains. Padula was a very active member of the brazilian community since 2006 if I'm not mistaken, but due to reasons beyond my knowledge is inactive in the Fedora community for quite some time now (he's still very active in the Mozilla community, however). And he owns both domains. Alejandro was worried because the LATAM domain had suffered some sort of outage during some days, which is obviously bad for the project. He was also concerned (and I totally agreed with him on this) because those domains shouldn't be owned by a person (rather, it should be registered on behalf of the Fedora Project or, ultimately, Red Hat), specially if this person is now inactive. To make a long story short, I spent more than 1 month doing the indirection and talking to both guys about this issue. Padula initially said he could transfer the domains without problem, but then changed his mind and said he wouldn't do it. On the other side, Alejandro was getting upset because Padula did not want to make the transfer, and the LATAM community was pressuring him. In the end, I totally gave up, and the LATAM guys registered yet another domain</a>, but right now are still using the old domain. Yes, a mess. Working with LATAM</h2> Anyway, after this episode, and after witnessing how active the LATAM community was in contrast with the brazilian community, I decided to work directly with them. I wanted to do something, and I was eager to start working as a real ambassador, spreading the word about Fedora everywhere. And my friends from Panamá, Argentina, México, Venezuela, etc., seemed the right people to work with. So I started attending the weekly meetings on #fedora-latam</code>, at Freenode, every Wednesday night. It is a well-organized meeting (run by Alejandro), whose main goal is to vote tickets from LATAM ambassadors (including brazilians). Tickets are basically requests made through a Trac</a> instance</a>, and are used to ask for swags, media, sponsorship for travels, etc. The Fedora Project has a budget, and the LATAM region gets a fraction of this budget for annual expenses, so our job as ambassadors was to vote those tickets and decide whether they deserve to be approved or not, according to some rules inside the project</a>. Keep in mind: we are dealing with money here. It's not yours nor mine, but it's still money that should be used to promote a project that embraces open source initiatives (unfortunately, I cannot say Fedora is Free Software, but that is a topic for another post). So, after some weeks working with the LATAM guys, I became the default owner of Trac tickets from brazilian ambassadors. And a few more weeks down the road Alejandro asked me to produce media (Fedora DVDs) and be resposible for distributing them in Brazil. I spent a lot of time ordering the medias (I had to travel to São Paulo in order to make sure everything was OK), and every time an ambassador requests Fedora DVDs I go through a series of steps</a> (link in pt_br, portugues) to guarantee that she gets her media and I get my reimbursement. I also like to give talks and presentations about the project, and so I've attended some events (or organized them) just to be able to do that. I have posted some reports about them in this blog, you can find them in the archives (if you can read in pt_BR). So, enough of self-promotion: why I am leaving the ambassador's program after all? Disappointment</h2> A few things started to happen: During the weekly LATAM meetings, it bothered me to see that the tickets were being approved without any kind of serious discussion. Everyone (including myself!) was just giving "+1" to everything!</li> FISL</a>, the biggest open source (no, it is not about Free Software!!) event in LATAM, is going to happen on July. Suddenly, new brazilian ambassadors were popping out of nowhere, and inactive ambassadors were pretending to do something.</li> As a consequence, we received 9 sponsorship requests in our Trac. Some from active people, some not.</li> </ul> Something that I should have noticed before became crystal clear to me: some people are there just to take advantages for their own. They are not interested in the project, in the philosophy (yes, you can laugh at my face now...), in the promotion of the ideals, etc. They just want free lunch. And they get it... During the last meeting I attended, two weeks ago, we were going to vote the FISL tickets. A few days before the meeting, I sent the following message to the LATAM Ambassadors list: Hi there, This message is just to let you know that we will be discussing several FISL tickets in our next meeting, May 8th. You can take a look at the meeting agenda by going to: https://fedorahosted.org/fedora-latam/report/9</a> I would like to ask everyone to read the requests and make your decision based on merits, please. In my opinion, only active ambassadors should receive the honor of being sponsored by Fedora to go to FISL14. Let's not spend money unnecessarily, so try to avoid the "+1" wave when voting for the tickets. Thanks a lot, --Sergio. </blockquote> As I said, some tickets were filed by inactive ambassadors, and I wanted us to at least discuss the matter with him/her, showing that we were not happy with his/her conduct. It is one thing when you have personal problems and have to step away from the project for a while; it is another different thing when you disappear without saying a word and then comes back to request sponsorship for travel. We began the meeting by discussing tickets filed by active members, and approving them without thinking much about it. However, eventually we got to the problematic ones. There is this specific guy, whose name I will not mention here, who was very absent since I started in the project, and I felt the need to point that out. I told him I hadn't seen him in quite a while, and explained that there were many ambassadors doing things for Fedora. He's a long term contributor to the project, as he himself told me in a not-so-friendly tone during the meeting. But that was not the subject of the discussion, and while he kept saying how hard he worked for the project in the last 5 years, or how much he's done for this or that, I remained silent and began to think: what the hell am I doing? Why am I wasting my time in a Wednesday night to convince a group that someone maybe doesn't deserve the credit he's asking for? Well, the only reasonable answer was: because I feel it is the right thing to do. But nobody said a word during this discussion, and I started to feel something else. I felt that people were not interested in evaluating how much this guy (or anybody else, for that matter) really did for the project! And the feeling was corroborated when someone else said: "Hey, let's just approve the ticket now, we can continue the discussion later". WHAT????. Let me see if I get it: we are here to discuss, reach a consensus, and vote. You want to approve, maybe discuss, fuck the consensus. Well... I left before the end of the meeting, but I still managed to see this behaviour explained by some people: there was enough money to approve all tickets, so the meeting was just a formality needed to explain the expenses later. I was at least fully convinced that I did not belong there. Not my place</h2> If you are part of a team and you disagree with its members, I believe you have two choices most of the time: you can either (a) discuss with them, try to understand their reasons for being different, try to explain yours, see what you can do to overcome this, or (b) leave it. Sometimes I choose one, sometimes another. This is the time for (b). I don't want to spend more time and energy into something that doesn't work the way I think it should. I don't feel motivated to fight against the tide, because I am not so strong and the tide keeps getting bigger and bigger. And I also don't want to stop people from doing what they think is right, honestly. In the end of the day, I still want to believe that everyone has a conscience and knows what's correct... But I am not going to cross my arms and sit. Some friends and I decided to create our own group, called LibrePlanet São Paulo</a> (link in pt_br, portugues), and focus on the real important thing: Free Software</a>. I really hope we can make a difference with our local community, and we have started with the right foot already: we organized the Document Freedom Day in our city this year! As for Fedora, as I said, I still intend to continue contributing to it. I'm still subscribed to the fedora-devel mailing list, and I still follow the project's decisions, partly because it is part of my job, partly because I strongly believe you have to give back what you take for free -- as in freedom -- from the community. I also have some DVDs and I intend to distribute them. But my time as a Fedora Ambassador is coming to an end. It was a good experience, I met good people, had a great time doing talks and presentations, and most of all, did what I felt right at the right time. So, as Douglas Adams said, "...thanks for all the fish!". Document Freedom Day 2013 in Campinas -- São Paulo -- Brazil 2013-04-12T00:00:00-05:00 Hi, there! This is the report of the Document Freedom Day</a> event that took place in Campinas</a>, São Paulo state</a>, Brazil</a>. I will talk a little bit about how we (keep reading to know who "we" are!) organized it, and the conclusions that can be drawn to help for the next edition. Organization</h2> The DFD (or Document Freedom Day) 2013 in Campinas was organized by the LibrePlanet São Paulo</a> (link in pt_BR) group. If you follow this blog, and if you speak portuguese, then you have probably read the announcement of the group</a> that I made last year. If you haven't: LibrePlanet São Paulo is part of the LibrePlanet</a> project (sponsored by the Free Software Foundation</a>), and "... is a global network of free software activists and teams working together to help further the ideals of software freedom by advocating and contributing to free software.". The DFD 2013 was an important event to us because it was the first serious event that we organized as a group. Despite some mistakes and errors, I believe we did fine and were able to learn some great lessons for the next events that we plan to do. By the way, if you want to see the official page which we used to promote the event (and organize it too), take a look here</a>. The page is in pt_br, portugues. Basically, we should have: (a) focused more on defining the venue as soon as possible, because that would have made it possible to (b) start sending announcements about the event earlier. We also should have contacted the Document Freedom organization and asked swags and banners earlier, because when we did it was too late for the shipment to arrive in time. And last but not least, we should really have taken pictures!! Unfortunately, I have absolutely no pictures to post here, so you will have to believe just in the words I write... But well, nothing is perfect, and hey, the event happened!. So let's talk it :-). The Event</h2> DFD 2013 occurred on Wednesday, March 27th. After some discussion, we decided to schedule the event from 13h (1 p.m.) to 17h (5 p.m.), with 4 presentations of 50 minutes each, approximately. The venue chosen was CCUEC</a>, the Center of Computing at the University of Campinas, UNICAMP</a>. This center has some great people working on it who are involved with Free Software since the beginning of the movement, particularly Rubens Queiroz de Almeida</a>, a very nice guy (very famous in the Brazilian Free Software scene) who helped us a lot with the organization of this event. We understand that doing the event on a Wednesday afternoon was something that made it very hard for most people to attend, and that is probably the main reason for the low attendance: only 8 people in the audience. I have to say I was a little frustrated in the beginning, but hey, what really matters is that we spread the word about Free Software to 8 brave souls there, who will hopefully spread the word again to more people, and so on :-). So, it was time for the show to begin! Our schedule was (presentation titles translated): "What is Free Software?", by me</li> "Free Documents or the End of the World", by Rubens Queiroz de Almeida</li> "HTML5: all the faces of the new standard", by Ricardo Panaggio</li> "EPUB3: The book in the XXI century", by Raniere Silva</li> </ol> So my presentation was scheduled to be the first one, and I really liked it (surprise!). It was virtually the first time I gave a "philosophical" talk, and a very important one: a general presentation about Free Software, its history, the present, and a little bit of the future. In my opinion, what I liked about my talk is that I focused less on the "freedom" part, and more on the "respect" part of the philosophy. This is something I did because I wanted to use a different argument that was on my head for a long time: that the main thing behing the Free Software is the respect towards others, and only with that one can achieve freedom. I watched Rubens too, who gave an excelent presentation about why we need free documents and standards. Rubens is very talkative and warm, which makes the audience feel relaxed. People liked his presentation a lot, from what I noticed. Unfortunately, Ricardo Panaggio had a problem with his computer before his presentation, so we decided to switch: Raniere Silva would take his place as the third presenter, while Ricardo tried to fix the problem. I helped him with his problems, and because of this I was unable to watch Raniere's talk. In the end, we could not solve Ricardo's problem and he decided to give his presentation without any slides. In my opinion, he managed to catch everyone's attention (also because HTML5 is such a hot topic today), so I guess the missing slides were not so important after all! At 17h o'clock, we declared DFD 2013 finished. I still had time to distribute some Free Software stickers (from FSF), and talk a little with two or three people there, who were satisfied with the presentations! It made my day, of course :-). And just because of that I now feel motivated to organized another DFD next year! Acknowledgements</h2> I would like to thank Rubens Queiroz for helping with the promotion, the location, and the presentation during the event. DFD 2013 would have been impossible without his help. Thanks, Rubens! The LibrePlanet São Paulo team, specially Ricardo Panaggio, were also deeply involved with me in the organization. And I hope we manage to make a bigger event next year! Finally, I would like to thank everyone who attended the event, even for watch only one talk. Your presence there was really, really important to all of us. See you all next year! Relato dos Install Fests na UNESP de Rio Claro/SP e na UNICAMP/SP 2013-04-01T00:00:00-05:00 E... Aqui estamos (estou?) com mais um relato sobre duas atividades envolvendo o Projeto Fedora</a>! Ele contempla, respectivamente, os Install Fests ocorridos na UNESP de Rio Claro/SP</a> e na UNICAMP</a>. Foram atividades que envolveram diversas pessoas, tiveram vitórias e derrotas, alegrias e tristezas, mas acima de tudo um sentimento de impotência (principalmente no Install Fest ocorrido na UNICAMP) em relação às novas "tecnologias" de boot, principalemente ao Secure Boot</a>. Install Fest: missão UNESP de Rio Claro/SP</h2> Este foi o Install Fest mais tranquilo. Ele começou a ser organizado logo depois da minha participação na Semana da Computação da UNESP de Rio Claro</a>, e a intenção inicial era realizá-lo no dia da matrícula dos alunos ingressantes na Universidade. No final das contas, decidimos postergar a data, e isso foi uma boa escolha. O Install Fest aconteceu no dia 06 de março de 2013, em um auditório da Biblioteca do campus, e começou com uma palestra minha sobre o Projeto Fedora. Foi basicamente a mesma palestra que eu havia apresentado na Semana da Computação, mas de uma maneira mais sucinta porque tínhamos pouco tempo. Creio que a palestra foi bem recebida, porque o público demonstrou interesse em contribuir com o Projeto Fedora depois que eu expliquei os meios para isso :-). Além disso, apesar do número pequeno de pessoas (aproximadamente 12 participantes), todos estavam bastante interessados no conteúdo, o que é uma motivação extra! Bem, após a palestra era hora de começar a instalar os sistemas. Levei vários DVDs do Fedora, em basicamente 2 versões: LiveDVDs, que permitem o boot e a utilização de um sistema Fedora sem a necessidade de instalar nada na máquina, e InstallDVDs, que não oferecem a opção de "experimentar" o sistema, mas já possuem todos os pacotes necessários para fazer uma instalação completa. Expliquei a todos os presentes algumas regras básicas de todo Install Fest: é preciso reparticionar o disco rígido caso se queira manter o Microsoft (R) Windows (R), quem organiza o Install Fest não pode assumir responsabilidade por nenhuma falha na instalação (apesar de elas serem raras), e também não pode assumir responsabilidade caso o usuário torne-se viciado no GNU/Linux :-). Dito isso, começamos a colocar as mãos na GNU/massa. O primeiro desafio (e, até então, único!) dos Install Fests recentes é imposto pelos próprios fabricantes de notebooks. Um disco rígido que ainda utilize MBR</a> (a maioria) suporta apenas 4 partições primárias. Antigamente, os fabricantes criavam apenas uma partição para o Microsoft (R) Windows (R), e às vezes chegavam a criar outra partição de "recuperação", mas paravam por aí. Atualmente, não é raro encontrar computadores com 4 partições primárias já criadas. Eu inclusive já cheguei a ver notebooks com discos de 1 TB com uma partição primária de pouco mais de 1 MB! É uma prática totalmente absurda, e a meu ver é feita com má-fé, visando dificultar a instalação de outros sistemas operacionais. Além disso, pra piorar ainda mais, alguns fabricantes (HP me vem à cabeça, mas existem outros) dão um jeito de invalidar a garantia caso o esquema de particionamento seja alterado!!! Felizmente, vários computadores no Install Fest possuíam apenas 3 partições (ou até menos!), e aqueles que possuíam 4 partições ou usavam um outro boot sector (chamado GPT</a>), ou já estavam fora da garantia do fabricante e podiam ter seus esquemas de particionamento alterados. O próprio Microsoft (R) Windows (R), a partir da versão 7 (se não me engano), oferece uma ferramenta específica para redimensionar e reparticionar o disco, portanto essa primeira etapa foi concluída com sucesso em todas as máquinas (por favor, se você participou do Install Fest e se lembra de alguma máquina na qual não foi possível efetuar o reparticionamento, por favor contate-me <about> para que eu corrija o post!). Depois de reparticionar, era hora de começar a instalação. Quase todos preferiram utilizar o InstallDVD, porque a instalação pela internet iria demorar muito. Após o boot, deparamo-nos com a interface do instalador do Fedora 18. Depois de ter lido diversas críticas sobre ele, pude finalmente confirmar que, infelizmente, quase todas condizem. Confesso que fiquei confuso no início, principalmente na tela de particionamento e seleção de disco, que não é nem um pouco intuitiva. Sei que o instalador foi reescrito, e que ele foi um dos principais motivos do atraso no lançamento do Fedora 18, então espero muito que as melhorias para o Fedora 19 contemplem, principalmente, essa parte de interface com o usuário. Após apanhar um pouco, acabei me acostumando com ele e as outras instalações foram mais tranquilas. Conforme as instalações foram acabando, os sistemas começaram a ser configurados. Se minha memória não falha, todos optaram por instalar o GNOME 3, que é o desktop padrão do Fedora 18. Eu particularmente não gosto dele, e também tive algumas dificuldades (principalmente ao tentar encontrar modos de alterar opções mais avançadas), mas algumas pessoas gostaram do visual. No final, esqueci de contar quantas máquinas foram instaladas, mas creio que chegamos perto de 11. Todas as instalações foram bem sucedidas, até onde minha memória alcança :-). E novamente eu fiquei bastante satisfeito com minha ida à UNESP de Rio Claro! Entretanto, nuvens negras estavam se aproximando, e minha alegria duraria pouco... Install Fest: missão UNICAMP</h2> Há alguns anos começaram a surgir notícias sobre um novo sistema que substituiria a BIOS</a>, permitindo muito mais flexibilidade durante o boot e inclusive adicionando camadas de segurança que protegeriam o usuário de vírus e outras ameaças. Esse sistema chama-se UEFI</a> (e uma das tais "camadas de segurança" chama-se Secure Boot</a>), e no ano passado ele ganhou muita notoriedade porque a Microsoft (R) anunciou que seu então novo sistema, o Windows (R) 8, só poderia ser utilizado em máquinas com UEFI</a>. Isso causou uma corrida dos fabricantes de computador para adaptar-se a esse novo modelo (e ganhar o famigerado selo de compatibilidade da Microsoft (R)), e gerou incoformismo em boa parte das comunidades envolvidas com Software Livre e/ou Open Source. Resumindo, o grande problema desse novo esquema é a necessidade de uma chave criptográfica assinada por uma autoridade certificadora para que o sistema operacional seja iniciado. Essa é a segurança que o Secure Boot</a> provê, e o único jeito de obter uma chave assinada é... (tambores)... pagando à Microsoft (R)! Até onde eu sei, o Microsoft (R) Windows (R) 8 não funciona caso o Secure Boot</a> esteja desabilitado (um meio perfeitamente válido de instalar uma distribuição GNU/Linux que não possui a tal chave criptográfica), então a distribuição é obrigada a compactuar com esse esquema caso queira oferecer a opção de dual-boot ao usuário. E atualmente, as duas únicas distribuições que oferecem isso são o Fedora e o Ubuntu. Bem, depois dessa sucinta explicação, começa aqui meu relato sobre o que aconteceu no Install Fest. No dia 13 de março de 2013, quarta-feira, nos reunimos no Instituto de Computação</a> da UNICAMP para realizarmos a instalação de distribuições GNU/Linux. Novamente, eu levei vários DVDs do Fedora para serem utilizados pelos alunos ingressantes nos cursos de Ciência e Engenharia de Computação. Dessa vez não houve palestra introdutória sobre o Projeto Fedora, mas eu resolvi pegar 10 minutos e explicar as "regras" de um Install Fest. Também comentei sobre a má prática que algumas fabricantes de notebooks têm quando decidem entregar um disco rígido todo particionado e sem a possibilidade de adição de novas partições primárias. Dito isso, começamos a instalar. Infelizmente, devido a diversos fatores como inexperiência, tempo curto para organização do evento, e erro na estimativa de quantas pessoas iriam ao evento, acabamos ficando com muita gente pra instalar e pouca gente pra ajudar. Não chegamos a fazer uma contagem oficial, mas eu suponho que pelo menos 20 pessoas estavam na sala querendo instalar o Fedora. E a grande maioria delas estava com notebooks novos, com Microsoft (R) Windows (R) 8, i.e., com UEFI e Secure Boot habilitados. Conforme íamos reparticionando os discos e bootando os DVDs do Fedora, começamos a perceber que havia algo errado. Depois de terminar a instalação em algumas máquinas, notávamos que o sistema não iniciava. O que tínhamos que fazer, em alguns casos, era desabilitar o Secure Boot (mesmo assim, sem sucesso em alguns casos). E depois disso, o Fedora finalmente era iniciado, mas o Microsoft (R) Windows (R) 8 não aparecia na lista de sistemas operacionais do GRUB! Ou seja, era impossível fazer com que os dois sistemas convivessem na mesma máquina. Tivemos alguns casos um pouco mais graves, mas que no fim foram resolvidos. E antes que você me pergunte qual foi a solução, eu respondo: reabilitamos o Secure Boot, e praticamente desfizemos a instalação do Fedora. Ou seja, a esmagadora maioria dos alunos presentes no Install Fest voltou pra casa com uma máquina sem Fedora ou qualquer outra distro GNU/Linux. Eu pessoalmente vi apenas 2 instalações bem sucedidas, apesar de que depois do Install Fest fiquei sabendo de mais. Saí do evento bastante chateado, achando que a culpa havia sido nossa, e que os alunos nunca mais iriam querer instalar GNU/Linux nas suas máquinas. Mas depois de um tempo, coloquei as idéias em ordem e resolvi escrever este post. Não estou eximindo ninguém da culpa, creio que devíamos ter planejado o Install Fest um pouco melhor, e com certeza aprendemos com os erros que cometemos. Mas acho muito importante apontar alguns dedos e dizer o que realmente aconteceu. Conclusões</h2> A conclusão principal não poderia ser outra. É preciso tomar muito cuidado com essas novas tecnologias de boot. Quando for comprar uma máquina nova, é preciso prestar muita atenção a isso, pois essas novas tecnologias nada mais são do que armadilhas para tirar a sua liberdade de escolher o que quer executar na sua máquina. É preciso lutar contra essas imposições que as empresas fazem (não seja inocente pensando que é só a Microsoft (R) que está por trás disso...), e é preciso tomar conta da sua liberdade. Se quiser demonstrar ainda mais seu apoio contra essas imposições (e entender mais do porquê delas existirem), clique aqui e leia a página da Free Software Foundation sobre o assunto (e assine a petição também!)</a>. Conclusões secundárias: um Install Fest (ou qualquer evento, na verdade) precisa ser organizado com antecedência, e precisa ter bastante gente disposta a ajudar nas instalações. Só assim as coisas fluem. Agradecimentos</h2> Não posso deixar de agradecer o Ricardo Panaggio</a> por me ajudar indo até a UNESP de Rio Claro comigo! Ele também ajudou bastante no Install Fest da UNICAMP. Também gostaria de agradecer ao Marcel Godoy e ao Centro Acadêmico da Computação da UNESP de Rio Claro pela organização e divulgação do Install Fest lá. Muito obrigado! O Install Fest da UNICAMP só foi possível com a ajuda do Grupo Pró-Software Livre</a> da UNICAMP, em especial ao Gabriel Krisman. O Ivan S. Freitas</a> e o Raniere Gaia Silva</a> também ajudaram no apoio logístico do Install Fest. Por fim, gostaria de agradecer à comunidade Fedora pelo apoio com os DVDs. Obrigado a todos! Misunderstanding the Free Software Philosophy 2012-12-17T00:00:00-05:00 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</a>. 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! 2012-12-15T00:00:00-05:00 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</a>! O que é o LibrePlanet</h2> O projeto LibrePlanet</a> teve início em 2006, durante a reunião de membros da FSF</a> (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</a>. O surgimento do LibrePlanet São Paulo</h2> Essa história é um pouco longa, mas vou tentar resumir :-). Tudo começou quando eu, Ricardo Panaggio</a>, Ivan S. Freitas</a> e Raniere Gaia Silva</a> 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</a>, 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?</h2> É simples! Siga os seguintes passos: Entre na nossa Wiki</a>, e leia todas as informações presentes lá antes de qualquer coisa!</li> Depois disso, efetue a criação de seu usuário na FSF, indo até este link de cadastro</a> 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 :-).</li> 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</a>, clique no link Edit, e insira algumas informações sobre lá. Se quiser, utilize minha página pessoal</a> como exemplo. É importante que você insira, no final de todo o conteúdo, a seguinte linha: {% raw %}{{user SP}}{% endraw %}</code>. Ele faz com que você passe a pertencer ao grupo LibrePlanet de São Paulo.</li> Agora, é importante que você também efetue sua inscrição na nossa lista de discussão. Vá até esta página de inscrição</a> 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!</li> Ufa, último passo! Se você utiliza IRC e frequenta a rede Freenode, entre no nosso canal: #lp-br-sp</code>! É lá que a maior parte das discussões acontece, então seria muito legal se você também pudesse participar delas!</li> </ol> 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 2012-12-01T00:00:00-05:00 Nesta última sexta-feira, dia 30/11/2012, estive presente na sétima edição do SoLiSC 2012</a>, em Florianópolis, para apresentar uma palestra introdutória sobre o GDB</a>. Este é um relato sobre minha particição no evento :-). Impressões sobre o evento</h2> 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á</a>, 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</a> 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</code>. 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</a> 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</a>. Apresentação "GDB Crash Course"</h2> 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</a> 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: https://github.com/sergiodj/gdb-unicamp2011</a> (fonte, em Beamer/LaTeX)</li> http://fedorapeople.org/~sergiodj/presentations/2012/SoLiSC/</a> (PDF)</li> </ul> Conclusão</h2> Gostaria de agradecer especialmente à Eliane Domingos</a>, ao David Jourdain e ao Olivier Hallot</a>, todos membros da TDF</a> 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</a> 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! GDB and SystemTap Probes -- part 3 2012-11-02T00:00:00-05:00 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</a>, and the second here</a>. My goal with this third post is to talk a little bit about how you can use the SDT</code> probes with tracepoints</code> inside GDB</code>. 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</code> probes are laid out inside the binary. So, let's start! Complementary information</h2> In my last post, I forgot to mention that the SDT</code> probe support present on older versions of Fedora GDB</code> is not exactly as the way I described here. This is because Fedora GDB</code> adopted this feature much earlier than upstream GDB</code> 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</code> 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</code> 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</h2> Before anything else, let me explain what a tracepoint</code> 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</code>, and those actions will be performed when the tracepoint</code> is hit. Neat, huh? :-) There is a nice description of what a tracepoint</code> in the GDB documentation</a>, I recommend you give it a reading to understand the concept. Ok, so now we have to learn how to put tracepoints</code> 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; }</code></pre> Very simple, isn't it? Ok, to the tracepoints</code> now, my friends. Using tracepoints</code> inside GDB</code></h2> In order to properly use tracepoints</code> inside GDB</code>, you will need to use gdbserver</code>, a tiny version of GDB</code> suitable for debugging programs remotely, over the net or serial line. In short, this is because GDB</code> cannot put tracepoints on a program running directly under it, so we have to run it inside gdbserver</code> and then connect GDB</code> to it. Running our program inside gdbserver</code></h3> In our case, we will just start gdbserver</code> in our machine, order it to listen to some high port, and connect to it through localhost</code>, so there will be no need to have access to another computer or device. First of all, make sure you have gdbserver</code> installed. If you use Fedora, the package name you will have to install is gdb-gdbserver</code>. If you have it installed, you can do: $ gdbserver :3001 ./test_program Process ./test_program created; pid = 17793 Listening on port 3001</code></pre> The second argument passed to gdbserver</code> instructs it to listen on the port 3001 of your loopback interface, a.k.a. localhost</code>. You will notice that gdbserver</code> will stay there indefinitely, waiting for new connections to arrive. Don't worry, we will connect to it soon! Connecting an instance of GDB</code> to gdbserver</code></h3> Now, go to another terminal and start GDB</code> 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</code></pre> The command you have to use inside GDB</code> is target remote</code>. 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</code>, 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</code></h3> Every command should be issued on GDB, not on gdbserver! In your GDB</code> prompt, put a tracepoint</code> in the probe named my_probe</code>: (gdb) trace -probe-stap my_probe Tracepoint 1 at 0x4005a9</code></pre> As you can see, the trace</code> command takes exactly the same arguments as the break</code> command. Thus, you need to use the -probe-stap</code> modified in order to instruct GDB</code> to put the tracepoint</code> in the probe. And now, let's define the actions associated with this tracepoint</code>. To do that, we use the actions</code> command, which is an interactive command inside GDB</code>. It takes some specific keywords, and if you want to learn more about it, please take a look at this link</a>. For this example, we will use only the collect</code> keyword, which tells GDB</code> to... hm... collect something :-). In our case, it will collect the probe's first argument, or $_probe_arg0</code>, 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)</code></pre> Simple as that. Finally, we have to define a breakpoint</code> in the last instruction of our program, because it is necessary to keep it running on gdbserver</code> in order to examine the tracepoints</code> later. If we didn't put this breakpoint</code>, our program would finish and gdbserver</code> would not be able to provide information about what happened with our tracepoints</code>. In our case, we will simply put a breakpoint</code> on line 10, i.e., on the return 0;</code>: Running the trace experiment</h3> Ok, time to run our trace experiment. First, we must issue a tstart</code> to tell GDB</code> to start monitoring the tracepoints</code>. 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)</code></pre> Remember, GDB</code> is not going to stop your program, because tracepoints</code> are designed to not interfere with the execution of it. Also notice that we have also stopped the trace experiment after the breakpoint</code> hit, by using the tstop</code> command. Now, we will be able to examine what the tracepoint</code> has collected. First, we will the tfind</code> command to make sure the tracepoint</code> 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</code></pre> And it works! Notice that we are printing the probe argument using the same notation as with breakpoints</code>, even though we are not exactly executing the STAP_PROBE1</code> instruction. What does it mean? Well, with the tfind start</code> command we tell GDB</code> to actually use the trace frame collected during the program's execution, which, in this case, is the probe argument. If you know GDB</code>, think of it as if we were using the frame</code> 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</code> probe support in GDB</code> with tracepoints</code>. 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</code> probe is laid out in the binary</h2> 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</code>, which is the heart of the whole feature, I also recommend this page</a>, 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</h2> After this series of blog posts, I expect that you will now be able to use the not-so-new feature of SDT</code> probe support on GDB</code>. Of course, if you find some bug while using this, please feel free to report it using our bugzilla</a>. And if you have some question, use the comment system below and I will answer ASAP :-). See ya, and thanks for reading! GDB and SystemTap Probes -- part 2 2012-10-27T00:00:00-05:00 I tell you this: it is depressing when you realize that you spent more time struggling with blog engines than writing posts on your blog! It's been a long time since I wrote the first post</a> about this subject, and since then the patches have been accepted upstream, and GDB 7.5</a> now has official support for userspace SystemTap probes :-). Yay! Well, but enough of cheap talk, let's get to the business! Errata for my last post</h2> Frank Ch. Eigler</a>, one of SystemTap's maintainers, kindly mentioned something that I should say about SystemTap userspace probes. Basically, it should be clear that SDT</code> probes are not the only kind of userspace probing one can do with SystemTap. There is yet another kind of probe (maybe even more powerful, depending on the goals): DWARF-based function/statement probes. SystemTap supports this kind of probing mechanism for quite a while now. It is not the goal of this post to explain it in detail, but you might want to give it a try by compiling your binary with debuginfo support (use the -g</code> flag on GCC</code>), and do something like: $ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo $ stap -e 'probe process("/bin/foo").statement("@file.c:443") { log($$vars) }' -c /bin/foo</code></pre> And that's it. You can read SystemTap's documentation, or this</a> guide to learn how to add userspace probes. Using GDB with SystemTap SDT Probes</h2> Well, now let's get to the interesting part. It is time to make GDB</code> work with the SDT</code> probe that we have put in our example code. Let's remember it: #include <sys/sdt.h> int main (int argc, char argv[]) { int a = 10; STAP_PROBE1 (test_program, my_probe, a); return 0; }</code></pre> It is a very simple example, and we will have to extend it later in order to show more features. But for now, it will do. The first thing to do is to open GDB</code> (with SystemTap support, of course!), and check to see if it can actually see probe inserted in our example. $ gdb ./test_program GNU gdb (GDB) 7.5.50.20121014-cvs Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> ... (gdb) info probes Provider Name Where Semaphore Object test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program</code></pre> Wow, it actually works! :-) If you have seen something like the above, it means your GDB</code> is correctly recognizing SDT</code> probes. If you see an error, or if your GDB</code> doesn't have the info probes</code> command, then you'd better make sure you have a recent version of GDB</code> otherwise you won't be able to use the SDT</code> support. Putting breakpoints in the code</h3> Anyway, now it is time to start using this support. The first thing I want to show you is how to put a breakpoint in a probe. (gdb) break -probe-stap my_probe Breakpoint 1 at 0x4004ae</code></pre> That's all! We have chosen to extend the break</code> command in order to support the new -probe-stap</code> parameter. If you're wondering ... why the -probe prefix?, it is because I was asked to implement a complete abstraction layer inside GDB</code> in order to allow more types of probes to be added in the future. So, for example, if someone implements support for an hypothetical type of probe called xyz</code>, you would have break -probe-xyz</code>. It took me a little more time to implement this layer, but it is worth the effort. Anyway, as you have see above, GDB</code> recognize the probe's name and correctly put a breakpoint in it. You can also confirm that it has done the right thing by matching the address reported by info probes</code> with the one reported by break</code>: they should be the same. Ok, so now, with our breakpoint</code> in place, let's run the program and see what happens. (gdb) run Starting program: /home/sergio/work/src/git/build/gdb/test_program Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8 8 STAP_PROBE1 (test_program, my_probe, a);</code></pre> As you can see, GDB</code> stopped at the exact location of the probe. Therefore, you are now able to put marks (i.e., probes) in your source code which are location-independent. It means that it doesn't really matter where in the source code your probe is, and it also doesn't matter if you change the code around it, changing the line numbers, or even moving it to another file. GDB</code> will always find your probe, and always stop at the right location. Neat! Examining probes' arguments</h3> But wait, there's more! Remember when I told you that you could also inspect the probe's arguments? Yes, let's do it now! Just remember that, in SDT</code>'s parlance, the current probe's argument is a</code>. So let's print its value. (gdb) p $_probe_arg0 $1 = 10 (gdb) p a $2 = 10</code></pre> "Hey, captain, it seems the boat really floats!" Check the source code above, and convince yourself that a</code>'s value is 10</code> :-). As you might have seen, I have used a fairly strange way of printing it. It is because the probe's arguments are available inside GDB</code> by means of convenience variables. You can see a list of them here</a>. Since SDT</code> probes can have up to 12 arguments (i.e., you can use STAP_PROBE1</code> ... STAP_PROBE12</code>), we have created inside GDB</code> 12 convenience variables, named $_probe_arg0</code> until $_probe_arg11</code>. I know, it is not an easy name to remember, and even the relation between SDT</code> naming and GDB</code> naming is not direct (i.e., you have to subtract 1 from the SDT</code> probe number). If you are not satisfied with this, please open a bug in our bugzilla</a> and I promise we will discuss other options. I would like to emphasize something here: just as you don't need debuginfo support for dealing with probes inside GDB</code>, you also don't need debuginfo support for dealing with their arguments as well. It means that you can actually compile your code without debuginfo support, but still have access to some important variables/expressions when debugging it. Depending on how GCC</code> optimizes your code, you may experience some difficulties with argument printing, but so far I haven't heard of anything like that. More to come</h2> Ok, now we have covered more things about the SDT</code> probe support inside GDB</code>, and I hope you understood all the concepts. It is not hard to get things going with this, specially because you don't need extra libraries to make it work. In the next post, I intend to finish this series by explaining how to use tracepoints</code> with SDT</code> probes. Also, as I said in the previous post of this series, maybe I will talk a little bit about how the SDT</code> probes are organized within the binary. See you soon! Relato das Apresentações na UNESP de Rio Claro/SP 2012-10-24T00:00:00-05:00 Conforme eu havia comentado no post anterior</a>, segue o relato sobre as apresentações que fiz na Semana da Computação</a> da UNESP de Rio Claro</a>. TL;DR: Gostei de ter tido a oportunidade de dar as apresentações, e principalmente de ter feito minha primeira palestra como Embaixador</a> do Projeto Fedora</a> no Brasil. Sobre a palestra a respeito do GDB</a>, também gostei do jeito que ela foi conduzida. Notei algumas falhas que precisam ser corrigidas, mas no geral a experiência foi muito boa. Apresentação "O Projeto Fedora"</h2> Foi a primeira apresentação da noite, de acordo com a grade de programação. Começou meia hora atrasada, pois a organização pediu para esperarmos mais pessoas chegarem (estava chovendo bastante no momento, o que dificultou a locomoção). Comecei a palestra falando um pouco sobre o Projeto Fedora. Acabei passando rapidamente pelas origens do projeto, uma falha que pretendo corrigir em próximas ocasiões. Dei muita ênfase na definição de comunidade e no que isso significa quando lidamos com software livre. Confesso que fiz algumas comparações com o Ubuntu, o que talvez não tenha sido uma boa idéia (de acordo com os guidelines do Projeto Fedora para Embaixadores). De qualquer modo, a mensagem foi passada e notei que algumas pessoas se interessaram em conhecer mais a respeito do projeto e da filosofia. Pontos positivos: Creio ter conseguido informar as pessoas a respeito do projeto, com a ajuda dos ótimos slides do Paul W. Frields</a>. É sempre gratificante dar palestras, mesmo que apenas uma ou duas pessoas no final acabem se interessando de verdade. Além disso, me senti bem por estar divulgando um projeto que respeita as liberdades dos usuários (ou pelo menos tenta fazer isso ao máximo), e que eu realmente uso e gosto. Pontos a serem melhorados: Fazer uma palestra um pouco menos "pessoal". É muito difícil conseguir isso, mas tenho a forte impressão de que minha orientação totalmente pró-software-livre acaba (às vezes) afastando algumas pessoas, que vêem no entusiasta por software livre uma pessoa "radical" e "xiita". Preciso pensar um pouco a respeito do assunto... A conclusão é que fiquei bastante satisfeito com o resultado da palestra. Percebi que, depois dela, algumas pessoas vieram comentar que estavam utilizando Fedora, ou que já andavam pensando em trocar de distribuição, que agora o Fedora era uma opção. O objetivo foi cumprido :-). Apresentação "GDB Crash Course"</h2> Creio que essa já é a quarta vez que apresento essa palestra, e a terceira vez junto com meu amigo Edjunior</a>. Sempre que ela termina, fico(amos) com a impressão de que ainda não acertamos no ponto, e dessa vez não foi diferente. A palestra começou em ponto, às 21h, e decidimos tentar uma abordagem um pouco diferente. A última vez que apresentamos a palestra foi no evento da Semana Integrada</a> da PUC Campinas</a>. Naquela ocasião, tínhamos optado por começar falando mais sobre os comandos do GDB</code>, e depois mostrarmos como a coisa funciona, estilo hands-on. Dessa vez, resolvemos ir mostrando a prática junto com a teoria. Ficou melhor, e acho que a apresentação ficou mais fluida, mas ainda assim esbarramos no velho problema da interdependência dos comandos: quando íamos falar sobre breakpoints</code>, precisávamos ter mostrado algum outro comando que só iria ser explicado mais à frente, que por sua vez iria precisar de outro comando, que iria precisar de breakpoints</code>, etc. Enfim, no final acabamos sendo obrigados a pular alguns comandos, e a adiantar a explicação de outros, quebrando um pouco o fluxo dos slides. Notei que algumas pessoas estavam bastante interessadas no GDB</code>, talvez por já programarem há algum tempo. As outras, aparentemente, ainda não conseguiam ver muita utilidade para um depurador, mas mesmo assim tentavam aprender algo que talvez fosse lhes servir no futuro. Já era de se esperar, mas mesmo assim não deixo de me surpreender quando vejo que uma palestra técnica consegue atrair muito mais atenção do que uma palestra "filosófica", como foi a do Projeto Fedora. Talvez seja reflexo da sociedade em que vivemos, ou talvez seja apenas uma impressão errônea da minha parte. A conclusão, finalmente, é que a palestra parece ter sido útil para algumas pessoas (mesmo que poucas), e isso nos dá ainda mais fôlego pra continuarmos tentando divulgar esse projeto pouco conhecido (mas muito útil) que é o GDB</code>. Agradecimentos</h2> Não poderia deixar de agradecer primeiramente à organização da SECCOMP da UNESP de Rio Claro pelo ótimo evento. Fiquei surpreso com a infra-estrutura e, principalmente, com a receptividade das pessoas. Gostei muito do ambiente descontraído, e espero não ter decepcionado muita gente por lá com meus comentários informais e caipiras durante as palestras :-). Também agradeço ao meu amigo Edjunior por ter me acompanhado até sua alma matter para me ajudar na realização da palestra sobre o GDB</code>. Até a próxima! Apresentação na UNESP de Rio Claro/SP 2012-10-23T00:00:00-05:00 Hoje, dia 23/10/2012, estarei na UNESP de Rio Claro</a> para dar duas apresentações na Semana da Computação</a>. A primeira palestra será sobre o Projeto Fedora</a>. Vai ser a primeira vez que falarei sobre o projeto depois de ter me tornado Embaixador</a> do Fedora no Brasil. Confesso que estou um pouco apreensivo, mas escolhi slides muito bons feitos pelo Paul W. Frields</a>, ex-líder do Projeto e bastante competente em suas apresentações. Pretendo fazer um relato sobre a palestra na quarta-feira. A segunda apresentação será sobre o GDB</a>. Essa apresentação vai ser mais um crash course sobre como utilizar a ferramenta, e os slides estão disponíveis em https://github.com/sergiodj/gdb-unicamp2011</a>. Espero que ambas as palestras sejam bem recebidas pelo público! Volto depois pra contar como foi :-). Abraços. GDB and SystemTap probes -- part 1 2012-03-29T00:00:00-05:00 After a long time, here we are again :-). With this post I will start to talk about the integration between GDB and SystemTap. This is something that Tom Tromey</a> and I did during the last year. The patch is being reviewed as I write this post, and I expect to see it checked-in in the next few days/weeks. But let's get our hands dirty... SystemTap Userspace Probes</h2> You probably use (or have at least heard of) SystemTap, and maybe you think the tool is only useful for kernel inspections. If that's your case, I have a good news: you're wrong! You can actually use SystemTap to inspect userspace applications too, by using what we call SDT probes, or Static Defined Tracing probes. This is a very cheap and easy way to include probes in your application, and you can even specify arguments to those probes. In order to use the probes (see an example below), you must include the <sys/sdt.h></code> header file in your source code. If you are using Fedora systems, you can obtain this header file by installing the package systemtap-sdt-devel</code>, version equal or greater than 1.4</code>. Here's a simple example of an application with a one-argument probe: #include <sys/sdt.h> int main (int argc, char argv[]) { int a = 10; STAP_PROBE1 (test_program, my_probe, a); return 0; }</code></pre> As you can see, this is a very simple program with one probe, which contains one argument. You can now compile the program: $ gcc test_program.c -o test_program</code></pre> Now you must be thinking: "Wait, wait... Didn't you just forget to link this program against some SystemTap-specific library or something?" And my answer is no. One of the spetacular things about this <sys/sdt.h></code> header is that it does not have any dependencies at all! As Tom said in his blog post</a>, this is "a virtuoso display of ELF and GCC asm wizardy". If you want to make sure your probe was inserted in the binary, you can use readelf</code> command: $ readelf -x .note.stapsdt ./test_program Hex dump of section '.note.stapsdt': 0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap 0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@. 0x00000020 00000000 00000000 00000000 74657374 ............test 0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob 0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...</code></pre> (I will think about writing an explanation on how the probes are laid out on the binary, but for now you just have to care if you actually see an output from this readelf</code> command.) You can also use SystemTap to perform this verification: $ stap -L 'process("./test_program").mark("*")' process("./test_program").mark("my_probe") $arg1:long</code></pre> So far, so good. If you see an output like the one above, it means your probe is correctly inserted. You could obviously use SystemTap to inspect this probe, but I won't do this right now because this is not the purpose of this post. For now, we have learned how to: Include an SDT probe</code> in our source code, and compile it;</li> Verify if the probe was correctly inserted.</li> </ol> In the next post, I will talk about the GDB support that allows you to inspect, print arguments, and gather other information about SDT probes</code>. I hope you like it! My workflow with GDB and git -- part 1 2011-11-29T00:00:00-05:00 This post is actually a "reply" to Gary Benson's Working on gdb</a> post. I have been working with GDB</a> for quite some time now, and even though the project officially uses CVS</a> (yes, you read it correctly, it is CVS indeed!) as its version control system, fortunately we also have a git</a> mirror. In the end, what happens is that almost every developer uses the git mirror and just goes to CVS to commit something. But this is another discussion. Aside of this git mirror, we also have the Archer</a> repository (which uses git by default). My plan here is to show you how I do my daily work with GDB. The workflow is pretty simple, but maybe you will see something here that might help you. Checking out the code</h2> The first thing to do is to check out the code. I only have one GDB repository here, and I make branches out of it whenever I want to hack. So, to check out (or clone, in git's parlance) the code, I do (or did): With this, we have just cloned the GDB repository, and also added another remote (i.e., repository). This is useful because we might want to hack on a branch which is on Archer, but use GDB's master branch as a base. Create a new branch for your work</h2> So, now it's time to create a new branch for you. Here I use one of my little "tricks" (taught to me by my friend Dodji</a>), which is the command git-new-workdir</code>. This is a nice command because it creates a new working directory for your project! Maybe you're wondering why this is so cool. Well, if you ever worked with git, and more specifically, if you ever used more than one branch at a time, then maybe you will understand my excitement. In this scenario, having to constantly switch between the branches is not something rare. When you have uncommited work in your tree you can always use git stash</code>, but that is not the ideal solution (for me). Sometimes I would forget what was on the stash, and later when I checked it, it was full of crap. Also, I like to have a separate directory for every project I am working on. It is also important to mention that git-new-workdir</code> is under the directory /usr/share/doc/git-VERSION/contrib/workdir/</code>, so I created an alias that will automagically call the script for me: So, after setting up the script, here is what I do: Build GDB</h2> In order to build the project, I create a build-64</code> directory inside my project directory (which, in the example above, is work/lazy-debuginfo-reading</code>). GDB fortunately supports VPATH building (i.e., build the project outside of the source tree). I strongly recommend you to use it. As you may have noticed, I use -g3</code> (include debuginfo) and -O0</code> (do not optimize the code) in CFLAGS</code>. Also, since some of the features I work on may affect code in other architectures, I use --enable-targets=all</code>. It will tell configure to compile everything related to all architectures (not only x86_64</code>, for example). At last, I specify a separate debug directory which GDB should use to search for debuginfo files. Finalizing (for now)</h2> After that, you will have a fresh GDB binary compiled in the build-64</code> directory. But that is not enough yet, since you will also want to test GDB and make sure you didn't insert a bug while hacking on it. In my next post, I will explain what is my "testflow". I hope it will be useful for someone :-). Stay tuned!

Accessing the superuser shell inside ChromeOS</h2>
Now, you will need to access the superuser (`root</code>) shell inside ChromeOS, to enable SeaBIOS. Followthe steps described in the Arch[GNU/]Linux wiki page</a>. For this specific step, you don't need to login, which is good.</p>`

So long, Ambassadors...

Document Freedom Day 2013 in Campinas -- São Paulo -- Brazil

Relato dos Install Fests na UNESP de Rio Claro/SP e na UNICAMP/SP

Misunderstanding the Free Software Philosophy

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

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

GDB and SystemTap Probes -- part 3

GDB and SystemTap Probes -- part 2

Relato das Apresentações na UNESP de Rio Claro/SP

Apresentação na UNESP de Rio Claro/SP

GDB and SystemTap probes -- part 1

My workflow with GDB and git -- part 1

- fedora-planet

Improve gcore and support dumping ELF headers

Memory mappings, core dumps, GDB and Linux

Respectful Software

Fedora on an Acer C720P Chromebook

Reflexões de um ativista -- Parte 02

About coherence, Twitter, and the Free Software Foundation

Reflexões de um ativista -- Parte 01

Relato: FAD SP 2013

GDB and SystemTap integration improving linker-debugger interface

- fedora-planet

Improve gcore and support dumping ELF headers

Memory mappings, core dumps, GDB and Linux

Types of memory mappings</h2> There can be four types of memory mappings:</p> Anonymous private mapping</li> Anonymous shared mapping</li> File-backed private mapping</li>

Anonymous</code></h3> A mapping is anonymous if one of these conditions apply:</p> The pathname</code> associated with it is either /dev/zero (deleted)</code>, /SYSV%08x (deleted)</code>, or <filename> (deleted)</code> (see below).</li>

Respectful Software

Fedora on an Acer C720P Chromebook

Reflexões de um ativista -- Parte 02

About coherence, Twitter, and the Free Software Foundation

Reflexões de um ativista -- Parte 01

Relato: FAD SP 2013

GDB and SystemTap integration improving linker-debugger interface

So long, Ambassadors...

Disappointment</h2> A few things started to happen:</p> During the weekly LATAM meetings, it bothered me to see that the tickets were being approved without any kind of serious discussion. Everyone (including myself!) was just giving "+1" to everything!</li>

Document Freedom Day 2013 in Campinas -- São Paulo -- Brazil

Relato dos Install Fests na UNESP de Rio Claro/SP e na UNICAMP/SP

Misunderstanding the Free Software Philosophy

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

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

GDB and SystemTap Probes -- part 3

GDB and SystemTap Probes -- part 2

Relato das Apresentações na UNESP de Rio Claro/SP

Apresentação na UNESP de Rio Claro/SP

GDB and SystemTap probes -- part 1

My workflow with GDB and git -- part 1