Recentemente comprei um Notebook Aspire 1410 de 11.6″,  e depois de instalar o Ubuntu 10.04 eu vinha experimentando problemas de performance, e recorrentes problemas de IO do HD, sempre tinha que reinstalar o sistema, pois corrompia o raiz(/) do sistema, até que resolvi estudar os comentários sobre esse notebook e achei a origem dos problemas. Acabou que descobri que existe um bug na BIOS, no módulo AHCI, que é uma funcionalidade de SATA 2, então resolvi atualizar a BIOS, porém lendo mais fórums sobre a instalação nesse notebook e sobre essa tecnologia AHCI, ela somente dá suporte a hot swapping e NCQ, o hot swapping é a possibilidade de desconectar o hd com a placa ligada(o que eu não vou fazer) e NCQ é uma tecnologia de acesso a disco mais eficaz em ambientes de intensa leitura e gravação de dados no HD, suporta cache e etc, o que também não é o meu caso. Portanto eu não preciso dessa tecnologia AHCI, e na BIOS o SATA MODE estava configurado para AHCI, troquei para IDE MODE e pronto. Os problemas pararam de ocorrer e a máquina ficou mais rápida e o boot já não leva 5 minutos.

Com o Ubuntu 9.10 eu instalei e funcionou corretamente, mas de vez em quando aparecia uns erros estranhos envolvendo HD no /var/log/syslog. O que não me deixava feliz e me deixava preocupado.

Portanto fica a dica, se você tiver um computador igual ao meu Aspire 1410 (11″6), desabilite o modo AHCI que muito provavelmente você não vai utilizar os recursos e poupará dores de cabeça e depois instale o seu Ubuntu 10.04.

Tirando esse problema, esse notebook é show de bola, tenho usado ele para trabalhar também e ele segura o trabalho sem frescuras, as vezes ele se esquenta  ;-) , mas agente acaba se entendendo. Cheguei até a me arrepender de ter comprado ele, mas já pedi desculpa dele e estamos felizes.

Só queria deixar registrado a dica!

:wq!

A Constituição Brasileira diz em seu Art. 1º, parágrafo único V, Que “Todo o poder emana do povo, que o exerce por meio de representantes eleitos ou diretamente, nos termos desta Constituição”.

Diz também no  Art. 5º, parágrafo II que “Ninguém deixará de fazer alguma coisa senão em virtude de Lei”; e no parágrafo IV  que ” É livre a manifestação do pensamento, sendo vedado o anonimato”; parágrafo IX que diz que “É livre a expressão da atividade intelectual, artística, científica e de comunicação, independente de censura ou licença”.

Diz também no parágrafo XVI do Art. 5º que “Todos podem reunir-se pacificamente, sem armas, em locais abertos ao público, independente de autorização, desde que não frustem outra reunião anteriormente convocada para o mesmo local, sendo apenas exigido prévio aviso à autoridade competente”.

A Constituição Brasileira diz também eu seu Art. 5º, parágrafo XXXIII, que “Todos têm direito a receber dos órgãos públicos informações de seu interesse particular, ou de interesse coletivo ou geral, que serão prestadas no prazo da Lei, sob pena de responsabilidade, ressalvadas aquelas cujo sigilo seja imprescindível à segurança da sociedade e do Estado”; XXXIV – “São a todos assegurados, independentemente do pagamento de taxas; a) O direito de petição aos Poderes Públicos em defesa de direitos ou contra ilegalidade ou abuso de poder.”

Este manifesto vem à público expressar o sentimento de repressão sofrida à um grupo de aproximadamente 100 pessoas, que protestaram contra a aprovação do Projeto de Lei Complementar 006/09, aprovado na Câmara Municipal de Manaus, que instituiu a criação de duas taxas: a Taxa de Resíduos Sólidos Domiciliares (TRSD) e a Taxa de Resíduos de Serviços de Saúde (TRSS).

O grupo, do qual sou integrante, vem sofrendo repressão política desde que decidiu publicar um outdoor com os nomes dos vereadores que aprovaram a criação das taxas. Todas as empresas de publicidade por nós procuradas desistiram da publicação do outdoor, alegando a não interferência em assuntos políticos.

Este manifesto vem à público informar que todos os integrantes do movimento contra a “Taxa do Lixo” são cidadãos de bem, que gozam dos direitos constitucionais e de liberdade de expressão, assim como todos os demais direitos à nós concedidos pela Constituição Brasileira.

Nosso sentimento de protesto tem como finalidade o puro exercício da cidadania. Nosso grupo é composto por profissionais liberais, autônomos, estudantes, médicos, jornalistas, juristas, analistas de sistemas, engenheiros, dentre outros.

No dia 04 de janeiro de 2010, um dos integrantes de nosso movimento foi procurado em seu trabalho por dois homens sem identificação, com gravadores e microfones em punho, para dar explicações de seu trabalho.

Os dois homens foram avisados de que não estavam autorizados a adentrarem no recinto sem prévio aviso à direção do mesmo. Mas, seguiram fazendo entrevistas à pessoas e funcionários do local.

O integrante de nosso grupo que foi covardemente coagido, não tem nenhuma ligação de cunho político, muito pelo contrário, aderiu ao movimento por pura indginação, é uma médica e está grávida.

Segundo testemunhas, os dois homens saíram de um Fiat Uno branco com identificação de uma rádio local , que tem por empresário e apresentador um ex-político.

Se confirmados os fatos apresentados por testemunhas de que tal rádio tentou de forma indireta, coagir um cidadão que expressa sua opinião de forma pacífica e legítima, levaremos o caso às autoridades competentes. Isto posto que uma rádio goza dos mesmos direitos constitucionais que qualquer cidadão brasileiro.

Uma rádio que tenta coagir um grupo que se expressa de maneira contrária, está rasgando a Constituição Brasileira, a mesma Constituição que garante os direitos aos veículos de comunicação.

Peço aos cidadãos de bem que não se calem, pois não vivemos mais em regime ditatorial. O ano é 2010 e não 1964.

E termino aqui com uma frase de Sun Tzu, dedicada a todos os que ainda tentam reprimir de maneira covarde, o sentimento de opinião contrária.

“Ao cercar um homem dê a ele ao menos uma saída. Caso contrário ele lutará até à morte.”

Manaus, 04 de janeiro de 2010.

Ao que vos manifesta e representa,

Evandro Borges

Muito simples de instalar:

1. baixe o tarball
2. instale como qualquer aplicação python ( python setup.py install )
3. configure PS1 no ~/.bashrc

wget -c http://bitbucket.org/krbullock/hg_ps1/get/tip.tar.gz

tar xvf tip.tar.gz

cd hg_ps1/

sudo python setup.py install

Coloque no ~/.bashrc o seguinte:

Se você tiver também o git instalado, coloque este abaixo:

Como pode ser visto no comando acima, tem também o __git_ps1, se você entrar em algum repositório git, também funciona, a melhor configuração para manter os dois foi essa acima. Isso é muito útil.

Nos últimos tempos estou conscientizando os meus colegas de trabalho sobre os benefícios da utilização de um controle de código distribuído. Fiz uma análise nas vantagens e desvantagens do Git e HG (Mercurial) e escolhemos o Mercurial pois precisamos trabalhar em um ambiente heterogeneo e o suporte do Git ao windows  ainda é precário, até achamos algumas iniciativas como o MSysGit, porém ainda possuem um longo caminho pela frente para se tornar uma ferramenta que atenda as nossas necessidades(realidade). A comunidade do mercurial está mais evoluida neste sentido, e ao que estudamos o Mercurial disponibiliza todas as funcionalidades que almejamos em um gerenciador de código distribuído.

O objetivo deste post é mostrar o fluxo de trabalho com mercurial, comentando os comandos executados em um fluxo de trabalho escolhido por mim. Alguns devem se perguntar, “Por que escolhido por você ?”, porque com o gerenciador de código distribuído não existe um fluxo de trabalho obrigatório a ser seguido, as ferramentas oferecem recursos para você adaptar fácilmente o fluxo de trabalho, portanto uma vez que você entende os conceitos do gerenciador de código distribuído você nota que é você quem faz seu fluxo de trabalho.

Não se assuste com as sequências de códigos, logo abaixo segue os comentários sobre as operações efetuadas, uma das coisas legais do mercurial é que a maioria dos comandos são legíveis, portanto tente entender somenter ao ler os comandos, senão entender, leia os comentários e avalie novamente os comandos, tudo deve fazer sentido, pelo menos eu espero que faça sentido.

Como dito anteriormente o objetivo não é explicar os conceitos. Portanto para entender os conceitos por trás do que é um gerenciador de código distribuído recomendo a leitura dos seguintes textos:

• Conceitos básicos de controle de versão de softwew: Centralizado e Distribuído.
• Entendendo git e instalando gitorious. Nesse post recomendo os capítulos Mudança de paradigma, Problemas da centralização 1, 2 e 3, Git: Ferramenta para pessoas sem paciência, Mundo ideal .
• Introdução ao controle de versão distribuído (Ilustrado). (Inglês)

Configuração

Para este post estou usando mercurial 1.3.1 instalado no ubuntu através do easy_install.

Recomendo configurar também o __hg_ps1, como nesse post.

Antes de começar configure seu .hgrc. Crie um arquivo no seu home:

touch ~/.hgrc

E então edite com seu editor favorito e coloque as seguinte informações sobre a aparência do hg:

[ui]

username = Seu Nome <seu@email.com.br>

style = compact

Antes de continuarmos, uma coisa que é muito legal no mercurial são as extensões. O mercurial já vem com uma série de extensões incluídas, para uma lista completa clique aqui, abaixo algumas que julgo essenciais, embora eu não vá explicar a utilização de todas nesse post, já deixe habilitado, não custa nada com certeza explicarei nos posts seguintes.

• mercurialqueue
• rebase
• graphlog

Para habilitar adicione ao arquivo ~/.hgrc também uma nova seção para as extensões:

[extensions]

hgext.graphlog =

hgext.mq =

hgext.rebase =

Comandos básicos

Tendo em mente que você já sabe os conceitos, vamos fazer uma lista breve de comandos básicos que você deve saber na ponta do dedo.

hg clone <url>

faz uma cópia local do repositório informado

hg pull

faz download das mudanças no repositório de origem (pai)

hg push

faz upload das mudanças no repositório de origem (pai)

hg status

verifica se há alterações locais

hg tip

verifica qual a versão que está a frente no repositório, ou se preferir no topo(HEAD)

hg incoming

verifica o que tem de novo no repositório de origem, frequentemente usado antes de fazer um hg pull, para saber o que se esperar.

hg outgoing

verifica o que você tem de novo em relação ao repositório de origem, frequentemente usado antes de fazer hg push

hg merge

uni duas branches ou changeset transformando em uma.

Trabalhando

Vamos agora iniciar o trabalho, você vai codificar um projeto novo, então você cria uma pasta, inicia o repositório e adiciona inicialmente um arquivo de README com instruções ou informações sobre o projeto:

Agora temos uma pasta com o nosso projeto e que está sendo versionado pelo mercurial, adicionamos um arquivo com informações para ser rastreado, fizemos o commit e depois verificamos qual o tip(head) do repositório. Você pode verificar que a saída do hg tip foi algo bem resumido, isso por que configuramos no ~/.hgrc na seção [ui] , o estilo compacto style = compact . Se você deseja que o output dos comandos do mercurial sejam mais verbosos, basta comentar o style = compact ou remover do ~/.hgrc.

Dentro de uma equipe de desenvolvimento de software, existem pelo menos 2 ciclos básicos que ficam em loop olhando pela perspectiva de implementação e não de análise, eu chamo de ciclo implementativo e corretivo.

Abaixo apresento minha solução para os ciclos em um mundo ideal. Há quem diga que não vivemos em um mundo ideal, mas eu acho importante para entender e fixar os conceitos.

Ciclo implementativo

1. Identicar nova funcionalidade e traçar funcionamento básico
2. Abrir uma ramificação(branch) do projeto
3. Codificar e testar na branch criada SOMENTE para esta feature
4. Unir(merge) tip da branche da nova feature ao tip da mainline (branche default) e commitar
5. Fechar a ramificação da branche da nova feature

Claro, aqui não é usado nenhuma formalidade nem nome bonito. É simplesmente como eu resumo minhas tarefas implementativas ao meu gosto.

Esse processo pode variar, o mercurial dá a liberdade de você fazer isso como quiser, abaixo eu demonstro como eu faço isso. Uma coisa interessante de ser mencionada é que as branchs são operações no repositório e portanto entram para o histórico do repositório, não esqueça que as branches precisam ser commitadas, dependendo do seu projeto você pode não querer saber como cada desenvolvedor criou a branch ou que nome deu para a branch, eu acho interessante e não vejo problema nisso, muito pelo contrário, temos um histórico fidedigno do desenvolvimento do projeto.

Então vou criar a branche para implementar a funcionalidade UltraMegaBoga de todos os tempos .

Dae você pode ver que usamos o hg branch para nomear a branche padrão atual (default) e depois criamos de fato através do commit (ci), e depois confirmamos usando o hg branches para verificar quais as branches que temos no repositório. E agora sim podemos codificar a funcionalidade. No commit automaticamente somos movidos para a branch nova que acabamos de criar.

Então, implementando uma nova feature:

Opa!, muita informação?… nada, só algumas sendo repitidas.

Linhas 1 ~ 10: Nestas linhas apenas criamos um arquivo, colocamos conteúdo dentro dele, executamos, verificamos o status do repositório e eles nos diz que o arquivo novo não foi adicionado e então o adicionamos ao projeto para ser rastreado e então commitamos. Simples hein ?!

Linhas 11: Na linha 11 há um comando novo que ainda não comentamos, o comando hg glog que mostra o log do repositório através de um grafo, o que facilita bastante a vida quando estamos trabalhando com branches(ramificações), para entender melhor veja bem que o glog traz a arvore de forma natural, ou seja,  da raiz até o topo ou nós. Na primeira coluna mostra os nós e aonde você está em relação aos nós da arvore, cada nó desse representa um commit, os nós são representados por o e onde você está através do @, na segunda coluna estão as revisões de números inteiros e sequencias que você pode usar para se direcionar ou situar na árvore ou histórico, o mercurial usa revisões sequencias e hashs para controlar o histórico e os changesets(conjuntos de mudanças).

E então esses procedimentos se repetem até o nó 4 ou changeset 63ddafc85f03, conforme pode ser visto localizando o @ no resultado do comando hg glog.

Vamos voltar para o branche default para fazer o merge e incorporar as modificações da branche UltraMegaBoga

Outro comando novo, hg update, com esse comando você pode alternar entre as branches(ramificações) do seu projeto e nas revisões também bastando passar o parâmetro hg update -r REV, na linha 1 alternei para a branch default e você pode perceber na saída do comando hg glog que o @ voltou para revisão 0 que é onde a revisão default parou, certo ? os outros commits foram da branche NovaFeature_UltraMegaBoga.

Agora vamos fazer o merge das duas branches.

hg merge <nome_do_branch> e então a união é feita, mas você pode ver pela saída do hg glog da linha 7 que o @ aparece tanto na revisão 0 quanto na 4, porque faltou criar o nó que significa a união dos projetos e que será ponto de partida para novas alterações, e eles nos avisa ao fazer o merge não esqueça de fazer o commit. E então fizemos o commit informando que estamos incorporando a nova funcionalidade. e então você pode ver o resultado do glog novamente, gerou-se a revisão 5 e novo hash. Agora percebesse que o glog é realmente muito útil né ?

Agora para finalizar o ciclo, precisamos fechar a branch que criamos para desenvolver a feature, essa é uma funcionalidade que veio no mercurial 1.2, pois antes disso o mercurial não permite deletar branch, imagine a quantidade de branches que perduravam a vida toda no repositório ?!.

Encerrando as atividades da branch UltraMegaBoga.

Basicamente na saída acima, voltamos para a branch da funcionalidade UltraMegaBoga e fazemos um commit de encerramento, com o parâmetro –close-branch. Com isso damos fim ao Ciclo Implementativo.

Ciclo corretivo

No ciclo corretivo, existem 2 aspectos:

1. Você encontrou o problemas durante o desenvolvimento, antes de lançar uma versão.
2. Você encontrou ou encontraram pra você depois de ter lançado a versão.

Para primeira ocasião você pode usar o mesmo mecanismo do ciclo implementativo para fazer as correções. Agora na segunda ocasião eu sugiro uma abordagem diferente, o ideal é corrigir o problema e gerar patches para serem incorporados uma vez que o software já foi congelado(lançado a versão) e está apenas sofrendo correções esporádicas e não mais vivendo em um intenso processo de produção, para isso eu uso a extensão do mercurial chamada MercurialQueues, que é um conjunto de comandos para gerenciamentos de uma fila de patchs no estilo LIFO(Last-In / First-Out), o ciclo corretivo se divide em:

1. Identificar a causa do problema
2. Consertar o bug
3. Gerar patch e exportar

Alguns devem ser perguntar o porque de eu sugerir MercurialQueues, pelo motivo de que os commits são maleáveis, no padrão os commits do mercurial são imutáveis, já com o MQ posso trabalhar em varios patches ao mesmo tempo somente manipulando a fila ao invés de ter que ficar importando e/ou exportando patches, posso também mesclar patches sem que isso interfira nos commits. IMHO, é mais conveniente. Você pode também usar o patch para aplicar a correção na versão que está em desenvolvimento

Comandos básicos

hg qinit

hg qnew

hg qrefresh

hg qpop

hg qpush

hg qfinish

hg qimport

Abaixo um exemplo de como criar uma fila e desenvolver um patch usando mercurial queues.

Linhas 1 ~ 10: É iniciada uma fila através do comando hg qinit -c , -c significa que a fila será versionada e portanto poderá ser usado o comando hg qcommit. Depois verificamos se está tudo zerado usando os comandos hg qseries e hg qapplied , o qseries nos permite verificar quais patchs estão na fila e o qapplied quais patchs estão aplicados efetivamente no repositório. Para criar um novo patch basta executar o hg qnew <nome_do_patch> que no exemplo acima atribui o nome fix_bug_01.patch. Alteramos o arquivo e podemos ver com o glog que ao criar o patch, já é aplicado automaticamente no repositório e por padrão coloca como msg do commit [mq]:  nome_do_patch.

Linhas 40 ~ 51: É incluídas as alterações feitas no patch atual através do comando hg qrefresh. É feita uma alteração no arquivo teste.py  e pra ver a diferença entre hg diff e hg qdiff é executado hg diff que é a última alteração que o repostório reconhece, quando executamos o hg qrefresh ele pega as alterações e armazena internamente no patch e as alterações não ficam mais no repositório comum e sim no patch que está sendo desenvolvido com mercurial queue. O hg qdiff mostra todas as alterações incluídas(através do qrefresh) no patch.

Linhas 67 ~ 75: É verificado que o patch continua aplicado (através do qapplied) e já que o patch está completo está na hora de armazena-lo e retirá-lo da lista de aplicados através do comando hg qpop que remove do topo da fila o patch e como o único e no topo é o fix_bug_01.patch não retorna nada o comando hg qapplied e então o patch é commitado através do hg qcommit essa fila de patchs é um outro repositório interno do mercurial, se você quiser confirmar é só entrar no .hg/patches do se repositório e rodar o comando hg glog para constatar o sub-repositório de patches criado pelo MercurialQueue.

Para exportar o patch pode usar o comando hg export <nome_do_patch> e para importar para o repositório normal use hg import ou se quiser importar para uma outra lista de patches hg qimport e então o patch será adicionado ao hg qseries.

Enfim as possibilidades são enormes com o MercurialQueue, e isso foi só uma demonstração básica do uso de MercurialQueues.

Ufa! Espero que alguém tenha paciência pra ler. Essa tá longe de ser a versão final desse post. Publiquei logo para ter um norte. Portanto agradeceria bastante as sugestões de melhoria, críticas, correções e etc.

Próximos posts(Aguardem) :

• Trabalhando com o Mercurial – Mais sobre MercurialQueues
• Trabalhando com o Mercurial – Rebaseando
• Trabalhando com o Mercurial – Resolvendo Conflitos

Estou muito contente com esse projeto, pois dá ênfase na convergência de esforços dos mais diferentes grupos dentro do software livre além de poder orientá-los para que trabalhem juntos para a difusão do grupo regional de software livre a nível nacional, dessa forma ganhando força para avançar os trabalhos com e para a comunidade de software livre em geral.

Meus parabéns a todos os envolvidos, os que me recordo agora são:

• Daniel Bruno
• Antônio Junior
• Davyd Smelk
• Ayrton Freeman
• Jônatas Nona
• Éverton Arruda
• Marcelo Mendes

Se esqueci alguém, me avise.

Por vários fatores eu já esperava que a minha palestra fosse atrair poucos interessados, mas gostei muito dos participantes que estavam lá, pois como eram poucos foi possível fazer uma espécie de bate-papo e troca de experiências sobre o conteúdo.

Também não posso deixar de agradecer ao André Felipe Dias por permitir o uso das imagens do seu artigo Conceitos Básicos De Controle de Versão de Código: Centralizado e Distribuído.

Como prometido, segue aqui o link para download da palestra.

Críticas construtivas são sempre bem vindas, comente!

Seguindo a onda de posts de feedback, vou escrever o meu:

Kaio Rafael

Marcelo Mendes

É difícil escrever mais coisas do que o Kaio e Marcelo já escreveram, porém gostaria de ressaltar alguns fatos.

IMHO, esse foi um dos melhores senão o melhor Debian Day já realizado por nós do Debian-Am, acompanhei todos e 1 ou 2 não consegui contribuir de fato com a realização do evento. Além de tudo serviu para mostrar que o trabalho colaborativo realmente faz a diferença.

Este Debian Day foi diferenciado, pois o nosso ilustre amigo e principal articulador da comunidade Davyd Smelk adoeceu a tal ponto de mal conseguir andar e com isso não pode comparecer ao evento. Esse evento também marcou a participação de mais pessoas na comunidade Debian-Am que de fato ajudaram na organização, como o pessoal do Projeto Zagaia , o Ruy, o Carlos Lucoli e outros. Espero que isso marque uma nova fase no Debian-AM e que todos continuem ajudando como ajudaram neste Debian Day.

Outra coisa que também precisa ser ressaltada é que foi o primeiro Debian Day que trouxemos alguém de fora para palestrar, contamos com a presença do grande e muito amigável Fábio Berbert de Paula, criador do vivaolinux.com.br que ministrou 2 excelentes palestras com informações muito úteis para todos os presentes, sendo técnicos ou não.

Também não podemos esquecer  de agradecer os Patrocinadores e Apoiadores do evento que nos ajudaram a concretizar o nosso objetivo.

Esse ano o evento teve o foco em assuntos técnicos, com isso tivemos que pagar o preço na quantidade de participantes em relação aos outros Debian Days, mas acredito que esta será a linha adotada daqui em diante em relação ao Debian Day.

Algumas fotos do HackFest de preparativos na madrugada anterior ao evento:

Nerdões

Nerdões

Algumas fotos do Evento:

Oficina de BrDesktop

Palestra do Fábio Berbert

Parabéns a todos!

Debian Day é um evento realizado anualmente por vários grupos de Software Livre em todo o mundo. Também conhecido por Dia Debian e Dia D, este evento comemora o aniversário da distribuição GNU/Linux Debian, que neste ano (2009) completa 16 anos de existência.

Em Manaus, o Debian Day é realizado pelo Grupo de Usuários Debian do Amazonas, conhecido por Debian-AM, sendo patrocinado pela UniLaSalle e com o apoio do Projeto Zagaia, AIT Technologies e Gráfica Silva.

Neste ano, teremos um I Desafio DebianDay de Programação:

E também um convidado especial, o criador e mantenedor do site Viva o Linux (http://vivaolinux.com.br), Fábio Berbert de Paula.

Convidamos todos a participarem deste evento.
Data: 22 de Agosto de 2009.
Local: UniLaSalle, Dom Pedro I, em frente à praça de alimentação do Dom Pedro I.
Horário: 9h – 17:30h, credenciamento de 8h – 9h.
Entrada: 2Kg de alimentos não perecíveis, exceto sal.

Para saber como participar do desafio de programação, visite o site de evento.

Site: http://diadebian.org/am/2009

Optando pela dica de um amigo, consegui diminuir esse tempo de compilação para aproximadamente ~50 minutos usando 6 núcleos no total, 2 núcleos do meu notebook e mais 4 da minha estação de trabalho.

É algo bem simples de fazer, let’s do it

Primeiramente você precisa instalar o ICECC nos computadores que você irá compartilhar recursos para compilação e nada mais óbvio do que usar o apt-get ou aptitude:

~$ aptitude install icecc

Depois de instalado nas máquinas que você deseja utilizar os recursos é necessário configura-lás em um grupo para que elas possam se comunicar, em uma analogia equivalente seria como configurar um grupo de rede onde cada máquina consegue enxergar as outras porque estão no mesmo grupo. Para configurar essa rede é preciso editar o arquivo /etc/icecc/icecc.conf e colocar a seguinte diretiva apontando para o nome da rede:

ICECC_NETNAME=”nome_da_sua_rede“

onde tem nome_da_sua_rede substitua pelo o nome de sua preferência para a rede de compilação e configure essa diretiva com o nome que você definiu para cada máquina que você irá utilizar para a compilação e depois reinicie o daemon delas com:

sudo invoke-rc.d icecc restart

Nessa rede é preciso que ao menos uma das máquinas seja a responsável por distribuir os dados de compilação, pegar o retorno e juntar tudo. A essa máquina damos o nome de “Scheduler”, para configurar uma máquina como scheduler é preciso que o arquivo /etc/default/icecc esteja da seguinte forma:

# Defaults for icecc initscript

# sourced by /etc/init.d/icecc

START_ICECC=”true”

START_ICECC_SCHEDULER=”true”

E depois reiniciar o daemon com:

ICECC_NETNAME=”nome_da_sua_rede”

Dai em diante é só compilar algum código grande que você verá a diferença, também existe uma ferramenta para você monitar a compilação é o icecc-monitor, para instalar (nada mais óbvio):

sudo aptitude install icecc-monitor

Depois adicione o path do icecc ao seu $PATH, inserindo o seguinte comando no seu ~/.bashrc :

export PATH=/usr/lib/icecc/bin/:$PATH

source ~/.bashrc

E boa compilação, keep hacking!