Wireless no positivo mobo white

Opa! Minha obsessão por escrever posts arrumadinhos faz com que eu nunca blogue nada. Vou tentar me livrar disso, e aqui vai um post direto de um email que escrevi no XAPlivre.

Pra quem tem mobo white ou outros clones/OEM do MSI Wind que possuem wireless rtl8187se (rodem lspci num terminal pra conferir), o site abaixo contém os fontes de um driver livre que compila sem erros e funciona muito bem.

http://code.google.com/p/msi-wind-linux/

Procurem os fontes em tar.bz2 nos downloads da página e instalem o pacote kernel-devel para obter os headers C necessários para compilar módulos de terceiros para o kernel instalado. Pelo menos no Fedora o nome do pacote é kernel-
devel.

Descompactando o tar.bz2, basta entrar no diretório rtl8187se_coffee e rodar o script makedrv para compilar os módulos, e depois rodar o script wlan0up como root. Este último vai inserir os módulos no kernel em execução e a partir daí depois de alguns segundos o Network Manager já vai reconhecer a placa wireless.

Fora o wireless, cujo driver ainda não está upstream, o Fedora 11 detecta e roda muito bem todo o hardware do mobo white. A bateria tem durado um pouco mais de 4h, mesmo com uso não trivial. Uma ótima combinação!

Fábulas de Esopix

Este post tem umas três partes que poderiam ter sido postadas separadamente, mas acho que não é assim que a gente funciona... então vai junto mesmo. :)

Eu sou fã de livros de bolso, os pocket books como os da L&PM Pocket e da Martin Claret. De certa forma, dá pra se argumentar que os pocket books são os precursores dos netbooks que estão invadindo o mercado hoje em dia, já que desde a segunda guerra os pocket books se tornaram sinônimo de informação com mobilidade, praticidade e preço baixo. Numa época em que os livros eram feitos em encadernações luxuosas, pesadas e caras (veja como se presta a representar notebooks tradicionais), de repente surgiu a idéia de criar livros mais simples e baratos para a população de baixa renda (OLPC, anyone?). Com o tempo, a popularização dos pocket books foi tão grande que qualquer banca de revistas os tinha à venda (Mobo nas casas Bahia e assemelhadas?), e então começaram a surgir as coleções de pocket books "de luxo", com uma encadernação mais refinada, porém ainda simples, e papel mais branco e resistente (com certeza quem leu até aqui consegue visualizar MSI Winds, Acer Aspire Ones e Mobo Whites da atualidade).

Acho que o papel dos livros de bolso na disseminação da cultura e da educação (instrução?) têm o mesmo papel que os netbooks carregados de software livre hoje em dia. O bom é que os livros de bolso não precisam de bateria e têm cheirinho de livro! Quer saber o que me dar de natal? Faça random(400) e me dê o livro de bolso com o número sorteado da coleção "A Obra Prima de Cada Autor" da Martin Claret. :D

Há algumas semanas eu e a Fran estávamos no ótimo Café Brasiliano, aqui em Chapecó, e lá tem estandes tanto da Martin Claret quanto da L&PM (é uma cachaça). Enquanto tomávamos café, eu percebi dois livros bem interessantes: Fábulas de La Fontaine (nº 200) e Fábulas de Ésopo (nº 182). Ambos possuem um pouco da história das fábulas, dos seus autores, e uma explicação a cerca do gênero literário que geralmente se encontra passando por fábula. É interessante saber que inicialmente poucas fábulas eram escritas para crianças, ao contrário do que se pensa. A grande maioria das fábulas se prestava a transmitir algum conhecimento moral ou simples experiência de vida para adultos se tornarem também menos obtusos (e na verdade, algumas me parecem puramente manipulação da massa iletrada).

A fábula é um misto de conto, provérbio e poema. Sempre tem uma lição de moral, mas para transmitir a lição faz uso de uma narrativa (se não tivesse a narrativa seria um provérbio). A narrativa pode ser em prosa (conto) ou em verso (poema). Um dos aspectos mais interessantes é o universo ilimitado dos personagens, já que na fábula tudo tem vida. Se fossem apenas narrativas sobre humanos com uma lição de moral, seriam parábolas. ;-) Mas na fábula se pode ver um musgo conversando com uma pedra, ou um deus e um mortal, ou ainda um pássaro, uma raposa e uma roseira. Essa liberdade faz com que o formato seja reconfortante, por nos levar de volta a um universo infantil e fantasioso, e até surpreendente, já que nunca imaginamos quem (ou o quê) mais sairá do plano dos objetos e se tornará sujeito de alguma ação para daí dar um sentido mais profundo para a narrativa (a "moral da história").

Pois bem, e o título desse post, afinal, o que significa?

Tenho lido várias fábulas de Ésopo e de La Fontaine, e um dia arrumando as caixinhas de CDs do OpenBSD na estante, de repente me caiu uma ficha daquelas: faz anos que os caras do OpenBSD vêm contando pequenas fábulas em cada uma das suas edições! A cada edição vem uma historinha no encarte da caixinha, contando com personagens (que são animais) um pouco do que aconteceu no projeto e no mundo do software livre nos meses anteriores à edição.

De repente me deu uma baita vontade de criar pequenas histórias nesse formato, usando personagens que representem projetos de software livre e outros players do mundo Unix em geral, de forma a divertir e informar (ou confundir) os leitores. Aí se fez necessário criar um pseudônimo para assinar essas histórias, e surgiu o Esopix. :D

Esopix foi um admirador do mundo Unix que viveu no final do século XX e início do século XXI e, temendo que as gerações mais novas pudessem esquecer as lições do passado, passou a documentar passagens que representassem a essência daquilo que "os antigos" aprenderam desde os tempos imemoriais. Ele não era muito experiente, e nem tudo o que ele escrevia era verdadeiro ou mesmo correto, mas pelo menos ele tentou deixar um legado em prosa ou verso das lições mais importantes que havia aprendido.

Espero que gostem do resultado... :)

OpenBSD no EeePC

Logo antes do evento TcheLinux em Santa Maria, o Filipe Rosset passou aqui em casa e me deixou emprestado um EeePC 701 (aqueles pretinhos minúsculos originais, certamente projetados por oftalmologistas) pra mim fuçar e eu resolvi instalar OpenBSD nele.

Baixei um snapshot para i386 (eu procuro comprar as caixinhas de CDs para ajudar (e porque são bonitas e divertidas) mas sempre instalo snapshots), botei num pendrive, bootei o pendrive e instalei direto no disquinho SSD dele (acho que é SSD né? não lembro direito). Foi até chato, instalou sem nenhum problema. O único ajuste necessário foi desabilitar o suporte a APM (config -ef /bsd; disable apm; quit), já que o BIOS do EeePC suporta tanto APM quanto ACPI mas na verdadade algumas coisas só funcionam bem com o ACPI mesmo e o APM fica atrapalhando.

Como era de se esperar, a WiFi Atheros não funcionou, e eu achei que a webcam funcionaria, mas também não funfou. Plugando outra WiFi em uma portinha USB o bichinho ficou bem divertido.

O que me lembrou disso ontem foi ver um commit no OpenBSD habilitando o suporte a modo bulk no driver de webcams USB, o que fez a câmera do EeePC 701 funcionar. Com as recentes atualizações no driver de DRM no kernel e no X, o EeePC teria também aceleração 3D por default (sem configurar nada). Só falta aquela porcaria de Atheros proprietária.

Juntando também o recente servidor de som nativo, com conversão automática entre formatos de múltiplas streams, o OpenBSD está ficando cada vez mais apetitoso no desktop... e acho que fica ótimo num netbook, por ser simples, completo e enxuto.

Estou curioso para ver como os snapshots mais recentes do OpenBSD se comportam num Acer Aspire One. Alguém discorda que os AA1 são os melhores netbooks atuais?

TcheLinux Porto Alegre 2008

"O evento foi tão bom que vou começar a blogar de novo por causa dele."

Mas bah! Me aventurei em uma viagem bate-e-volta para passar o sábado passado em Porto Alegre, saindo de Chapecó às 23h de sexta e chegando em POA às 5h30 da manhã de Sábado. Eu e o Filipe Rosset, bom amigo aqui de XAP que anda se enveredando pelo TcheLinux e pelo seu irmão caçula (e bem recente) XAPlivre. Chegamos na rodoviária, tomamos café da manhã e fomos pra PUC. Chegamos lá umas 6h30, acho. Fomos os primeiros a chegar e causar espanto nos guardas da PUC (um com chapéu vermelho e o outro com camiseta de pinguim), mas logo mais gente foi chegando, fomos nos apresentando (para os novos) ou botando os papos em dia (para os velhos conhecidos).

Como pra voluntário do TcheLinux não tem moleza, antes de termos um chimarrão pronto já estávamos arrastando mesas, abrindo caixas, ajudando a organizar a lojinha, o local para guardar os donativos, colando cartazes, preparando crachás, etc. Finalmente chega o Douglas Landgraf com uma bomba de chimarrão (pô Filipe, essa foi triste) e depois de uns mates o cérebro sai do modo uni-neurônio. Começou a chegar gente pra fazer inscrição, começaram a chegar donativos, e eu lembrei que obviamente ainda tinha que terminar minhas apresentações pra duas palestras (ainda bem que eram só à tarde).

Começou a encher de gente, vários amigos chegando, colegas do trabalho atual, de outros trabalhos antigos, e inclusive uns tanto do trabalho atual quanto de outros trabalhos antigos (vai entender). Depois da primeira enxurrada de gente e donativos que ajudei a organizar (me especializei em ensacar sacos de donativos) fui correndo pra abertura do evento. Mais uma vez o Leo manda aquela abertura ótima, algo como "é isso aí gurizada, estamos um pouco atrasados então vamos lá. É um prazer estar aqui, espero que gostem do evento e mãos à obra!". O TcheLinux prega muito o método "shut up and hack" e no evento não poderia ser diferente... "Bom dia a todos, vamos fazer desse um ótimo evento e agora se mandem pras palestras que é o que importa!".

Me mandei pra sala onde seriam minhas palestras, mais tarde, e me dediquei ao meu esporte predileto: dar palpite nas palestras dos colegas. Algumas pessoas ficam mais nervosas do que outras, algumas começam a palestra meio fechadas ou rígidas, e inclusive o público às vezes está meio frio. O que eu faço? Entro na sala e largo uma piada ridícula. :D Nem fico (mais) vermelho, mas com a descontração do público e do palestrante a tensão desaparece e a palestra se torna quase uma conversa entre amigos. E, na minha humilde opinião, é pra isso que nós fazemos os eventos: para que as pessoas interajam e saiam com mais conhecimento. Todas as pessoas, inclusive os palestrantes.

Cheguei na palestra do Maraschini, sobre pipes, e vi que ela está melhor do que foi em Santa Maria. Mais uma prova de que todos aprendem nos eventos, inclusive os palestrantes. Com a interação da platéia e algumas conversas entre amigos, a palestra de repente se torna mais do que havia nos slides. E aí entra o Douglas, com a sua palestra mutante sobre como colaborar com o desenvolvimento do Linux. Tem tantos assuntos que podem ser falados, aspectos técnicos, culturais, comportamentais, ou mesmo simples procedimentos. Como essa palestra não é rigidamente estruturada, eu aproveito pra dar pitaco a toda hora, e não raro algum ouvinte faz algum comentário que vira uma sub-palestra de uns 15 a 20 minutos. É uma conversa entre iguais, onde quem está na frente apenas tem a responsabilidade de manter um pouco o foco e o caminho dos assuntos. Essa é a troca que eu mais gosto nos eventos do TcheLinux: a gente nunca sabe exatamente onde uma palestra vai parar, mas tem certeza que vai aprender algo que não esperava (ainda mais quando estão na sala o Luis Claudio, o Arnaldo e o Eduardo, velhos colegas e amigos, para trazer mais experiência para as conversas).

Próximo do almoço eu finalmente terminei minha primeira apresentação. :D A segunda já estava parcialmente pronta, e francamente a segunda palestra que eu apresentei acabou sendo tão abrangente que os slides não adiantariam muito. Vou evitar fazer palestras assim tão grandes no futuro, e parar de estourar o tempo das palestras (já estou queimando a paciência dos amigos com minhas palestras sem fim).

Logo depois do (farto) almoço, o Luis Claudio conseguiu uma proeza: ninguém dormiu na palestra dele! O assunto, Real Time Linux, é bem interessante, e o Luis Claudio domina o assunto e a platéia... acabei fazendo só uma ou duas intromissões, já que não conseguia ficar quieto. Aí vem o Arnaldo, e nos esmaga com sua apresentação animal sobre as tecnologias atuais de depuração do kernel, sua motivação, história e estado atual. Algumas das tecnologias que ele falou ele mesmo criou, adaptou ou ajuda a desenvolver. É difícil achar um evento no Brasil onde esse tipo de assunto fosse falado por alguém tão íntimo com estas tecnologias. Ficou legal o link entre a minha palestra e a do Arnaldo, porque ele falou de várias tecnologias, inclusive SystemTap, e depois eu aprofundei e demonstrei com exemplos como usar SystemTap.

Terminada a palestra do Arnaldo, eu levo meu notebook pessoal, chinelão, pro projetor e nada (eu já esperava). Aí peguei o notebook da Red Hat, esse com pedigree, e nada também. Putz! O ThinkPad nunca negou fogo pra um projetor de vídeo antes! Acabei tendo que usar o notebook do Arnaldo e perdi vários minutos no início da apresentação sobre SystemTap (que, aliás, gostei bastante de apresentar). Consegui acabar a palestra de SystemTap quase na hora que deveria (ei, dá um desconto já que deu problema no notebook), tomei um copo d'água e já continuei falando começando a palestra sobre diagnóstico de problemas não triviais em redes TCP/IP (com Linux, obviamente). Eu realmente preciso fechar um pouco mais o escopo dessa palestra, sempre estoura o tempo.

Tinha muito mais gente na palestra de TCP/IP do que na de SystemTap, o que é de se esperar, já que o assunto interessa a quase qualquer pessoa da área de informática hoje em dia. Fiquei com a sensação de que eu fui melhor na de SystemTap, talvez porque o escopo era menor e mais focado, porém menos gente viu ela. Aí quando lota a sala na de TCP/IP eu acabo falando de tantas coisas que nem olho pros slides pra saber onde eu deveria estar. "Na próxima eu melhoro", eu sempre prometo.

Acabadas as minhas palestras, eu corri pro auditório pra fazer o painel sobre trabalho com software livre. Eu nem tinha idéia do que seria conversado, mas foi bem divertido, e acho que foi instrutivo para quem estava lá. Tendo o Arnaldo, eu, o Aurélio e o Leo fazendo uma ponta também, com o CASantos pra moderar, até que tinha bastante variedade de opiniões e experiências. Achei muito legal que algumas pessoas da platéia participaram bastante, com opiniões e informações que geraram boas discussões. É esse o ponto! Os eventos são pra isso, interagir e todos crescerem com o debate. Acho que atingimos o objetivo.

Aí ficou tranquilo... encerramento, agradecimentos, abraços nos velhos amigos. Não consegui comprar o livro de shell do Aurélio, nem as canecas do grupo que eu queria, mas isso me deixou feliz! Melhor que tenham ido para pessoas que estão começando e bem motivadas do que para um macaco velho como eu (já fazem 14 anos que fuço em Linux).

Me despedi do pessoal todo e fui correndo visitar meu irmão. Já eram mais de 19h30. Fiquei na casa dele exatos 5 minutos e ele me levou correndo pra rodoviária. Cheguei na rodoviária às 20h30, entreguei a passagem, subi no ônibus e ele partiu.

Viajei no total 13 horas e 30 minutos, e fiquei em Porto Alegre 15 horas. Foi quase meio-a-meio, e eu obviamente estava completamente exausto. Mas essas 15 horas foram fantásticas. Pude rever bons amigos, aprender, ensinar, fazer novos amigos, e ajudar inclusive gente que eu nem conheço a ter o que comer. Dei pitaco em 4 palestras, apresentei duas e participei de um painel. ACTION PACKED!

Sinceramente, os eventos do TcheLinux estarão sempre entre os melhores sábados que já tive. Espero que novos membros comecem a se engajar na organização dos eventos e mantenham esse espírito vivo.

Em verdade, em verdade vos digo

"Deixar a vida nos levar" é um misto de covardia e irresponsabilidade. "Viver o momento" é estar absolutamente consciente e atento, é procurar experimentar a Verdade. Não são os instintos que nos tornam humanos. Os instintos nos tornam plantas. As emoções nos tornam animais. A razão nos torna humanos. A Vontade é requisito da Liberdade. Você já identificou um arquétipo hoje? The Matrix has you, Neo.

Tchelinux's Software Libre Seminar in Pelotas

IMHYBO (In my humble yet biased opinion) it was a great success!

We had around 300 people attend, collected around 600Kg of food for those in need, and everyone had a great time organizing, presenting and attending talks. I was really impressed with the interest of the participants, and the age distribution. It was really great to see talks about fairly complicated subjects, such as steganography, virtualization and internals of the linux kernel being attended by both fairly young and fairly "experient" :) people.

Personally, I barely looked at the slides for my talk about the workings of the TCP/IP and networking in general inside the kernel. The audience had so many questions and comments that the talk was more of a guided tour, with their questions leading the way.

I want to present my deepest THANK YOU to Marilton, from UCPel, who got us all the infrastructure we needed for the event, in such short notice. I don't think there was a single problem or issue throughout the whole day.

And of course, THANKS to all my friends at TcheLinux! If we keep on maintaining such great quality at our events, we're surely going to make people understand what the spirit of Software Libre is all about. We just gather together and make things happen, no frills or large egos to stand in the way, and in the end everyone wins.

Nice NFS race condition

Lately I've been working fairly hard to find out an NFS problem that seemed very weird. I knew it had to be a race condition somewhere, because of the way in which it was reproduced and the contradicting information I got from the various debugging tools used (tcpdump, systemtap, nfs_debug, etc). The problem is that my initial estimate was "a race condition somewhere in the server or the client". Pretty broad, eh? But like many seemingly complex problems, once you really understand it it's so simple it makes you want to cry.

Whenever a process asks Linux to open or stat a file, the actual path lookup for that file happens through the "directory entry cache" (dentry cache, dcache). Since it would be a huge performance loss to actually have to go to disk (or a server) whenever you want to lookup an entry in a directory, Linux keeps a cache in memory of the currently (or at least recently) used portion of the whole filesystem structure (including all mount points). It is kept as a tree, just like the filesystem structure, so it's easy to navigate through it and quickly lookup a file or directory, or at least get to the parent directory of an entry and get the parent's inode to issue the lookup call on.

There are two types of dentries in the dcache: positive and negative. A positive dentry is what you would expect: a dentry for an existing file or directory, with a pointer to it's inode. Another interesting information to keep in the cache is about files or directories which we know *do not* exist. If we lookup a file and find out it does not exist, we can surely keep that infomation around for whoever asks again until we notice the directory has changed. So that's the role of a negative dentry: one whose inode pointer is NULL. So if you lookup a file and find its dentry and it has a NULL inode pointer, you know the file has been looked up recently and does not exist.

It's probably an even better optimization to cache dentries for files that *do not* exist than it is to keep for files which *do*. Just do an strace on any quick shell command and take a look at the number of files it tries to open and fails. Think of things like looking for a library in several possible paths. Or localization files. Many attempts fail until the file is found at one of the possible locations. Specially on NFS, it is very expensive to have to send a lookup to the server and wait for the answer only to find out the file does not exist. So NFS tries specially hard to keep negative dentries around.

So how do we know when to trust and when not to trust dentries in the dcache? We look at the modification time of the directories containing them. If the directory changed since the dentry was created, we revalidate it against the filesystem on disk or the server. And here lies the root of our problem. How precise is the timestamp kept on files and directories? Usually the precision is one second. And we know a lot can happen in one second.

Imagine a directory is changed in an NFS export in a server. And imagine an NFS client looks up a non-existant file in that directory and gets (rightfully) told by the server the file does not exist. Now imagine some process in the server creates the file that was just looked up by the NFS client. And now, imagine the three things happen in one and the same second.

Oops! The directory changed in the server and we cannot detect it! Why? Because the time resolution of one second was not enough to indicate the second change happened. Since they all happened in the same second, the NFS client cannot detect the directory changed, and it will not expire its negative dentry in the dentry cache. So the NFS client will keep thinking this file does not exist.

Do you want to see it for yourself? Easy! Follow these simple instructions:

# mkdir -p /local/foo /nfs/foo

# echo '/local/foo *(rw)' >> /etc/exports

# service nfs start (or whatever the incantation is in your Linux distro)

# mount localhost:/local/foo /nfs/foo

# touch /local/foo; stat /nfs/foo/bar; touch /local/foo/bar

If you were lucky enough that the three commands in the line above all executed in the same second, you will get the prize:

# ls -la /nfs/foo
total 16
drwxr-xr-x 2 root root 4096 Mar 4 03:06 .
drwxr-xr-x 3 root root 4096 Mar 4 03:04 ..
?--------- ? ? ? ? ? /nfs/foo/bar

See how ls lists the entry but cannot stat it to display informations about it? strace the ls command if you want, it's really that simple. The entries returned in the getdirents call are ".", ".." and "bar", yet stating "/nfs/foo/bar" gets an error response stating the file does not exist.

Of course, now that I know how simple it is and I don't have to stare at thousands of captured NFS packets and insert yet another dfprintk or systemtap probe to try and make sense of things, I even think it is beautiful. It's so simple and easy to reproduce. :) If you touch the directory again, Linux invalidates the cache and things go back to normal. But until you do, it will keep trusting that cached information.

Now all we need is to figure out The Right Thing to do about it. My first attempt requires that client and server have their clocks synched with NTP or some such, and involves not caching lookup information if we notice the directory has been changed just this second, because we know there could be other changes which we don't know about. I'm still trying to work it out with the NFS gurus, though, and I might come up with a better way to handle it.

Charuto e lua na madrugada

Madrugada de um longo dia de trabalho, com muitas batalhas e algumas vitórias. Saio pra rua por volta das duas e meia, pra comemorar as vitórias fumando um charuto (meio charuto, na verdade; os tais half-coronas) e dar um tempo pra cabeça esfriar um pouco. Como é bom morar em uma casa! Chego no cantinho da charutada e o que vejo? A lua nascendo no leste, se descortinando aos poucos em meio a nuvens e alguns galhos de árvores próximas. Passo um tempo admirando-a e aparentemente ela gostou de ser observada, pois logo moveu do caminho todos os obstáculos e ficou bem exposta, grande e luminosa. Baforeio (tecnicamente era pra ser "baforo" mas é tão feio) o charuto enquanto admiro a lua e escuto o vento nas árvores e as marolas da lagoa próxima. Parecia de encomenda! E ainda o tradicional órion em cima pra brincar de achar as "três marias".

O mais divertido do dia foi procurar um possível problema de desempenho em máquinas ia64 ao ler o arquivo /proc/net/tcp. Parece mentira, mas ler esse arquivo em algumas máquinas grandes demorava um tempão (wall clock) e causava uma baita contenção de read_locks, a ponto de grudar CPUs em 100% de soft irqs e degradar o desempenho geral. Como a gente sempre pensa no pior, lá estava eu pensando em problemas de alinhamento ou coerência de cache ou alguma outra especificidade da máquina em que o problema ocorria no acesso à memória para estes locks ou estruturas específicas do TCP.

A minha sorte foi ter que parar de trabalhar nisso e focar em outro problema urgente, pois assim um colega seguiu investigando o problema por outro lado. Ao testar em máquinas diferentes ele viu que o problema estava relacionado ao tamanho da memória, pois demorava mais em máquinas com mais memória, de forma linear. Lá pelas tantas ele achou o "problema", que na verdade (como sempre) é uma feature que saiu pela culatra.

Para ler este arquivo se faz um loop sobre o tcp_ehash, listando todas as conexões atuais. O tcp_ehash é alocado durante o boot, calculado como uma fração do máximo de memória que o kernel pode alocar para suas próprias estruturas durante o boot. Em arquiteturas x86 e derivadas, isto está limitado à quantidade de lowmem, e portanto tem um limite superior razoavelmente baixo que nunca será ultrapassado. Só que em máquinas de verdade, que não precisam perder tempo com essa incomodação de dma zone, low mem e high mem, não existe um limite específico, e o hash cresce linearmente com a memória.

Aí em x86 o hash nunca passa de 262144 entradas (o que provavelmente já é bem mais do que o necessário), mas em uma ia64 com 96GB de RAM o hash catou 16777216 entradas. Fazer um loop dentro do kernel, pegando locks, para 262144 entradas é beeeem mais rápido do que repetir o loop 16 milhões de vezes. O meu colega testou inclusive em uma máquina ia64 com 1TB de RAM, e não teve paciência de esperar o programa de teste terminar. Ele não me disse quantos hash entries foram alocados, mas calculo algo em torno de 178 milhões. Agora imagina rodar netstat em uma máquina quieta, quase sem conexões, e o comando ter que esperar o kernel fazer loops pegando e soltando locks 178 milhões de vezes, principalmente quando 99.999% das hash entries estão vazias?!?! Massa!

O lado bom é que se pode limitar o número de hash entries via um parâmetro no boot... thash_entries=32768 deixa o hash pequeninho e provavelmente não atrapalha nada. :) Claro que será legal avaliar bem o uso deste hash e tentar chegar numa função mais apropriada para o cálculo do seu limite. Mas pelo menos o "problemão bizarro" está remediado.

Esse pensamento de que "o mundo inteiro é x86" às vezes atrapalha... quando máquinas de verdade entram no jogo, a escalabilidade vai pras cucuias. É como o meu colega disse: "problemas de lentidão em ia64 geralmente são apenas problemas gerais de escalabilidade que as outras arquiteturas simplesmente não são grandes o suficiente para alcançar".

Só essa última afirmação valeu o charuto. :)

Bin Buddhism, New Job

Bin Buddhism: a philosophy like Zen Buddhism, but oriented towards eliminating suffering caused by attachment to data bits. All bits are an illusion, be them on disk or on tape. Backups are an illusion of an illusion. All data vanishes anyway.

OK, that was cheap. But at least I'm posting something after a long time.

Job Update! I'm now working for Red Hat, which means I'm back to my beloved Linux world! I still keep a passion for OpenBSD, and I like to inspire my work on it, of course. It's been a rough start, as I slowly get used to processing massive amounts of information every day, but nevertheless I can say that I'm feeling realized as a professional again, as I used to feel when working for Conectiva. I might end up posting more often now. :)

FUN: Why learn the API when there's javadoc?

OK, it's fake, but it's fun!

Old passions revisited: linux-ha and kernel hacking

Wow, long time no post. As usual. Anyway I decided to write something to mark this moment when I'm slowly going back to my most pleasurable mind games: Linux High-Availability projects and Linux kernel hacking for fun and profit. I'm slowly finding the old mailing lists, checking the archives, setting up mail filters to keep the sanity level on average, reading up on articles and whitepapers... all the pleasing activities of simple and uncompromised curiosity/creativity.

This is not to mean I'm not using OpenBSD anymore. I'm still in love with OpenBSD and still think there are lessons to learn there. Lessons of simplicity, correctness and cleanliness. My HDs will always carry an A6 partition from now on. :-) It's just that most of my friends are Linux people, and it's easier for me to find ways to participate and contribute on Linux than on OpenBSD, which is not that well known where I live. And it's also surely easier to find Linux development jobs.

Now that I have the time and resources to participate better in the "community", I've been remembering the forgotten "warm fuzzy feeling" of helping people on mailing lists, coding and simply sending patches away, just helping. Maybe that's the reason why I hadn't been feeling quite myself in the last several months. Kernelnewbies, here I come! (BTW, Happy Birthday Rik! Live long and prosper!)

pt_BR: Como gerenciar projetos sem tirar o tesão do desenvolvimento?

O que se pode fazer quando precisamos parar e pensar em headers HTTP, webservices e escovação de bits, mas as ferramentas de gerência só entendem números de requisitos e Use Cases de alto nível? Como convencer um ou todos os clientes internos a pagar TAMBÉM pelo trabalho de infraestrutura necessário para viabilizar as suas features?

Tenho saudades do tempo em que eu simplesmente fazia cvs commit e mandava email pra uma lista. :-(

Kids, parents and free software

• Four-year-old son suddenly gets crazy about breakout/arkanoid-type games.
• Father downloads five game variations for the son to check out.
• Son picks the one he likes the most.
• Father hacks the game to start with 999 balls.
• Profit!

Ahh rainy weekends are just not a problem anymore. :)

Addendum:

The breakout game he picked, xbreaky, is a fairly simple and small game that most likely appeals to kids much more than the gorgeous-looking and noisy lbreakout2. xbreaky has simple basic colors and cute block patterns, but it does have a problem: the ball ALWAYS bounces at 90 degrees.

No matter what you do with the beam to try and hit the ball sideways, spinning, on the edge or whatever, it always bounces off at 90 degrees. Now, Lucas at 4 years cannot understand the simple geometrical patterns the ball describes in the screen and mentally project the next N moves, but any grown up (especially a computer nerd) just KNOWS it will take about 2^13 bounces for the FSCKING BALL to hit that FREAKING LAST BLOCK.

Sometimes it feels like I'm watching a Lorenz Attractor. Really.

Cognitive dissonance? How about cognitive dis-own-ance!

Who said you can claim ownership over your thoughts and perceptions? I can think your thoughts as well, specially considering they've been through me already! Should be just a matter of proper perception tuning.
Short post, no time to post for ages, but happened to think of a catchy phrase for the title. :)

Make sure to generate entropy, for God is a compressor

Somehow these days I was tying up Carlos Castañeda's Eagle's Gift with the fact that "when you die all your life passes in front of you" and stuff, and also with the fact that everybody likes a good story, so even God must surely do. Even more so, He gave us life so that we could experiment and then tell Him interesting and fun things. He actually can't experiment life Himself, since He's the absolute. If you're the absolute everything, you can't surely be the individual, detached something. So you need the individual somethings to tell you how things were while journeying through the infinite everything.

So I was thinking that perhaps when you die you get your chance to tell God how great and fun your life was, and if He laughs and likes it, He'll get you a nice gift. Now, imagine how absurdly many dull and stupid lifes He has to listen to, until He gets to finally receive a truly beloved child and eagerly hear their story. The dull, repeating ones get only a kind of "Ah, ok. Wait on the line for your next try." response from Him. The fun, diverse and entertaining lives get responses like "You have understood the true meaning of life and love, my beloved child, so I'll give you FNORD.".

If you live a dull life, you'll only increment some counter in an already established pattern. You'll be God's déjà vu. You'll be lost in the compression algorithm of the Universal Mind.

So make sure you create interesting and unexpected conscience patterns! Experiment some chaos, bring diversity to your life (or at least to your perception of your life). Make sure you carve up your own patterns in the Universal Mind's compression tables (they'll be there forever), and make sure existance is more enjoyable to everyone (people will be able to pick up your cool patterns through intuition). All you need is chaos and love.

Hail Eris!

Rediscovering Discordianism

Hey, long time no post. I'll try to have a bit more of a discipline with this blog thing, as I usually have interesting ideas when I'm away from the computer, and then forget them immediately upon approaching the computer. In any case, I just felt like writing about Discordianism, and I don't even have any new thing to say about it.

Recently I've spent a week in the US for some massive amounts of meetings and intense hands-on coding (we've got a lot of stuff to deliver soon and email+teleconfs was not enough to handle it). One of the good things I've done there is go to Barnes and Nobles and buy my own copy of The Illuminatus Trilogy, which I find to be one of the best books I ever read. Totally mind-fucking, but since everyone likes a good fuck and we nerds like mental things, a bit of mind-fucking is the best thing that can happen to a nerd. You feel so much mental pleasure in the massive amount of intricate, false, true and ha ha only serious information in that book.

So now I think I've increased the participation of Discordianism in my religious side, so that Yoga is 45%, Discordianism is 45% and mostly everything else gets to share 10%. I don't think there is anything else of religion that does not fit either of the first two, but hey, life always surprises us, so there is that 10% there just in case.

In fact, I even found out that I was born in a year that maps to 23 (1 + 9 + 7 + 6), which gave me an instant warm fuzzy feeling for a few minutes. Heh, that book even sent me reading The Revelation again, around chapter 13, I think. Too bad there's no chapter 23 in it.

The recent Katrina mess in the US and the position of Bush about it reminded me of this:

10. The Earth quakes and the heavens rattle; the beasts of nature flock together and the nations of men flock apart; volcanoes usher up heat while elsewhere water becomes ice and melts; and then on other days it just rains.

11. Indeed do many things come to pass.

HBT; The Book of Predictions, Chap. 19

AM Radio

Nerds are strange beasts with stranger tastes.

Today I remembered how I really like AM radio. I got to work by bus, and decided to plug some noise into my ears other than the usual traffic and city noise. I always try to carry my AM/FM radio around (it's a Sony digital something (I noticed people expect brands and models of gadgets mentioned in nerdy blogs)), since I'd rather listen to something weird/new than my good old CD collection, which I actually hardly listen to. MP3 players are also not my thing, since I'd soon get fed up with the same songs all the time, or I'd loose several hours a week managing playlists. I like radio, and today I tripped on the band button and suddenly was (gladly) dragged back to the AM universe.

Static, white noise. I could listen to my GSM cellphone receiving a message from my wife before the phone announced it. I also heard the clicks and feeps of my answer as it found its way into data packets and off the air. Sometimes a bit of 60Hz signals when the bus was close to high-voltage lines. And over all that, information. I think that's what I like about AM radio. It's much too low-tech for trendy, fashionable, "pop culture" things, so all you can get is raw information and news from interesting people. Hey, I even voted (YES) in this interactive poll about whether we should pass a city law to forbid smoking on any public closed place.

As I write I also remember how my trusty radio was one of my best friends when I spent 6 to 8 months working in Brasília, only seeing my family in Porto Alegre every two weekends. Brasília is a nice city, but you HAVE to have a car in order to get to know it and I didn't. It was like breakfast-work-lunch-work-dinner-(work?-)sleep. For days and weeks (sometimes weekends). After the first few weeks of walking around the hotels and work, I didn't really have a lot more to do than read in my room and listen to my radio. I started trying to find the weirdest radio ever, and the candidates were usually religious radios of all sorts. They were really fun to listen to, specially during the night.

So now, as I work with IPv6, security, Unix and embedded devices, I listen to good old AM radio (and love it). Go figure.