intel!

Nenhum post relacionado.

Teve até um número de pessoas legal para o horário, agradecimentos à coordenação que conseguiu me encaixar com tamanha rapidez na grade!

Eu vou ter de mexer em algumas coisas para diminuir tamanho e alguns assuntos, mas no mais, foi bem legal.

intel

Nenhum post relacionado.

O comando varnishhist mostra um histograma dos requests sendo servidos pelo cache, desde o momento do varnish pegar o request do kernel até entregar a resposta ao kernel novamente.

É uma ferramenta interessante para ver como está a saúde de seu cache, mas meio chatinha de se entender de cara. Além disso existem opções na linha de comando para adicionar e remover informações. Por exemplo, pode-se usar o -b para checar apenas o status dos requests aos backends, e -c para checar apenas os requests dos clientes.

A grande questão que normalmente faz os iniciantes coçarem a cabeça é exatamente como interpretar o histograma. Não tema, é bem simples depois que se entende:

• No topo esquerdo são mostradas a escala do gráfico e o número de requests sendo tratados no histograma. No caso do exemplo acima a escala é de 1:15, ou seja, cada símbolo | ou # representa 15 requests, e um total de 2000 requests já passaram desde que o programa iniciou.
• Os símbolos | e # querem dizer respectivamente um cache hit e um cache miss. Trocando em miúdos: o request foi servido a partir do cache do varnish ou teve de ser buscado em algum backend.
• A escala do eixo X é logarítmica, e da esquerda para a direita mostra o tempo que cada request demorou do início ao fim, em segundos. Então 1e0 quer dizer 1 segundo de demora, enquanto 1e-3 quer dizer 0.001 segundos (1 milisegundo).

Então, quanto mais para a esquerda estiverem os requests, mais rápido eles estão sendo servidos. Um grande número de # significa que seu cache não está fazendo o que devia (cachear!). O histograma bom é aquele parecido com o do exemplo: a maioria dos requests está no canto esquerdo do gráfico (rápidos) e são hits. É normal que hits sejam rápidos e misses sejam lentos, mas dependendo da velocidade dos backends você pode acabar com muitos misses no lado esquerdo do histograma.

intel!

Posts relacionados:

1. Guia sobre o Exim Coloquei hoje no ar o guia sobre o Exim. Está...
2. Cluster corosync/pacemaker para balanceamento web (nginx, varnish ou apache) (or how to replace wackamole with heartbeat!) Objetivo: Construir um cluster com N máquinas rodando nginx e varnish para...
3. Meus Projetos Parados Costumo plagiar meu amigo Bruno lá de Divinópolis: “Eu tenho...

Construir um cluster com N máquinas rodando nginx e varnish para fornecer balanceamento de carga e cacheamento de aplicações e sites web, de forma a garantir disponibilidade e escalabilidade. O cluster será formado por N máquinas, todas ativas ao mesmo tempo em um pool de IPs que será utilizado num DNS round-robin ou balanceador via hardware para os endereços das aplicações internas. Caso um número N-1 de máquinas do cluster se torne indisponível, os IPs das máquinas indisponíveis devem ser realocados para evitar a perda de serviços.

Qual é o objetivo real aqui: servir conteúdo estático ou aplicações dinâmicas que possam ser cacheadas e balanceadas (ou seja, partes que não sejam dinâmicas ou que sejam geradas dinâmicamente mas não personalizadas o bastante para serem individuais para um determinado usuário). Usando o DNS round-robin se garante que cada IP vai receber mais ou  menos o mesmo número de requisição, não é exato mas é razoável o bastante. O problema de DNS RR é que caso um dos servidores caia aquele IP fica inacessível, e é aí que entra o cluster como esse que estou descrevendo. Caso um dos nós fique indisponível o IP dele é associado a outro nó, configurado de forma idêntica, que vai cuidar das requisições dele. Essa configuração pode ser aplicada inclusive para outros serviços que seguem uma mesma teoria.

Do ponto de vista de escalabilidade, você pode se precaver contra picos de acesso mantendo uma grande pool de IPs associados com um determinado nome, vamos supor, 12 IPs, e apenas 2 máquinas no cluster. Esses 12 endereços estarão distribuidos entre os nós de forma uniforme. No caso de um pico, basta adicionar máquinas no cluster e os endereços serão redistribuidos, sem necessidade de mudanças externas. As possibilidades são muitas.

Para isso funcionar direito, todas as máquinas do cluster tem de ter a mesma configuração e acessar os mesmos recursos. Isso pode ser feito via NFS, shared storage via NAS ou SAN, algum gerenciador de configuração como Chef ou Puppet, não importa. O que importa é que as configurações não saiam de sincronia.

Lembre-se também que conteúdo personalizado para usuários (carrinhos de compras, sites de administração de aplicações, áreas de postagens de comentários) tem de passar por servidores fora dessa estrutura ou ter alguma forma de persistência de sessão, mas isso é um problema comum a qualquer tipo de balanceamento de carga.

Arquitetura de cluster:

O corosync faz parte da nova geração de ferramentas da alta disponibilidade para Linux. Podemos chamar isso tudo de heartbeat 3, mas na verdade é mais complexo que isso:  São vários projetos funcionando em uníssono para prover as funcionalidades antes disponibilizadas pelo heartbeat, e o heartbeat é agora uma das opções disponíveis para desempenhar o mesmo serviço que o corosync desempenha (comunicação entre os nós). O pacemaker por outro lado já é outra parte do sistema que cuida de gerenciar os serviços rodando, monitoramento e catalogação dos mesmos. Como eu disse, complexo. A complexidade aumentou mas as possibilidades também: os clusters não estão limitados mais a dois nós e podem ser configurados como ativos-passivos, ativos-ativos, ativos+n-ativos e quase todas as outras configurações imaginável.

Nginx + Varnish:

Faz um tempo que escolhi usar nginx+varnish na minha estrutura de balanceamento. O nginx é colocado na frente do varnish para prover algumas funcionalidades não presentes ou que seriam complexas ou custosas de se fazer no varnish, como reescrita de algumas URLS, compressão de conteúdo em gzip, adição de alguns headers de expiração (Expires:). Além disso, o nginx é utilizado para servir conteúdo multimídia como imagens, áudio e vídeo diretamente do disco sem passar pelo cache, aumentando o throughput e liberando o varnish para servir apenas conteúdo de menor tamanho. O nginx também possui um módulo especializado para servir arquivos de vídeo flv diretamente do disco que ajuda na nossa infraestrutura.

Execução:

Inicialmente eu tinha pensado em usar o wackamole, que faz redistribuição de IPs como eu queria, mas o projeto está parado a 2 anos e meio e aparentemente anda meio brigado com as interfaces no Linux 2.6. Depois de tentar resolver durante alguns dias um bug bizarro resolvi partir para a solução corosync. A instalação e configuração do Nginx e do Varnish fogem um pouco do objetivo desse post, existem vários outros na internet mostrando como montar um balanceador de carga com o nginx na frente do varnish (que eu prefiro) ou o varnish na frente do nginx (que eu acho uma solução menos escalável). A configuração inicial foi feita baseada no guia “Cluster from scratch on Fedora 11” disponível no site do pacemaker.

A primeira coisa a se fazer é garantir que os nós do cluster se encontrem corretamente na rede. É importante que os nomes estejam resolvendo corretamente noDNS e também que o arquivo /etc/hosts aponte corretamente para os ips. Certifique-se que o /etc/hosts inclua os shortnames dos servidores, o comando ping nomedoservidor (sem sufixo dns) tem de responder pelo ip correto. Além disso, uname -n deve retornar o nome do servidor também sem sufixo dns (ou seja, sem .algo), caso isso não seja o caso edite o arquivo /etc/hostname e execute:

# hostname $(cat /etc/hostname)

Os seguintes pacotes foram instalados (usando o repositório lenny-backports):

# aptitude install corosync pacemaker

E o aptitude vai se encarregar de instalar o resto das dependências, incluindo cluster-glue e cluster-agents. Com os nós do cluster se falando e o software instalado, é hora de configurar o corosync. O corosync usa um endereço multicast para se comunicar entre os nós, favor prestar atenção com possíveis conflitos de porta/ips já existentes na rede. As únicas configurações alteradas do arquivo /etc/corosync/corosync.conf padrão do Debian foram: bindnetaddr, use_logd,use_mgmtd e consensus.

Esta configuração tem de ser copiada para todos os nós do cluster. Depois de feito isso, inicie o corosync no primeiro nó, cheque o syslog por algum erro mais gritante e depois inicie os outros nós do cluster caso esteja tudo bem. Existem duas properties chatas que tem de ser mudadas de cara. Toda a configuração do cluster pode ser feita através de um imenso XML (ugh) ou através do comando crm que manipula o XML (legal):

# crm configure property stonith-enabled=false
# crm configure property no-quorum-policy=ignore

STONITH é o acrônimo para Shoot The Other Node In The Head, um serviço que não vamos usar nessa configuração mas é usado para serviços que tem de garantir que uma segunda cópia não rode ao mesmo tempo e para isso usam técnicas para desligar, bloquear ou ‘atirar na cabeça do outro nó’. O Debian tem essaproperty habilitada por padrão e o cluster não sobe sem o STONITH estar configurado corretamente ou a property estar desligada. O quórum já é uma propriedade interessante: ela garante que o cluster só seja considerado ‘consistente’ se tiver mais da metade dos nós ativos (isso é obviamente impossível em um cluster com 2 máquinas em que uma falha…), neste caso desabilitamos o quórum porque não importa o número de máquinas inativas, o cluster sempre vai estar ativo.

Para checar o funcionamento, use o comando crm_mon ou crm status (os dois são a mesma coisa, mas o crm_mon tem um loop que fica mostrando as informações em tempo real enquanto o crm status é one shot). A saída tem de ser algo assim:

# crm status
============
Last updated: Thu Dec 23 11:20:23 2010
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
3 Nodes configured, 3 expected votes
0 Resources configured.
============

Online: [ node01 node02 node03 ]

Depois das máquinas adicionadas e online no cluster, basta adicionar os resources que serão compartilhados, neste caso os 3 endereços IP. Usando o crm novamente (linhas quebradas para caber aqui, mas pode digitar tudo em uma linha só):

# primitive vip-1 ocf:heartbeat:IPaddr2 params ip="X.X.X.X" \ 
cidr_netmask="XX" op monitor interval="30s"

Repita isso mais duas vezes mudando vip-1 para vip-2 e vip-3 respectivamente para cada IP. Lembre-se que o que está sendo adicionado aqui são os IPs virtuais, não os IPs dos nós. Os parâmetros são auto-explicativos: cidr_netmask é a máscara de rede em formato CIDR do endereço, op monitor interval=“30s”vai monitorar o serviço para checar se ele está funcionando a cada 30 segundos (no caso, monitorar o IP). ocf:heartbeat:IPaddr2 é uma definição de Resource Agent, existem vários outros para vários outros serviços.

Com isso os IPs vão cada um para um nó do cluster. Isso acontece com outros serviços também. Nas palavras do project manager do corosync/pacemaker:

<beekhof> it tries to spread them out
<beekhof> regardless of what type they are
<beekhof> unless you use location constraints to tell pacemaker which ones they prefer

Isso também garante que caso mais VIPs sejam adicionados eles sejam balanceados o melhor possível entre os nós do cluster.

Checando com o crm status:

# crm status
============
Last updated: Thu Dec 23 11:43:39 2010
Stack: openais
Current DC: node01 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
3 Nodes configured, 3 expected votes
3 Resources configured.
============

Online: [ node01 node02 node03 ]

 vip-1  (ocf::heartbeat:IPaddr2):       Started node01
 vip-2  (ocf::heartbeat:IPaddr2):       Started node02
 vip-3  (ocf::heartbeat:IPaddr2):       Started node03

A partir de agora caso um dos nós do cluster se torne indisponível o VIP rodando nele vai automaticamente ser movido para algum outro nó do cluster.

Os comandos crm configure show e crm configure show xml são interessantes para ver como as coisas são feitas.

intel.

Posts relacionados:

1. Aprendendo a amar o histograma do varnish (varnishhist) Post rápido sobre uma ferramenta com má fama O comando...
2. VULoad, para observar load average em terminais Update: dei uma mexida nele e já coloquei a versão...
3. Turbogears (ou zope, ou ruby) Behind Apache: Diminuindo o load. E então, muita gente usa frameworks como o Turbogears ou...

O MongoDB é um banco de dados não SQL que tem ganhado espaço. Foursquare por exemplo usa o Mongo com uma massa de dados razoável (3 shards de 60Gb, de acordo com uma informação já um pouco desatualizada). Nas versões mais recentes, o MongoDB também ganhou suporte nativo a sharding e uma replicação mais robusta.

Bancos NoSQL como  Mongo tem grandes diferenças com os RDB existentes. A mais importante, SQL não existe, então algumas coisas como SELECT SUM() ou SELECT … GROUP BY que se está acostumado a usar tem de ser implementados de outra forma. As vezes é melhor implementar todo esse tratamento na aplicação, mas no caso do MongoDB ele possui uma implementação de Map/Reduce nativa, exatamente para se fazer esse tipo de tratamento de dados. Um detalhe interessante na performance deste sistema é que no caso de bancos com shards o trabalho é dividido entre os mesmos.

Para testar o ganho de performance e se a divisão era feita corretamente, fiz o seguinte teste: habilitei sharding em uma collection com dados de logs com 19 milhões de registros, cada registro com tamanho entre 150 e 220 bytes. Usei as seguintes funções para o Map/Reduce:

Função de mapeamento (map):

function m() {
	emit(this.c, {duration: this.d,
			size: this.s,
			conn: 1});
}

Função de redução (reduce):

function r(key, val) {
	var total_duration = 0;
	var total_size = 0;
	var total_conn = 0;
	for (var i = 0; i < val.length; i++) {
		total_duration += val[i].duration;
		total_size += val[i].size;
		total_conn += 1;
	}
	return {duration: total_duration,
			size: total_size,
			total_conn : total_conn };
}

O balanceamento dos dados entre os dois shards que eu criei demorou quase três horas, nesse tempo o banco continua disponível exceto por updates em dados que estão no processo de serem movidos para outro shard. Depois de terminado esse processo eu tinha dez milhões de registros no servidor original e os outros nove milhões e qualquer coisa no segundo shard.

O processo de Map/Reduce com apenas um banco demorou 15 minutos para completar, agindo sobre todos os registros. Depois do sharding, esse tempo caiu pela metade indo para 7 minutos. Se a melhora for sempre nesta proporção a adição de shards implica diretamente na divisão do tempo do processamento pelo número de shards envolvidos. De acordo com a equipe de desenvolvimento do MongoDB eles estão trabalhando agora para melhorar o paralelismo da operação de Map/Reduce mas aparentemente isso depende da engine que eles usam para interpretar o javascript das funções.

O sharding do MongoDB é bem implementado, mas tem de se ter cuidado na hora de escolher a chave pela qual ele vai fazer a divisão dos dados. Uma chave mal escolhida pode fazer com que os shards fiquem mal balanceados e acabe com todo o ganho de performance que teria sido conseguido. Um exemplo seria se no meu teste eu tivesse acabado com um milhão de records em um dos shards, e os outros dezoito no outro: os resultados estariam disponíveis no shard com menos data muito antes do outro terminar.

intel

Posts relacionados:

1. Ftrace – tracing de funções do kernel Linux Saiu um artigo sobre o assunto na LWN a alguns...
2. Para ser um Sysadmin Vendo o formspring do fike eu tentei me lembrar do...

Eu tenho por exatamente usado para estudar internals. Por exemplo:

[tracing]# cat trace
          <idle>-0     [000] 1726568.996435: hrtimer_get_next_event <-get_next_timer_interrupt
          <idle>-0     [000] 1726568.996436: _spin_lock_irqsave <-hrtimer_get_next_event

Essa saída aí em cima mostra a thread idle (swapper), PID 0, rodando na CPU 0, timestamp de quando a função foi executada e as funções que estão rodando. Existem várias configurações que podem ser feitas, como por exemplo adicionar informações de latência no tracing. Isso faz com que além dos timestamps sejam colocadas as informações de quanto tempo cada função demorou para executar.

Eu escrevi um scriptizinho em bash para facilitar minha vida ao ligar e desligar o tracing. Na minha máquina funcionou beleza (ainda tem bugs, mas funciona), mas lembre-se que alguns tracers (como o function) tem de ser habilitados no Kernel e pelo menos no kernel do Debian não estavam. Como eu já estava recompilando o 2.6.36 para fazer alguns testes, aproveitei para habilitar.

O Perfikt é uma ferramenta  GTK que usa dados do Valgrind e aparentemente tem suporte para a interface de tracing do kernel, fornecendo uma interface gráfica bem simpática para a parada.

Mais sobre o assunto (em inglês):

• Documentação oficial do Kernel
• Matérias da LWN: First look, Debugging the Kernel using Ftrace partes 1 e 2

intel

Posts relacionados:

1. LinuxCon Brasil 2010 – Dia 2 Continuando, o segundo dia da LinuxCon prometia ser tão interessante...
2. Turbogears (ou zope, ou ruby) Behind Apache: Diminuindo o load. E então, muita gente usa frameworks como o Turbogears ou...
3. Resumo semanal de coisas nerds…. Apache na liderança também em sites SSL. Com o apache2...

Nesse final de semana de eleição tivemos de colocar umas coisas no ar na EBC para atender as demandas de infraestrutura dos sistemas suportando as rádios, agência de notícias, apuração em tempo real e tv ao vivo, e para isso fizemos vários testes incluíndo balanceamento e carga. Num desses um dos colegas do desenvolvimento me sacaneou porque eu estava usando os gráficos do Zabbix para monitorar o load dos servidores, enquanto usava o iftop em um terminator todo repartido para ver como andava a rede dos mesmos.

Como nada é mais inspirador que uma boa aporrinhação-construtiva, tirei um tempo nas madrugadas para fazer um trequinho em python-ncurses para a próximas vez que eu precisar monitorar o Load Average de máquinas em modo console. Na verdade, eu imagino que já exista, mas como eu ando precisando reanimar meus skills em python eu nem me esforcei muito para procurar. Abaixo dois screenshots da paradinha em funcionamento:

Essa é minha máquina local, com quatro processadores e pouco load. Não tinha nada a mão para gerar um bom enfileiramento de processos então ficou assim mesmo.

A idéia é a seguinte: até o meio da tela eu mostro uma barra linear que vai até o valor de Load Average igual ao número de CPUs disponíveis na sua máquina (ou seja, até onde o seu Load Average está tranquilo, leia isso aqui para entender). Depois disso eu uso um multiplicador configurável (no código claro) para mostrar a barra de excesso de load. Visualmente é fácil de interpretar, mesmo se estiver com vários abertos na: se a barra passou do meio da tela o load está alto demais e processos estão começando a enfileirar, quanto mais pro final da tela, pior.

Ainda tem algumas coisinhas cosméticas para mexer, e eu ainda tenho de testar em uma máquina com load alto de verdade, para ver como ele se comporta (por exemplo, se ele vai conseguir se atualizar corretamente com um grande enfileiramento acontecendo).

Mais um screenshot, agora usando o terminator para mostrar duas telas simultâneas, no meu VPS que só tem uma CPU:

O código está no Github, você pode baixar direto clicando aqui. Obviamente, é GPL. É um bom exemplo de como usar ncurses com python também, para quem quiser ter um feeling de como era programar na era dos terminais. Por exemplo, eu tinha me esquecido como era ter de se lembrar de re-escrever a tela. Ou fazer barras usando código ASCII. Mas foi bem divertido. Vou dar mais umas hackeadas nele depois se pensar em mais informações ou alguma otimização que for interessante de fazer.

intel.

Posts relacionados:

1. E depois perguntam… Máquina aqui de casa, Windows XP, usada apenas para checar...
2. (quase) Trocando o Prism por um script de 60 linhas Quase, mas quase mesmo. O Prism é o antigo xulrunner...
3. Meus Projetos Parados Costumo plagiar meu amigo Bruno lá de Divinópolis: “Eu tenho...

O Código de Ética do Administrador de Sistemas

Nós como Administradores de Sistemas profissionais nos comprometemos aos mais altos padrões de conduta ética e profissional e concordamos em ser guiados por este código de ética, e encorajamos a todos outros Administradores de Sistemas a fazer o mesmo.

Profissionalismo Irei manter a conduta profissional no ambiente de trabalho e não permitirei que questões ou crenças pessoais me façam tratar pessoas injustamente ou sem profissionalismo.

Integridade Serei honesto nas minhas relações profissionais e verdadeiro nas minhas competências e nos impactos dos meus erros. Buscarei assistência de outros quando for necessário.

Irei evitar conflitos de interesses e tendências sempre que possível. Quando meu conselho for procurado, se eu tiver algum conflito de interesse ou tendência, irei declará-los se apropriado, e recusar se necessário.

Privacidade Irei acessar informações privadas em sistemas computacionais apenas quando necessário no curso de meus deveres técnicos. Irei manter e proteger a confidencialidade de qualquer informação a qual eu tenha tido acesso, independente do método pelo qual eu tenha tido conhecimento à mesma.

Leis e Normas Irei me educar com relação a leis, regulamentos e normas relativas a execução dos meus deveres.

Comunicação Irei me comunicar com a gerência, usuários e colegas sobre assuntos computacionais de interesse mútuo. Irei me esforçar para escutar e entender as necessidades de todas as partes envolvidas.

Integridade dos sistemas Irei me esforçar para garantir a integridade, confiabilidade e disponibilidade dos sistemas pelos quais eu sou responsável.

Irei desenhar e manter cada sistema de maneira a suportar o propósito do sistema para a organização.

Educação Irei continuar a atualizar e melhorar meu conhecimento técnico e outras habilidades relacionadas ao trabalho. Irei compartilhar meu conhecimento e experiência com outros.

Responsabilidade com a Comunidade de Computação Irei cooperar com a comunidade de computação para manter a integridade de redes e recursos computacionais.

Responsabilidade social Como profissional informado, irei encorajar o desenvolvilento e adoção de normas e leis consistentes com estes princípios éticos.

Responsabilidade ética Irei me esforçar para construir e manter um ambiente de trabalho seguro, sadio e produtivo.

Irei aceitar e oferecer críticas construtivas de trabalhos técnicos quando apropriado e irei creditar corretamente as contribuições de outros.

Irei liderar por exemplo, mantendo elevados padrões éticos e graus de profissionalismo no exercício dos meus deveres. Irei auxiliar meus colegas a seguir este código de ética.

Posts relacionados:

1. Para ser um Sysadmin Vendo o formspring do fike eu tentei me lembrar do...
2. Trac Hacks Indispensáveis Então, eu uso bastante o trac como gerenciador de projetos....
3. Usando o Tor e Foxy Proxy para acessar o YouTube E então. Pela segunda vez tenho a impressão de que...

O Panel com os desenvolvedores do Kernel foi bem interessante. Foi meio um QA sobre futuro e passado do Kernel, com direito a casos pitorescos como “Qual o código menos mantido no código do kernel” (resposta, a camada TTY).

Outras palestras interessantes do dia incluiram a do Glauber da Red Hat sobre KVM, que me deixou bastante animado com relação a evolução do projeto. Ou “produto” como eles chamam lá na corporação deles.

Teve um palestrante que faltou. Foi… Trágico.

A palestra do Thomas Gleixner do RT Patch foi hilária. Eles são realmente meio malucos, mas aparentemente o patch está a caminho de ser aprovado. Claro que existem penalidades de performance em se usar um sistema Real Time, em torno de 25% até, mas se você quer usar um real time kernel você tem de se conformar.

No final das contas, a qualidade das palestras da LinuxCon é inegável, principalmente dos palestrantes internacionais.

intel.

Posts relacionados:

1. LinuxCon Brasil 2010 – Dia 1 Depois de algum tempo sem ir a eventos de SL...
2. II Festival Software Livre Bahia Então. Na quinta a noite estarei indo para Salvador, participar...
3. Sobre o novo sistema de avaliação de palestras do FISL Esse post é uma rant. Nem é tão pela minha...

Primeiro dia, cheguei mais o fike já no final da palestra sobre MeeGo, mas nem senti muito porque o assunto não é láááá esse meu interesse todo (ojeriza a QT dá nisso). Eu meio que assisti a fala do Ian Pratt do Xen Project sobre os novos rumos do Xen e quando terminou tudo que eu conseguia pensar era em KVM. Ele meio que me perdeu quando mostrou a Virtualização para Notebooks. A idéia é boa? É boaish… Mas tem formas menos overkill de implementar, me parece.

A keynote seguinte foi o bate papo entre Linus Torvalds, Andrew Morton e Jim Zemlin da Linux Foundation, foi bem interessante, cheio de coisa que estamos carecas de saber mas que imagino tenha sido a primeira vez que muita gente tenha visto e em alguns casos como o meu foi a primeira vez que eu vi ao vivo, como por exemplo o fato do Linus ser um tosco Mas ele fez o que pode para ser simpático e vencer a timidez que lhe é característica, imagino que por ser uma das raras visitas ao Brasil ele se dobrou para ser um pouco mais public relations, deu autógrafos, posou para algumas fotos (não para todas, tinha muita gente).

Andrew Morton, coredump e boné do debian

O Andrew Morton foi menos assediado, consegui uma foto com ele para minha coleção tiete.

O problema do assédio é bem complicado. Por um lado, o Linus tinha de entender que existem pessoas que vão tentar tirar fotos e conversar e pedir autógrafos e tal. Pelo outro lado, isso deve ser um SACO, e a incapacidade de se locomover por um evento pode ser um ótimo motivo para nunca mais voltar. Na verdade, me disseram que na convenção da Austrália espalharam cartazes pedindo para não aporrinharem demais o coitado se quisessem que ele voltasse.

Vem com a fama. Não imagino que ele queria ser famoso quando ele escolheu ser programador na verdade. Como ele mesmo disse, ele só escolheu uma profissão que garantiria que ele sempre teria dinheiro pra viver

Linus, cercado e autografando

Depois do almoço acabei perdendo a palestra do Jon Corbet, no finalzinho que peguei ele falava sobre System Tap e performance counters no Linux, boas novidades para quem sente falta de um dtrace de gente grande como nós pobres sysadmins.

A palestra do Jeremy Allison foi uma grata surpresa. Ele trabalha no Google com Samba,  estava no evento como representante do projeto e é um dos criadores da parada. Ele falou muito sobre como usar o Samba em dispositivos embarcados ou produtos próprios, como interagir (e como não interagir) com o Dev Team do Samba. Também falou da preocupação com a segurança e de alguns projetos interessantes, como uma empresa (não citada) que está trabalhando com o Samba 4 para fornecer uma solução completa de substituição do Active Directory e um projeto que ele está trabalhando no Google, que também usa Samba 4 e que, de acordo com ele, se contasse teria de nos matar depois. Mas só o prospecto de Samba 4 + Google dá o que pensar né?

Abordei ele depois da palestra para conversar sobre Samba e consegui uma boa confirmação de que a versão atual no git HEAD do projeto já consegue substituir um AD com um número razoável de usuários (1500-2000) desde que não tenha relações de confiança demais, com sucesso, e que mais ou menos no meio do ano que vem o Samba 4 deve estar sendo lançado.

Chupa. Active. Directory.

Depois dessa palestra eu fiquei mais zanzando e fazendo um networking com uns conhecidos que eu não via a tempos. Otávio,  e faw do Debian, andrelop, Luiz Blanes, Corinto Meffe, Deivi Khun (esse é meu vizinho na verdade), Julio Neves, e por ai vai.

Cena engraçada e frase punk do dia:

Otávio, fike, eu, faw, andrelop e mais uns chegados parados conversando e combinando uma churrascaria

Camarada da Organização:

- E ai, vocês vão no jantar dos famosos?

Todo mundo se entreolha, faw responde:

- Claro que não, você está olhando pro chão de fábrica do software livre.

Amanhã, último dia e volta pra casa. Cheio de idéias! Compra-se dia de 30 horas para implementá-las todas!

intel

Posts relacionados:

1. LinuxCon Brasil 2010 – Dia 2 Continuando, o segundo dia da LinuxCon prometia ser tão interessante...
2. FISL6.0 Minha palestra sobre Exim foi aceita no FISL 6.0 Agora...
3. II Festival Software Livre Bahia Então. Na quinta a noite estarei indo para Salvador, participar...