Se você ainda não usou e quer usar, deixe aqui o seu e-mail.
Lembre-se: são apenas 8 convites.
Lots of Bits
Logo que comecei a usar o Fedora 12, uma das coisas que mais quis fazer foi testar o GNOME 2.28. É claro, o GNOME vem se desenvolvendo lentamente quando comparado ao seu “rival”, KDE, mas, ainda assim, vem evoluindo com consistência e estabilidade.
De um modo geral, as melhorias foram sensíveis, mais focadas em lapidar a interface e proporcionar mais simplicidade e leveza. Até aí morreu o Neves…
Demorei a perceber que faltavam alguns ícones, por exemplo, no menu “Sistema” e naquela caixinha de buscas do Firefox. Um ser humano normal não se incomodaria com isso, fiquei intrigado, mas deixei passar.
Tudo ficaria bem se toda vez que eu clicasse no menu “Sistemas” não me deparasse com aquela coisa vazia. Eu estava tão acostumado aos ícones no menu que o incômodo veio crescendo, crescendo até que eu fui procurar o que havia de errado.
Desinstalei o Firefox, apaguei a pasta .mozilla e reinstalei: continuou na mesma. Talvez um erro no GTK por causa do tema default do Fedora tivesse sido a causa dos ícones faltosos. Mudei de tema, mas não adiantou.
Quem sabe um problema na configuração do meu gconf? Deletei as pastas .gconf e .gconfd e nada…
Já ia desinstalar o GNOME inteiro quando perguntei a um amigo se o GTK dele também estava bugado. Com cara de espanto ele quis saber do que eu estava falando e me ouviu desabafar: “cara, sumiram vários ícones do meu tema…”.
Foi aí que ele me disse que tinha lido em algum lugar sobre a decisão do Projeto GNOME de desativar vários ícones para limpar a interface.
Como sou brasileiro e não desisto nunca, fui procurar a tal decisão do pessoal do GNOME e, mais importante ainda, como desfazer isso.
O segredo está no gconf. Se você for como eu, vai ter preguiça de editar na mão, por isso, instale o gconf-editor:
yum install gconf-editor
Abra-o (Aplicativos » Sistema » Editor de configurações) e faça um ctrl+F para abrir a caixa de buscas. Antes de buscar, marque “Pesquisar também em nomes de chaves” e procure pela entrada “menus_have_icons”.
O que você procura está em /desktop/gnome/interface/menus_have_icons. Marque buttons_have_icons e menus_have_icons. Pronto!
Depois de adotarem o Empathy como padrão em vez do Pidgin ainda tenho que aturar mais essa…
Finalmente instalei o Fedora 12 final aqui na minha máquina e, para minha felicidade, quase tudo transcorreu sem grandes malabarismos (especialmente no que diz respeito à instalação de codecs de vídeo e áudio).
O primeiro passo, se você instalou o F12, agora é fazer um update (aproveite enquanto está em apenas 101 MB em média
), como o yum-presto vem ativado por default, não se preocupe, a economia no tamanho dos downloads chega a mais de 80%.
Depois, não perca tempo, instale os repositórios para softwares de terceiros (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 Soares, (o rei das traduções do Fedora) me avisou que o suporte a codecs estava excelente e, como todo incrédulo, fui testar a dica: dei dois cliques num vídeo AVI e o PackageKit foi atrás dos codecs, instalando sem problemas. Depois, mais dois cliques nos meus vídeos RMVB e lá foi o PackageKit de novo buscar os codecs. Resultado: codecs de vídeo (inclusive RMVB e FLV) instalados e funcionando com dois pares de cliques (vai facilitar muito a próxima versão do 1step-install que, graças a Deus, já é quase desnecessário).
Contudo, como nem tudo são flores, um recente bug nos drivers disponibilizados pela NVIDIA forçou o repositório RPMFusion a retirá-lo dos pacotes temporariamente já que, para funcionar direito, eles necessitariam de ajustes manuais.
Uma versão, mantida no repositório de teste, pode ser instalada, mas vai requerer configurações adicinais. Como o driver nouveau tornou-se um padrão no Fedora desde o Fedora 11, um choque entre este e o driver fornecido pela NVIDIA impedia o correto funcionamento de ambos. Como o nouveau ainda é bastante genérico, a maioria dos usuários prefere instalar os drivers fornecidos pelo fabricante e isso gerou o problema.
Antes de tentar instalar seu driver, desative o nouveau a fim de impedir o conflito:
su -
mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img
dracut /boot/initramfs-$(uname -r).img $(uname -r)
Depois, diminua o nível de proteção do SELinux para que ele não impeça o driver de carregar:
setsebool -P allow_execstack on
E instale o driver:
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia
ou
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia-PAE
se você usar um kernel PAE.
su -
mv /boot/initrd-$(uname -r).img /boot/initrd-$(uname -r)-nouveau.img
mkinitrd /boot/initrd-$(uname -r).img $(uname -r)
reboot
E instale o drtver
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia
ou
yum --enablerepo=rpmfusion-nonfree-updates-testing install kmod-nvidia-PAE
se você usar um kernel PAE.
Logo uma solução definitiva será apresentada. Qualquer novidade (e tendo tempo e paciência) eu posto aqui.
Adoro o Firefox (e quem não adora?), mas sempre que posso testo o Google Chrome.
Infelizmente, para quem usa Linux, usar o Google Chrome implica em macetes para que ele funcione via WINE ou pegar o código fonte do Chromium e compilar.
Talvez alguns de vocês se lembrem de que disponibilizei aqui uma vez os RPMs do Chromium para Fedora e hoje, na hora do almoço, fui ver se havia alguma atualização disponível (é claro que havia).
Então, pessoal, ficam aí as atualizações do Chromium para Fedora 10, 11 e rawhide (com versões 32 e 64 bits) instaláveis via YUM.
Quer mais moleza do que isso?
Faça assim:
su -c 'gedit /etc/yum.repos.d/chromium.repo'
[chromium]
name=Chromium Test Packages
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
enabled=1
gpgcheck=0
$ su -c 'yum install chromium'
Cortesia do super fera Spot, um dos maiores empacotadores do Projeto Fedora.
Muitas pessoas (pelo menos assim acredito), gostariam de aprender a receita para gerar um RPM de seu software favorito; a regra de ouro se você usa uma distribuição que gerencia pacotes é “evite, sempre que possível, instalar softwares que não sejam empacotados para o seu linux”, mas, se você usa Fedora ou alguma dessas outras distros “linha dura” pode acabar ficando sem aquele programinha que você tanto gosta.
Para evitar essa tragédia, vou aproveitar o post de hoje para ensinar em passos simples como empacotar um software qualquer em RPM.
Busquei ao acaso um software qualquer que ainda não exista nos repositórios do Fedora, um exemplo bem simples é o FMIT (Free Music Instrument Tuner for Linux). O software é pequeno e pode ser instalado da maneira clássica (./configure, make, make install), por isso é perfeito para o nosso exemplo.
Vá ao site do FMIT baixar o código fonte:
Com o código fonte em mãos, descompacte-o e vá dar uma olhada no que ele pede para compilar sem problemas. Se você está acostumado a instalar softwares direto pelo código fonte vai se lembrar de que o ./configure checa e avisa quais os componentes necessários para uma compilação (e instalação) correta.
Já adianto que o FMIT necessita alsa-lib-devel, freeglut-devel, fftw3-devel, jack-audio-connection-kit-devel, portaudio-devel e qt3-devel para compilar direito e também alsa-lib, fftw3, freeglut, jack-audio-connection-kit para rodar com todas as funcionalidades.
Instalar um software a partir do código fonte consiste mesmo em juntar todas as peças necessárias para poder compilar e isso exige paciência aliada a algumas habilidades detetivescas.
Já baixamos o código fonte e ficamos familiarizados com o que nosso software vai depender para ser compilado. O próximo passo é preparar seu sistema para gerar RPMs. Instalar o ambiente de desenvolvimento é muito simples:
$ su -c 'yum install rpmdevtools'
Isso instala os softwares necessários e
$ rpmdev-setuptree
Que vai gerar as pastas e as macros usadas no desenvolvimento.
O local de desenvolvimento, você vai reparar, fica dentro de uma pasta chamada rpmbuild (~/rpmbuild). Nunca, nunca mesmo, em hipótese alguma, faça RPMs como root porque isso pode dar “permissões demais” aos seus pacotes e não queremos isso, certo?
Dentro de ~/rpmbuild há 5 pastas: SRPMS, RPMS, SPECS, BUILD, SOURCES;
A parte mais chata é essa. Um arquivo .spec tem partes muito bem definidas que precisam ser levadas à risca para gerar um bom pacote, mas não se assuste, hoje em dia há muita coisa já pronta ou automatizada para nos ajudar. Por exemplo, você pode usar o VI/VIM para gerar um arquivo .spec genérico e “oco” para você:
Entre na pasta dos arquivos .spec
$ cd ~/rpmbuild/SPECS
Mande o VI/VIM criar o arquivo .spec vazio:
$ vim fmit.spec
Reparou que “automagicamente” o nosso arquivo de especificação já veio com os campos a preencher? Alguns campos 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 |
Vamos preencher o nosso spec passo a passo. A primeira seção é bem simples, são apenas informaçõ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, colocamos as dependências para compilar 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 terceira seção, uma explicação mais detalhada sobre o software:
1 2 | %description Free Music Instrument Tuner for Linux, bla, bla bla... |
Agora, na quarta seção, um detalhe importante: o FMIT é um software muito simples que pode ser compilado com ./configure, make e make install sem precisar de mais nenhum parâmetro adicional, por isso, não precisa mexer em nada nessas partes 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 compilador precisasse de alguma instrução extra haveria mais coisas 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 catalogar 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 considerado documentação no seu pacote
Você se lembra dessa parte? “%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} –n)” Isso gerou, do lado da pasta BUILD uma nova pasta chamada BUILDROOT. Essa novas pasta é uma pasta “fake” onde o software vai se instalar pensando que está sendo instalado no sistema. Ela tem capacidade de imitar todas as pastas da pasta / de modo a garantir que o software consiga encontrar os lugares devidos à sua “acomodação”. Você deve olhar nessa pasta para descobrir quais arquivos precisam 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, mantenha um histórico do seu trabalho:
1 2 3 | %changelog * Sun May 10 2009 Henrique "LonelySpooky" Junior - 0.97.7-1 - Initial package |
A etapa mais fácil. Mande o rpmbuild gerar seu rpm:
$ rpmbuild -ba ~/rpmbuil/SPECS/fmit.spec
Se tudo correr bem você vai ver as mensagens de compilação e, ao fim, as seguintes 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 prometido, na pasta RPMS estará seu rpm do fmit e um pacotinho com informações de debug que você não precisa.
Este é um exemplo tão genérico quanto possível e tentei apresentar de forma simples como proceder, mas, convém avisar, gerar RPMs varia muito dependendo da linguagem de programação e mesmo um pacote simples como esse pode ser feito de forma mais “elegante”. Em todo caso, espero que tenha matado a curiosidade de alguns ou dado um “empurrãozinho” em quem deseja começar no empacotamento.
Muita gente já sabe que aqui no blog disponibilizo há algum tempo os scripts que fiz para instalar meus codecs e plugins de maneira preguiçosa e descomplicada. A intenção, nem de longe, é criar um software famoso e usado por milhares de pessoas. Ao contrário, as ambições são modestas (se é que existem). O 1Step-Install é muito específico: codecs e plugins; oi escrito, a princípio apenas para mim, mas poderia acabar ajudando outros (tão preguiçosos quanto eu).
Se você quer um software que configure o seu sistema inteiro de uma forma interativa, procure o easyLife, mas se você, simplesmente quer seus recursos multimídia funcionando e não quer saber de ficar respondendo “Sim” e “Não”, talvez os scripts lhe ajudem.
Nem precisa ir muito longe: baixe o 1Step-Install AQUI MESMO.
Saiu escondidinho e sem muito alarde que um dos maiores contribuidores no desenvolvimento do Fedora (e engenheiro da Red hat) Tom “Spot” Callaway está empacotando o Chromium, que é a vertente livre do Google Chrome, para Fedora. Não perdi tempo e fui testar os pacotes.
Ainda há mais a fazer para que os pacotes cheguem no YUM. O processo de empacotar é longo somente porque cada pacote precisa se enquadrar aos rigores legais e técnicos da Red Hat antes de ser aceito. O Chromium ainda vai levar um tempo para acertar esses pormenores, mas o pacote já funciona e decidi deixá-los aqui para quem quiser usar.
A instalação é simples:
1 — Use o YUM para instalar o pacote minizip
su -c 'yum install minizip'
2 — Baixe os pacotes chromium-3.0.184 e v8-1.2.7
3 — Instale os dois pacotes
su -c 'rpm -ivh chromium-3.0.184*.rpm v8-1.2.7*.rpm'
4 — Aproveite
Fedora 10
Fedora 11
Desde que o Linux existe, nas cabeças e corações de toda a comunidade figura o ideal de um mundo 100% livre, onde as pessoas, finalmente, entenderão os benefícios do Open Source, instituições públicas e empresas 100% legalizadas e plenamente funcionais com o pinguim e os sistemas proprietários, cada vez mais acuados, começam a mudar suas posturas de negócio.
A realidade, no entanto, é um pouco mais cruel. O fenômeno do software livre acabou se deparando com uma barreira antiga e que está acostumada a levar à extinção muitos ramos promissores de negócios: a pirataria.
Esperava-se que nos (assim chamados) países de terceiro mundo o Linux seria um importante ator na igualização digital. Todos imaginavam nossas terras cheias de computadores vestidos de Debian, Mandrake, Suse e Red Hat (Ubuntu não existia), mas aqui, para nós no Brasil, na Índia, em Taiwan, na China e na maior parte do mundo, o software proprietário também é quase de graça e nesse caso, a escolha é bem óbvia.

Apesar da realidade não ser tão bonita quanto gostaríamos, a migração, assim como a evangelização, são possíveis e um fator determinante, mas que é o ponto fraco da comunidade Linux, é o tato e a sutileza na hora do convencimento e da implantação.
Linuxistas são vistos como arrogantes (mesmo entre os próprios Linuxistas) já que muitas vezes um técnico ou um programador está fora da realidade do usuário e escapa-lhe ver “o outro lado da moeda”.
Depois de alguns anos, cheguei à conclusão de que o desconhecimento e o preconceito do usuário, aliados à preguiça de aprender algo novo são problemas que devem ser vencidos gradativamente. Por quantas e quantas vezes, ao ver que eu estava instalando Linux em sua estação, o usuário, com olhos suplicantes, perguntava: “não pode instalar o XP?”. Por isso comecei este artigo e espero que seja de alguma valia para quem lida sempre com essa realidade.
Esta postura idiota apenas contribui para a má fama do Linux frente aos leigos. Em vez de perder tempo falando mal do sistema dos outros, concentre seus esforços em mostrar como o seu sistema é bom. O usuário, na verdade, não se importa com o sistema operacional. Num mundo perfeito as pessoas nem ouviriam falar em Windows e Linux, apenas se preocupariam em viver enquanto o computador faz o que deveria fazer. Você fazer longos discursos inflamados à Stallman para quem, simplesmente, não se importa é perda de tempo. Em vez de meter o pau, mostre que a solução livre funciona e não seja egoísta: deixe bem claro que tem Linux para todos os gostos. Se o usuário não gostar do Fedora, tem o Ubuntu, o Mandriva, o openSuse… e um deles, certamente vai agradá-lo.
Toda mudança é traumática e fica ainda pior quando é brusca e forçada. Empurrar o Linux goela abaixo apenas vai aumentar a repulsa pelo sistema. Uma boa solução para isso é começar a substituir os softwares proprietários pelas soluções livres gradativamente. Troque o MS Office pelo OpenOffice, o Internet Explorer pelo Firefox, o Outlook pelo Thunderbird ou Evolution e comece migrando sua própria máquina. Tudo que é novo leva tempo, por isso, deixe que vejam você usando. Sempre vai haver alguma conversa sobre vírus ou outro tipo de malware e esta é sua chance de dizer que se sente seguro quanto a isso porque Linux não pega vírus.
Tomo como exemplo de caso meu irmão, que é o típico usuário: música, vídeo, MSN e muitos downloads. O computador tinha um dual boot onde eu mantinha o Fedora e o XP usando uma conexão wireless que caía constantemente. Meu irmão ficava intrigado ao ver que minha conexão nunca caía e que, além de tudo, também eu podia ver vídeos, navegar e usar MSN. Foi pensando somente no próprio benefício que ele começou a usar o Linux e hoje em dia já entendeu que pode gravar DVDs com o K3b, bater papo com o aMSN, ouvir músicas com o Amarok e ver vídeos no Kaffeine (player favorito dele).
Não mandei que ele migrasse e nem arranquei o Windows, ele viu e percebeu que funciona.
Meu próprio movimento de migração foi gradativo. 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, finalmente, 100%.
Aquele Win XP da contabilidade, finalmente deu seu último suspiro… Vá dar uma olhada, mexa nuns fios, coce o cavanhaque e, de chapéu na mão, dispare: “infelizmente, não há muito que possamos fazer… se pelo menos fosse software original…”.
Mas, falando sério, não tenha receio de mostrar para o usuário que o software dele não tem nenhum tipo de suporte devido à natureza piratesca. É como vender seu voto: uma vez que você votou por dinheiro, nem pense em exigir saúde, educação e impostos mais justos. O compromisso do político com você termina no momento em que o dinheiro muda de dono. Com o software pirata é assim também: você usa, mas não tem o direito de reclamar. Formate e sempre alfinete.
A cara feia do chefe vale mais que mil palavras. Se a chefia concordar com a migração você estará com a faca e o queijo na mão.
Na hora de convencer seu chefe, lembre-se: não interessam os bonitos ideais da FSF, o que ele quer são resultados e benefícios e na hora de expô-los, seja realista. Nem tudo são flores no mundo Linux. Diga ao seu chefe que, com Linux, será possível ter mais controle sobre as máquinas, automatizar tarefas vitais como backups diários, parar de se preocupar com vírus e gozar de uma segurança um pouco (ou muito) maior, mas não se esqueça dos pontos negativos que são a curva de aprendizado – a produtividade dos funcionários vai cair durante um tempo, mas logo volta a crescer – será preciso parar alguns setores por alguns dias para a implementação, dar treinamento aos funcionários e descartar hardwares incompatíveis. Mostre que isso não é uma despesa e sim um investimento e, por último, mas não menos importante, fale sobre a tranqüilidade de parar de usar software pirata, estar 100% legalizado e poder bradar isso aos quatro ventos. Tenha tudo escrito, documentado e apresente um caso de sucesso, como o do MPE de Tocantins, onde a galera deu show.
Padronização é a palavra chave. Tendo o aval do chefe padronize o máximo de coisas que puder. Não tente trabalhar com várias distros ao mesmo tempo pois cada uma é diferente em algum ponto e isso pode ser ruim. Se tudo for padronizado, significa que tudo poderá, também, ser documentado e até um macaco poderá realizar tarefas no caso de você ir fazer um transplante de coração ou cair de avião na Cordilheira dos Andes.
Numa situação ideal seu chefe diria com a mão em seu ombro “Meu filho, isso é o que estávamos precisando por aqui! Um jovem com garra! Pode fazer o que for preciso… e tome aqui um aumento!”. Se for possível, padronize também o seu hardware. Jogue fora todo o lixo tecnológico e troque por hardware de confiança, que você sabe ser compatível e encontrará as peças de olhos fechados. Entenda que esse gasto vai ser compensado no futuro da seguinte forma: se todas as máquinas forem dual core de 2,4 Ghz e elas funcionarem bem, significa que vão funcionar bem indefinidamente e dependendo das condições e do cuidado do usuário, podem ter uma loooonga vida.
O pior inferno na minha vida é pegar o Linux e ter que instalá-lo em hardware bizarro. Uma placa de rede KTL em um P233 de 2 MB de vídeo usando uma maldita impressora matricial da década de 70. São horas ou talvez dias de trabalho estressante onde a relação custo/benefício é desfavorável.
Ao contrário do que pode parecer, migrar não é como numa installfest onde você vai, alegremente e de máquina em máquina fazendo o show da formatação. É preciso fazer backups com todo o cuidado, agendar sua ida ao local para que a equipe se estruture de modo a não sofrer muito com a situação atípica e estar preparado para responder a eventuais perguntas. Ao responder tranqüilize-os, diga que vai ser uma boa mudança e que o suporte vai estar á disposição para esclarecimentos e helpdesk.
Mesmo que aquela menina linda de olhos verdes e minissaia lhe peça, não abra concessões na hora de instalar os softwares. “Tem como colocar Windows na minha máquina?”. A resposta é 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 controle, mesmo em situações de crise a resolução não vai ser muito dolorosa. Quando você estruturar tudo para funcionar em Mandriva, por exemplo, aquele espertinho que gosta de usar Knoppix não deve ter permissão para instalá-lo e isso deve ficar bem claro. Você é o técnico e o usuário só USA. Ele não decide nada.
Busque sempre a solução livre antes de tudo mas, em último caso, apele pro WINE. Se aquele programa essencial não existe para Linux isso pode justificar uma não migração. Faça testes e experimente o WINE, que está muito maduro e consegue resultados espantosos.
No funcionalismo público, por exemplo, é comum softwares que só existem para Windows serem usados para transferência de dados. Antes de migrar, esteja certo de cobrir cada centímetro de terreno. Você vai estar lutando contra a má vontade do usuário também e qualquer coisa fora do normal será pretexto para reclamação.
Pode ser que não aconteça, mas é bastante improvável… o telefone vai tocar e vai tocar muito. Bote uma música suave tocando no ambiente, pinturas em tons pastéis nas paredes e providencie uma bela janela com paisagem, senão você vai acabar matando alguém. =)
Logo após a migração começa o movimento anti-migração. O propósito deles é tornar sua vida tão miserável que você nunca mais vai querer ver um pingüim na sua frente, por isso, prepare-se e tenha em mente o item 7. Com o tempo as pessoas se acostumam e logo vão usar o Linux como se sempre tivessem usado. Você vai se deparar com todos os tipos de problemas: pessoas realmente confusas buscando ajuda, pessoas que sabem, mas fizeram alguma besteira e pessoas cheias de má vontade, que vão telefonar para perguntar imbecilidades do tipo “como se clica no menu?”.
Afirmações do tipo “eu não vou usar isso”, “eu odeio o Linux” e “vou falar com o chefe” podem acontecer. Lembre-se do item 7.
Depois de migrar, aí sim, use toda a sua dialética. Fale de como é bonito o movimento de software livre, emocione-se, faça valer a sua veia teatral de modo que as pessoas se sintam tão mal por usar software pirata que até em suas casas vão querer Linux.
Estou exagerando? Garanto que não. De tanto eu falar meus amigos e parentes já começam a migrar aos poucos – e sem eu nem tocar no assunto deles migrarem.
Isso acontece porque eu sempre comento sobre a relação pirataria/furto, sobre as dores de cabeça de sempre ter que crackear os programas (cada vez mais inteligentes) e digo que, no futuro, crackear um software vai ser tanta encheção de saco que acaba valendo comprar o original ou usar o software livre.
Enfim, o convencimento das pessoas não se faz pela força. Infelizmente, nem a maioria da comunidade Linux está preparada para evangelizá-lo e acaba contribuindo inversamente no processo.
Uma das coisas mais irritantes no GNOME é a área de transferência de péssima qualidade.
No GNOME, você só pode copiar/recortar um conteúdo por vez, ou seja, a área de transferência só tem um espaço e se você, por ventura, copiar/recortar outra coisa, o conteúdo anterior será substituido pelo novo. No KDE temos o Klipper, que copia/recorta e armazena tudo em uma lista que pode ser facilmente acessada depois.
Além disso, no GNOME, digamos que você copia um texto do OpenOffice; se o OpenOffice for fechado, o conteúdo some da área de transferência.
Mas para o GNOME existe o Glipper, que pode ser facilmente instalado via YUM:
# yum install glipper
Um pequeno inconveniente, facil de resolver é que o Glipper não inicia automaticamente com o GNOME e por isso, você deve iniciá-lo “no braço”. Para fazer o Glipper iniciar automaticamente com o GNOME, basta que você use o recurso de autostart.
Procure pelo arquivo ~/.gnome2/session-manual. Se ele não existir, crie-o. Adicione as seguintes linhas:
[Default]
num_clients=1
0,RestartClientHint=3
0,Priority=50
0,RestartCommand=glipper
0,Program=glipper
Feito isso, finalmente, sua área de transferência estará muito mais dinâmica e útil, além de iniciar automaticamente.
O Fedora Core, nativamente, já vem com suporte a VFAT para as partições Windows; contudo os usuários comuns possuem permissão de somente leitura e é uma dúvida clássica imaginar qual seria a maneira de ativar a escrita nesses casos.
Isso pode facilmente ser configurado com a edição do arquivo fstab que fica dentro da pasta /etc. Para tanto, proceda da seguinte forma:
No KDE:
Abra um terminal e torne-se root:
# su (será solicitado que você informe a senha de root)
Chame o seu editor de texto e abra o arquivo fstab em /etc:
# kate /etc/fstab
Agora, adicione a seguinte linha no fim do seu fstab, não se esquecendo de sempre deixar uma linha em branco ao final:
/dev/hdb1 /mnt/D vfat umask=0,gid=100,uid=1000 0 0
salve o arquivo e, ao reinicar, sua permissão de escrita estará ativada
No GNOME:
Abra um terminal e torne-se root:
# su (será solicitado que você informe a senha de root)
Chame o seu editor de texto e abra o arquivo fstab em /etc:
# gedit /etc/fstab
Agora, adicione a seguinte linha no fim do seu fstab, não se esquecendo de sempre deixar uma linha em branco ao final:
/dev/hdX /mnt/windows vfat umask=0,gid=100,uid=1000 0 0
salve o arquivo e, ao reinicar, sua permissão de escrita estará ativada
OBSERVAÇÕES IMPORTANTES:
Para que o procedimento funcione é importante que o usuário tenha em mente dois conceitos indispensáveis e que esta linha do fstab é “genérica” devendo ser mudada para as condições de cada HD: o primeiro conceito é que ele deve saber qual é a partição a ser chamada de VFAT (hda1, hda5, hda7, hdb1…) e que isso deve ser substituido no lugar do hdX, como mostrado 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 conceito é que DEVE ser criada uma sub-pasta como “ponto de montagem” dentro da pasta /mnt ou dentro da pasta /media e, claro, não importa o nome que se dê a essa sub-pasta, desde que o mesmo nome seja mantido no seu fstab. Veja no exemplo:
/dev/hdX /mnt/windows vfat umask=0,gid=100,uid=1000 0 0
/dev/hdX /mnt/D vfat umask=0,gid=100,uid=1000 0 0
Comentários