Archive for the 'artigo' Category

ENIAC: o primeiro computador

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

Revista Fedora Brasil: no fio da navalha

Uma das ini­ci­a­ti­vas mais bem suce­di­das do Pro­jeto Fedora Bra­sil é, sem dúvida, a Revista Fedora Brasil.

A revista foi ide­a­li­zada para levar infor­ma­ção de qua­li­dade para a Comu­ni­dade de usuá­rios Fedora no Bra­sil, mas, aca­bou tra­tando tam­bém de assun­tos rele­van­tes para usuá­rios de outras distribuições.

Ape­sar da grande popu­la­ri­dade, a Revista Fedora Bra­sil tem uma exis­tên­cia que pode­mos cha­mar de “con­tur­bada”, pela escas­sez de con­tri­bui­ções e assi­dui­dade de par­ti­ci­pan­tes. Torna-se quase uma iro­nia, mas o fato é que mui­tos pro­je­tos bem suce­di­dos, na ver­dade, sofrem momen­tos dra­má­ti­cos pela carên­cia de con­tri­bui­ções e isso, quase sem­pre, fica invi­sí­vel aos olhos dos usuários/leitores.

Nós, que esta­mos à frente da RFB desde o começo, acre­di­ta­mos que uma pos­tura honesta diante des­sas difi­cul­da­des ajuda a escla­re­cer todos os que per­ma­ne­cem espe­rando ansi­o­sa­mente pelo lan­ça­mento da pró­xima edi­ção, além de, quem sabe, con­se­guir a ajuda neces­sá­ria para que os pro­ble­mas sejam mini­mi­za­dos ou resolvidos.

Para que a revista exista é neces­sá­rio que pes­soas escre­vam arti­gos e este é um poto com­pli­cado por­que cada um que con­tri­bui está fazendo uma doa­ção em tempo e em conhe­ci­mento; isso, na comu­ni­dade Open Source, tam­bém pode sig­ni­fi­car certo des­com­pro­misso, que acaba levando ao mais bra­si­leiro dos “dei­xar na mão”.

É óbvio que sem­pre con­ta­mos com auto­res que nunca dei­xa­ram de cola­bo­rar reli­gi­o­sa­mente, mos­trando tex­tos que sem­pre me dei­xa­ram orgu­lhoso em publi­car. (Obri­gado a todos!)

Além de ter arti­gos tam­bém é pre­ciso revi­sar, para que o resul­tado final seja cor­reto e bonito, den­tro de um padrão de cor­re­ção. Nisso, modés­tia à parte, temos os melho­res, sem­pre rápi­dos e pre­ci­sos (até ávidos por mais trabalho).

Pági­nas boni­tas pre­ci­sam de arte e dia­gra­ma­ção; esse sem­pre foi nosso Cal­ca­nhar de Aqui­les. Quem nos sal­vava aqui era o Hélio Fer­reira. Pro­va­vel­mente Hélio é o único mor­tal capaz de fazer mil coi­sas ao mesmo tempo e sobres­sair em todas. Seu layout é sem­pre elo­gi­ado pelos mem­bros do Pro­jeto Fedora inter­na­ci­o­nal, mas a sobre­carga à qual Hélio vinha sendo sub­me­tido estava evi­dente desde o começo.

Neste ponto já temos as maté­rias pron­tas e revi­sa­das, falta arte e dia­gra­ma­ção, mas este pro­cesso está estag­nado há meses.

Se você tem alguma expe­ri­ên­cia com os softwa­res de dese­nho veto­rial (como Inks­cape), edi­ção de ima­gens (GIMP) ou se sabe dia­gra­mar usando o Scri­bus e gos­ta­ria de dar uma força para que a 6ª edi­ção da Revista Fedora Bra­sil tenha con­di­ções de final­mente ser lan­çada, cadastre-se no nosso grupo de desen­vol­vi­mento em http://revista.projetofedora.org . Espe­ra­mos com isso entre­gar, ao menos, esta última edi­ção aos nos­sos lei­to­res e ami­gos, além de fazer valer o tra­ba­lho duro de todos aque­les que con­tri­buí­ram e ainda estão aguar­dando o resul­tado de seus tra­ba­lhos na revista.

Um grande abraço

Hen­ri­que Junior – Túlio Macedo

Edi­to­res

  • Share/Bookmark

Minha primeira experiência com o Haiku (OpenBeOS)

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

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)

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

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

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

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

Mais tempo de vida para o Fedora

Um assunto que já até virou piada nas lis­tas de dis­cus­são de desen­vol­vi­mento do Fedora é o aumento do ciclo de vida de cada uma das nos­sas rele­a­ses, mas dessa vez, gra­ças aos esfor­ços her­cú­leos e à paci­ên­cia de Jeroen van Meeuwen existe grande pos­si­bi­li­dade de que, a par­tir do Fedora 12 haja um acrés­cimo de lon­ge­vi­dade na dis­tro favo­rita dos Fedorans.

Sem que­rer puxar sar­di­nha para o meu lado, mas acho o Fedora uma dis­tro exce­lente para con­fi­gu­rar ser­vi­do­res. As tec­no­lo­gias dis­po­ni­bi­li­za­das pelo Pro­jeto estão reple­tas das faci­li­da­des que só um pen­sa­mento atu­a­lís­simo pode dar. Esta­mos falando de usar a ver­são mais recente do MySQL, com jus­ta­mente aquela fea­ture super legal que você pre­cisa e que vai tes­tar com empol­ga­ção, mas… você usa­ria um Fedora para mon­tar seu ser­vi­dor, mesmo sabendo que den­tro de 13 meses ele será con­si­de­rado morto pelo Pro­jeto Fedora e dei­xará de rece­ber updates?

Admi­nis­tra­do­res mais rela­xa­dos dirão que não há pro­blema nisso (eu mesmo ainda tenho máqui­nas rodando Fedora Core 3 e que nunca me deram pro­blema), mas alguns admi­nis­tra­do­res, que lidam com dados sigi­lo­sos e “ape­ti­to­sos” para hac­kers mal inten­ci­o­na­dos não podem dei­xar de sen­tir cala­frios só de ima­gi­nar suas máqui­nas desa­tu­a­li­za­das em con­tato com a grande rede.

É por isso que, par­ti­cu­lar­mente, sem­pre achei um grande des­per­dí­cio ter o Fedora com todo esse poten­cial e não poder usá-lo em ser­vi­do­res que cor­rem grande risco de inva­são. A melhor alter­na­tiva é o exce­lente CentOS/Red Hat EL com seus 7 anos de suporte, mas o Cen­tOS mais atual (5.3) é o equi­va­lente ao nosso Fedora Core 6 e para nós, que usa­mos o Fedora 11, sem­pre fica alguma sen­sa­ção de perda. Como diz meu amigo Igor Soa­res, “o Fedora de hoje é o Red Hat de amanhã”.

E por­que o Pro­jeto Fedora tra­ba­lha assim? Um fedora a cada seis meses e um ciclo de vida de 13 meses para cada release?

Bem, isso está dire­ta­mente rela­ci­o­nado com o motivo de ser do Fedora: mover-se rápido con­forme as tec­no­lo­gias vão sur­gindo e mos­trar para a Red Hat o que há de melhor para adi­ci­o­nar ao seu pro­duto de nível enter­prise, o RHEL. Com isso em mente, o tempo de vida de cada Fedora é bas­tante curto por­que, a rigor, não existe motivo para con­ti­nuar se pre­o­cu­pando com uma rele­ase já tes­tada, apri­mo­rada e subs­ti­tuída por outra mais recente. Unindo-se a isso o fato de que cada man­te­ne­dor pre­cisa cui­dar de seus paco­tes para cada um dos Fedo­ras “ati­vos”, a quan­ti­dade limi­tada de pes­soal e a grande demanda de infra-estrutura é fácil per­ce­ber o porquê de um ciclo tão curto.

Mas, é como disse antes: um Fedora tem cer­tas qua­li­da­des que o CentOS/RHEL ainda não tem e muita gente (inclu­sive eu), con­ti­nua pedindo por um Fedora mais lon­gevo sem­pre que a opor­tu­ni­dade surge.

No dia 4 de julho Jeroen van Meeuwen res­sus­ci­tou o assunto e veio com mais que pala­vras; já havia pro­posto o “exten­ded life time” como uma fea­ture para o Fedora 12 e tra­zia bons e paci­en­tes argu­men­tos para quase todas as difi­cul­da­des téc­ni­cas apre­sen­ta­das. Como resul­tado de todo o tra­ba­lho o Fedora Board (a lide­rança do Pro­jeto) come­çou a con­si­de­rar seri­a­mente a pos­si­bi­li­dade de man­ter as atu­a­li­za­ções de segu­rança por mais algum tempo.

O que resta saber agora é se haverá volun­tá­rios o sufi­ci­ente para tor­nar o ELT uma coisa pra­ti­cá­vel e deci­dir quanto mais de tempo será adi­ci­o­nado à vida do Fedora. Ouvi falar em adi­ci­o­nar 6 meses, mas torço por um suporte de 2 anos. Sou um oti­mista. :-)

Segue em anexo a dis­cus­são do tópico e vou ficar aqui fazendo figa: 2 anos! 2 anos! 2 anos!

Fea­ture pro­po­sal: Exten­ded Life Cycle Sup­port (131)
  • Share/Bookmark

As pessoas preferem GNOME?

Se você é um fã do KDE, amigo lei­tor, pode achar o título bas­tante pro­vo­ca­tivo e injusto, mas até eu me sur­pre­endi com deter­mi­na­dos dados que pude reu­nir durante os últi­mos meses e que me ale­gro em com­par­ti­lhar aqui no meu blog.

No iní­cio de 2009 a Pre­fei­tura da cidade de Para­cambi (RJ), onde tra­ba­lho come­çou a ensaiar os pri­mei­ros pas­sos para a “dança da migra­ção” rumo ao soft­ware livre. O assunto “migra­ção” em si é bas­tante conhe­cido e a inter­net está coa­lhada de links con­tando casos e dicas para quem tem uma empresa e pre­tende migrar; aliás, aqui mesmo escrevi um post sobre o assunto onde resu­mia um pouco daquilo que aprendi com o tempo em diver­sas situações.

Como estou che­fi­ando a migra­ção e isso, con­se­quen­te­mente, coloca o meu tra­seiro na reta, estu­dei com cui­dado as dis­tros que iría­mos usar e o nosso público alvo. O medo em usar Fedora era jus­ta­mente o curto período de vida: ficar sem upda­tes depois de 13 meses é mesmo um argu­mento muito forte con­tra a apli­ca­ção prá­tica do Fedora, mas, em desk­tops, isso é quase irre­le­vante já que as máqui­nas ficam den­tro de uma rede pro­te­gida por firewalls.

Nos ser­vi­do­res, Fedora nem pen­sar! Se por um lado o desk­top pode muito bem viver sem atu­a­li­za­ções um ser­vi­dor não pode se dar a esse luxo; por esse motivo, Fedora nos ser­vi­do­res é impra­ti­cá­vel e esco­lhe­mos o Cen­tOS. Cri­a­re­mos um repo­si­tó­rio para os nos­sos Fedo­ras e todas as atu­a­li­za­ções que dese­jar­mos serão con­tro­la­das por ali. A dobra­di­nha CentOS/Fedora foi esco­lhida jus­ta­mente pela faci­li­dade de inte­gra­ção e, em segundo lugar, pela fami­li­a­ri­dade que já tenho.

O ponto fun­da­men­tal aqui, entre­tanto, foram as pes­soas. Era pre­ciso estu­dar os usuá­rios para deter­mi­nar em qual per­fil se enqua­dra­vam e ten­tar, dessa maneira, redu­zir a curva de apren­di­zado no máximo possível.

Minha pri­meira dúvida foi: GNOME ou KDE? Embora eu seja usuá­rio GNOME e tenha sido um dos que joga­ram pedras no KDE 4.0, admito que o KDE 4.2 está exce­lente, bonito e fun­ci­o­nal. A melhor saída me pare­ceu a pes­quisa de campo. Duas máqui­nas de hard­ware seme­lhante, uma com KDE e outra com GNOME e as pes­soas, depois de dois dias, diriam qual gos­ta­ram mais.

Ten­tei influ­en­ciar o mínimo pos­sí­vel, por exem­plo, jamais dizendo que uso GNOME e sem dar nenhum trei­na­mento: a expe­ri­ên­cia deve­ria ser o mais crua pos­sí­vel com o usuá­rio sozi­nho e usando seu pró­prio cére­bro para encon­trar e exe­cu­tar as coisas.

Ao con­trá­rio do que eu ima­gi­nava, ape­nas 1/3 dos usuá­rios pre­fe­riu o KDE e os outros 2/3, que esco­lhe­ram GNOME, ale­ga­ram que o KDE é bas­tante con­fuso, com espe­cial ênfase no menu.

A mai­o­ria deu sinais de que não explora o desk­top e que ficam foca­dos ape­nas na tríade office/MSN/internet, sem inte­resse em coi­sas como beleza, plas­moids ou efei­tos de tran­si­ção. Na ver­dade, os mui­tos adi­ti­vos do KDE. 4.2 foram con­si­de­ra­dos um obs­tá­culo para suas neces­si­da­des simples.

A expli­ca­ção dada pelos usuá­rios era que o GNOME é mais “sim­ples” mas tam­bém repa­rei que a mai­o­ria fez uma coisa inte­res­sante: pega­ram a barra supe­rior do GNOME e a colo­ca­ram na parte de baixo, ficando com duas bar­ras infe­ri­o­res. A solu­ção esco­lhida foi desen­vol­ver um tema sim­ples para GNOME que se pare­cesse com o Win­dows XP: uma barra infe­rior azul, ícones no estilo do Luna e papel de parede com uma pai­sa­gem de gra­mado verde.

O fato é que a mai­o­ria dos usuá­rios sequer se importa com o sis­tema ope­ra­ci­o­nal que estão usando por­que tem uma visão afu­ni­lada do desk­top, ou seja, quando abrem um apli­ca­tivo o res­tante do desk­top “desaparece”.

A migra­ção vai ser gra­da­tiva e, pelo menos assim espero, suave e sem trau­mas. O pri­meiro setor migrado deu um resul­tado melhor do que o espe­rado não regis­trando nenhuma cha­mada para suporte ao nosso GNOME-XP até agora (4 semanas).

  • Total de pes­soas pes­qui­sa­das: 50 aproximadamente.
  • Dura­ção da pes­quisa: Pouco mais que 1 mês
  • Faixa etá­ria: 23 a 60 anos
  • Os usuá­rios que pre­fe­ri­ram KDE: eram em mai­o­ria pes­soas mais jovens e com mais desen­vol­tura diante do teclado.
  • Os usuá­rios que pre­fe­ri­ram GNOME: abran­giam quase todas as pes­soas de mais idade ou que, nor­mal­mente, não esta­vam inte­res­sa­das em ter mais inti­mi­dade com o computador.
  • Share/Bookmark

Um Yahoo Mail turbinado

Muita gente vai dis­cor­dar de mim, mas acho o Yahoo Mail melhor que o Gmail. A grande iro­nia aqui é que já admiti faz tempo a supe­ri­o­ri­dade latente do e-mail do Goo­gle, que, lite­ral­mente, faz lou­cu­ras para ino­var na forma de se ler e-mails e parece uma força quase irre­sis­tí­vel para quem (assim como eu) recebe e envia deze­nas (ou cen­te­nas) de e-mails todo dia.

O ser­viço do Yahoo ganha em con­fi­a­bi­li­dade, mas no que­sito pra­ti­ci­dade, parece ter ficado com os con­cei­tos usa­dos ainda na época dos cli­en­tes de e-mail, de ter que bai­xar as men­sa­gens para o PC antes de encher os 4 MB da caixa de entrada enquanto batia-se um papi­nho nas salas do extinto MSN (alguém lem­bra?). Essas dife­ren­ças ficam ainda mais gri­tan­tes por­que o Gmail apre­senta ino­va­ções numa velo­ci­dade ver­ti­gi­nosa e o Yahoo vai, vaga­ro­sa­mente, se dei­xando passar.

Faz alguns meses que, no entanto, fiquei sabendo de mudan­ças no Yahoo Mail e come­mo­rei por­que, ape­sar de admi­tir que o Gmail é legal, algo nele me inco­moda (devo ter pegado birra depois de ser saca­ne­ado quando mais pre­ci­sei do ser­viço)… enfim, o Gmail é aquela mulher bonita, moder­ni­nha, de mente aberta e que ás vezes você se pega pen­sando: “esse diabo de mulher vai me dar dor de cabeça”. Tem quem goste. :-P

Então, eu estava diva­gando nas metá­fo­ras de novo? O assunto aqui são as ino­va­ções do Yahoo Mail: fui fuçar no blog de desen­vol­vi­mento do ser­viço o que vem por aí e gos­tei muito do que encon­trei. Con­fira: Con­ti­nue rea­ding ‘Um Yahoo Mail turbinado’

  • Share/Bookmark