Tag Archive for 'artigo'

ENIAC: o primeiro computador

Publicado dia 1 de fevereiro de 2010 em artigo. 3 Comments Tags: .
inventores

Os ide­a­li­za­do­res do projeto.

Se lhe per­gun­ta­rem um dia qual o com­pu­ta­dor mais famoso do mundo, pro­va­vel­mente a res­posta será “HAL 9000” ou algum outro dis­po­si­tivo fic­tí­cio, mas, com cer­teza, se lhe dis­se­ram o nome ENIAC você saberá do que se trata ou terá cer­teza de já ter escu­tado essa pala­vra em algum lugar. Você pode nem per­ce­ber, mas o ENIAC é um des­ses raros casos em que um evento torna-se tão impor­tante que passa a fazer parte do sub-consciente cole­tivo. A impres­são latente aqui, tra­zida pela pala­vra ENIAC, é de algo assom­bro­sa­mente moderno e pode­roso, nunca antes visto e revo­lu­ci­o­ná­rio. De fato, foi assim, mas já se pas­sa­ram 63 anos desde que ele, o pri­meiro com­pu­ta­dor do mundo, entrou em operação.

Nos anos 1940 o mundo estava em plena II Guerra Mun­dial e sabia-se que o exér­cito melhor pre­pa­rado ven­ce­ria. Cal­cu­lar tra­je­tó­rias balís­ti­cas era uma tarefa com­pli­cada que exi­gia conhe­ci­men­tos de física e mate­má­tica, além de cál­cu­los demo­ra­dos fei­tos à mão. Era comum que hou­ves­sem equi­pes de mate­má­ti­cos tra­ba­lhando nos cál­cu­los 24 horas por dia na ten­ta­tiva de oti­mi­zar a pon­ta­ria durante os ata­ques. Con­ti­nue rea­ding ‘ENIAC: o pri­meiro computador’

  • Share/Bookmark

Minha primeira experiência com o Haiku (OpenBeOS)

Publicado dia 28 de setembro de 2009 em análise, artigo, opinião and sistema operacional. 2 Comments Tags: , , , .

Alguns devem ter per­ce­bido que estou “revi­si­tando” alguns tex­tos anti­gos aqui no blog. Bem, isso faz parte de algu­mas mudan­ças que pre­tendo fazer para tor­nar o blog mais atra­tivo e variado.

Minha pri­meira ati­tude foi revi­sar e atu­a­li­zar uma série que come­cei mas nunca che­guei a ter­mi­nar sobre sis­te­mas ope­ra­ci­o­nais em dez par­tes. Ontem repos­tei o texto sobre o BeOS, desde o começo do desen­vol­vi­mento até a sua morte e o sur­gi­mento do Haiku, que é uma ver­são atual e open­source do finado SO.

Bai­xei o Haiku e ins­ta­lei aqui na minha máquina vir­tual, mas não espe­rava que a expe­ri­ên­cia fosse tão mar­cante. Por isso, decidi com­par­ti­lhar com vocês minhas impres­sões. Vamos lá?

A ima­gem ISO vem com­pac­tada no for­mato ZIP, são ape­nas 164,4 MB para bai­xar e, des­com­pac­tado, vai a 379,9 MB. Mesmo com a minha cone­xão de 300 K levou pouco mais de uma hora e meia baixando.

Meio rece­oso, dei o boot na ima­gem pela máquina vir­tual, mas tudo cor­reu bem. A pri­meira tela é bas­tante sim­pá­tica e pouco depois leva para uma caixa ofe­re­cendo a pos­si­bi­li­dade de ins­ta­lar ou rodar live. Instalei.

Ao con­trá­rio do que esta­mos acos­tu­ma­dos, o Haiku não par­ti­ci­ona auto­ma­ti­ca­mente durante a ins­ta­la­ção; ele detecta não haver par­ti­ção, mas não toma nenhuma pro­vi­dên­cia. Cabe a você ir no par­ti­ci­o­na­dor (que não é muito intui­tivo), sele­ci­o­nar os espa­ços e os for­ma­tos, apli­car e depois vol­tar para a instalação.

Feito isso, o resto é tran­quilo e rápido. Ape­nas dez minu­tos depois o Haiku está rodando e o boot leva ape­nas 15 segundos.

A parte “mar­cante” que men­ci­o­nei foi sen­tir o mesmo que sen­tia no começo da minha vida linu­xer. A emo­ção de ins­ta­lar um outro SO e explorá-lo, ir tate­ando no escuro e vendo novi­da­des. Ses­são nostalgia…

Na VM o dis­po­si­tivo de rede não foi reco­nhe­cido, por isso não pude tes­tar a inter­net e nem expe­ri­men­tar o BeZilla Brow­ser (um remake do Fire­fox), mas rodei pelo sis­tema inteiro admi­rando simi­la­ri­da­des e dife­ren­ças entre Linux, Win­dows e Haiku. O BeOS é uma parte da his­tó­ria e quando você se dá conta de que está ali, aces­sando um SO total­mente dife­rente, é impos­sí­vel não pen­sar em como nos­sos hori­zon­tes ficam res­tri­tos com o pas­sar do tempo.

Não pre­tendo fazer do Haiku o meu sis­tema ope­ra­ci­o­nal, mas gra­ças e ele eu pude sen­tir, nova­mente, a empol­ga­ção da des­co­berta que já não tinha mais nos GNO­MEs e KDEs da vida. Pra fechar, seixo algu­mas scre­enshots que tirei e vídeos mos­trando um pouco da Sili­con Graphics dos Pobres, como era chamado.

Visão geral

Abrindo 26 apli­ca­ti­vos ao mesmo tempo

Colo­cando o Haiku sob Stress

1 Star2 Stars (+4 rating, 2 votes)
 Loading ... Loa­ding …

  • Share/Bookmark

Sistemas Operacionais (parte 3 de 10) AtheOS

Publicado dia 25 de setembro de 2009 em artigo and sistema operacional. 2 Comments Tags: , .

AtheOS (de Athena Ope­ra­ti­o­nal Sis­tem) era um sis­tema ope­ra­ci­o­nal ini­ci­al­menteatheoslogo dese­nhado para comportar-se de forma seme­lhante ao Ami­gaOS. Seu desen­vol­vi­mento come­çou no iní­cio de 1994 pelo pro­gra­ma­dor noru­e­guês Kurt Skauen. Inte­res­san­te­mente, o AtheOS foi desen­vol­vido para que Kurt tes­tasse o sis­tema de arqui­vos cri­ado por ele, o ATheFS (ou AFS). O AtheOS tor­nouse notó­rio quando seu anún­cio ao público foi feito de uma maneira um tanto inu­si­tada. Kurt jogou no Use­net uma men­sa­gem onde anun­ci­ava estar rodando um ser­vi­dor com seu pró­prio sis­tema ope­ra­ci­o­nal (licen­se­ado pela GPL) e que dese­java que as pes­soas o aju­das­sem ten­tando invadi-lo. O resul­tado foi uma chuva de ata­ques ao ser­vi­dor de Kurt e, por con­se­quen­cia, cen­te­nas de olhos de pes­soas dis­pos­tas a aju­dar no desen­vol­vi­mento.
shotKurt desen­vol­veu o sis­tema sozi­nho e quase que arte­sa­nal­mente durante o tempo todo e, embora dis­po­ni­bi­li­zasse o código fonte pela GPL, relu­tava ter­mi­nan­te­mente em acei­tar con­tri­bui­ções de ter­cei­ros ao seu sis­tema. A comu­ni­dade, por fim, ini­ciou seu fork, dei­xando que Kurt per­ma­ne­cesse sozi­nho com seu AtheOS e ini­ciou o Syl­la­ble.
O Sis­tema ope­ra­ci­o­nal de Kurt come­çara com um sis­tema de arqui­vos de 64 bits e com suporte a jour­na­ling. AtheOS foi com­ple­ta­mente escrito do zero, sem apro­vei­tar código de nenhum outro local. Atu­al­mente, roda em pro­ces­sa­do­res intel, AMD e com­pa­tí­veis e tem uma con­si­de­rá­vel quan­ti­dade de softwa­res por­ta­dos para roda­rem sobre o sis­tema, como o Apa­che e o PHP 3. Em vez de usar o X11 como seu ser­vi­dor de vídeo, o AtheOS usa seu pró­prio ser­vi­dor de vídeo, o que, segundo o desen­vol­ve­dor, tem mui­tos prós e con­tras. Os con­tras (alguns), são o lento desen­vol­vi­mento do ser­vi­dor grá­fico, o fato de que mui­tos softwa­res são escri­tos para rodar sobre o X11 e não pode­rão ser por­ta­dos para o AtheOS. Como prós temos o fato de que o ser­vi­dor grá­fico do AtheOS é muito mais lece que o X11 e de que mui­tos pro­ces­sos, com áreade trans­fe­rên­cia, por exem­plo, são geren­ci­a­dos pelo So em vez de pelo ser­vi­dor grá­fico, o que causa uma maior con­sis­tên­cia no fun­ci­o­na­mento e faci­lita o apren­di­zado do usuá­rio.
atheshotA GUI do AtheOS é com­posta por dois ele­men­tos prin­ci­pais: um ser­vi­dor de apli­ca­ções e uma dll que pro­vi­den­cia uma inter­face em C++ entre o ser­vi­dor e as apli­ca­ções. A GUI é pro­gra­mada usando uma API em C++ que per­mite a cri­a­ção de diver­sos wid­gets que pos­suem, cada um, seu pró­prio ambi­ente grá­fico.
O ker­nel, total­mente escrito do zero, tem suporte a SMP (Sym­me­tric Multi Pro­ces­sing) e pos­sui um cli­ente TCP/IP embu­tido. O suporte a módu­los per­mite que ele­men­tos sejam car­re­ga­dos ou des­car­re­ga­dos da ini­ci­a­li­za­ção do ker­nel e tam­bém tem supo­trte a diver­sos sis­te­mas de arqui­vos.
Como era de se espe­rar, o AtheOS (a cru­zada de um homem só) teve um desen­vol­vi­mento lento e me lem­bro bem de que em 2004, quando ouvi falar nele pela pri­meira vez, não dava suporte a mui­tas fun­ções bási­cas de teclado. O Syl­la­ble rapi­da­mente suplan­tou o AtheOS, e, por fim, Kurt aban­do­nou o pro­jeto AtheOS, pas­sando a dedicar-se a outros empre­en­di­men­tos. O Syl­la­ble con­ti­nua a ser desen­vol­vido pela comu­ni­dade e seguiu rumos dife­ren­tes dos pre­ten­di­dos por Kurt Skauen.
O site ofi­cial do AtheOS está em um ser­vi­dor que, é claro, roda AtheOS. As espe­ci­fi­ca­ções téc­ni­cas são: Dual Cele­ron 466 com 768MB RAM e 85Gb de espaço nos dis­cos. esta máquina está exe­cu­tando os seguin­tes ser­vi­ços: HTTP, FTP, CVS, SSH, DNS e Mail (SMTP/POP3).
HTTP: Apa­che V1.3.9
FTP: wu-ftpd 2.6.0
CVS: CVS V1.10.
DNS: Bind
Mail: QMail

UPDATE:

O desen­vol­vi­mento do AtheOS veio ficando cada vez mais e mais lento enquanto cres­cia o inte­resse de Kurt em apren­der a pilo­tar seu avião. Depois da ver­são 0.3.7 alguns pro­gra­ma­do­res envol­vi­dos com o pro­jeto deci­di­ram levar adi­ante um fork cha­mado Syl­la­ble. Este fork foi lan­çado logo na ver­são 0.4.0 em julho de 2002 e, enquanto escrevo este update, encontra-se na 0.6.2.

1 Star2 Stars (+15 rating, 6 votes)
 Loading ... Loa­ding …

Mais sobre o AtheOS

  • Share/Bookmark

Uma TI mais verde (e equivocada)

Publicado dia 24 de setembro de 2009 em análise, artigo, internet and opinião. 4 Comments Tags: , , , .

Está na moda a cons­ci­ên­cia eco­ló­gica e, seguindo essa ten­dên­cia, as pala­vras “boas” da vez são (anote aí): verde, eco­no­mia, pla­neta, árvore e doa­ção. Se você usar qual­quer uma des­sas pala­vras nos seus pro­je­tos – não importa quão imbe­cil ele seja – as pes­soas serão obri­ga­das a aplaudi-lo, afi­nal, o que vale é a inten­ção! Ou será que não vale?

Embora eu seja a favor das ati­tu­des eco­ló­gi­cas, o mais cho­cante na nova gera­ção de abra­ça­do­res de árvo­res e natu­re­bas é a quan­ti­dade de desin­for­ma­ção que essa gente tem. Árvo­res são boas, mas a babo­seira ambi­en­ta­lista de agora trata cada árvore como uma limpa e efi­ci­ente fábrica de ar puro… é como se cada semente fosse um tan­que de oxi­gê­nio em poten­cial, espe­rando para cres­cer e jogar na atmos­fera o pre­ci­oso O2.

Será que nin­guém se lem­bra das aulas de bio­lo­gia no ensino médio? Árvo­res são cri­a­tu­ras vivas como qual­quer ani­mal e res­pi­ram, assim como você e eu, oxi­gê­nio, exa­lando CO2. Acon­tece que no pro­cesso de fotos­sín­tese as plan­tas usam a luz como cata­li­sa­dor num pro­cesso fotoquí­mico que envolve CO2. Logo, de noite, quando não há luz do sol para fotos­sin­te­ti­zar a gli­cose, as plan­tas com­pe­tem conosco pelo mesmo O2. Para resu­mir, a planta faz duas coi­sas: res­pira como nós e faz fotos­sín­tese (observe bem que o ponto chave aqui é o pre­fixo FOTO), por­tanto, sem luz, sem pro­du­ção de oxi­gê­nio e a planta con­ti­nua, assim como nós, res­pi­rando O2.

Há tam­bém alguns estu­dos “geni­ais” que suge­rem replan­tar flo­res­tas com euca­lipto por­que cres­cem rápido e são gran­des. Ima­gine replan­tar a flo­resta amazô­nica com euca­lip­tos? Melhor seria adi­ci­o­nar mais uma pala­vra ao dici­o­ná­rio des­sas pes­soas: bio­di­ver­si­dade.

Entre­tanto, estou diva­gando. Se por um lado não acre­dito nessa ladai­nha de plante um “tan­que de oxi­gê­nio”, acre­dito que árvo­res aju­dam na regu­la­ção da tem­pe­ra­tura, na manu­ten­ção da fer­ti­li­dade do solo, no embe­le­za­mento das cida­des e na sus­ten­ta­ção de um bioma vari­ado, por isso achei legal falar sobre o pro­jeto eco4planet.

O eco4planet é um bus­ca­dor (que, na ver­dade usa o Goo­gle cus­to­mi­zado), mas que pro­mete plan­tar uma árvore a cada 50.000 bus­cas rea­li­za­das pelo seu sis­tema. A tela, como não pode­ria dei­xar de ser é preta, para “eco­no­mi­zar ener­gia”. Sim! O eco4planet é feito por bra­si­lei­ros e, a prin­cí­pio, vai plan­tar as árvo­res em Ribei­rão Preto (SP). Se os caras forem inte­li­gen­tes, tem tudo para dar certo (só espero que não saiam plan­tando euca­lip­tos a torto e a direito).

Se for fazer uma busca pela net, dê uma chance aos caras. Cada árvore plan­tada faz pose para uma foto que você pode ver aqui.

eco

P. S.:

Ape­nas mais duas obser­va­ções (já que estou com a mão na massa):

  1. Se você usa moni­to­res LCD pode usar uma tela mais negra que a alma do Steve Bal­mer e não vai fazer eco­no­mia nenhuma. Isso de telas escu­ras eco­no­mi­za­rem ener­gia só fun­ci­ona nos velhos CRT1.
  2. Quer ver me dei­xar puto e vir falar das “emis­sões de car­bono”, “car­bono zero”… Car­bono é um ele­mento quí­mico da tabela perió­dica que é SÓLIDO à tem­pe­ra­tura ambi­ente (gra­fite, dia­mante…). Car­bono e dió­xido de car­bono são duas coi­sas muito diferentes.
  1. http://googleblog.blogspot.com/2007/08/is-black-new-green.html ↩
  • Share/Bookmark

Gerador automático de tweets — odeio o Twitter parte 2

Publicado dia 17 de setembro de 2009 em internet and opinião. 13 Comments Tags: , , , .

Quando digo que não suporto o Twit­ter sei que muita gente dis­corda e deve me achar um cara retró­grado e “por fora”, mas, sin­ce­ra­mente, quanto mais o tempo passa, mais minha opi­nião sobre micro­blog­ging se consolida.

Não é ape­nas pelo fato de haver milhões de pes­soas com­par­ti­lhando com todo o mundo atos banais com os quais nin­guém se importa, tam­pouco por limi­tar o, já pobre, pseudo-português das pes­soas a 140 carac­te­res (cri­ando outra vari­ante bizarra do inter­ne­tês), mas, seja­mos dire­tos, o Twit­ter é ape­nas a ver­são 2.0 das revis­tas de fofoca.

Legal para empre­sas, legal para pro­je­tos e até para pro­fis­si­o­nais que dese­jam com­par­ti­lhar suas roti­nas de tra­ba­lho, o Twit­ter se vê explo­dindo mundo a fora reple­tos de Joões-Ninguém que acham rele­vante fazer que todos sai­bam que ele vai cor­tar as unhas do pé ou pre­pa­rar o jan­tar, ou ir deitar.

Não gosto mesmo e a prova de quão tosco é, em geral, o micro­blog­ging é que já existe o gera­dor de Twe­ets: se você não tem nada para escre­ver, gere um tweet randô­mico e diga ao mundo quão vazio você é.

Seguem aí 5 twe­ets “ale­a­tó­rios” para mos­trar o nível do negócio.

  • Meu namoro ter­mi­nou. A fila vai ter que andar!
  • O Twit­ter aca­bou com o meu tempo livre!
  • já dizia Con­fu­cio: — conheça-te a ti mesmo antes de conhe­cer a si próprio…
  • Se minha sogra só pudesse recla­mar em 140 carac­te­res ela teria uma crise de abs­ti­nên­cia de palavras
  • Bai­xando epi­só­dios do #Lost para fazer uma mara­tona neste fim-de-semana.

E fica a minha per­gunta: quem se importa?

  • Share/Bookmark

Meme do Yahoo: outro serviço que você não sabe se precisava

Publicado dia 15 de agosto de 2009 em artigo, internet, opinião and yahoo!. 0 Comments Tags: , , , .

Tudo o que o mundo pre­ci­sava era mais um site à Twit­ter, mesmo assim ontem fui con­fe­rir o Yahoo Meme, um ser­viço de pos­ta­gens mul­ti­mí­dia muito seme­lhante ao Tum­blr. Todo o desen­vol­vi­mento acon­tece na base do Yahoo aqui no Bra­sil e, por enquanto, ainda se encon­tra em fase alfa, mas per­mite que as pes­soas se cadas­trem como can­di­da­tos a expe­ri­men­tar a novidade.

A idéia é meio óbvia e, claro, alguém iria ten­tar isso um dia: se um blog é um mon­tão de texto e o Twit­ter é um pou­qui­nho de texto, por­que não fazer um site inter­me­diá­rio, sem as limi­ta­ções de texto do Twit­ter, nem tão extenso como um blog e com capa­ci­da­des mul­ti­mí­dia? O espí­rito é o mesmo dos micro­blogs: com­par­ti­lha­mento rápido de idéias, mas em texto, vídeo, som ou ima­gem e sem limite de caracteres.

O ser­viço **para mim** vai ser tão (in)útil quanto o Twit­ter; até o tenho, mas acho ridí­culo ficar pos­tando essas men­sa­gens cur­tas acerca do meu coti­di­ano pes­soal ou de tra­ba­lho e, tam­bém, não acho que alguém se importe (sem­pre tem, claro, esse tipo de gente que lê revis­tas de fofoca e acha inte­res­sante a vida alheia, mas eu não tenho tempo para isso).

Empre­sas, por outro lado, podem usar os micro­blogs para mos­trar o desen­vol­vi­mento de seus pro­du­tos. Adoro ver como anda o Mari­aDB, a NASA ou o Goo­gle e o Yahoo.

Em todo caso, como sem­pre, só o tempo dirá se mais essa ten­ta­tiva do Yahoo dará fru­tos pois já ficou mais do que pro­vado que os ser­vi­ços mais idi­o­tas podem ser um sucesso e os mais legais um fracasso.

  • Share/Bookmark

Cinco simples passos para fazer seu RPM

Publicado dia 13 de agosto de 2009 em artigo, dica and software. 14 Comments Tags: , , , .

Mui­tas pes­soas (pelo menos assim acre­dito), gos­ta­riam de apren­der a receita para gerar um RPM de seu soft­ware favo­rito; a regra de ouro se você usa uma dis­tri­bui­ção que geren­cia paco­tes é “evite, sem­pre que pos­sí­vel, ins­ta­lar softwa­res que não sejam empa­co­ta­dos para o seu linux”, mas, se você usa Fedora ou alguma des­sas outras dis­tros “linha dura” pode aca­bar ficando sem aquele pro­gra­mi­nha que você tanto gosta.

Para evi­tar essa tra­gé­dia, vou apro­vei­tar o post de hoje para ensi­nar em pas­sos sim­ples como empa­co­tar um soft­ware qual­quer em RPM.

Bus­quei ao acaso um soft­ware qual­quer que ainda não exista nos repo­si­tó­rios do Fedora, um exem­plo bem sim­ples é o FMIT (Free Music Ins­tru­ment Tuner for Linux). O soft­ware é pequeno e pode ser ins­ta­lado da maneira clás­sica (./configure, make, make ins­tall), por isso é per­feito para o nosso exemplo.

Pri­meiro passo: con­se­guindo o código fonte

Vá ao site do FMIT bai­xar o código fonte:

Com o código fonte em mãos, descompacte-o e vá dar uma olhada no que ele pede para com­pi­lar sem pro­ble­mas. Se você está acos­tu­mado a ins­ta­lar softwa­res direto pelo código fonte vai se lem­brar de que o ./configure checa e avisa quais os com­po­nen­tes neces­sá­rios para uma com­pi­la­ção (e ins­ta­la­ção) correta.

Já adi­anto que o FMIT neces­sita alsa-lib-devel, freeglut-devel, fftw3-devel, jack-audio-connection-kit-devel, portaudio-devel e qt3-devel para com­pi­lar direito e tam­bém alsa-lib, fftw3, fre­e­glut, jack-audio-connection-kit para rodar com todas as funcionalidades.

Ins­ta­lar um soft­ware a par­tir do código fonte con­siste mesmo em jun­tar todas as peças neces­sá­rias para poder com­pi­lar e isso exige paci­ên­cia ali­ada a algu­mas habi­li­da­des detetivescas.

Segundo passo: cri­ando o ambi­ente certo

Já bai­xa­mos o código fonte e fica­mos fami­li­a­ri­za­dos com o que nosso soft­ware vai depen­der para ser com­pi­lado. O pró­ximo passo é pre­pa­rar seu sis­tema para gerar RPMs. Ins­ta­lar o ambi­ente de desen­vol­vi­mento é muito simples:

$ su -c 'yum install rpmdevtools'

Isso ins­tala os softwa­res neces­sá­rios e

$ rpmdev-setuptree

Que vai gerar as pas­tas e as macros usa­das no desenvolvimento.

O local de desen­vol­vi­mento, você vai repa­rar, fica den­tro de uma pasta cha­mada rpm­build (~/rpmbuild). Nunca, nunca mesmo, em hipó­tese alguma, faça RPMs como root por­que isso pode dar “per­mis­sões demais” aos seus paco­tes e não que­re­mos isso, certo?

Den­tro de ~/rpmbuild há 5 pas­tas: SRPMS, RPMS, SPECS, BUILD, SOURCES;

  • A pasta SOURCES é onde você deve jogar o código fonte do pro­grama que vai empa­co­tar. Não se pre­o­cupe em descompactá-lo;
  • Na pasta SPECS você vai criar um script que é pró­prio para fazer RPMs cha­mado “arquivo de espe­ci­fi­ca­ção”. Nele escre­ve­re­mos todos os dados do RPM como nome, ver­são, des­cri­ção etc. Geral­mente ele recebe o nome do pro­grama a ser empa­co­tado com a exten­são .spec, por­tanto, como vamos empa­co­tar o FMIT, ele deve se cha­mar fmit.spec;
  • Na pasta BUILD ocorre o pro­cesso de com­pi­la­ção. Aqui é onde é feito o tra­ba­lho sujo pelo com­pi­la­dor. O seu código fonte é auto­ma­ti­ca­mente des­com­pac­tado aqui, che­cado, com­pi­lado e empa­co­tado. Pense nessa pasta como a “linha de pro­du­ção” dos seus pacotes.
  • Em RPMS são joga­dos os paco­tes pron­tos. Basta vir aqui e ins­ta­lar as crianças. =)
  • SRPMS tam­bém con­tém RPMs, mas não do tipo que vem com um exe­cu­tá­vel. O SRPM é ape­nas o código fonte do seu RPM. Com um SRPM, qual­quer um é capaz de repro­du­zir o seu RPM sem nenhum esforço. Den­tro dele temos o código fonte do soft­ware, o seu arquivo .spec ou qual­quer outra coisa que você tenha colo­cado em seu pacote.

Ter­ceiro passo: Cri­ando o seu arquivo .spec

A parte mais chata é essa. Um arquivo .spec tem par­tes muito bem defi­ni­das que pre­ci­sam ser leva­das à risca para gerar um bom pacote, mas não se assuste, hoje em dia há muita coisa já pronta ou auto­ma­ti­zada para nos aju­dar. Por exem­plo, você pode usar o VI/VIM para gerar um arquivo .spec gené­rico e “oco” para você:

Entre na pasta dos arqui­vos .spec

$ cd ~/rpmbuild/SPECS

Mande o VI/VIM criar o arquivo .spec vazio:

$ vim fmit.spec

Repa­rou que “auto­ma­gi­ca­mente” o nosso arquivo de espe­ci­fi­ca­ção já veio com os cam­pos a pre­en­cher? Alguns cam­pos são óbvios (outros nem tanto). Senão, vejamos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

Name:		# O nome do programa
Version:       # A versão do programa
Release:        1%{?dist}	# A release do pacote. Aqui vem aquela parte -1.fc11, -2.fc11...
Summary:       # Curta descrição do software
 
Group:		# A qual grupo pertence o software? Por exemplo: Applications/Multimedia
License:	# Qual a licensa vigente sobre o software? Por exemplo, GPL, MIT...
URL:		# Site do desenvolvimento upstream
Source0:	# O link do código fonte.
BuildRoot:      %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)  # Troque esta parte por %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: 	# Todos os pacotes necessários para a compilação.
Requires: 		# Todos os pacotes que são “dependências” para o seu software rodar bem.
 
%description 	# Uma descrição mais completa do seu software
 
%prep 		# Nesta seção o seu código fonte é “tratado”. Descompacta-se, aplica-se patches...
%setup -q
 
%build 		# Aqui vem, automática a parte do ./configure e do make
%configure
make %{?_smp_mflags}
 
%install 	# Instalação do software
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
 
%clean 		# Limpeza do seu “espaço de trabalho” para garantir que esteja limpo se precisar usar de novo.
rm -rf $RPM_BUILD_ROOT
 
%files 	# Diga nesta seção quais os arquivos presentes no seu RPM, assim, ao desinstalá-lo, não sobrará nenhum “lixo”.
%defattr(-,root,root,-)
%doc
 
%changelog		# Para manter um histórico do seu trabalho

Quarto passo: pre­en­cendo seu arquivo .spec

Vamos pre­en­cher o nosso spec passo a passo. A pri­meira seção é bem sim­ples, são ape­nas infor­ma­ções gerais:

1
2
3
4
5
6
7
8
9
10

Name:		fmit
Version:	0.97.7
Release:	1%{?dist}
Summary:	Free Music Instrument Tuner for Linux
 
Group:		Applications/Multimedia
License:	GPLv2
URL:		http://home.gna.org/fmit/index.html
Source0:	http://download.gna.org/fmit/fmit-0.97.7.tar.gz
BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

Na segunda seção, colo­ca­mos as depen­dên­cias para com­pi­lar e para funcionar:

BuildRequires:	alsa-lib-devel >= 0.9
BuildRequires:	freeglut-devel
BuildRequires:	fftw3-devel
BuildRequires:	jack-audio-connection-kit-devel >= 0.103
BuildRequires:	portaudio-devel
BuildRequires:	qt3-devel
Requires:	alsa-lib >= 0.9
Requires:	fftw3
Requires:	freeglut
Requires:	jack-audio-connection-kit >= 0.103

Na ter­ceira seção, uma expli­ca­ção mais deta­lhada sobre o software:

1
2

%description
Free Music Instrument Tuner for Linux, bla, bla bla...

Agora, na quarta seção, um deta­lhe impor­tante: o FMIT é um soft­ware muito sim­ples que pode ser com­pi­lado com ./configure, make e make ins­tall sem pre­ci­sar de mais nenhum parâ­me­tro adi­ci­o­nal, por isso, não pre­cisa mexer em nada nes­sas par­tes aqui:

1
2
3
4
5
6
7
8
9
10
11
12
13

%prep
%setup -q
 
%build
%configure
make %{?_smp_mflags}
 
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
 
%clean
rm -rf $RPM_BUILD_ROOT

É claro que se nosso com­pi­la­dor pre­ci­sasse de alguma ins­tru­ção extra have­ria mais coi­sas a fazer na quarta seção, mas isso não vem ao caso agora; quem sabe num pró­ximo artigo?

A quinta seção vai cata­lo­gar tudo que há no seu RPM para instalação/desinstalação:

1
2

%files
%defattr(-,root,root,-)
1

%doc AUTHORS COPYING ChangeLog TODO

Liste tudo que pode ser con­si­de­rado docu­men­ta­ção no seu pacote
Você se lem­bra dessa parte? “%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} –n)” Isso gerou, do lado da pasta BUILD uma nova pasta cha­mada BUILDROOT. Essa novas pasta é uma pasta “fake” onde o soft­ware vai se ins­ta­lar pen­sando que está sendo ins­ta­lado no sis­tema. Ela tem capa­ci­dade de imi­tar todas as pas­tas da pasta / de modo a garan­tir que o soft­ware con­siga encon­trar os luga­res devi­dos à sua “aco­mo­da­ção”. Você deve olhar nessa pasta para des­co­brir quais arqui­vos pre­ci­sam ser “declarados”

1
2
3
4

%{_bindir}/fmit 	# %{_bindir} significa /usr/bin
%{_datadir}/fmit	# %{_datadir} significa /usr/share
%{_datadir}/applications/fmit.desktop
%{_libdir}/*.a	# %{_libdir} significa /usr/lib

Na sexta seção, man­te­nha um his­tó­rico do seu trabalho:

1
2
3

%changelog
* Sun May 10 2009 Henrique "LonelySpooky" Junior  - 0.97.7-1
- Initial package

Quinto passo: gerando o RPM

A etapa mais fácil. Mande o rpm­build gerar seu rpm:

$ rpmbuild -ba ~/rpmbuil/SPECS/fmit.spec

Se tudo cor­rer bem você vai ver as men­sa­gens de com­pi­la­ção e, ao fim, as seguin­tes linhas:

Gravou: /home/lonely/rpmbuild/SRPMS/fmit-0.97.7-1.fc11.src.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-0.97.7-1.fc11.i586.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-debuginfo-0.97.7-1.fc11.i586.rpm

Como pro­me­tido, na pasta RPMS estará seu rpm do fmit e um paco­ti­nho com infor­ma­ções de debug que você não precisa.

Este é um exem­plo tão gené­rico quanto pos­sí­vel e ten­tei apre­sen­tar de forma sim­ples como pro­ce­der, mas, con­vém avi­sar, gerar RPMs varia muito depen­dendo da lin­gua­gem de pro­gra­ma­ção e mesmo um pacote sim­ples como esse pode ser feito de forma mais “ele­gante”. Em todo caso, espero que tenha matado a curi­o­si­dade de alguns ou dado um “empur­rão­zi­nho” em quem deseja come­çar no empacotamento.

Lei­tu­ras recomendadas

  • Share/Bookmark

Sobre a guerra Ubuntu vs Fedora

Publicado dia 27 de maio de 2009 em artigo and opinião. 18 Comments Tags: , .

fedora_ubuntu

O Linux hoje em dia já não é mais o que foi. Não há mais neces­si­dade de ser um expert para des­fru­tar de um bom desk­top livre e nem é pre­ciso abrir mão de bons pro­gra­mas num tipo de fal­si­dade hipó­crita, na vã ilu­são de que todos aque­les softwa­res mal fei­tos, feios e num alfa eterno, ser­viam para nos­sas tarefas.

O Linux está maduro, ao alcance de todos (mesmo os pouco expe­ri­en­tes) e adqui­riu beleza, fun­ci­o­na­li­dade e vari­e­dade. Exis­tem Linux para todos os gos­tos, dos boni­tos e fáceis até os feios e difí­ceis mas, como não pode­ria dei­xar de ser, nesse ecos­sis­tema cres­cente sem­pre há as espé­cies que mais se des­ta­cam e neste caso esta­mos falando de Ubuntu e Fedora.

Con­tando com comu­ni­da­des imen­sas, as duas dis­tros se enca­ram como num jogo de fute­bol e corre, num bur­bu­ri­nho anô­nimo, que o Pro­jeto Fedora e a Cano­ni­cal dis­pu­tam uma cor­rida em busca dos cora­ções (e men­tes) de seus usuá­rios. Mas será isso mesmo?

Não se pode cul­par as pes­soas por terem pai­xão por suas esco­lhas. Alguns defen­dem suas dis­tri­bui­ções favo­ri­tas com argu­men­ta­ções fero­zes, tone­la­das de prós (com os con­tras gen­til­mente ame­ni­za­dos) e belas his­tó­rias ilus­tra­ti­vas, mas o fato é que tal com­pe­ti­ção não existe.

Obvi­a­mente não estou a par dos bas­ti­do­res da Cano­ni­cal, mas a visão ofi­cial do Pro­jeto Fedora é que Ubuntu e Fedora nem mesmo com­par­ti­lham o mesmo público alvo e por isso não lutam pelo mesmo espaço.

Sem­pre há, é claro, aque­les que não acei­tam essa visão, mas os cabe­ças e os mais expe­ri­en­tes do Pro­jeto Fedora (e eu, modes­ta­mente) acre­di­tam que o Ubuntu veio para suprir uma neces­si­dade e que tem feito isso muito bem, lapi­dando o Linux num desk­top de alto nível.

A con­fu­são que pode dar a enten­der que o Fedora busca o mer­cado de desk­tops (alvo do Ubuntu) é que ele está natu­ral­mente mais fácil e isso (essa faci­li­dade), embora não seja nosso obje­tivo pri­má­rio, é evo­lu­ti­va­mente com­pre­en­sí­vel. O Pro­jeto Fedora não está e nem estará dis­posto a se des­viar de seus “man­tras” que são ento­a­dos pelos cor­re­do­res do Projeto:

  • Somos 100% soft­ware livre: nenhuma das nos­sas linhas de código é proprietária.
  • Sem­pre tra­ba­lhar junto ao ups­tream: Tudo que melho­ra­mos, muda­mos ou cor­ri­gi­mos é entre­gue aos desen­vol­ve­do­res originais.
  • Nós usa­mos pri­meiro: as novas tec­no­lo­gias desem­bar­cam pri­meiro no Fedora.

Para con­se­guir tra­zer aos seus usuá­rios a faci­li­dade de ins­ta­lar um codec pro­pri­e­tá­rio o Ubuntu pre­ci­sou cru­zar a linha que os Fedo­rans não cru­za­riam, que é lan­çar mão do código fechado e isso, por si só, já é um bom exem­plo de como as dis­tros seguem dire­ções dife­ren­tes. Alguém teria que fazer isso algum dia, certo?

Embora o Fedora seja muito fácil de usar, o per­fil de nos­sos usuá­rios é mais o das pes­soas que não se impor­tam de cor­rer atrás dos codecs ou de usar um apli­ca­tivo externo — como o exce­lente easy­Life — para con­se­guir os com­po­nen­tes que o Fedora não pode for­ne­cer (eu, por exem­plo, passo anos sem sequer mudar o papel de parede ori­gi­nal e não me importo de ins­ta­lar “no braço” o que pre­ciso). Acho que a melhor forma de defi­nir é: o Fedora SERVE para desk­top e o Ubuntu É um desk­top. Por outro lado, o Fedora é ideal para quem gosta de estu­dar o sis­tema, tes­tar as coi­sas e fuçar bas­tante. Espon­ta­ne­a­mente, acre­dito, os com per­fil mais curi­oso movem-se para o Fedora e os de per­fil mais prá­tico migram para Ubuntu.

As crí­ti­cas que mui­tos conhe­ci­dos (inclu­sive eu) fazem ao Ubuntu são rela­ci­o­na­das ao seu modo obs­curo de tra­tar o código usado nas rele­a­ses, por nem sem­pre estar com­pro­me­tido em pas­sar aos desen­vol­ve­do­res ori­gi­nais as melho­rias que con­se­guem imple­men­tar e por con­tri­buir pouco para o desen­vol­vi­mento do Linux em geral com novas linhas de código (por exem­plo, par­ti­ci­pando com somente 0,1% dos pat­ches para o Ker­nel em 3 anos), mas isso é um outro assunto.

Para resu­mir, Fedora e Ubuntu não estão, de fato, com­pe­tindo, mas se com­ple­men­tam já que cada um deles abrange um nicho dife­rente de usuários.

P.S.: Texto escrito para alguns dos meus alu­nos da Facul­dade Simon­sen que às vezes se exal­tam dis­cu­tindo qual dis­tro é a melhor. :-)

  • Share/Bookmark

Eu também sou código fechado

Publicado dia 30 de abril de 2009 em artigo and opinião. 14 Comments Tags: , .

closedSim, sim, pes­soal, eu tam­bém sou código fechado. Recen­te­mente li no site do meu amigo Max Raven (se não me engano) uma maté­ria que expres­sava muito bem um efeito cola­te­ral dessa coisa de “dei­xar livre” tudo aquilo que pro­du­zi­mos. Dizia o artigo que empre­sas aus­tra­li­a­nas esta­vam indo ao Flickr bus­car fotos de meni­nas boni­ti­nhas para usar em suas cam­pa­nhas publi­ci­tá­rias, mas (sem­pre tem um mas) bus­cava somente as fotos licen­ci­a­das sob Cre­a­tive Com­mons que per­mi­tisse o uso irres­trito das fotos. As tais empre­sas valendo-se da polí­tica livre (que está muito na moda) eco­no­mi­za­vam alguns dígi­tos com as mode­los e ainda tinham o amparo legal que jus­ti­fi­casse essa atitude.

É por essas e outras que as minhas fotos no Flickr são todas com “todos os dire­tos reser­va­dos”, assim como os meus tex­tos no Recanto das Letras. Não quero dizer que eu tenha talento para, por exem­plo, ser rou­bado pela Nati­o­nal Geo­graphic nas minhas fotos, mas acre­dito que aproveitar-se do talento alheio para bene­fí­cio finan­ceiro pró­prio é uma ati­tude assaz baixa, até mesmo para uma empresa.

Essa calhor­da­gem é muito mais comum do que se pode pen­sar. Usar o nome GPL em vão é uma velha tática para atrair trou­xas seden­tos pela pro­messa de uma solu­ção livre e barata para seus problemas.

Ano pas­sado a Pre­fei­tura onde tra­ba­lho ini­ciou um pro­cesso de abo­li­ção da escra­va­tura e deci­diu usar solu­ções livres em tan­tas áreas quan­tas fos­sem pos­sí­veis. Des­co­bri­mos um soft­ware cha­mado i-Educar que era licen­ci­ado pela GPL e fomos atrás. Pri­meiro de tudo, a enorme difi­cul­dade para che­gar aos códi­gos fonte do soft­ware já demons­tra­vam a “boa fé” da tal empresa por trás da solu­ção. Quando, final­mente che­ga­mos ao código fonte, tratava-se de uma ver­são muito mais antiga que a ver­são cor­rente e, por fim, diver­sos arqui­vos do tal código fonte haviam sido excluí­dos e outros reno­me­a­dos com suges­ti­vos nomes como xxx.php. Os manu­ais de ins­ta­la­ção, pre­cá­rios, reple­tos de hia­tos e total­mente desen­con­tra­dos com o código fonte que foi alte­rado pelo pes­soal da Cobra (segundo os desen­vol­ve­do­res do tal i-Educar).

Não con­ti­nu­a­mos cor­rendo atrás da solu­ção, enfim, pois depois de tro­car inú­me­ros e-mails, par­ti­ci­par de chats e lis­tas de dis­cus­são ofereceram-me o suporte para ins­ta­lar o i-Educar, afi­nal, se eu não con­se­gui fazer fun­ci­o­nar era pre­ciso o suporte (enten­de­ram a jogada?) que cus­tava (não me lem­bro bem), R$ 3.000 ou 10.000.

Mais impor­tante nisso tudo é que a ima­gem do soft­ware livre ficou quei­mada e con­forme pala­vras do supe­rin­ten­dente na época: “esse negó­cio de soft­ware livre é pica­re­ta­gem!”. O que pode­ria dizer em defesa do soft­ware livre eu disse, mas ele não pare­ceu acre­di­tar muito.

Depois que desis­ti­mos do i-Educar (isso faz um quase ano) nunca mais pro­cu­rei saber como anda o soft­ware — e nem me inte­ressa para ser sin­cero — mas eles foram um caso clás­sico de uma pos­tura comum: aproveitar-se do “Livre” para dis­tor­cer o con­ceito em bene­fí­cio próprio.

  • Share/Bookmark

Como funciona: Pacotes RPM

Publicado dia 25 de janeiro de 2009 em artigo and como funciona?. 9 Comments Tags: , .

A pala­vra RPM é um acrô­nimo recur­sivo que sig­ni­fica RPM Package Mana­ger. De modo resu­mido ele é o equi­va­lente aos paco­tes .deb ou, se pre­fe­rir, aos arqui­vos .exe do Win­dows, já que serve para ins­ta­lar, desins­ta­lar e atu­a­li­zar arqui­vos e/ou softwa­res no sis­tema operacional.

Se você não gosta de his­tó­ria, pode pular a seção seguinte e ir direto para “Como funciona?”.

Um pouco de história

No iní­cio da década de 90 já era evi­dente a neces­si­dade de criar um “geren­ci­a­mento de paco­tes” que fosse fun­ci­o­nal e sim­ples de usar. Até então, o método mais comum de ins­ta­la­ção de softwa­res era a tra­di­ci­o­nal com­pi­la­ção e ins­ta­la­ção direta pelo código fonte. Esse método, no entanto, era uma clara des­van­ta­gem por­que excluía os usuá­rios menos téc­ni­cos e fazia com que o sis­tema ope­ra­ci­o­nal tivesse quase ou nenhum con­trole sobre os softwa­res que eram ins­ta­la­dos. Era comum que um soft­ware não pudesse mais ser desins­ta­lado ou que, para garan­tir a desins­ta­la­ção, o código fonte tivesse que ser man­tido no sis­tema. Foi por isso que a Red Hat ini­ciou as pes­qui­sas em busca de um método de geren­ci­a­mento de paco­tes que fosse efe­tivo e simples.

RPP

Foi o nome do geren­ci­a­dor de paco­tes usado pelos pri­mei­ros Red Hats. O RPP foi a “musa ins­pi­ra­dora” para mui­tas das habi­li­da­des que o RPM de hoje em dia aca­bou her­dando. Ele tinha uma uti­li­za­ção sim­ples, bas­tando uma linha de comando para ins­ta­lar um pacote; per­mi­tia a exe­cu­ção de scripts de pré e pós instalação/desinstalação; era capaz de fazer uma veri­fi­ca­ção dos paco­tes para des­co­brir se alguma alte­ra­ção nos arqui­vos tinha sido feita e sal­vava as infor­ma­ções do pacote (como des­cri­ção, ver­são, nome e lis­tas de paco­tes) em um banco de dados. Aca­bou não vin­gando por­que, embora fosse rela­ti­va­mente efi­ci­ente, não con­se­guia tra­ba­lhar com o código fonte ori­gi­nal dos softwa­res que ins­ta­lava. Isso que­ria dizer que cada empa­co­ta­dor pre­ci­sava hac­kear o soft­ware antes de empacotá-lo para que ele fun­ci­o­nasse bem com o RPP. Além disso, o RPP era inca­paz de tra­ba­lhar com arqui­te­tu­ras dife­ren­tes da x86… Embora tenha sido o geren­ci­a­dor de paco­tes RPP o grande dife­ren­cial da Red Hat no iní­cio da empresa, logo ficou claro que a limi­ta­ção de não poder tra­ba­lhar com outras arqui­te­tu­ras viria a se tor­nar um pro­blema e por esse motivo, as pes­qui­sas por um geren­ci­a­mento melhor de paco­tes continuou.

PMS (Pac­kage Mana­ge­ment System)

O PMS não foi desen­vol­vido pela Red Hat. Ao con­trá­rio, era desen­vol­vido por um grupo de desen­vol­ve­do­res che­fi­a­dos por Rik Faith que cri­a­ram a dis­tri­bui­ção cha­mada Bogus Linux . Os paco­tes PMS não eram muito bons por­que usa­vam um banco de dados pobre­mente dse­nhado e facil­mente cor­rup­tí­vel, tam­bém esta­vam limi­ta­dos a ape­nas uma arqui­te­tura mas intro­du­zi­ram o con­ceito de tra­ba­lhar dire­ta­mente com o código fonte do “ups­tream” (i.e. dos desen­vol­ve­do­res ori­gi­nais). Qual­quer mudança neces­sá­ria para que o soft­ware fun­ci­o­nasse era apli­cada por sim­ples patches.

PM

Pouco depois, Rik Faith e Doug Hoff­man , já con­tra­ta­dos pela Red Hat, con­ti­nu­a­ram tra­ba­lhando num geren­ci­a­dor de paco­tes e desen­vol­ve­ram o PM, que jun­tava todas as van­ta­gens do RPP e do PMS. Infe­liz­mente, her­dou tam­bém as fra­que­zas dos dois geren­ci­a­do­res de paco­tes e pos­suía um banco de dados muito cor­rup­tí­vel, além de, claro, con­ti­nuar sendo com­pa­tí­vel com somente um tipo de arquitetura.

RPM 1 (Finalmente)

Espelhando-se nas duas bem suce­di­das ten­ta­ti­vas de cri­a­ção de geren­ci­a­mento (RPP e PMS), Marc Ewing e Erik Troan come­ça­ram a tra­ba­lhar em um ter­ceiro geren­ci­a­dor de paco­tes que se cha­ma­ria RPM (Red Hat PackageManager).

Ape­sar de ins­pi­rado pelo RPP, PMS e PM, o RPM iria focar em resol­ver todos os pro­ble­mas que esses geren­ci­a­do­res antes não tinham con­se­guido resol­ver. A lin­gua­gem de pro­gra­ma­ção esco­lhida foi o Perl, por ser fácil e rápido de programar.

Ape­sar do RPM 1 ter sido, rela­ti­va­mente, um êxito, apre­sen­tava diver­sos problemas:

  • Era muito mais lento do que se tivesse sido escrito em C;
  • O banco de dados era extre­ma­mente frá­gil e que­bra­diço, corrompendo-se à toa;
  • Não era pos­sí­vel exe­cu­tar o geren­ci­a­dor por um dis­quete, já que o fato de ser escrito em perl con­su­mi­ria um espaço extra;
  • Embora fun­ci­o­nasse em outras arqui­te­tu­ras, o fun­ci­o­na­mento ocor­ria com problemas
  • O geren­ci­a­dor de paco­tes não era “expan­sí­vel’. O que sig­ni­fi­cava que qual­quer mudança maior no código faria com que os paco­tes ante­ri­o­res se tor­nas­sem incom­pa­tí­veis com as ver­sões futuras.

RPM 2

Marc e Eric rees­cre­ve­ram o RPM total­mente, usando dessa vez a lin­gua­gem C. Essa deci­são aumen­tou em muito a velo­ci­dade de exe­cu­ção do geren­ci­a­dor de paco­tes. Adi­ci­o­nal­mente, o banco de dados foi rede­se­nhado e per­mi­tia que as con­sul­tas fos­sem exe­cu­ta­das em 1/10 do tempo que antes era tomado pelo RPM 1. Atu­al­mente, o RPM está na ver­são 4.4.2.3.

Como fun­ci­ona?

Um RPM é, na ver­dade, um meta pacote. Para faci­li­tar o enten­di­mento, pense nele como um pacote com diver­sos rótu­los cola­dos nele e que cada um des­ses rótu­los con­tém um tipo de infor­ma­ção que é “inte­res­sante” que seu sis­tema saiba. O soft­ware que você deseja ins­ta­lar está lá, com­pac­tado por um pro­cesso antigo e efi­ci­ente cha­mado cpio.

O que vem no RPM está “pré-compilado”. Isso quer dizer que o soft­ware foi pre­pa­rado em outra máquina, o resul­tado da com­pi­la­ção foi empa­co­tado e tudo que você faz é ins­ta­lar o soft­ware pronto para usar.

A ana­to­mia de um pacote RPM é a seguinte:

  1. O iní­cio do pacote RPM é a “guia” que ensina ao sis­tema ope­ra­ci­o­nal que se trata de um pacote RPM. Nessa seção exis­tem cabe­ça­lhos lidos pelo sis­tema que são impor­tan­tes para o manu­seio do pacote. Aqui cabe uma boa ana­lo­gia com o GRUB.
  2. Esta seção arma­zena assi­na­tu­ras que garan­tem a auten­ti­ci­dade dos paco­tes. É pos­sí­vel, por exem­plo que um dis­tri­bui­dor assine seus RPMs com sua pró­pria marca, que é iden­ti­fi­cada pelo sis­tema. Isso reforça a segu­rança e per­mite a um usuá­rio ins­ta­lar (ou não) somente softwa­res dis­po­ni­bi­li­za­dos por dis­tri­bui­do­res cuja assi­na­tura seja con­fiá­vel (como Fedora, Red Hat, Man­driva, Opensuse…).
  3. Na ter­ceira seção per­ma­ne­cem as infor­ma­ções como nome do soft­ware, ver­são, rele­ase, des­cri­ção, lista de arqui­vos, depen­dên­cias… Essas entra­das são arma­ze­na­das no banco de dados do RPM.
  4. A quarta (e maior) seção con­tém, final­mente, os arqui­vos com­pac­ta­dos. Na figura ela é repre­sen­tada por .tar.gz mas isso é mera­mente ilus­tra­tivo. Na ver­dade, o método de com­pres­são é o cpio. Cada pacote RPM tem uma limi­ta­ção de tama­nho: 2 GB para sis­te­mas 32 bits e 4 GB para sis­te­mas 64 bits.

g2474

Agora que você já entende como é um pacote RPM, está pronto para des­co­brir o que ele faz. Não vou entrar aqui em deta­lhes de como criar um pacote, isso foge ao escopo do nosso artigo, no entanto, de qual­quer forma, antes de botar a mão na massa para fazer um RPM é sem­pre bom enten­der como ele funciona.

Quando você ins­tala um soft­ware qual­quer com o ./configure, make e make install, ele veri­fica se seu sis­tema está ok para rodá-lo, busca as pas­tas cor­re­tas, gera os links, ins­tala as pági­nas de manual e exe­cuta quais­quer outras ope­ra­ções neces­sá­rias. Num pacote RPM ocorre exa­ta­mente o mesmo, mas o soft­ware é enga­nado e acaba se ins­ta­lando numa árvore de dire­tó­rios falsa cha­mada “fake root”. A árvore falsa é exa­ta­mente igual á árvore do seu sis­tema ope­ra­ci­o­nal, mas é “vazia”, sem nenhum outro soft­ware; tudo que existe nessa árvore falsa é o soft­ware que foi “enga­nado” e se ins­ta­lou na árvore de dire­tó­rios falsa. Depois disso, o soft­ware que monta os RPMs (cha­mado RPM­Build) pega essa árvore falsa e a com­pacta den­tro do pacote.

Durante a ins­ta­la­ção do soft­ware que, agora, está den­tro do RPM o soft­ware é des­com­pac­tado e “colado” em cima da árvore de dire­tó­rios de verdade.

Como a árvore falsa e a árvore ver­da­deira são exa­ta­mente iguais, o resul­tado disso é que o RPM acres­centa o novo soft­ware com seus arqui­vos, links e docu­men­ta­ções à árvore exis­tente, algo muito pare­cido com um “copiar e colar” em larga escala.

Tudo que você ins­ta­lou via RPM fica regis­trado num banco de dados SQLite que fica loca­li­zado em /var/lib/rpm (mas não tente abrir esse banco de dados dire­ta­mente, geral­mente o resul­tado é amargo). Se seu RPM foi bem feito ele con­tém uma lista de todo e qual­quer arquivo que foi copi­ado para o seu HD. Cabe ao pro­gra­ma­dor do pacote (empa­co­ta­dor) dizer ao RPM o que ele está jogando no disco, caso con­trá­rio, um RPM mal feito, ao ser desins­ta­lado, pode dei­xar lixo inú­til para trás.

Um pacote RPM é, afi­nal, algo muito simples.

  • Share/Bookmark