Archive for the 'dica' Category

Mais 8 convites para o Google Wave

Se você ainda não usou e quer usar, deixe aqui o seu e-mail.

Lembre-se: são ape­nas 8 convites.

  • Share/Bookmark

O GNOME cortou alguns ícones. Traga-os de volta!

Logo que come­cei a usar o Fedora 12, uma das coi­sas que mais quis fazer foi tes­tar o GNOME 2.28. É claro, o GNOME vem se desen­vol­vendo len­ta­mente quando com­pa­rado ao seu “rival”, KDE, mas, ainda assim, vem evo­luindo com con­sis­tên­cia e estabilidade.

De um modo geral, as melho­rias foram sen­sí­veis, mais foca­das em lapi­dar a inter­face e pro­por­ci­o­nar mais sim­pli­ci­dade e leveza. Até aí mor­reu o Neves…

Demo­rei a per­ce­ber que fal­ta­vam alguns ícones, por exem­plo, no menu “Sis­tema” e naquela cai­xi­nha de bus­cas do Fire­fox. Um ser humano nor­mal não se inco­mo­da­ria com isso, fiquei intri­gado, mas dei­xei passar.

Tudo fica­ria bem se toda vez que eu cli­casse no menu “Sis­te­mas” não me depa­rasse com aquela coisa vazia. Eu estava tão acos­tu­mado aos ícones no menu que o incô­modo veio cres­cendo, cres­cendo até que eu fui pro­cu­rar o que havia de errado.

Desins­ta­lei o Fire­fox, apa­guei a pasta .mozilla e reins­ta­lei: con­ti­nuou na mesma. Tal­vez um erro no GTK por causa do tema default do Fedora tivesse sido a causa dos ícones fal­to­sos. Mudei de tema, mas não adiantou.

Quem sabe um pro­blema na con­fi­gu­ra­ção do meu gconf? Dele­tei as pas­tas .gconf e .gconfd e nada…

Já ia desins­ta­lar o GNOME inteiro quando per­gun­tei a um amigo se o GTK dele tam­bém estava bugado. Com cara de espanto ele quis saber do que eu estava falando e me ouviu desa­ba­far: “cara, sumi­ram vários ícones do meu tema…”.

Foi aí que ele me disse que tinha lido em algum lugar sobre a deci­são do Pro­jeto GNOME de desa­ti­var vários ícones para lim­par a interface.

Como sou bra­si­leiro e não desisto nunca, fui pro­cu­rar a tal deci­são do pes­soal do GNOME e, mais impor­tante ainda, como des­fa­zer isso.

O segredo está no gconf. Se você for como eu, vai ter pre­guiça de edi­tar na mão, por isso, ins­tale o gconf-editor:

yum install gconf-editor

Abra-o (Apli­ca­ti­vos » Sis­tema » Edi­tor de con­fi­gu­ra­ções) e faça um ctrl+F para abrir a caixa de bus­cas. Antes de bus­car, mar­que “Pes­qui­sar tam­bém em nomes de cha­ves” e pro­cure pela entrada “menus_have_icons”.

O que você pro­cura está em /desktop/gnome/interface/menus_have_icons. Mar­que buttons_have_icons e menus_have_icons. Pronto!

Depois de ado­ta­rem o Empathy como padrão em vez do Pid­gin ainda tenho que atu­rar mais essa…

  • Share/Bookmark

Fedora 12: primeiras impressões, multimídia e drivers nvidia

Final­mente ins­ta­lei o Fedora 12 final aqui na minha máquina e, para minha feli­ci­dade, quase tudo trans­cor­reu sem gran­des mala­ba­ris­mos (espe­ci­al­mente no que diz res­peito à ins­ta­la­ção de codecs de vídeo e áudio).

O pri­meiro passo, se você ins­ta­lou o F12, agora é fazer um update (apro­veite enquanto está em ape­nas 101 MB em média :-P ), como o yum-presto vem ati­vado por default, não se pre­o­cupe, a eco­no­mia no tama­nho dos down­lo­ads chega a mais de 80%.

Depois, não perca tempo, ins­tale os repo­si­tó­rios para softwa­res de ter­cei­ros (copie as três linhas):

su -c 'rpm -ivh \
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \

http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm’

Meu amigo, Igor Soa­res, (o rei das tra­du­ções do Fedora) me avi­sou que o suporte a codecs estava exce­lente e, como todo incré­dulo, fui tes­tar a dica: dei dois cli­ques num vídeo AVI e o Pac­ka­ge­Kit foi atrás dos codecs, ins­ta­lando sem pro­ble­mas. Depois, mais dois cli­ques nos meus vídeos RMVB e lá foi o Pac­ka­ge­Kit de novo bus­car os codecs. Resul­tado: codecs de vídeo (inclu­sive RMVB e FLV) ins­ta­la­dos e fun­ci­o­nando com dois pares de cli­ques (vai faci­li­tar muito a pró­xima ver­são do 1step-install que, gra­ças a Deus, já é quase desnecessário).

Con­tudo, como nem tudo são flo­res, um recente bug nos dri­vers dis­po­ni­bi­li­za­dos pela NVIDIA for­çou o repo­si­tó­rio RPM­Fu­sion a retirá-lo dos paco­tes tem­po­ra­ri­a­mente já que, para fun­ci­o­nar direito, eles neces­si­ta­riam de ajus­tes manuais.

Uma ver­são, man­tida no repo­si­tó­rio de teste, pode ser ins­ta­lada, mas vai reque­rer con­fi­gu­ra­ções adi­ci­nais. Como o dri­ver nou­veau tornou-se um padrão no Fedora desde o Fedora 11, um cho­que entre este e o dri­ver for­ne­cido pela NVIDIA impe­dia o cor­reto fun­ci­o­na­mento de ambos. Como o nou­veau ainda é bas­tante gené­rico, a mai­o­ria dos usuá­rios pre­fere ins­ta­lar os dri­vers for­ne­ci­dos pelo fabri­cante e isso gerou o problema.

Antes de ten­tar ins­ta­lar seu dri­ver, desa­tive o nou­veau a fim de impe­dir o conflito:

Fedora 12

su -
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img
dracut /boot/initramfs-$(uname -r).img $(uname -r)

Depois, dimi­nua o nível de pro­te­ção do SELi­nux para que ele não impeça o dri­ver de car­re­gar:
setsebool -P allow_execstack on
E ins­tale o dri­ver:
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia
ou
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia-PAE

se você usar um ker­nel PAE.

Fedora 11

su -
mv /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r)-nouveau.img
mkinitrd /boot/initrd-$(uname -r).img $(uname -r)
reboot

E ins­tale o drt­ver
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia
ou
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia-PAE
se você usar um ker­nel PAE.

Logo uma solu­ção defi­ni­tiva será apre­sen­tada. Qual­quer novi­dade (e tendo tempo e paci­ên­cia) eu posto aqui. ;)

  • Share/Bookmark

Novidade: Repositório do Google Chromium para Fedora

Adoro o Fire­fox (e quem não adora?), mas sem­pre que posso testo o Goo­gle Chrome.

Infe­liz­mente, para quem usa Linux, usar o Goo­gle Chrome implica em mace­tes para que ele fun­ci­one via WINE ou pegar o código fonte do Chro­mium e compilar.

Tal­vez alguns de vocês se lem­brem de que dis­po­ni­bi­li­zei aqui uma vez os RPMs do Chro­mium para Fedora e hoje, na hora do almoço, fui ver se havia alguma atu­a­li­za­ção dis­po­ní­vel (é claro que havia).

Então, pes­soal, ficam aí as atu­a­li­za­ções do Chro­mium para Fedora 10, 11 e rawhide (com ver­sões 32 e 64 bits) ins­ta­lá­veis via YUM.

Quer mais moleza do que isso? ;-)

Faça assim:

  • Adi­ci­one o repo­si­tó­rio do Chromium:

su -c 'gedit /etc/yum.repos.d/chromium.repo'

  • E colo­que o seguinte con­teúdo no arquivo:

[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=1
gpgcheck=0

  • Depois:

$ su -c 'yum install chromium'

Cor­te­sia do super fera Spot, um dos mai­o­res empa­co­ta­do­res do Pro­jeto Fedora.

1 Star2 Stars (+6 rating, 3 votes)
Loading ... Loa­ding …
  • 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

1Step-Install novo na área

Muita gente já sabe que aqui no blog dis­po­ni­bi­lizo há algum tempo os scripts que fiz para ins­ta­lar meus codecs e plu­gins de maneira pre­gui­çosa e des­com­pli­cada. A inten­ção, nem de longe, é criar um soft­ware famoso e usado por milha­res de pes­soas. Ao con­trá­rio, as ambi­ções são modes­tas (se é que exis­tem). O 1Step-Install é muito espe­cí­fico: codecs e plu­gins; oi escrito, a prin­cí­pio ape­nas para mim, mas pode­ria aca­bar aju­dando outros (tão pre­gui­ço­sos quanto eu).

Se você quer um soft­ware que con­fi­gure o seu sis­tema inteiro de uma forma inte­ra­tiva, pro­cure o easy­Life, mas se você, sim­ples­mente quer seus recur­sos mul­ti­mí­dia fun­ci­o­nando e não quer saber de ficar res­pon­dendo “Sim” e “Não”, tal­vez os scripts lhe ajudem.

Nem pre­cisa ir muito longe: baixe o 1Step-Install AQUI MESMO.

  • Share/Bookmark

Experimente em primeira mão o Chromium para Fedora

chromiumSaiu escon­di­di­nho e sem muito alarde que um dos mai­o­res con­tri­bui­do­res no desen­vol­vi­mento do Fedora (e enge­nheiro da Red hat) Tom “Spot” Cal­laway está empa­co­tando o Chro­mium, que é a ver­tente livre do Goo­gle Chrome, para Fedora. Não perdi tempo e fui tes­tar os pacotes.

Ainda há mais a fazer para que os paco­tes che­guem no YUM. O pro­cesso de empa­co­tar é longo somente por­que cada pacote pre­cisa se enqua­drar aos rigo­res legais e téc­ni­cos da Red Hat antes de ser aceito. O Chro­mium ainda vai levar um tempo para acer­tar esses por­me­no­res, mas o pacote já fun­ci­ona e decidi deixá-los aqui para quem qui­ser usar.

A ins­ta­la­ção é simples:

1 — Use o YUM para ins­ta­lar o pacote minizip

su -c 'yum install minizip'

2 — Baixe os paco­tes chromium-3.0.184 e v8-1.2.7

3 — Ins­tale os dois pacotes

su -c 'rpm -ivh chromium-3.0.184*.rpm v8-1.2.7*.rpm'

4 — Aproveite

Fedora 10

Fedora 11

  • Share/Bookmark

A difícil arte da migração: como fazer amigos e influenciar pessoas

1 Star2 Stars (+88 rating, 19 votes)
Loading ... Loa­ding …

Desde que o Linux existe, nas cabe­ças e cora­ções de toda a comu­ni­dade figura o ideal de um mundo 100% livre, onde as pes­soas, final­mente, enten­de­rão os bene­fí­cios do Open Source, ins­ti­tui­ções públi­cas e empre­sas 100% lega­li­za­das e ple­na­mente fun­ci­o­nais com o pin­guim e os sis­te­mas pro­pri­e­tá­rios, cada vez mais acu­a­dos, come­çam a mudar suas pos­tu­ras de negócio.

A rea­li­dade, no entanto, é um pouco mais cruel. O fenô­meno do soft­ware livre aca­bou se depa­rando com uma bar­reira antiga e que está acos­tu­mada a levar à extin­ção mui­tos ramos pro­mis­so­res de negó­cios: a pirataria.

Esperava-se que nos (assim cha­ma­dos) paí­ses de ter­ceiro mundo o Linux seria um impor­tante ator na igua­li­za­ção digi­tal. Todos ima­gi­na­vam nos­sas ter­ras cheias de com­pu­ta­do­res ves­ti­dos de Debian, Man­drake, Suse e Red Hat (Ubuntu não exis­tia), mas aqui, para nós no Bra­sil, na Índia, em Taiwan, na China e na maior parte do mundo, o soft­ware pro­pri­e­tá­rio tam­bém é quase de graça e nesse caso, a esco­lha é bem óbvia.

Ape­sar da rea­li­dade não ser tão bonita quanto gos­ta­ría­mos, a migra­ção, assim como a evan­ge­li­za­ção, são pos­sí­veis e um fator deter­mi­nante, mas que é o ponto fraco da comu­ni­dade Linux, é o tato e a suti­leza na hora do con­ven­ci­mento e da implantação.

Linu­xis­tas são vis­tos como arro­gan­tes (mesmo entre os pró­prios Linu­xis­tas) já que mui­tas vezes um téc­nico ou um pro­gra­ma­dor está fora da rea­li­dade do usuá­rio e escapa-lhe ver “o outro lado da moeda”.

Depois de alguns anos, che­guei à con­clu­são de que o des­co­nhe­ci­mento e o pre­con­ceito do usuá­rio, ali­a­dos à pre­guiça de apren­der algo novo são pro­ble­mas que devem ser ven­ci­dos gra­da­ti­va­mente. Por quan­tas e quan­tas vezes, ao ver que eu estava ins­ta­lando Linux em sua esta­ção, o usuá­rio, com olhos supli­can­tes, per­gun­tava: “não pode ins­ta­lar o XP?”. Por isso come­cei este artigo e espero que seja de alguma valia para quem lida sem­pre com essa realidade.

1 – Linux é bom; Win­dows é ruim! Minha dis­tri­bui­ção é a melhor; as outras fedem!

Esta pos­tura idi­ota ape­nas con­tri­bui para a má fama do Linux frente aos lei­gos. Em vez de per­der tempo falando mal do sis­tema dos outros, con­cen­tre seus esfor­ços em mos­trar como o seu sis­tema é bom. O usuá­rio, na ver­dade, não se importa com o sis­tema ope­ra­ci­o­nal. Num mundo per­feito as pes­soas nem ouvi­riam falar em Win­dows e Linux, ape­nas se pre­o­cu­pa­riam em viver enquanto o com­pu­ta­dor faz o que deve­ria fazer. Você fazer lon­gos dis­cur­sos infla­ma­dos à Stall­man para quem, sim­ples­mente, não se importa é perda de tempo. Em vez de meter o pau, mos­tre que a solu­ção livre fun­ci­ona e não seja egoísta: deixe bem claro que tem Linux para todos os gos­tos. Se o usuá­rio não gos­tar do Fedora, tem o Ubuntu, o Man­driva, o open­Suse… e um deles, cer­ta­mente vai agradá-lo.

2 – Você TEM que usar!

Toda mudança é trau­má­tica e fica ainda pior quando é brusca e for­çada. Empur­rar o Linux goela abaixo ape­nas vai aumen­tar a repulsa pelo sis­tema. Uma boa solu­ção para isso é come­çar a subs­ti­tuir os softwa­res pro­pri­e­tá­rios pelas solu­ções livres gra­da­ti­va­mente. Tro­que o MS Office pelo Ope­nOf­fice, o Inter­net Explo­rer pelo Fire­fox, o Outlook pelo Thun­der­bird ou Evo­lu­tion e comece migrando sua pró­pria máquina. Tudo que é novo leva tempo, por isso, deixe que vejam você usando. Sem­pre vai haver alguma con­versa sobre vírus ou outro tipo de malware e esta é sua chance de dizer que se sente seguro quanto a isso por­que Linux não pega vírus.

Tomo como exem­plo de caso meu irmão, que é o típico usuá­rio: música, vídeo, MSN e mui­tos down­lo­ads. O com­pu­ta­dor tinha um dual boot onde eu man­ti­nha o Fedora e o XP usando uma cone­xão wire­less que caía cons­tan­te­mente. Meu irmão ficava intri­gado ao ver que minha cone­xão nunca caía e que, além de tudo, tam­bém eu podia ver vídeos, nave­gar e usar MSN. Foi pen­sando somente no pró­prio bene­fí­cio que ele come­çou a usar o Linux e hoje em dia já enten­deu que pode gra­var DVDs com o K3b, bater papo com o aMSN, ouvir músi­cas com o Ama­rok e ver vídeos no Kaf­feine (player favo­rito dele).

Não man­dei que ele migrasse e nem arran­quei o Win­dows, ele viu e per­ce­beu que funciona.

Meu pró­prio movi­mento de migra­ção foi gra­da­tivo. Antes, era 90% do disco pro Win e 10% pro Línux, depois 50% pra cada. Em pouco tempo 90% do disco tinha Linux e, final­mente, 100%.

3 – Seja cruel!

Aquele Win XP da con­ta­bi­li­dade, final­mente deu seu último sus­piro… Vá dar uma olhada, mexa nuns fios, coce o cava­nha­que e, de cha­péu na mão, dis­pare: “infe­liz­mente, não há muito que pos­sa­mos fazer… se pelo menos fosse soft­ware original…”.

Mas, falando sério, não tenha receio de mos­trar para o usuá­rio que o soft­ware dele não tem nenhum tipo de suporte devido à natu­reza pira­tesca. É como ven­der seu voto: uma vez que você votou por dinheiro, nem pense em exi­gir saúde, edu­ca­ção e impos­tos mais jus­tos. O com­pro­misso do polí­tico com você ter­mina no momento em que o dinheiro muda de dono. Com o soft­ware pirata é assim tam­bém: você usa, mas não tem o direito de recla­mar. For­mate e sem­pre alfinete.

4 – Con­vença o seu chefe.

A cara feia do chefe vale mais que mil pala­vras. Se a che­fia con­cor­dar com a migra­ção você estará com a faca e o queijo na mão.

Na hora de con­ven­cer seu chefe, lembre-se: não inte­res­sam os boni­tos ide­ais da FSF, o que ele quer são resul­ta­dos e bene­fí­cios e na hora de expô-los, seja rea­lista. Nem tudo são flo­res no mundo Linux. Diga ao seu chefe que, com Linux, será pos­sí­vel ter mais con­trole sobre as máqui­nas, auto­ma­ti­zar tare­fas vitais como bac­kups diá­rios, parar de se pre­o­cu­par com vírus e gozar de uma segu­rança um pouco (ou muito) maior, mas não se esqueça dos pon­tos nega­ti­vos que são a curva de apren­di­zado – a pro­du­ti­vi­dade dos fun­ci­o­ná­rios vai cair durante um tempo, mas logo volta a cres­cer – será pre­ciso parar alguns seto­res por alguns dias para a imple­men­ta­ção, dar trei­na­mento aos fun­ci­o­ná­rios e des­car­tar hardwa­res incom­pa­tí­veis. Mos­tre que isso não é uma des­pesa e sim um inves­ti­mento e, por último, mas não menos impor­tante, fale sobre a tranqüi­li­dade de parar de usar soft­ware pirata, estar 100% lega­li­zado e poder bra­dar isso aos qua­tro ven­tos. Tenha tudo escrito, docu­men­tado e apre­sente um caso de sucesso, como o do MPE de Tocan­tins, onde a galera deu show.

5 – Padro­nize tudo.

Padro­ni­za­ção é a pala­vra chave. Tendo o aval do chefe padro­nize o máximo de coi­sas que puder. Não tente tra­ba­lhar com várias dis­tros ao mesmo tempo pois cada uma é dife­rente em algum ponto e isso pode ser ruim. Se tudo for padro­ni­zado, sig­ni­fica que tudo poderá, tam­bém, ser docu­men­tado e até um macaco poderá rea­li­zar tare­fas no caso de você ir fazer um trans­plante de cora­ção ou cair de avião na Cor­di­lheira dos Andes.

Numa situ­a­ção ideal seu chefe diria com a mão em seu ombro “Meu filho, isso é o que está­va­mos pre­ci­sando por aqui! Um jovem com garra! Pode fazer o que for pre­ciso… e tome aqui um aumento!”. Se for pos­sí­vel, padro­nize tam­bém o seu hard­ware. Jogue fora todo o lixo tec­no­ló­gico e tro­que por hard­ware de con­fi­ança, que você sabe ser com­pa­tí­vel e encon­trará as peças de olhos fecha­dos. Entenda que esse gasto vai ser com­pen­sado no futuro da seguinte forma: se todas as máqui­nas forem dual core de 2,4 Ghz e elas fun­ci­o­na­rem bem, sig­ni­fica que vão fun­ci­o­nar bem inde­fi­ni­da­mente e depen­dendo das con­di­ções e do cui­dado do usuá­rio, podem ter uma loo­o­onga vida.

O pior inferno na minha vida é pegar o Linux e ter que instalá-lo em hard­ware bizarro. Uma placa de rede KTL em um P233 de 2 MB de vídeo usando uma mal­dita impres­sora matri­cial da década de 70. São horas ou tal­vez dias de tra­ba­lho estres­sante onde a rela­ção custo/benefício é desfavorável.

6 – Faça aos pou­cos, mas faça.

Ao con­trá­rio do que pode pare­cer, migrar não é como numa ins­tall­fest onde você vai, ale­gre­mente e de máquina em máquina fazendo o show da for­ma­ta­ção. É pre­ciso fazer bac­kups com todo o cui­dado, agen­dar sua ida ao local para que a equipe se estru­ture de modo a não sofrer muito com a situ­a­ção atí­pica e estar pre­pa­rado para res­pon­der a even­tu­ais per­gun­tas. Ao res­pon­der tranqüilize-os, diga que vai ser uma boa mudança e que o suporte vai estar á dis­po­si­ção para escla­re­ci­men­tos e helpdesk.

7 – Não abra concessões.

Mesmo que aquela menina linda de olhos ver­des e minis­saia lhe peça, não abra con­ces­sões na hora de ins­ta­lar os softwa­res. “Tem como colo­car Win­dows na minha máquina?”. A res­posta é não!Se você fizer pra um, vai ter que fazer pra todos e quem cede um pouco cede muito.

Se você tiver tudo sob con­trole, mesmo em situ­a­ções de crise a reso­lu­ção não vai ser muito dolo­rosa. Quando você estru­tu­rar tudo para fun­ci­o­nar em Man­driva, por exem­plo, aquele esper­ti­nho que gosta de usar Knop­pix não deve ter per­mis­são para instalá-lo e isso deve ficar bem claro. Você é o téc­nico e o usuá­rio só USA. Ele não decide nada.

8 – Não tenha ver­go­nha do WINE

Bus­que sem­pre a solu­ção livre antes de tudo mas, em último caso, apele pro WINE. Se aquele pro­grama essen­cial não existe para Linux isso pode jus­ti­fi­car uma não migra­ção. Faça tes­tes e expe­ri­mente o WINE, que está muito maduro e con­se­gue resul­ta­dos espantosos.

No fun­ci­o­na­lismo público, por exem­plo, é comum softwa­res que só exis­tem para Win­dows serem usa­dos para trans­fe­rên­cia de dados. Antes de migrar, esteja certo de cobrir cada cen­tí­me­tro de ter­reno. Você vai estar lutando con­tra a má von­tade do usuá­rio tam­bém e qual­quer coisa fora do nor­mal será pre­texto para reclamação.

9 – Migrou? Pre­pare os calmantes.

Pode ser que não acon­teça, mas é bas­tante impro­vá­vel… o tele­fone vai tocar e vai tocar muito. Bote uma música suave tocando no ambi­ente, pin­tu­ras em tons pas­téis nas pare­des e pro­vi­den­cie uma bela janela com pai­sa­gem, senão você vai aca­bar matando alguém. =)

Logo após a migra­ção começa o movi­mento anti-migração. O pro­pó­sito deles é tor­nar sua vida tão mise­rá­vel que você nunca mais vai que­rer ver um pingüim na sua frente, por isso, prepare-se e tenha em mente o item 7. Com o tempo as pes­soas se acos­tu­mam e logo vão usar o Linux como se sem­pre tives­sem usado. Você vai se depa­rar com todos os tipos de pro­ble­mas: pes­soas real­mente con­fu­sas bus­cando ajuda, pes­soas que sabem, mas fize­ram alguma bes­teira e pes­soas cheias de má von­tade, que vão tele­fo­nar para per­gun­tar imbe­ci­li­da­des do tipo “como se clica no menu?”.

Afir­ma­ções do tipo “eu não vou usar isso”, “eu odeio o Linux” e “vou falar com o chefe” podem acon­te­cer. Lembre-se do item 7.

10 – Chan­ta­gem emocional

Depois de migrar, aí sim, use toda a sua dia­lé­tica. Fale de como é bonito o movi­mento de soft­ware livre, emocione-se, faça valer a sua veia tea­tral de modo que as pes­soas se sin­tam tão mal por usar soft­ware pirata que até em suas casas vão que­rer Linux.

Estou exa­ge­rando? Garanto que não. De tanto eu falar meus ami­gos e paren­tes já come­çam a migrar aos pou­cos – e sem eu nem tocar no assunto deles migrarem.

Isso acon­tece por­que eu sem­pre comento sobre a rela­ção pirataria/furto, sobre as dores de cabeça de sem­pre ter que crac­kear os pro­gra­mas (cada vez mais inte­li­gen­tes) e digo que, no futuro, crac­kear um soft­ware vai ser tanta enche­ção de saco que acaba valendo com­prar o ori­gi­nal ou usar o soft­ware livre.


Enfim, o con­ven­ci­mento das pes­soas não se faz pela força. Infe­liz­mente, nem a mai­o­ria da comu­ni­dade Linux está pre­pa­rada para evangelizá-lo e acaba con­tri­buindo inver­sa­mente no processo.

  • Share/Bookmark

Área de trabalho funcionando no GNOME

Uma das coi­sas mais irri­tan­tes no GNOME é a área de trans­fe­rên­cia de pés­sima qualidade.

No GNOME, você só pode copiar/recortar um con­teúdo por vez, ou seja, a área de trans­fe­rên­cia só tem um espaço e se você, por ven­tura, copiar/recortar outra coisa, o con­teúdo ante­rior será subs­ti­tuido pelo novo. No KDE temos o Klip­per, que copia/recorta e arma­zena tudo em uma lista que pode ser facil­mente aces­sada depois.

Além disso, no GNOME, diga­mos que você copia um texto do Ope­nOf­fice; se o Ope­nOf­fice for fechado, o con­teúdo some da área de transferência.

 

Mas para o GNOME existe o Glip­per, que pode ser facil­mente ins­ta­lado via YUM:
# yum install glipper
Um pequeno incon­ve­ni­ente, facil de resol­ver é que o Glip­per não ini­cia auto­ma­ti­ca­mente com o GNOME e por isso, você deve iniciá-lo “no braço”. Para fazer o Glip­per ini­ciar auto­ma­ti­ca­mente com o GNOME, basta que você use o recurso de autostart.

Pro­cure pelo arquivo ~/.gnome2/session-manual. Se ele não exis­tir, crie-o. Adi­ci­one as seguin­tes linhas:

[Default]
num_clients=1
0,RestartClientHint=3
0,Priority=50
0,RestartCommand=glipper
0,Program=glipper

Feito isso, final­mente, sua área de trans­fe­rên­cia estará muito mais dinâ­mica e útil, além de ini­ciar automaticamente.

  • Share/Bookmark

VFAT com escrita para todos os usuários

O Fedora Core, nati­va­mente, já vem com suporte a VFAT para as par­ti­ções Win­dows; con­tudo os usuá­rios comuns pos­suem per­mis­são de somente lei­tura e é uma dúvida clás­sica ima­gi­nar qual seria a maneira de ati­var a escrita nes­ses casos.
Isso pode facil­mente ser con­fi­gu­rado com a edi­ção do arquivo fstab que fica den­tro da pasta /etc. Para tanto, pro­ceda da seguinte forma:

No KDE:
Abra um ter­mi­nal e torne-se root:
# su (será soli­ci­tado que você informe a senha de root)
Chame o seu edi­tor de texto e abra o arquivo fstab em /etc:
# kate /etc/fstab
Agora, adi­ci­one a seguinte linha no fim do seu fstab, não se esque­cendo de sem­pre dei­xar uma linha em branco ao final:
/dev/hdb1 /mnt/D vfat umask=0,gid=100,uid=1000 0 0
salve o arquivo e, ao rei­ni­car, sua per­mis­são de escrita estará ativada

No GNOME:
Abra um ter­mi­nal e torne-se root:
# su (será soli­ci­tado que você informe a senha de root)
Chame o seu edi­tor de texto e abra o arquivo fstab em /etc:
# gedit /etc/fstab
Agora, adi­ci­one a seguinte linha no fim do seu fstab, não se esque­cendo de sem­pre dei­xar uma linha em branco ao final:
/dev/hdX /mnt/windows vfat umask=0,gid=100,uid=1000 0 0
salve o arquivo e, ao rei­ni­car, sua per­mis­são de escrita estará ativada

OBSERVAÇÕES IMPORTANTES:
Para que o pro­ce­di­mento fun­ci­one é impor­tante que o usuá­rio tenha em mente dois con­cei­tos indis­pen­sá­veis e que esta linha do fstab é “gené­rica” devendo ser mudada para as con­di­ções de cada HD: o pri­meiro con­ceito é que ele deve saber qual é a par­ti­ção a ser cha­mada de VFAT (hda1, hda5, hda7, hdb1…) e que isso deve ser subs­ti­tuido no lugar do hdX, como mos­trado aqui:

/dev/hdX /mnt/windows vfat umask=0,gid=100,uid=1000 0 0
/dev/hda5 /mnt/windows vfat umask=0,gid=100,uid=1000 0 0

O segundo con­ceito é que DEVE ser cri­ada uma sub-pasta como “ponto de mon­ta­gem” den­tro da pasta /mnt ou den­tro da pasta /media e, claro, não importa o nome que se dê a essa sub-pasta, desde que o mesmo nome seja man­tido no seu fstab. Veja no exemplo:

/dev/hdX /mnt/win­dows vfat umask=0,gid=100,uid=1000 0 0
/dev/hdX /mnt/D vfat umask=0,gid=100,uid=1000 0 0

  • Share/Bookmark