Guax

Tem um dunga escondido nessa foto

Detalhe como foi proposital, o FOCO da câmera está no fundo e não no Dunga. E isso era uma coletiva de imprensa a câmera ficou assim o vídeo todo. aheauheuha

Primeiro vamos aos esclarecimentos para tentar evitar qualquer flame. Sou usuário de Slackware ha 6 anos mais ou menos mas faz 2 anos que convivo diariamente com Debian. Esse ensaio sobre os pacotes desta última distro é feito em cima da minha experiência com as duas e não representa qualquer tipo de preconceito com a distro. Espero que leiam até o final antes de comentar ou expressar uma opinião mais acalorada. Agora vamos ao que interessa.

Estrutura Do Pacote

A estrutura de um pacote .deb pronto é simples e não tem nada complexo. E um pacote do Slackware não fica atrás. A diferença principal é que os dados do software estão em um tar separado dos arquivos que fazem o controle da instalação. Não são muitos arquivos e em resumo o principal de um pacote .deb é:

debian-binary

Arquivo de texto com a versão do binário do pacote.

control.tar.gz

Meta informação do pacote. Dependências e coisas do tipo.

data.tar ou data.tar.gz ou data.tar.bz2 ou ainda data.tar.lzma

O diretório que contém os arquivos do programa a ser instalado.

Tudo isso comprimido em um pacote ar. Acho que é o mínimo e o máximo necessário para um controle de pacotes com dependencias como no Debian.

No Slackware a estrutura é semelhante mas é basicamente um pacote tar gzip, bzip ou xz que representa o mesmo que o data.tar no pacote Debian, mas com um sub-diretório install onde estão os arquivos de controle da instalação.

Geração do Pacote e a Aberração Debianization

Ok, aqui o bixo pega. Então vou fazer em forma de comparativo entre Slackware e Debian.

No Slackware

É nois que voa bruxão

A geração de pacotes no Slackware é feita usando preferivelmente um script em shell para automatização da compilação e empacotamento chamado SlackBuild Script, é um shell script perfeitamente normal que qualquer pessoa com o mínimo de experiência no mesmo consegue dar manutenção. Em geral o que o slackbuild faz pode ser divido em duas fases:

1. Compilação e instalação do pacote em um diretório temporário
2. Geração do pacote com o facilitador makepkg

A primeira fase é feita usando as ferramentas disponíveis pela aplicação. Pode ser autoconf, ant ou qualquer build system. Até mesmo um chroot se faz necessário em alguns casos. A segunda parte é a normalização do pacote que consiste em compactação de man pages, strip de shared libraries, a inclusão do próprio build script como doc e dos arquivos para o diretório install/ e por fim a compactação do diretório e criação do t?z.

É importante ressaltar que nos pacotes Slackware o código fonte original não é mexido e sequer distribuido junto com os SlackBuilds na maioria dos casos. Alguns casos existem onde patches são necessários para que o pacote funcione corretamente mas estes são aconselhados somente se o programa não puder funcionar sem este ou isso representar um risco grave de segurança e estabilidade. A politica pura e simples é: Desenvolvimento é papel dos desenvolvedores e não dos empacotadores.

No Debian

Coididoido esse debian.

O documento de política de desenvolvimento do Debian é um monstro de 10 sessões com mais 10 sub-sessões cada e 7 anexos. Recomendo a leitura se quiser confirmar o que eu digo aqui. Vou resumir a forma de criação padrão de pacotes.

A mudança na forma de pensar já começa na nomenclatura do indivíduo que empacota. No Slackware é um empacotador. No Debian é um desenvolvedor.

Primeiro salva-se o código fonte original em um .orig e então pode se começar a Debianização do aplicativo. Um pacote é feito geralmente usando de 2 a 4 aplicativos facilitadores e geralmente o autoconf é o responsável pela geração do pacote. Tudo isso fica dentro do código fonte em um diretório debian/. A estrutura é complexa e é necessário um longo periodo e leitura da documentação para a compreensão do sistema de empacotamento e criação de um pacote seguindo todas as guidelines.

Na documentação em vários trechos é recomendado a edição do código fonte original para debianização do aplicativo. O que ao meu ver só maximiza as possibilidades de problema como aquele infame warning no openssl que foi silenciado por um Debian desenvolver e fez com que as chaves de milhares de servidores fossem geradas de forma previsível.

Também há uma preocupação grande mas parcialmente justificável de separar os cabeçalhos de bibliotecas em pacotes adicionais e usar a mesma estrutura para gerar mais de um pacote elevando a complexidade do sistema.

Pensamentos Finais

Não muitos, eu não gosto desse sistema e as guidelines do Debian são uma aberração pra mim. Vou tentar criar um DebBuild script para gerar pacotes Debian no estilo Slackware e posto aqui se o fizer.

Meu chefe certo dia falou que o sistema do Slackware dependia do “artista” e não era processual o suficiente. Mas lendo a guideline do Debian eu descobri que ele está errado nisso, pois a inversa é verdadeira. O sistema do Debian é justamente isso, um sistema com sub-sistemas e macro-sistemas usados para gerar coisas que no final das contas são simples, uma arquitetura digna de um arteiro e não artista.

PS IMPORTANTE

Eu falo aqui da forma de geração de pacotes recomendada e ensinada pelo documento abaixo. NÃO estou considerando outras formas, se existirem, de gerar pacotes Debian. Como por exemplo a utilização de um script sh ou CDBS.

Referências

deb (file format) From Wikipedia, the free encyclopedia

Debian Policy Manual From Debian.org

PS.  gentil correção do caio:

[11:39] <caio1982> guax: debian-binary nao eh a versao do pacote, seu animal, eh a versao dos binarios do debian (.debs em geral distribuidos em “formato debian”, nao sao backward compatible pra sempre)

PS2. adição do caio: http://build-common.alioth.debian.org/cdbs-doc.html

De conformidade com o Código Penal brasileiro o estelionato é capitulado como crime ecônomico (Título II, Capítulo VI, Artigo 171), sendo definido como “obter para si ou para outrem, vantagem ilícita, em prejuízo alheio, induzindo ou mantendo alguém em erro, mediante artifício, ardil ou qualquer outro meio fraudulento.”

Estelionato virtual tendo o G1 como cúmplice involuntário.

Sério youtube, WTF???

Tem site melhor pra procurar esse tipo de coisa.

Isso que da tentar me sugerir uma tradução literal dos lixos to youtube brasileiro. =P

Sábado dia 24 de Abril tivemos no IFSC em Florianópolis a edição 2010 do FLISOL. O número de inscritos pelo sistema de inscrições é de 116 pessoas. Por conta da chuva nossa expectativa baixou bastante e o número de pessoas que realmente apareceu no evento foi de mais ou menos umas 40 pessoas. Muitos podem achar isso terrível, menos da metade dos inscritos. Eu vejo diferente.

Eu participo do Flisol e dos eventos de software livre de Florianópolis desde que me mudei pra cá, contribuindo com a maioria deles na organização com palestras ou instalações. Nunca na história desse país eu tinha visto tantos interessados no evento assim de uma hora pra outra. Afinal fizemos o lançamento faltando menos de um mês pro evento e o esforço de divulgação foi relativamente pequeno. 40 pessoas é mais ou menos o número de participantes dos primeiros anos, perdendo somente para os quase 70 do ultimo Flisol (um dia ensolarado). Uma vitória pro SL aqui em Santa Catarina com certeza.

No Flisol eu não precebo cadeiras vazias, as ocupadas é que importam.

Esses 40 são o público ideal para o Software Livre. São as pessoas que saem debaixo de chuva num sábado e pegam ônibus para ir pro evento. Estão realmente interessados. Desses 40 ainda temos uns poucos que fazem o SL ser a coisa mais divertida atualmente no ramo de TI que eu conheço. Eles são participativos, conversam, são gente boa, pagam cuca com pizza para os instaladores ou simplesmente vem conversar sobre coisas nerds. São doutores em matemática, pedagogos, programadores, sapateadores baianos, namoradas e namorados que foram arrastados pra lá e até figurinhas mais famosas como o Hélio Chissini pra falar sobre cerveja, musica e mal do Ubuntu. Não que alguém precise gostar de software livre pra ser gente boa, mas é dentro do SL que eu vejo isso ser praticamente mandatório.

O povo das instalações e a futura convertida ao Slackware. Força Melissa, arruma esse grub ae. o/

Nesses pequenos eventos que eu vejo os palestrantes nervosos e outros não tão nervosos que tem como único interesse o desenvolvimento do SL. Vejo palestras começarem sobre um tema e terminarem com outro devido ao incentivo da platéia. Outras terminam com perguntas respondidas por todos os presentes e temos uma palestra a parte sobre como funciona o movimento SL. Palestrantes de pés descalços e sentados enquanto escutam o que pessoas na platéia tem pra contribuir. Protocolo zero e conteúdo maravilhoso, isso pra mim é mais elegante que qualquer terno e gravata.

É por isso que o Flisol desse ano pra mim foi mais um grande sucesso. Não vou citar nomes por que são muitas as pessoas que merecem meu obrigado nesse post e eu não quero correr o risco de esquecer ninguém.

O palco não é o único ponto onde a atenção tem que estar voltada.

Muito longo pra um tweet.

SOCIALISM:
        You have two cows.  Give one to your neighbour.
COMMUNISM:
        You have two cows.
        Give both to the government.  The government gives you milk.
CAPITALISM:
        You sell one cow and buy a bull.
FACISM:
        You have two cows.  Give milk to the government.
        The government sells it.
NAZISM:
        The government shoots you and takes the cows.
NEW DEALISM:
        The government shoots one cow,
        milks the other, and pours the milk down the sink.
ANARCHISM:
        Keep the cows.  Steal another one.  Shoot the government.
CONSERVATISM:
        Freeze the milk.  Embalm the cows.

:(

O título alternativo para essa foto é: “Business Software, intenção e implementação”.

Comecei a brincar novamente com CDR, estava esboçando um daemon para acompanhar o fluxo das ligações e percebi que o buraco é mais embaixo. Explico:

Uma ligação com transferência.

A é uma ligação vinda da PSTN e é direcionada para B que é um ramal interno. B transfere a ligação para C, outro ramal interno. A fala com B durante 2 minutos, o tempo de atendimento foi de 10 segundos sendo no total 2:10 minutos de ligação. A fala com C por outros 2 minutos e espera 10 segundos também para ser atendido (transferência cega). Temos um total de 4:20 de ligação e 4:00 de conversação.

Até ai tudo bem, só que esses 4 minutos não são o tempo pelo qual A foi bilhetado. Ele foi cobrado por 4:10 de ligação já que somente os primeiros 10 segundos de chamada o canal dele estava em estado não atendido. Essa conta fica mais maluca de ser extraída do CDR do Asterisk se considerar que num sistema de produção de médio porte temos transferências feitas pelo originador, transferências para PSTN e cadeias intermináveis de transbordo em filas e grupos de ramais.

Múltiplas tarifações na mesma ligação são possíveis em conferências por exemplo onde geralmente liga-se para o cliente e transfere para a sala de conferência. Nesse caso todos os canais devem ser tarifados e não somente uma vez o tempo da ligação.

Ostrich Ski