Linux Guia Prático

Prévia do material em texto

Índice
Prefácio 9
Convenções usadas neste livro 10
Notas gramaticais 11
Introdução: Uma breve história do Linux 12
Como baixar, gravar e dar boot 15
Rodando o Linux, sem sair do Windows 18
Capítulo 1: Entendendo o Sistema 27
A árvore genealógica das distribuições 27
As primeiras distribuições Linux 27
A família Red Hat 28
O Debian 31
Knoppix e os live-CDs 32
O Ubuntu 35
Juntando as peças 36
Gentoo, BSD e Solaris 37
A questão dos aplicativos 38
Pacotes e instaladores 40
Entendendo o sistema 42
O kernel 43
Entendendo os diretórios 47
Usando o terminal 49
Comandos do prompt 54
O su, o sux e o sudo 57
A questão das permissões 59
Uma introdução ao shell-script 64
Montando e desmontando 70
Usando o Gparted 76
O X e as interfaces 80
Gerenciador de login 83
Xkill e processos 84
Boot, serviços e arquivos de inicialização 88
Opções para solucionar problemas 91
Capítulo 2: Aprofundando os estudos com o
Slackware 94
As origens 94
Instalando o Slackware 95
Boot e particionamento 96
O instalador 100
Selecionando as partições 102
Seleção dos pacotes 105
Gerenciador de boot 109
Passos finais 113
Sobrevivendo ao primeiro boot 117
Configurando o X 124
Drivers 3D da nVidia e da ATI 131
Configurando o KDE 3.x 133
Opções do Kcontrol 133
Barra de tarefas e dicas 141
Arquivos de configuração 146
Instalação de programas 148
Repositórios adicionais 151
Instalando a partir do código-fonte 152
Configurando o Slackware como desktop 153
Configurando placas wireless no Slackware 160
Configurando o lilo 164
Ativando e desativando serviços no Slackware 167
Aplicativos em modo texto 171
Gerenciadores de pacotes no Slackware 178
Usando o Slackpkg 178
Usando o Slapt-get 180
Capítulo 3: Mandriva, KDE 4 e aplicativos 184
Dicas de instalação 184
Particionamento 186
Seleção de pacotes e dependências 190
Contas, serviços e gerenciador de boot 193
Adicionando repositórios extras 198
Entendendo o urpmi 201
Mandriva Control Center 204
Suporte a hardware 205
Configuração da rede 209
Sistema e serviços 212
Compartilhamentos de rede 219
Partições e pontos de montagem 220
Segurança e firewall 222
Wizards para servidores 224
Dual-Boot com o Windows 227
Bluetooth 228
Remapeando teclas 230
VMware Player no Mandriva 232
Configurando o Grub manualmente 234
Entendendo o KDE 4 240
Opções do Systemsettings 244
Opções gerais 244
Opções avançadas 250
Usando o Dolphin 253
Dicas de aplicativos 256
Dicas para o Firefox 256
Navegando em conexões lentas 264
Leitores de PDF 267
Editores e visualizadores de imagem 268
Comunicadores e e-mail 271
VoiP 273
Players de áudio e servidores de som 276
Players de vídeo 281
K3B e Brasero 287
Dicas para o OpenOffice/BrOffice 289
Outras opções de aplicativos de escritório 297
Descompactação de arquivos 298
Capítulo 4: OpenSUSE e o YaST 301
Download e instalação via rede 302
Mais dicas de instalação 304
Particionamento, pontos de montagem e opções 308
Entendendo o LVM 311
As opções finais 312
YaST e a organização do sistema 316
Gerenciamento de pacotes 317
Usando o Zypper 319
Hardware e drivers 323
Sistema 327
Configuração da rede 329
Serviços de rede 334
AppArmor 337
Segurança e outros 339
Acesso remoto 341
Usando o Xen 344
Capítulo 5: Ubuntu 350
Opções de instalação 351
Sudo e o gerenciador de boot 355
Dicas de pós instalação 357
Configurando o Unity 359
Configuração do sistema e atualizações 372
Configuração da rede 375
Usando múltiplos monitores 379
Configurando o GNOME 383
Configuração das fontes 388
Usando o gconf-editor 390
Dicas para o Nautilus 391
Múltiplas áreas de trabalho 395
Usando o Ubuntu Tweak 396
Mais opções de configuração 398
Gerenciamento de pacotes e repositórios 403
Atualizações do sistema 407
Usando o apt-get e o aptitude 410
Entendendo o cache do apt e transportando os arquivos 414
Usando o dpkg e solucionando problemas 415
Synaptic, gnome-app-install e outros gerenciadores 418
Codecs, plugins, drivers e outros pacotes adicionais 420
Configuração de impressoras 425
Usando o KDE no Ubuntu 428
Mais opções de administração 430
Criando um diretório encriptado 433
Firewall no Ubuntu 438
Configurando o grub 2 443
Upstart e a configuração dos serviços 448
Instalando através do alternate CD 451
Instalando a partir do Windows 457
Instalando em um pendrive 458
Live-CD do Ubuntu como sistema de recuperação 461
A família Ubuntu 466
Criando sua própria versão com o Ubuntu Builder 469
Gerando uma imagem personalizada com o Clonezilla 471
Capítulo 6: Debian como desktop 474
Instalando o Lenny 475
Download dos pacotes, instalação e gerenciador de boot 478
Configuração básica 481
Configurando os repositórios 482
Configuração da rede 484
Terminal e sudo 487
Iceweasel x Firefox 488
NTFS-3g 489
Instalando drivers adicionais no Debian 490
Usando o KVM (Qemu) 493
Migrando para o Squeeze 497
Atualizando o Kurumin 7 para o Lenny 498
Instalando o Debian em netbooks 503
Dicas de configuração 507
Liberando espaço no SSD 510
Conexão 3G e Bluetooth 512
Usando o Debian em PCs antigos 514
Usando o LXDE 514
Dicas de aplicativos leves 516
Atualizando o kernel no Debian 518
Gerando um kernel personalizado 520
Compilando e instalando 526
Compilando no Debian 528
Detalhes sobre o uso do hdparm 529
Gerenciamento de energia 533
PowerTOP e outras dicas 536
Monitorando com o lm-sensors 541
Usando o notebook como segundo monitor 544
Usando dois monitores em placas nVidia 549
Capítulo 7: Fedora 555
As características básicas 555
Instalação e o Anaconda 557
Live-CDs e instalação via rede 564
Multimídia e repositórios adicionais 567
Gerenciamentode pacotes 569
Usando o yum 571
Configurando o Fedora 574
Dicas gerais 575
Configuração da rede 576
Módulos adicionais 578
Firewall e SELinux 579
Capítulo 8: Virtualização e Wine 584
Usando o VirtualBox 585
As opções básicas 590
Criando as máquinas virtuais 592
Instalando os extras para o convidado 598
Mais configurações 602
Usando o VirtualBox via linha de comando 607
Configuração da rede virtual 610
VMware Server em desktops 612
Instalando o VMware Server 613
Usando a interface de administração 615
Usando as VMs 620
Usando o Wine 624
Instalação e uso 626
Dicas para o Winecfg 631
Winetricks 634
PlayOnLinux 636
CrossOver, Bordeaux e Cedega 637
Aplicativos open-source para o Windows 639
Capítulo 09: Outras distribuições 643
Knoppix 643
sidux 645
Dreamlinux 649
LinuxMint 651
Big Linux 655
PCLinuxOS 657
Vector Linux 660
Arch Linux 662
Sabayon 669
Distribuições "pra inglês ver" 673
Distribuições minimalistas 674
Puppy Linux 674
Slax 680
GoblinX 684
Tiny Core 686
SliTaz 689
Referências 695
Prefácio
Em 2001 publiquei a edição inicial do livro Entendendo e Dominando o
Linux, que foi sucedida por diversas atualizações. Ele foi um dos primeiros
livros sobre Linux em português e por isso acabou atraindo muitos leitores,
tanto que até hoje a versão online (disponível na página da GDH Press) ainda
recebe muitas visitas.
Entretanto, com o passar dos anos ele foi ficando bastante desatualizado, já
que as distribuições Linux evoluem de forma extremamente rápida. Surgiu
então a idéia de escrever um novo livro a partir do zero, com uma abordagem
atualizada, que deu origem ao Linux, Guia Prático.
O principal objetivo do livro é mostrar como o sistema funciona, abordando
desde os aplicativos básicos e as ferramentas de configuração até os detalhes
mais técnicos sobre os componentes do sistema, sempre procurando manter
uma abordagem simples, porém aprofundada, assim como nos outros livros
da série.
Para evitar repetição de temas, cada capítulo aborda diferentes aspectos do
sistema, usando como exemplo uma distribuição diferente. A maior parte dos
tópicos sobre uso de linha de comando são abordados no capítulo sobre o
Slackware, enquanto os tópicos relacionados ao GNOME são concentrados
no capítulo do Ubuntu, por exemplo. Você encontrará também explicações
sobre o Mandriva, OpenSUSE, Debian, Fedora e várias distribuições
derivadas deles.
A ideia é oferecer uma abordagem prática do sistema, para que você possa
entender como as peças se encaixam e seja capaz de utilizar várias
distribuições, explorando os pontos fortes de cada uma e solucionando os
problemas que surgirem pelo caminho.
Convenções usadas neste livro
Localizações de arquivos, pastas e comandos citados dentro do texto vão
sempre entre aspas, como em: "/etc/fstab".
Arquivos de configuração, termos, opções e comandos citados pela primeira
vez, ou dignos de destaque são colocados em negrito como em:
"desktop=xfce". As aspas são usadas como uma forma de destacar termos e
comandos, por isso, são usadas de forma frequente.
Em alguns casos, o mesmo termo pode ser escrito de forma diferente em
diferentes situações, como por exemplo "X.org" (o nome do projeto) e "xorg"
(o nome usado nos arquivos de configuração) ou "Konqueror" (o nome do
programa) e "konqueror" (o comando usado para executá-lo via terminal). O
Linux é case-sensitive, por isso os comandos precisam ser sempre digitados
literalmente, respeitando as letras maiúsculas e minúsculas. 
Os comandos de terminal são colocados em fonte de largura fixa, para
facilitar a leitura e precedidos sempre por uma cerquilha (#) ou um símbolo
de dólar ($) que indica como devem ser executados. 
Comandos com uma cerquilha devem ser executados como root, como em:
# apt-get install debian-multimedia-keyring
Comandos com um símbolo de dólar, devem ser executados com um login
normal de usuário, como em:
$ konqueror
No Linux, o default é fazer login no sistema usando uma conta de usuário,
geralmente criada durante a instalação. Para se logar como root, você deve
usar o comando "su -" (seguido da senha) ou "sudo su", de acordo com a
distribuição usada.
Trechos de código, arquivos de configuração ou citações são incluídos com
afastamento para a direita e fonte de largura fixa, como em:
title Debian GNU/Linux, kernel 2.6.29-1-686
root (hd0,2)
kernel /boot/vmlinuz-2.6.29-1-686 root=/dev/sda3 ro quiet
initrd /boot/initrd.img-2.6.29-1-686
O destaque é necessário pois, assim como os comandos, estes exemplos
devem ser digitados literalmente, incluindo a diferenciação de letras
maiúsculas e minúsculas.
Alguns comandos e linhas de configuração longos são colocados com fonte
ligeiramente menor, para que ocupem uma única linha (quando isso for
importante), como em:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Isso é necessário, pois um comando quebrado em dois, ou uma linha de
configuração dividida em duas linhas, perde seu sentido quando executado e
resulta em erro.
Em muitos casos é usada a barra invertida (\) para quebrar comandos Linux
longos em várias linhas. Se digitados literalmente no terminal, estes
comandos são executados normalmente, pois o interpretador desconsidera o
"Enter" depois da barra. Na hora de digitar, você pode desconsiderar a barra
invertida e digitar os comandos numa única linha, se preferir.
 
Notas gramaticais
Este é um livro escrito em "tecniquês". Esta é uma língua que conserva certas
semelhanças com o português, mas possui palavras, termos e regras
específicas. Ao longo do livro é sempre dada prioridade à fluidez, clareza e
exatidão técnica do livro, em detrimento às regras gramaticais, quando
necessário, pois o objetivo é formar técnicos e não linguistas.
Com frequência são usados trechos escritos em linguagem coloquial, ou que
refletem a forma de falar entre o meio técnico. O mesmo se aplica ao uso de
pronomes e conjunções, que em muitas situações são usados de forma
diferente do comum.
Um exemplo é o "onde", que, diferentemente do português, é usado não
apenas para locais físicos, mas também para opções de configuração, menus e
funções dentro de aplicativos, arquivos de configuração e assim por diante,
que são tratados como "locais", muito embora não existam fisicamente. Para
tornar a leitura mais agradável e evitar desviar a atenção do leitor, o "onde" é
usado também em substituição ao "situação em que" em muitos pontos do
livro.
Outro ponto em que o tecniquês se diferencia do português é no uso do
masculino e feminino. Termos técnicos não possuem gênero, pois derivam de
palavras da língua inglesa, onde dizemos "the network card" e "the
operacional system". Para compatibilizar as duas línguas, adoto como regra
geral a atribuição de gênero baseada na tradução. A "network card" passa
então a ser feminina, pois traduzimos como "placa de rede".
Apesar disso, em muitas situações a atribuição de gênero é diferente do que
seria considerado correto dentro das regras da língua portuguesa, como em
"usuário e senha" (user and password) ou "arquivos e configurações". A
segunda palavra, nesses casos, é tratada como se fosse masculina.
Introdução: Uma breve história do Linux
 
O sistema operacional é o responsável por ativar todos os periféricos e criar o
ambiente sobre o qual todos os outros programas rodam. É ele o responsável
por reservar processamento suficiente para que o MP3 que você está ouvindo
em background continue sendo tocado mesmo quandovocê precisa abrir
outro aplicativo pesado, ou por transferir programas e bibliotecas sem uso
para a memória virtual quando a memória principal está quase toda ocupada,
por exemplo. Isso faz com que o trabalho do sistema operacional seja uma
atividade inglória, já que você só se lembra dele quando alguma coisa dá
errado. :)
Para tristeza de alguns e alegria de outros, o Windows é o sistema
operacional mais usado em desktops, o que faz com que ele seja a plataforma
mais familiar para a maioria. Muitas tarefas são complicadas (experimente
tentar encontrar drivers para alguma placa-mãe antiga, por exemplo), mas,
como muita gente usa e muitos passam pelos mesmos problemas, acaba
existindo uma rede de suporte em torno do sistema.
O domínio da Microsoft na área de sistemas operacionais começou em 1981,
com o lançamento do primeiro PC e da primeira versão do MS-DOS. Embora
não tivesse nada de especial com relação a outros sistemas da época, o DOS
cresceu em popularidade junto com os PCs, seguido pelas diversas versões do
Windows. Apesar disso, a Microsoft é uma página recente na história da
informática. Enquanto o MS-DOS ainda dava seus primeiros passos, o Unix
já era um sistema maduro, usado na maioria dos computadores de grande
porte e em estações de trabalho. A história do Unix começou em 1969, na
frente de um computador igual a este:
Este é um PDP-7, um "minicomputador" da década de 1960 que possuía
apenas 8 kbytes de memória RAM e utilizava fitas magnéticas para o
armazenamento de dados. Hoje em dia, qualquer agenda eletrônica ou celular
possui muito mais memória e poder de processamento do que ele, mas na
época era um equipamento relativamente poderoso, que custava US$ 72.000.
Devido às pesadas limitações da máquina, o sistema operacional deveria ser
extremamente enxuto e otimizado, de forma a extrair o máximo de
desempenho e consumir o mínimo possível de memória. A combinação da
criatividade dos desenvolvedores, a necessidade e as limitações impostas pelo
equipamento, resultou em um sistema bastante otimizado e elegante. Muitas
das idéias surgidas nessa época continuam sendo usadas até hoje.
O Unix evoluiu durante a década de 1970, passando a ser usado em cada vez
mais equipamentos e ganhando mais recursos. Quase sempre ele era usado
em aplicações "sérias", incluindo instalações militares, bancos e outras áreas
onde não existe margem para falhas. Devido a tudo isso, o sistema se tornou
muito robusto e estável.
Os primeiros sistemas Unix foram desenvolvidos de forma colaborativa,
dentro de universidades e centros de pesquisa. Embora naquela época ainda
não existisse a Internet como a conhecemos hoje, existia uma grande
colaboração entre os desenvolvedores. Isso mudou na década de 1980,
quando empresas como a AT&T, Sun e SCO, que detinham os direitos sobre
o sistema, passaram a desenvolver versões proprietárias e a concorrerem
entre si. A colaboração deixou de acontecer e a plataforma foi fragmentada
em versões incompatíveis.
Outro fator importante foi a falta de investimento em versões destinadas a
micros PCs. Na época, os PCs eram vistos como computadores muito
limitados, incapazes de rodar sistemas Unix completos (lembre-se de que
estou falando do início da década de 1980, quando ainda eram usados micros
XT e 286). Somados, estes dois fatores fizeram com que a plataforma
definhasse, deixando o caminho livre para o crescimento da Microsoft e das
diferentes versões do Windows. Chegamos, então, ao Linux.
Tudo começou em 1991, quando Linus Torvalds começou a trabalhar no
desenvolvimento de um sistema Unix para rodar em seu 386. Na época, o
único sistema similar era o Minix, um sistema operacional para uso
acadêmico, que era bastante limitado. No início, Linus usava o Minix para
rodar o editor, compiladores e outras ferramentas de desenvolvimento que
utilizava para desenvolver o kernel Linux, mas, a partir de um certo ponto,
ele passou a usar o próprio Linux. Ou seja, depois de um breve período de
encubação dentro do Minix, o Linux passou a ser desenvolvido dentro do
próprio Linux. :)
De início, o kernel Linux era um projeto muito pequeno, o hobby de um
único programador. Entretanto, ele tinha uma grande vantagem em relação
aos sistemas UNIX que o precederam: o simples fato de ser disponibilizado
sob a licença GPL. Isso permitiu que outros programadores adotassem o
projeto, passando a contribuir com melhorias e correções. Subitamente, toda
a demanda acumulada em relação a um sistema Unix para micros PC foi
canalizada em torno do Linux, fazendo com que o sistema passasse a crescer
em um ritmo cada vez mais acelerado, chegando ao que temos nos dias de
hoje.
A licença GPL, tão comentada, mas ao mesmo tempo tão mal-compreendida,
pode ser resumida em 4 direitos básicos e uma obrigação:
1- Aplicativos disponibilizados sob a GPL podem ser usados por
qualquer um e para qualquer fim, sem limitações. Mesmo que
eventualmente os criadores mudem de ideia e resolvam passar a
distribuir novas versões do programa sob outra licença, as versões que
foram distribuídas sob a GPL continuam disponíveis, o que permite que
outros desenvolvedores criem uma derivação e continuem o
desenvolvimento. Isso traz uma boa dose de segurança para quem usa o
aplicativo, já que reduz a chance de ele ser descontinuado e ficar
indisponível. Enquanto houver um volume considerável de usuários
interessados no aplicativo, é bem provável que o desenvolvimento
continue, de uma forma ou de outra. 
2- Direito de tirar cópias do programa, distribuí-las ou até mesmo
vendê-las a quem tiver interesse. Existe a possibilidade de ganhar algum
dinheiro vendendo CDs gravados, por exemplo, mas como todo mundo
pode fazer a mesma coisa, é preciso vender por um preço relativamente
baixo, cobrando pelo trabalho de gravação e não pelo software em si,
que está largamente disponível.
Isso faz com que a forma mais eficiente de ganhar dinheiro com os
softwares seja prestar suporte e vender serviços de personalização e não
com a venda direta, como no caso dos softwares comerciais. Para o
cliente, acaba sendo vantajoso, pois o custo de implantação será o gasto
com a consultoria e treinamentos, enquanto ao implantar um software
comercial qualquer, ele gastaria também com as licenças de uso.
3- Direito de ter acesso ao código fonte do programa, fazer alterações e
redistribuí-las. Para um programador este é o principal atrativo, já que
permite criar novos projetos usando como base o código fonte de
programas já existentes (ao invés de ter sempre que começar do zero),
sem falar na grande oportunidade de aprendizado que examinar o
código fonte de outros programas propicia.
4- Direito (e ao mesmo tempo a obrigação) de redistribuir as
modificações feitas. Este é o ponto onde existem mais mal-entendidos.
Se você desenvolve um software por hobby, ou para usá-lo
internamente na sua empresa, e não possui interesse em explorá-lo
comercialmente, você pode simplesmente divulgar o código fonte para
todo mundo, o que é o caminho mais lógico se você pretende atrair
outros interessados em ajudá-lo no desenvolvimento. Mas, caso você
pretenda receber pelo seu trabalho de desenvolvimento, existem duas
opções:
a) Você pode distribuir o software livremente para aumentar a base de
usuários e ganhar vendendo suporte, treinamentos e personalizações.
b) Você só é obrigado a distribuir o código fonte a quem obtém o
software, de forma que você pode trabalhar batendo de porta em porta,
vendendo o software para alguns clientes específicos e fornecendo o
código fonte apenas para eles. Não existe nada de errado com este
modelo, mas você perde a possibilidade de ter contribuições de outros
desenvolvedores, o que pode ser ruim a longo prazo.
Os softwares distribuídos sob a GPL também não "contaminam" softwares
comerciais ou de outras licenças no caso de distribuição conjunta. Por
exemplo, uma revista pode distribuir alguns softwares GPL no meio de um
monte de aplicativos proprietários na mesma edição. Os softwares GPL
continuam sendo GPL, com todas regras que vimos acima, enquantoos
softwares proprietários continuam sendo fechados. A revista deve incluir o
código fonte dos aplicativos GPL (ou pelo menos a informação de como
obtê-los via Internet) mas, naturalmente, não precisa fazer o mesmo com os
outros aplicativos incluídos no CD.
Você pode também usar algum software GPL em conjunto com o seu
aplicativo comercial, desenvolvendo um aplicativo qualquer que utiliza o
Postgree SQL (um servidor de banco de dados), por exemplo. O Postgree
SQL continua sendo GPL e o seu aplicativo continua sendo fechado;
qualquer um pode usar e tirar cópias do Postgree SQL, mas você controla a
distribuição do seu aplicativo. Uma coisa não interfere com a outra. 
Ou seja, muito embora alguns vejam a GPL como algum tipo de licença
comunista, que diz que todos os programadores devem fazer voto de miséria
e passar a trabalhar de graça em nome do bem comum, ela é na verdade
apenas uma licença que estimula a colaboração e o reaproveitamento de
softwares e componentes, e que vem nos trazendo diversas mudanças
positivas. De certa forma, podemos dizer que a GPL é uma licença até
bastante capitalista (no bom sentido), pois estimula a concorrência entre
projetos e empresas e dificulta a criação de monopólios, que são ruins para o
sistema econômico.
Voltando à história, embora o kernel seja o componente mais importante do
sistema (e também o mais complexo), ele não é o único. Qualquer sistema
operacional moderno é a combinação de um enorme conjunto de drivers,
bibliotecas, aplicativos e outros componentes. O kernel é apenas uma base
sobre a qual todos eles rodam.
Além do período de incubação dentro do Minix, o Linux se beneficiou de
diversos outros projetos anteriores, tais como o X (responsável pela interface
gráfica) e inúmeros utilitários, bibliotecas, linguagens de programação,
compiladores e assim por diante. A eles se soma uma grande lista de
interfaces e aplicativos que surgiram nos anos seguintes, tais como o
GNOME, o KDE, o Firefox e o OpenOffice.
Entre as ferramentas usadas desde os primeiros dias, estão o Emacs e o GCC,
desenvolvidos pela Free Software Fundation, como parte do projeto GNU. O
Emacs é um editor de texto que combina uma grande quantidade de recursos
e ferramentas úteis para programadores, enquanto o GCC é o compilador que
permite transformar o código escrito nele em arquivos executáveis.
Isso deu origem a uma das maiores flame-wars da história da informática,
com Richard Stallman passando a exigir o uso do termo "GNU/Linux" (que é
pronunciado como "guí-nuu issléchi Linux") para designar o sistema, em vez
de simplesmente "Linux", argumentando que o projeto GNU foi iniciado
antes e que por isso merece crédito.
Este é um caso em que as opiniões se dividem, com alguns dando razão à ele
e realmente usando o "guí-nuu issléchi Linux" (ou "guínû barra Linux", que é
a versão aportuguesada), e outros argumentando que os componentes do
projeto GNU correspondem a apenas uma pequena parte do sistema e que por
isso se fosse para dar o crédito devido a todos os inúmeros componentes que
formam uma distribuição atual, seria preciso chamar o sistema de
X/Qt/KDE/GTK/GNOME/Mozilla/Firefox/OpenOffice/...longa-
lista.../GNU/Linux.
O fato é que, excluindo qualquer discussão filosófica, o nome "Linux" puro e
simples é muito mais fácil de pronunciar, o que faz com que o "GNU/Linux"
não seja usado fora de alguns círculos específicos.
Continuando a história, embora o Linux tenha sido originalmente
desenvolvido para ser usado em micros PC (mais especificamente no 386 que
Linus Torvalds usava em 1991), a modularidade do sistema, o fato de ele ter
sido escrito inteiramente em C e as boas práticas empregadas no
desenvolvimento permitiram que ele ganhasse versões (ou ports) para outras
plataformas. Hoje em dia, o Linux roda em praticamente todo o tipo de
sistemas: de PCs domésticos equipados com chips de 32 ou 64 bits, a
equipamentos especializados, usados em maquinário industrial.
Existe até mesmo um fork do kernel Linux que é capaz de rodar em
processadores 8088 e 286 (o ELKS), como os usados nos primeiros micros
PC. Embora estejam obsoletos nos PCs a mais de duas décadas, versões
modernizadas desses chips são relativamente populares em sistemas
embarcados, concorrendo com chips Z80 e outros processadores de 8 ou 16
bits, que, embora desconhecidos do grande publico, são produzidos e usados
em quantidades gigantescas nos mais diversos tipos de dispositivos. É
justamente essa versatilidade que faz com que o Linux seja usado em tantas
áreas diferentes, de celulares a supercomputadores.
Ao ver micros com Linux em exposição nas lojas e em mercados, tenha em
mente que esta é apenas a ponta do iceberg. O uso do Linux em micros
domésticos, pelo grande público, é uma coisa relativamente recente. Antes de
chegar aos desktops, o Linux cresceu entre os desenvolvedores e usuários
avançados, dominou os servidores, invadiu o mundo dos dispositivos
embarcados (celulares, roteadores, pontos de acesso wireless e até mesmo
modems ADSL) e se tornou o sistema dominante no mundo dos
supercomputadores.
Segundo o http://www.top500.org/ (que mantém um rank atualizado dos 500
supercomputadores mais poderosos do mundo), em novembro de 2008 nada
menos do que 439 dos 500 supercomputadores mais poderosos rodavam
diferentes versões do Linux (http://www.top500.org/stats/list/32/osfam). Dos
restantes, 25 rodavam outros sistemas Unix e apenas 5 rodavam Windows,
um deles com o HPC Server 2008 e quatro com o Windows Computer
Cluster Server 2003, duas versões do Windows especialmente otimizadas
para a tarefa.
 
Como baixar, gravar e dar boot
A forma mais popular de disponibilizar novas versões das distribuições é
através de arquivos ISO, cópias binárias do conteúdo dos CDs ou DVDs de
instalação, que você pode gravar usando o Nero, K3B ou outro programa de
gravação, obtendo um CD idêntico ao original.
Um dos sites mais conhecidos com notícias sobre os lançamentos de novas
versões e links para baixar até mesmo as distribuições menos conhecidas é o
http://distrowatch.com/, que além dos links e notícias, mantém um
abrangente banco de dados sobre as distribuições Linux ativas e também as
inativas ou descontinuadas. Outra opção é o http://www.gdhpress.com.br/cd/,
que abriga nossa pequena lista de distribuições recomendadas.
http://www.top500.org/
http://www.top500.org/stats/list/31/osfam
http://distrowatch.com/
http://www.gdhpress.com.br/cd/
Como pode imaginar, disponibilizar ISOs de distribuições Linux para
download exige muita banda, o que faz com que muitos desenvolvedores
incentivem o download dos arquivos via bittorrent. Apesar disso, existem
diversos mirrors públicos que oferecem as imagens para download direto, a
maioria deles situados em universidades ou empresas de hospedagem. Alguns
links de mirrors nacionais, onde você pode fazer um download rápido são:
Mandriva: http://mandriva.c3sl.ufpr.br/official/iso/
http://www.las.ic.unicamp.br/pub/mandriva/
Ubuntu: http://ubuntu.c3sl.ufpr.br/ 
http://www.las.ic.unicamp.br/pub/ubuntu-releases/
Fedora: http://fedora.c3sl.ufpr.br/
http://www.las.ic.unicamp.br/pub/fedora/linux/releases/
OpenSUSE: http://mirrors.uol.com.br/pub/suse/distribution/
Debian: http://debian.c3sl.ufpr.br/
Slackware: ftp://ftp.slackware-brasil.com.br/
Quase sempre, você tem a opção de baixar a versão "x86" (que corresponde à
versão tradicional, destinada a máquinas com processadores de 32 bits) e a
versão "x86-64", que é a versão compilada para tirar proveito das instruções
de 64 bits suportadas pelos processadores atuais.
De uma forma geral, as versões de 32 bits são menos problemáticas, pois
você pode simplesmente instalar qualquer aplicativo, biblioteca ou plugin
sem precisar se preocupar em procurar uma versão de 64 bits do pacote.
Mesmo que seu micro seja baseado em um processador Core 2 Duo, Athlon
X2 ou outro processador de 64 bits, o uso das versões de 64 bits do sistema é
inteiramente opcional, o que faz com que muitos prefiram simplesmente
continuar usando as versões de 32 bits.
Ao contrário doque muitos pensam, usar um sistema de 64 bits nem sempre
resulta em ganhos de desempenho. Pelo contrário, na maioria das vezes o
desempenho acaba sendo inferior, pois o pequeno ganho derivado do uso das
instruções de 64 bits e dos novos registradores acaba sendo negado pelo uso
de endereços de 64 bits (que consomem mais memória) e pela necessidade de
duplicar bibliotecas e outros componentes do sistema, o que é feito sempre
que é preciso rodar binários de 32 bits dentro de um chroot em uma
http://mandriva.c3sl.ufpr.br/
http://www.las.ic.unicamp.br/pub/mandriva/
http://ubuntu.c3sl.ufpr.br/
http://www.las.ic.unicamp.br/pub/ubuntu-releases/
http://fedora.c3sl.ufpr.br/
http://mirrors.uol.com.br/pub/suse/distribution/
http://debian.c3sl.ufpr.br/
ftp://ftp.slackware-brasil.com.br/
distribuição compilada para usar processadores de 64 bits.
A grande vantagem de utilizar um sistema de 64 bits não é necessariamente
o desempenho, mas sim o suporte a mais de 3 GB de memória RAM. Todos
os processadores de 32 bits possuem um limite "físico" de endereçamento,
que limita a memória RAM suportada a um máximo de 4 GB. Destes, 1 GB é
sacrificado para endereçamento dos dispositivos (veja mais detalhes no
capítulo 4 do livro Hardware, o Guia Definitivo), o que, na prática, restringe
o sistema a um máximo de 3 GB de memória RAM.
Com isso, a decisão entre usar uma distribuição de 32 bits ou de 64 bits se
resume à quantidade de memória RAM que você pretende utilizar. Se seu PC
tem até 3 GB de memória e você não quer esquentar a cabeça com problemas
e incompatibilidades, o mais fácil é simplesmente usar a versão de 32 bits.
Se, por outro lado, seu micro tem 4 GB ou mais de memória e você pretende
que toda a memória seja realmente utilizada, então sua única opção é usar a
versão de 64 bits.
Voltando ao básico, gravar um arquivo ISO é diferente de gravar um arquivo
qualquer no CD. Um arquivo ISO é uma imagem binária que deve ser
gravada bit a bit na mídia, e não simplesmente adicionado dentro de uma
nova seção.
Ao usar o K3B, por exemplo, clique no "Ferramentas > Queimar imagem de
CD" (ou "Ferramentas > Queimar imagem ISO de DVD"), aponte o arquivo,
escolha a velocidade de gravação e clique em "Gravar". Marque a opção
"Verificar dados gravados"; ela verifica a mídia depois de concluída a
gravação, avisando sobre erros de gravação:
Com o CD ou DVD gravado, falta apenas configurar o setup do micro para
dar boot através dele. A maioria dos micros vêm configurados para dar boot
preferencialmente através do CD-ROM. Nesse caso, basta deixar o CD na
bandeja e você já cai na tela de boas-vindas do sistema. Se não for o seu caso,
pressione a tecla DEL, F1 ou F2 (dependendo do fabricante) para acessar o
Setup. Procure pela seção "Boot" e coloque o CD-ROM como dispositivo
primário. Feito isso, é só salvar a configuração usando a opção "Save & Exit
setup".
Ao reiniciar o micro sem o CD no drive, ele volta a carregar o Windows ou
outro sistema que estiver instalado no HD. Esta alteração apenas faz com que
ele passe a procurar o sistema primeiro no CD-ROM.
Um hábito saudável é verificar a integridade do arquivo ISO antes de gravar
o CD. Sempre é possível que o arquivo esteja incompleto, ou venha
corrompido por problemas com a conexão ou no gerenciador de downloads
usado. Você pode detectar este tipo de problema (e evitar gastar mídias à toa)
verificando o MD5SUM do ISO antes de gravar. Ele é um teste que soma
todos os bits do arquivo e devolve uma "assinatura", um código de 32 dígitos
que permite detectar qualquer mudança no arquivo.
Os códigos de assinatura dos arquivos estão quase sempre disponíveis na
página de download, como em:
ed6a5b3feb668866df812b1c2aed9d7f openSUSE-11.0-DVD-i386.iso
Você precisa apenas rodar o MD5SUM no arquivo baixado e ver se o
resultado é igual ao número da página. No Linux (qualquer distribuição),
acesse a pasta onde o arquivo foi baixado e digite:
$ md5sum openSUSE-11.0-DVD-i386.iso
No Windows, baixe o programa disponível no
http://www.md5summer.org/download.html, que é uma versão gráfica do
utilitário.
Sempre que o arquivo estiver corrompido ou incompleto, o resultado do
MD5SUM é diferente, o que permite detectar o problema. O MD5SUM é
bastante sensível; a alteração de alguns poucos bits dentro do arquivo é
suficiente para alterar completamente o resultado.
Outra dica é que você pode reparar downloads corrompidos usando o
bittorrent de forma bastante simples. Procure o link para baixar o ISO via
bittorrent e salve-o na mesma pasta onde está o arquivo corrompido. Ao
iniciar o download, o cliente bittorrent detectará o arquivo e tentará continuar
o download. Como o bittorrent trabalha baixando os arquivos em pedaços e
verificando cada parte de forma independente, ele será capaz de reparar o
arquivo, baixando apenas as partes danificadas, evitando que você precise
baixar todo o arquivo novamente.
Caso ele crie uma pasta com um arquivo vazio, basta fechar o programa,
mover o arquivo ISO para dentro da pasta (substituindo o arquivo vazio) e
começar de novo.
Concluindo, embora os CDs e DVDs ainda sejam as mídias de instalação
preferidas pela maioria, eles estão gradualmente perdendo espaço para os
pendrives, que acabam sendo mais práticos em muitas situações, sobretudo
no caso dos netbooks, que abandonam o uso do drive óptico em favor da
portabilidade.
Muitas distribuições, incluindo o Ubuntu e o Fedora, já oferecem utilitários
gráficos que permitem gerar um pendrive bootável (no Ubuntu, por exemplo,
você usaria o "Sistema > Administração > Create a USB startup disk") e, para
as demais, está disponível o UNetbootin, um pequeno utilitário que permite
gerar um pendrive bootável a partir do arquivo ISO do CD:
http://www.md5summer.org/download.html
Ele possui versões para Linux e para Windows e está disponível no: 
http://unetbootin.sourceforge.net/
Ele ainda não é compatível com todas as distribuições, mas a lista está
crescendo rapidamente. Se você utiliza uma conexão de banda larga, existe
também a opção de usar uma das opções de instalação via rede, onde ele
copia apenas uma pequena imagem de boot para o pendrive e o resto do
sistema é baixado através da rede ao iniciar a instalação.
 
Rodando o Linux, sem sair do Windows
Se, assim como a maioria, você possui um único PC ou notebook, uma opção
para testar as distribuições Linux sem precisar mexer no particionamento do
HD e instalar o sistema em dual-boot, é simplesmente rodar o sistema dentro
de uma máquina virtual (VM), no próprio Windows.
Com isso, você ganha liberdade para testar o sistema, fuçar nas
configurações, instalar e remover programas e assim por diante, sem precisar
se preocupar em deixar seu PC fora de operação. Uma máquina virtual nada
mais é do que um conjunto de arquivos dentro de uma pasta do HD, de forma
que se algo dá errado, você só tem o trabalho de deletar a pasta e começar de
novo.
Naturalmente, você pode também fazer o contrário, ou seja, rodar uma
distribuição Linux como sistema primário e instalar o Windows dentro de
http://unetbootin.sourceforge.net/
uma máquina virtual para tê-lo a disposição sempre que precisar de algum
programa específico, como veremos ao longo do livro.
As possibilidades são quase ilimitadas. Você pode testar diversas
distribuições Linux; ter um sistema de backup para navegar e instalar
programas, sem o risco de danificar o sistema principal; instalar o Ubuntu,
Mandriva, OpenSuSE, Debian, Fedora ou outras distribuições sem precisar
mexer no particionamento do HD; e assim por diante. Usar uma VM é a
forma mais prática de ter Windows e Linux na mesma máquina, pois você
pode usar os dois sistemas lado a lado.
Existem vários softwares de virtualização gratuitos para Windows, incluindo
versões do VMware e do VirtualBox, mas, para começar, recomendo o
VMware Player, que é uma opção bastante prática e fácil de usar. Você pode
baixá-lo no http://vmware.com/download/player/ ou diretamente no:
http://www.vmware.com/download/player/download.html
As versões da série 2.x são relativamentegrandes (o 2.0.5 tem nada menos do
que 170 MB :o), mas se você usa o Windows XP, pode baixar a versão 1.0.8,
que oferece basicamente as mesmas funções e tem apenas 28 MB.
Embora seja proprietário, o VMware Player é um aplicativo gratuito, você
precisa apenas fazer um cadastro rápido para baixar. A instalação é feita na
forma usual, no modelo "next > next > finish". Com o VMware instalado, o
próximo passo é criar a máquina virtual. É aqui que entra a principal dica
deste tópico, já que o VMware Player não permite criar as VMs, mas apenas
http://vmware.com/download/player/
http://www.vmware.com/download/player/download.html
executar máquinas virtuais previamente criadas.
Para continuar, baixe o linux-vm aqui:
http://www.gdhpress.com.br/downloads/linux-vm.zip
Ele é uma máquina virtual previamente configurada, pronta para usar, que
funciona tanto em conjunto com o VMware Player for Windows, quanto na
versão Linux. O arquivo compactado tem apenas 7 KB, pois um máquina
virtual vazia é basicamente um conjunto de arquivos de configuração. O
espaço usado cresce conforme você instala softwares dentro dela; logo depois
de instalar o Ubuntu, por exemplo, a pasta estará com cerca de 2.8 GB.
Comece descompactando a pasta em um diretório qualquer. Abra o VMware
Player e indique o arquivo "linux.vmx", dentro da pasta. Inicialmente, a
máquina virtual estará vazia, por isso o VMware ficará tentando dar boot via
rede, depois de esgotar as outras possibilidades. Na verdade, esse é o
comportamento esperado, que mostra que tudo está funcionando:
O boot da VM é idêntico a um boot normal do PC, com a exceção de que
tudo é feito dentro de uma janela. A máquina virtual é justamente um
ambiente simulado, onde o sistema operacional guest (convidado) roda.
Dentro da pasta, você encontra 4 arquivos. O "c.vmdk" é o disco virtual, que
armazenará o sistema operacional e todos os programas instalados dentro da
VM. Inicialmente ele é um arquivo vazio, mas ele vai crescendo conforme o
uso. O seguinte é o arquivo "linux.nvram", que guarda as configurações do
setup (sim, por estranho que possa parecer, a máquina virtual tem BIOS, e
http://www.gdhpress.com.br/downloads/linux-vm.zip
você acessa o setup pressionando a tecla F2 durante o boot).
O "linux.vmx" é o arquivo de configuração da máquina virtual, um arquivo
de texto, que você pode abrir (e até alterar) usando o notepad, e o "cd.iso" é
outro arquivo vazio, que representa o CD-ROM virtual:
Assim como em um PC de verdade, para usar a VM precisamos carregar
algum sistema operacional. A primeira opção é simplesmente deixar um CD
ou DVD gravado no drive. Ao abrir a VM, o VMware Player detecta a mídia
e inicia o boot automaticamente. A segunda é usar um arquivo ISO em vez do
CD gravado. Esta opção torna o boot bem mais rápido, pois o sistema é
carregado a partir de um arquivo no HD, ao invés do CD-ROM. Nesse caso,
substitua o arquivo "cd.iso" dentro da pasta com a máquina virtual pelo
arquivo ISO da distribuição desejada, deletando o arquivo "cd.iso" original e
renomeando o novo arquivo.
O default das versões 2.x do VMware Player é sempre restaurar o status
anterior da VM, o que vai lhe mandar de volta para a tela de boot via rede,
onde ela estava antes de ser fechada. Use a opção "VMware Player >
Troubleshoot > Reset" para realmente reiniciar a VM e dar boot através do
CD. A partir daí, você dar boot e usar o sistema da forma normal:
O padrão na maioria das distribuições é configurar o vídeo a 800x600 dentro
do VMware, mas você pode alterar a resolução da forma normal, usando uma
opção de boot ou o configurador dentro do sistema. No caso do Ubuntu, por
exemplo, a opção está no "Sistema > Preferências > Resolução de Tela".
Inicialmente, o VMware roda em uma janela, o que é uma forma prática de
usar os dois sistemas simultaneamente. Você pode simplesmente configurar a
VM para utilizar uma resolução de vídeo um pouco inferior à do seu monitor
e usar o sistema como se fosse outro aplicativo qualquer. Outra opção é usar
a VM em tela cheia, usando o botão de maximizar a janela. Nesse caso, você
usa "Ctrl+Alt" para chavear entre os dois sistemas.
Um inconveniente de usar o VMware Player em tela cheia é que você não
tem como desabilitar o menu de funções que é exibido na parte superior da
tela. Isso é um problema no caso do Ubuntu e outras distribuições com o
GNOME, já que ela cobre a barra de tarefas, que é também exibida na parte
superior. A solução é mover a barra para a parte inferior, clicando com o
botão direto sobre uma área livre e acessando o "Propriedades":
Outra configuração importante é a quantidade de memória RAM reservada
para a máquina virtual. Por padrão, ela vem configurada para usar apenas 256
MB (o que é pouco para rodar a maioria das distribuições atuais), mas você
pode alterar o valor clicando no "VMware Player > Troubleshot > Change
Memory Allocation":
O próprio VMware Player recomenda um valor, de acordo com o total de
memória disponível, mas uma recomendação geral é que você reserve 256
MB em micros com 512 de memória ou de 384 a 512 MB (de acordo com a
distribuição que pretender rodar dentro da VM) em micros com 1 GB:
Tecnicamente, é possível usar o VMware Player mesmo em micros com
apenas 256 MB de RAM, mas isso não é muito recomendável, pois com tão
pouca memória, tudo ficará bastante lento.
Continuando, existem duas formas de configurar a rede e acessar a internet de
dentro da máquina virtual. A mais simples (e usada por padrão na VM pré-
configurada) é o modo "NAT", onde o VMware Player cria uma rede virtual
entre o sistema principal e a máquina virtual, permitindo que ela acesse a
internet usando a conexão do sistema principal. Nesse modo, a máquina
virtual recebe um endereço interno, atribuído automaticamente, como
"192.168.150.129". Você só precisa deixar que o sistema configure a rede via
DHCP. Além de acessar a web, o sistema dentro da VM pode acessar outras
máquinas na rede local, mas não pode ser acessado diretamente por elas.
A segunda opção é o modo "Bridged", onde a máquina virtual ganha acesso
direto à rede local, exatamente como se fosse outro micro. Neste caso, você
precisa configurar a rede manualmente (ou via DHCP), como se estivesse
configurando um novo micro. Este modo é muito bom para estudar sobre
redes, testar a configuração de servidores e assim por diante, pois você pode
rodar várias VMs simultaneamente e simular uma rede completa, mesmo
tendo apenas um micro.
Para usar o modo Bridged, clique sobre a setinha ao lado do botão da placa
de rede e mude a opção (é preciso reiniciar o VMware Player para que a
mudança entre em vigor). Depois de reiniciar, não esqueça de reconfigurar a
rede dentro da VM:
Instalar o sistema dentro da VM não difere em nada de uma instalação
normal. A VM pré-configurada usa um disco virtual de 20 GB, que você
pode particionar a gosto, inclusive com a possibilidade de criar várias
partições ou instalar dois ou mais sistemas em dual-boot.
Naturalmente, ao "formatar" o HD virtual e instalar o sistema, nenhuma
alteração é feita no seu HD. Tudo é feito dentro do arquivo "c.vmdk" na pasta
da máquina virtual. O VMware faz com que o sistema rodando dentro da VM
enxergue e particione este arquivo, achando que está manipulando um HD de
20 GB. Na verdade, é tudo simulado.
Se quiser fazer um backup do sistema instalado ou copiá-lo para outra
máquina, é só copiar a pasta (ela pode ser usada inclusive em máquinas
rodando a versão Linux do VMware Player). Você pode também tirar cópias
da pasta e assim criar várias VMs diferentes. Se o micro tiver memória RAM
suficiente, é possível inclusive rodar várias VMs simultaneamente, simulando
uma rede e trocando arquivos entre elas.
O VMware permite também que dispositivos USB sejam usados dentro da
máquina virtual, incluindo impressoras, scanners, smartphones, pendrives,
etc.
Ao plugar um pendrive, por exemplo, é criado um botão referente a ele na
barra do VMware. Ao clicar no botão, o pendrive é conectado à máquina
virtual, como se fosse um dispositivo local.Como você pode ver no
screenshot, ele foi detectado pelo Ubuntu dentro da VM, que pode ler e salvar
arquivos normalmente:
O VMware Player inclui também um "setup", que você acessa pressionando
"F2" logo depois de iniciar a máquina virtual. Através dele, você pode definir
a ordem de boot (HD, CD-ROM ou rede), acertar a hora da máquina virtual,
entre outras opções, assim como em um PC real.
Você pode dar um toque final instalando o vmware-tools, um pacote de
drivers que melhora o desempenho do sistema dentro da VM em diversas
tarefas e adiciona um recurso de ajuste dinâmico do vídeo, onde a resolução
do vídeo dentro da VM é ajustada automaticamente, permitindo que você
redimensione a janela livremente, usando até mesmo formatos fora do
convencional:
Você pode baixar o arquivo de instalação do VMware Tools for Linux no: 
http://www.gdhpress.com.br/downloads/vmware-tools.tar.gz
Antes de instalá-lo, é necessário que você instale os headers do kernel e os
compiladores básicos dentro da VM. O Ubuntu já vem com os headers e os
http://www.gdhpress.com.br/downloads/vmware-tools.tar.gz
compiladores podem ser instalados rapidamente usando o apt-get:
$ sudo apt-get update
$ sudo apt-get install build-essential
Ainda a partir do terminal, acesse a pasta com os arquivos (se você baixou
usando o Firefox, eles serão salvos por padrão dentro da pasta "Área de
Trabalho" no diretório home) e descompacte o arquivo, como em:
$ cd "Área de Trabalho"
$ tar -zxvf vmware-tools.tar.gz
Para instalar, acesse a pasta que será criada e rode o programa de instalação:
$ cd vmware-tools-distrib/
$ sudo ./vmware-install.pl
O instalador faz várias perguntas, confirmando os diretórios de instalação dos
componentes. Basta ir pressionando Enter para que ele instale tudo nos
diretórios default. No final, ele confirma a resolução que será usada por
default para o vídeo. Para que os drivers sejam carregados, é necessário
reiniciar o ambiente gráfico (ou simplesmente reiniciar o sistema dentro da
VM). Ele inclui também um configurador gráfico, que você pode abrir
usando o comando "sudo vmware-toolbox".
Em outras distribuições, os passos de instalação são os mesmos, com a
diferença de que você executa os comandos diretamente como root, em vez
de usar o sudo. O mais importante é ter instalados os headers e os
compiladores, que são necessários para a instalação.
Algumas distribuições, como o OpenSuSE, já trazem o vmware-tools pré-
instalado, dispensando a instalação manual. No caso delas, basta instalar o
sistema dentro da VM da forma normal.
Capítulo 1: Entendendo o Sistema
 
O fato de existirem tantas distribuições Linux e tantas versões diferentes do
sistema, permite que o Linux seja usado nas mais diversas áreas, de um PC
doméstico a um supercomputador. O grande problema é que com tanta
variedade, até mesmo os mais experientes acabam se sentindo perdidos, o que
dizer então dos novos usuários. Muitos acabam então se limitando a usar uma
única distribuição e a dominar seus recursos na medida do possível, enquanto
outros preferem simplesmente continuar no Windows, onde as coisas
parecem mais simples.
Vamos então a uma introdução (não tão introdutória assim) sobre as
distribuições Linux e os diferentes componentes que formam o sistema, para
depois nos aprofundarmos nas peculiaridades de cada uma.
 
A árvore genealógica das distribuições
No começo, instalar o Linux era uma tarefa ingrata. Tudo o que existia era o
código-fonte do kernel, que precisava ser compilado (usando o Minix ou
outro sistema operacional) e combinado com outros utilitários e bibliotecas
(que também precisavam ser compilados, um a um) para que você tivesse um
sistema operacional funcional. Isso explica por que nos primeiros meses,
após o célebre anúncio feito por Linus Torvalds em agosto de 1991, o Linux
tinha apenas algumas dezenas de usuários, a maior parte deles
programadores, que em maior ou menor grau participavam do
desenvolvimento do sistema.
Alguém chegou a uma conclusão óbvia: por que não distribuir versões já
compiladas do sistema, que pudessem ser instaladas diretamente? Surgiram
então as primeiras distribuições Linux, que rapidamente passaram a ganhar
novos adeptos.
Hoje em dia existem mais de 500 distribuições Linux, contando apenas as
ativas. Apesar disso, 98% delas são personalizações de outras distribuições já
existentes, de forma que, se você começar a estudar um pouco sobre a árvore
genealógica das distribuições, vai perceber que existem menos de 10
distribuições principais (Debian, Red Hat/Fedora, Mandriva, Ubuntu,
Slackware, Gentoo, etc.) das quais todas as outras são derivadas.
Por mais diferente que seja a aparência e a escolha de softwares pré-
instalados, as distribuições derivadas mantêm muitas das características da
distribuição-mãe, de forma que se você consegue aprender a trabalhar com as
distribuições principais, passa a não ter grandes problemas ao trabalhar com
qualquer uma das distribuições derivadas delas.
Esta é a grande proposta deste livro: permitir que você tenha uma visão
abrangente do sistema e consiga utilizar qualquer distribuição, migrando de
uma para outra sem muita dificuldade. Com isso, você pode ter uma
distribuição principal, com a qual tem mais afinidade e onde se sente mais em
casa, mas também ter um bom conhecimento sobre as outras, o suficiente
para conseguir fazer o que precisa. Vamos lá. :)
 
As primeiras distribuições Linux
A primeira distribuição de que se tem notícia é um par de disquetes,
chamados simplesmente de "Boot/Root", que foram desenvolvidos no final
de 1991 por HJ Lu (que até hoje participa do desenvolvimento do kernel).
Eles incluíam apenas o mínimo necessário para inicializar o sistema e rodar
algumas ferramentas básicas, em modo texto. Não era exatamente uma
"distribuição Linux" no sentido atual, mas foi um ponto de partida.
O "Boot/Root" foi sucedido por distribuições como o MCC Interim Linux
(lançado em fevereiro de 1992), o SLS Linux (maio de 1992) e o Yggdrasil
(novembro de 1992). Cada uma delas segue uma ideia bastante diferente.
O MCC era ainda uma distribuição em modo texto, mas que já oferecia um
conjunto mais completo de aplicativos e compiladores. O SLS era distribuído
na forma de um conjunto de arquivos .zip, que eram usados para gerar os
disquetes de instalação a partir do MS/DOS, enquanto o Yggdrasil foi uma
espécie de antecessor dos live-CDs: você dava boot através de um disquete e
o sistema rodava a partir de um CD-ROM, com direito a ambiente gráfico e a
opção de instalá-lo no HD usando um script em shell. O sistema era
extremamente lento (os PCs da época usavam CD-ROMs 1x ou 2x e tinham
apenas 4 ou 8 MB de memória), mas funcionava.
A distribuição mais antiga ainda ativa é o Slackware, lançado em julho de
1993. O Slackware é uma das distribuições mais espartanas, que tem como
objetivo preservar a tradição dos sistemas Unix, provendo um sistema
estável, organizado, mas com poucas ferramentas automatizadas, o que te
obriga a estudar e ir mais a fundo na estrutura do sistema para conseguir usar.
Muita gente usa o Slackware como ferramenta de aprendizado, encarando os
problemas e deficiências como um estímulo para aprender.
Temos aqui o famoso instalador em modo texto, que é usado por todas as
versões do Slackware. Ele é basicamente o mesmo desde as primeiras
versões, recebendo apenas algumas pequenas modificações de acordo com as
mudanças nos componentes incluídos no sistema:
Assim como quase todas as distribuições atuais, o Slackware começou como
um "remaster" de uma distribuição anterior (o SLS Linux), incluindo diversas
modificações e melhorias. Esta é, justamente, a característica mais marcante
do desenvolvimento do sistema. Novas distribuições raramente são criadas do
zero; quase sempre é usada uma distribuição já existente como base, o que
permite que os desenvolvedores se concentrem em adicionar novos recursos e
corrigir problemas, aumentando radicalmente a velocidade de
desenvolvimento de novos projetos.
 
A família Red Hat
Pouco depois, emnovembro de 1994, foi lançado o Red Hat, que foi
desenvolvido com o objetivo de facilitar a configuração e tornar o uso do
sistema mais transparente, permitindo que ele atingisse um público mais
abrangente. Apesar de sua alma comercial, todas as ferramentas
desenvolvidas pela equipe do Red Hat tinham seu código aberto, o que
possibilitou o surgimento de muitas outras distribuições derivadas dele,
incluindo o Mandrake (França), o Conectiva (Brasil) e o SuSE (Alemanha).
O Red Hat foi a primeira distribuição a usar um sistema de gerenciamento de
pacotes, onde cada programa incluído no sistema é transformado em um
pacote compactado, que pode ser instalado através de um único comando. O
sistema guarda as informações dos pacotes instalados, permitindo que você
possa removê-los completamente depois (sem deixar restos de bibliotecas e
chaves de registro, como no Windows).
A ideia surgiu da observação dos processos que envolvem a instalação de
aplicativos a partir do código-fonte, onde você usa os tradicionais comandos
"./configure", "make" e "make install". O primeiro comando analisa o sistema
e gera a configuração necessária para fazer a instalação; o segundo faz a
compilação propriamente dita, enquanto o terceiro finaliza a instalação,
copiando os executáveis, bibliotecas e arquivos de configuração para as
pastas correspondentes do sistema.
Ao agrupar todos os arquivos em um único pacote compactado e
descompactá-lo no diretório raiz do sistema, você tem justamente um sistema
rudimentar de pacotes. A partir daí, a ideia foi evoluindo até chegar a
ferramentas como o yum e o apt-get e repositórios gigantescos que temos
hoje em dia.
O uso do gerenciamento de pacotes é uma das diferenças mais visíveis entre
o Linux e o Windows: no Windows você clica no executável do programa e é
aberto um instalador, o que leva a inconsistências, já que cada aplicativo usa
um instalador próprio e cada um se comporta de uma maneira um pouco
diferente. No Linux por sua vez você usa o gerenciador de pacotes para
instalar os programas que quer usar, um sistema muito mais simples e limpo.
Aqui temos o venerável Red Hat 9, lançado em 2003:
A partir de 2003 a Red Hat mudou seu foco, concentrando seus esforços no
público empresarial, desenvolvendo o Red Hat Enterprise Linux (RHEL) e
vendendo pacotes com o sistema, suporte e atualizações. A consequência
mais marcante da decisão foi a descontinuidade do Red Hat Desktop, que era
até então a distribuição Linux com o maior número de usuários.
A última versão foi o Red Hat 9. A partir daí, passou a ser desenvolvido o
Fedora, combinando os esforços de parte da equipe da Red Hat e vários
voluntários que, com a maior abertura, passaram a contribuir com melhorias,
documentação e suporte comunitário nos fóruns. O Fedora herdou a maior
parte dos usuários do Red Hat Desktop, tornando-se rapidamente uma das
distribuições mais usadas.
Fedora Core 5, rodando o GNOME
Em seguida temos o Mandrake, que começou de uma forma modesta, como
uma versão modificada do Red Hat, lançada em julho de 1998, cuja principal
modificação foi a inclusão do KDE (ainda na versão 1.0). O KDE e o
GNOME são os dois ambientes gráficos mais usados no Linux, dividindo a
preferência dos usuários e das distribuições. Ambos rodam sobre o X, usando
os recursos oferecidos por ele. O X cuida do acesso à placa de vídeo, teclado,
mouse e outras funções básicas, enquanto o KDE ou GNOME cuidam da
interface que é mostrada a você.
Superando todas as expectativas, o Mandrake conquistou rapidamente um
grande número de usuários. A partir de um certo ponto, ele passou a ser
desenvolvido de forma independente, sempre com o foco na facilidade de
uso. Muita gente começou a usar Linux justamente com o Mandrake 10 e o
10.1:
Mandrake 10.1: o primeiro contato com o Linux para muitos
O Conectiva foi a primeira distribuição Linux nacional e por muito tempo foi
uma das mais usadas por aqui, atendendo tanto usuários domésticos, quanto
empresas. Em 2005 aconteceu a fusão entre o Mandrake e o Conectiva, que
deu origem ao Mandriva, uma evolução do Mandrake, que passou a ser
desenvolvido combinando os esforços das equipes de ambas as distribuições.
Apesar dos esforços, a Mandriva acabou fracassando em encontrar um
modelo de negócios sustentável, levando a problemas financeiros que
acabaram por praticamente paralisar o desenvolvimento do sistema, sem falar
nas constantes ameaças de falência, demissões ou insolvência, que criavam
um clima de insegurança. Um grupo de usuários e ex-funcionários da
Mandriva e da Conectiva, muitos eles brasileiros iniciaram um fork do
Mandriva, o Mageia, cuja primeira versão foi lançada em junho de 2011. O
Mageia acabou se tornando o legítimo sucessor do Mandriva, herdando a
maior parte dos usuários do sistema.
A história do SuSE é um pouco mais complicada. As primeiras versões
foram baseadas no SLS (assim como o Slackware). Em 1995 os scripts e
ferramentas foram migrados para o Jurix, que por sua vez era baseado no
Slackware. A partir da versão 5.0, lançada em 1998, o SuSE passou a utilizar
pacotes RPM, o formato do Red Hat, incorporando a partir daí cada vez mais
características e ferramentas derivadas dele. Todas estas ferramentas foram
integradas no Yast, um painel de controle central que facilita bastante a
administração do sistema.
Devido a todas estas mudanças, o SuSE é difícil de catalogar, mas atualmente
o sistema possui muito mais semelhanças com o Fedora e com o
Mandriva/Mageia do que com o Slackware; por isso é mais acertado colocá-
lo dentro da família Red Hat.
Em 2003 a SuSE foi adquirida pela Novell, dando origem ao SUSE Linux
Enterprise Desktop (uma solução comercial) e ao OpenSUSE, um projeto
comunitário, que usa uma estrutura organizacional inspirada no exemplo do
Fedora.
Ao contrário do Ubuntu e mesmo do Mageia, o OpenSUSE tem uma base de
usuários relativamente pequena aqui no Brasil. Parte disto se deve ao fato de,
no passado, o SuSE ter sido uma distribuição fortemente comercial. O
sistema não era disponibilizado para download e mesmo a compra das
caixinhas era complicada, já que não existia uma filial nacional. Só com a
abertura do sistema depois da compra pela Novel é que o OpenSUSE passou
a recuperar o terreno perdido.
OpenSUSE, rodando o KDE
 
O Debian
Finalmente, temos o Debian, que é provavelmente a maior distribuição Linux
não-comercial, tanto em volume de desenvolvedores quanto em número de
usuários, diretos e indiretos.
O primeiro anúncio público do Debian foi feito em agosto de 1993, mas a
primeira versão (chamada Buzz) foi finalizada apenas em 1996. A demora se
deu devido ao tempo necessário para desenvolver as ferramentas de
gerenciamento de pacotes, as ferramentas de atualização do sistema e de
manutenção dos repositórios e toda a metodologia de desenvolvimento que
continua até hoje.
O Debian utiliza um sistema de desenvolvimento contínuo, onde são
desenvolvidas simultaneamente 3 versões, chamadas de Stable (estável),
Testing (teste) e Unstable (instável). A versão estável é o release oficial, que
tem suporte e atualizações de segurança frequentes, o atual é o Squeeze (6.0),
lançado em fevereiro de 2011.
Antes dele vieram o Lenny (5.0), lançado em fevereiro de 2009, o Etch (4.0),
lançado em dezembro de 2006, o Sarge (3.1), lançado em junho de 2005 e o
Woody (3.0), lançado em julho de 2002. Atualmente, novas versões estáveis
do Debian são lançadas a cada 18 a 24 meses, sendo que a próxima, batizada
de Wheezy, está prevista para o início de 2013.
A versão instável do Debian (chamada Sid) é a mais peculiar. Ela é uma
eterna versão de testes, que não é finalizada nunca. Ela serve como um
campo de testes para novos programas e novas versões dos pacotes já
existentes, permitindo que os problemas sejam detectados e corrigidos. Ao
usar o Sid, você tem acesso às versões mais recentes de todos os pacotes,
mas, em compensação, não existe garantia de estabilidade. Um aplicativo ou
recurso que funciona perfeitamente hoje pode deixar de funcionar amanhã e
ser novamente corrigidona versão seguinte. Um erro em algum dos pacotes
base pode fazer com que o sistema deixe de inicializar depois de atualizado e
assim por diante.
As versões estáveis do Debian são tão estáveis justamente porque ficam
congeladas, recebendo apenas atualizações de segurança e correções de bugs.
Diz a teoria que, se você continuar corrigindo bugs em um aplicativo, sem
adicionar outros no processo, em um determinado momento você chegará a
uma versão livre de falhas.
O maior problema é que, devido ao longo intervalo entre os lançamentos das
versões estáveis, os pacotes acabam ficando defasados em relação a outras
distribuições, que utilizam um ciclo de releases mais curto. Para amenizar o
inconveniente, existe a opção de usar o Testing, que é uma prévia da próxima
versão estável. Como o Testing é uma versão "incompleta", que ainda está
em desenvolvimento, normalmente o utilizamos em conjunto com o
Unstable, de forma que pacotes que ainda não estejam disponíveis no
Testing, possam ser instalados a partir dele.
Tipicamente, os pacotes começam no Unstable, onde recebem uma primeira
rodada de testes e, depois de algumas semanas, são movidos para o Testing.
Periodicamente, os pacotes no Testing são congelados, dando origem a uma
nova versão estável. Além destes, existe o Experimental, usado como um
laboratório para a inclusão de novos pacotes.
 
Knoppix e os live-CDs
O Debian em si é bastante espartano em termos de ferramentas de
configuração e por isso é mais popular em servidores do que em desktops.
Entretanto, por oferecer um repositório de pacotes incrivelmente completo, o
Debian é usado como base para o desenvolvimento de inúmeras outras
distribuições, que combinam os pacotes dos repositórios do Debian com
personalizações, scripts e componentes adicionais, de forma a atingirem
nichos específicos.
Um exemplo de destaque é o Knoppix, cuja versão 3.0 (a primeira a ganhar
notoriedade) foi lançada em julho de 2002. O Knoppix acabou se tornando
um marco dentro da história do Linux por dois motivos. O primeiro é que ele
foi a primeira distribuição Linux live-CD realmente utilizável, oferecendo um
bom desempenho e um excelente script de autoconfiguração, que detectava o
hardware da máquina durante o boot, gerando os arquivos de configuração de
forma automática e entregando um sistema funcional no final do processo.
Distribuições live-CD anteriores, como o DemoLinux, eram muito mais
lentas, limitadas e impráticas de usar.
O segundo motivo, e talvez o mais importante, era a possibilidade de
remasterizar o CD, gerando uma distribuição personalizada. Graças a isso, o
Knoppix deu origem a um enorme número de novas distribuições, como o
Kanotix (que deu origem ao atual Sidux), o Morphix (que, devido à sua
arquitetura modular, ajudou a criar toda uma nova família de distribuições) e
o Kurumin, que desenvolvi de 2003 a 2008.
Um live-CD é, em poucas palavras, uma versão pré-instalada do sistema, que
utiliza um conjunto de truques para rodar diretamente a partir do CD-ROM.
Tradicionalmente, qualquer sistema operacional precisa ser instalado no HD
antes de ser usado. Você dá boot usando o CD ou DVD de instalação e é
aberto um instalador (que, por sua vez, roda sobre algum sistema
minimalista), que se encarrega de instalar e configurar o sistema principal.
Depois de algum tempo respondendo perguntas e vendo a barra de progresso
da cópia dos arquivos, você reinicia o micro e pode finalmente começar a
usar o sistema. Isso é válido tanto para o Windows quanto para a maior parte
das distribuições Linux.
Para quem já se acostumou com a ideia, pode parecer natural rodar o sistema
a partir do CD e até mesmo instalar novos pacotes sem precisar modificar as
informações salvas no HD, mas, em 2002, quando o Knoppix começou a
ganhar popularidade, a ideia de rodar uma distribuição Linux completa a
partir do CD-ROM era considerada exótica. Muitas pessoas só acreditavam
depois de desconectar o cabo flat do HD e ver que o sistema realmente dava
boot apenas com o CD-ROM. :o
Apesar de receberam críticas por parte de alguns puristas, os live-CDs
cresceram rapidamente em popularidade. O Ubuntu passou a ser um live-CD
instalável a partir da versão 6.06, o Mandriva aderiu à ideia com o Mandriva
Discovery (que foi sucedido pelo atual Mandriva One) e até mesmo o Fedora
ganhou uma versão live-CD, o Fedora Live, sem contar o gigantesco volume
de distribuições baseadas neles e do próprio Ubuntu, que é distribuído na
forma de um live-CD instalável. Apesar do início tímido, os live-CDs
dominaram o mundo.
A base de tudo é um módulo de kernel chamado SquashFS (nas primeiras
versões do Knoppix era usado o cloop, baseado no mesmo princípio), um
hack que permite que o sistema rode a partir de um sistema de arquivos
compactado, gravado no CD-ROM. Os dados são descompactados "on-the-
fly", conforme são necessários.
O uso da compressão oferece duas vantagens: permitir que o sistema fique
muito menor (colocando até 2 GB de dados em um CD-ROM de 700 MB) e
melhorar o desempenho do sistema, aumentando a taxa de transferência
efetiva do CD-ROM. 
A ideia é que um CD-ROM de 52x é capaz de ler a, em média, 5.8 MB/s,
pois como o CD gira sempre na mesma velocidade, as informações gravadas
nas trilhas da parte externa do CD (mais longas) são lidas a mais ou menos o
dobro da velocidade das do centro (que são mais curtas). Um CD-ROM de
52x lê a 7.8 MB/s nas trilhas externas mas a apenas 3.9 MB/s nas internas.
Como o CD-ROM é gravado a partir do centro, na maior parte do tempo ele
lê os dados a 5 ou 6 MB/s.
No entanto, ao ler 5 MB/s de dados compactados a uma razão de 3x, ele
estará lendo, na prática, a quase 15 MB/s, um valor muito mais próximo à
taxa de transferência oferecida por um HD. Naturalmente, ainda existem
outros problemas, como o tempo de busca (que é muito mais alto em um CD-
ROM), mas o problema principal é amenizado. Se não fosse o sistema de
compressão, os live-CDs seriam três vezes maiores e três vezes mais lentos
ao rodar a partir do CD, deficiências que os tornariam sistemas muito menos
atrativos.
Em contrapartida, a compressão faz com que o trabalho do processador passe
a ser maior, pois, além de processar os dados referentes aos aplicativos, ele
tem que, ao mesmo tempo, descompactar os dados lidos pelo CD-ROM. Por
isso, mais do que em distribuições instaladas, o desempenho aumenta de
acordo com o poder de processamento da máquina.
Voltando ao Knoppix, a primeira etapa do boot é uma tela de boas-vindas,
contendo uma linha de opções onde você pode fornecer parâmetros para o
boot. Logo depois é carregado o kernel, que por sua vez inicializa o
hardware, cria um ramdisk usando uma parte (pequena) da memória RAM,
onde são armazenados arquivos de configuração e outros dados que precisam
ser alterados durante o uso.
Depois disso, entra em ação o hwsetup, o programa de detecção que, junto
com um conjunto de outros scripts, se encarrega de detectar a placa de vídeo,
som, rede, modem e outros periféricos suportados, exibindo mensagens que
ajudam a identificar a configuração da máquina e saber de antemão detalhes
como o processador, quantidade de memória RAM e placa de vídeo instalada
(imagine o caso de um técnico que instala o sistema em vários micros
diferentes, por exemplo):
Mensagens de boot no Knoppix, mostrando detalhes sobre a máquina
Como comentei, as primeiras distribuições live-CD utilizavam um ramdisk
para armazenar arquivos de configuração, o diretório home e outros arquivos
do sistema que precisam ser alterados durante sua execução. Entretanto, a
maior parte dos arquivos do sistema eram acessados diretamente a partir do
CD-ROM, de forma que você não podia instalar novos programas, nem fazer
alterações em componentes do sistema enquanto ele estivesse rodando a
partir do CD, devido à limitação óbvia de que o CD-ROM é uma mídia
somente-leitura.
O solução para esta última barreira veio com o UnionFS, que passou a ser
usado em larga escala a partir de 2005. O UnionFS funciona de uma forma
bastante engenhosa; é uma daquelas ideiasaparentemente simples, que
resolvem problemas complexos.
O UnionFS permite juntar dois (ou mais) diretórios em um, estabelecendo
uma hierarquia entre eles. O "Union" vem justamente de "união". Temos
então o arquivo compactado do CD em um nível hierárquico mais baixo,
montado em modo somente-leitura e um ramdisk, que originalmente está
quase vazio, mas que vai armazenando todas as alterações. Os dois são
montados em uma única pasta, que contém o conteúdo do arquivo
compactado e do ramdisk.
Na hora de ler um arquivo, o sistema verifica se existe uma versão mais
recente armazenada no ramdisk, caso contrário lê no arquivo principal. Na
hora de gravar, as alterações são sempre armazenadas no ramdisk, de forma
automática e transparente.
No final, você acaba podendo instalar programas via apt-get e fazer qualquer
tipo de alteração no sistema, praticamente da mesma forma como faria se ele
estivesse instalado. Naturalmente, todas as alterações são salvas na memória
RAM, de maneira que, para realmente instalar um volume significativo de
novos pacotes ou manipular grandes arquivos, você precisa ter um PC com
pelo menos 1 GB de memória RAM. Em micros com pouca RAM você verá
uma mensagem de "disco cheio" (quando na verdade o que acabou foi o
espaço no ramdisk) ou até mesmo efeitos diversos por falta de memória
disponível.
O UnionFS (juntamente com o AUFS, que é seu sucessor) é usado por padrão
em quase todas as distribuições live-CD atuais, incluindo o Ubuntu Desktop.
Isso permite que você teste novos programas (ou até mesmo configure
servidores como o Samba e o Squid) com o sistema rodando a partir do CD-
ROM, sem qualquer alteração nos arquivos do HD. Isso permite uma
liberdade muito grande para fuçar e brincar com o sistema, já que, em caso de
problemas, basta reiniciar o micro e começar de novo.
 
O Ubuntu
Também derivado do Debian, o Ubuntu é provavelmente a distribuição Linux
mais usada atualmente. Ele é desenvolvido pela Ubuntu Foundation, uma
organização sem fins lucrativos, que por sua vez é patrocinada pela Canonical
Inc., que ganha dinheiro vendendo suporte, treinamentos e customizações do
Ubuntu. Esta combinação de ONG e empresa tem dado muito certo,
combinando os esforços de um sem-número de voluntários e um grupo de
desenvolvedores bem pagos que trabalham em tempo integral no
desenvolvimento do sistema.
Ao invés do tradicional 1.0, 2.0, 3.0, etc., o Ubuntu usa um sistema de
numeração das versões bastante incomum. Os releases são numerados com
base no mês e ano em que são lançados e recebem um codinome. A primeira
versão oficial foi o Ubuntu 4.10 (lançado em outubro de 2004), apelidado de
"Warty Warthog", seguido pelo 5.04 (lançado em abril de 2005), apelidado
de "Hoary Hedgehog" e pelo 5.10 (outubro de 2005), batizado de "Breezy
Badger".
Os próximos foram o 6.06 LTS (Dapper Drake), 6.10 (Edgy Eft), 7.04
(Feisty Fawn), 7.10 (Gutsy Gibbon), 8.04 LTS (Hardy Heron), 8.10 (Intrepid
Ibex), 9.04 (Jaunty Jackalope), 9.10 (Karmic Koala), 10.04 LTS (Lucid
Lynx), 10.10 (Maverick Meerkat), 11.04 (Natty Narwhal), 11.10 (Oneiric
Ocelot) e 12.04 LTS (Precise Pangolin). Como pode ver, apesar de estranhos,
os nomes (pelo menos a partir do 6.06) utilizam letras sequenciais, o que
permite perceber rapidamente que o Precise é mais recente que o Oneiric, por
exemplo.
As versões regulares do Ubuntu recebem atualizações e correções durante um
período de 18 meses, de forma que você acaba sendo obrigado a atualizar o
sistema no máximo a cada três versões. Como uma opção para quem quer
mais estabilidade e deseja manter o sistema por mais tempo (sem precisar sair
correndo para atualizá-lo a cada 6 meses), existem as versões LTS (long term
support), que recebem atualizações por um período muito mais longo (3 anos
no caso das primeiras versões e 5 anos no caso dos servidores e das versões
desktop a partir do 12.04), permitindo que você instale o sistema uma vez e o
use por um longo tempo, recebendo todas as atualizações de segurança
necessárias e deixando para atualizar apenas quando sentir necessidade. Isso
torna as versões LTS do Ubuntu especialmente atrativas para o uso em
estações de trabalho e em empresas, bem como para quem quer simplesmente
um sistema Linux que possa ser usado sem muita dor de cabeça, sem
necessidade de atualizações e reinstalações constantes.
As versões LTS são montadas dentro de um controle de qualidade mais
estrito e passam por um período de testes mais longo, resultando em releases
muito mais estáveis. A primeira versão LTS foi o Ubuntu 6.06 (que recebeu
atualizações até junho de 2009), seguido pelo 8.04 (atualizado até abril de
2011) e o 10.04, que receberá atualizações até abril de 2013. A versão atual,
o 12.04 receberá atualizações até 2017.
Nas primeiras versões, o Ubuntu era fornecido em duas versões diferentes. O
"Live CD" (que rodava diretamente a partir do CD-ROM) e o "Install CD", a
versão principal, que era instalada através de um instalador em modo texto,
derivado do instalador do Debian Sarge:
A partir do 6.10 as duas versões foram unificadas. O sistema passou a ser um
Live-CD (chamado de "Desktop Edition"), que pode ser instalado
diretamente.
O maior problema com o Desktop Edition é que o boot do sistema através do
CD é um pouco demorado e ele fica muito lento em máquinas com menos de
512 MB de RAM. Para quem usa máquinas antigas, ou prefere instalar o
sistema diretamente, sem primeiro esperar o carregamento do desktop, está
disponível o "Alternate CD", que inclui os mesmos pacotes, mas é instalado
através do instalador em modo texto.
Apesar de ser distribuído em um único CD, o Ubuntu utiliza um repositório
bastante completo. Ao instalar o sistema, você tem um desktop pré-
configurado, contendo um conjunto básico de aplicativos, que você pode
personalizar instalando pacotes adicionais. Os repositórios do Ubuntu são
construídos a partir do repositório unstable do Debian, processo no qual os
pacotes recebem correções diversas e são recompilados, gerando o
repositório "Universe".
O Ubuntu deu origem a diversas distribuições, como o Kubuntu (baseado no
KDE), o Xubuntu (baseado no XFCE) e assim por diante, que compartilham
o mesmo repositório, mas são baseadas em conjuntos diferentes de pacotes.
Está disponível também o "Server Edition", uma versão destinada a
servidores, que é baseada no mesmo repositório, mas instala apenas os
componentes básicos do sistema, criando uma instalação enxuta, à qual você
pode adicionar apenas os serviços e os componentes desejados.
 
Juntando as peças
Em resumo, podemos classificar as distribuições Linux em três grandes
famílias: as derivadas do Red Hat, como o Fedora e o Mageia, as derivadas
do Debian, como o Ubuntu e o Kubuntu e as derivadas do Slackware, como o
Slax.
Apesar das diferenças estéticas, distribuições da mesma família são muito
similares na organização dos arquivos, gerenciamento de pacotes, localização
dos arquivos de configuração e assim por diante, de forma que é mais fácil
para alguém acostumado com o Debian migrar para o Ubuntu, que faz parte
da mesma família, do que migrar para o Fedora, por exemplo, que tem raízes
completamente diferentes.
Você pode ver uma tabela mais completa com as origens de cada distribuição
neste link do Distrowatch: http://distrowatch.com/dwres.php?
resource=independence
Como comentei na introdução, existem mais de 500 distribuições Linux
sendo desenvolvidas ativamente. Se incluirmos também as descontinuadas, o
número sobe para mais de 2.000. Basicamente, qualquer pessoa ou empresa
com tempo e conhecimentos suficientes pode desenvolver uma distribuição,
usando outra já existente como ponto de partida.
O enorme volume de distribuições é ao mesmo tempo o principal defeito e o
principal atrativo do Linux. Defeito no sentido de que a falta de um sistema
"padrão" (como no caso do Windows) gera confusão e retarda a adoção do
sistema em muitos nichos; e, atrativo, no sentido de que é justamente o
grande número de distribuições e o processo de seleção natural que ocorre
entre elas, que fazcom que o sistema evolua tão rapidamente e seja capaz de
se adaptar a ambientes tão diferentes.
 
Gentoo, BSD e Solaris
Você pode estar se perguntando em qual das famílias se encaixa o Gentoo,
http://distrowatch.com/dwres.php?resource=independence
que é outra distribuição bastante comentada. A resposta é que ele não se
encaixa em nenhuma. O Gentoo inaugurou uma nova linhagem, trazendo
uma abordagem diferente das demais distribuições para a questão da
instalação de pacotes e da própria instalação do sistema.
Tradicionalmente, novos programas são instalados através de pacotes pré-
compilados, que são, basicamente, arquivos compactados, contendo os
executáveis, bibliotecas e arquivos de configuração usados pelo programa.
Estes pacotes são gerenciados pelo apt-get, urpmi, yum ou outro gerenciador
de pacotes adotado pela distribuição em uso. Compilar programas a partir dos
fontes passa a ser então um último recurso para instalar programas recentes,
que ainda não possuem pacotes disponíveis. 
O Gentoo utiliza o Portage, um gerenciador de pacotes que segue a ideia dos
ports do FreeBSD, que é outro sistema Unix, similar ao Linux em diversos
aspectos. Os pacotes não contêm binários, mas sim o código-fonte do
programa, junto com um arquivo de configuração, contendo parâmetros que
são usados na compilação. Você pode ativar as otimizações que quiser, mas o
processo de compilação e instalação é automático. Você pode instalar todo o
KDE, por exemplo, com um "emerge kde". O Portage baixa os pacotes com
os fontes (de forma similar ao apt-get), compila e instala.
O ponto positivo desta abordagem é que você pode compilar todo o sistema
com otimizações para o processador usado na sua máquina. Isso resulta em
ganhos de 2 a 3% na maior parte dos casos, mas pode chegar a 30% em
alguns aplicativos específicos.
A parte ruim, é que compilar grandes pacotes demora um bocado, mesmo em
máquinas atuais. Instalar um sistema completo, com o X, o KDE e o
OpenOffice, demora uma tarde em um Core i5 e pode tomar um final de
semana em uma máquina mais antiga. Você pode usar o Portage também para
atualizar todo sistema, usando os comandos "emerge sync && emerge -u
world" de forma similar ao "apt-get upgrade" do Debian.
Nas versões atuais do Gentoo, você pode escolher entre diferentes modos de
instalação. No stage 1 tudo é compilado a partir dos fontes, incluindo o kernel
e as bibliotecas básicas. No stage 2 é instalado um sistema base pré-
compilado e apenas os aplicativos são compilados. No stage 3 o sistema
inteiro é instalado a partir de pacotes pré-compilados, de forma similar a
outras distribuições. A única exceção fica por conta do kernel, que sempre
precisa ser compilado localmente, mesmo ao usar o stage 2 ou 3. Entre eles, o
stage 1 é naturalmente a instalação mais demorada, mas é onde você pode
ativar otimizações para todos os componentes do sistema.
Existe um conjunto crescente de distribuições baseadas no Gentoo, como
vários live-CDs, com games e versões modificadas do sistema, alguns
desenvolvidos pela equipe oficial, outros por colaboradores. Uma das
primeiras distribuições a utilizar o Gentoo como base foi o Vidalinux, mas
entre as derivações atuais a mais popular é o Sabayon
(www.sabayonlinux.org).
Embora seja uma das distribuições mais difíceis, cuja instalação envolve mais
trabalho manual, o Gentoo consegue ser popular entre os usuários avançados,
o que acabou por criar uma grande comunidade de colaboradores em torno do
projeto. Isto faz com que o Portage ofereça um conjunto muito grande de
pacotes, quase tantos quanto no apt-get do Debian, incluindo drivers para
placas nVidia e ATI (entre outros drivers proprietários) e exista uma grande
quantidade de documentação disponível, com destaque para o Gentoo-Wiki,
que inclui inúmeras dicas e receitas que podem ser úteis também em outras
distribuições, sobretudo ao tentar configurar algum periférico problemático:
http://www.gentoo-wiki.com
Concluindo, além do Linux, existem outros sistemas Unix open-source, entre
os quais se destacam o FreeBSD, o OpenBSD, o NetBSD e o OpenSolaris.
Embora o kernel e alguns dos utilitários básicos do sistema sejam diferentes,
os softwares usados (tais como o KDE, GNOME, OpenOffice e assim por
diante) são basicamente os mesmos, o que torna os sistemas muito similares.
Temos aqui, por exemplo, um screenshot do OpenSolaris, rodando o
GNOME:
http://www.sabayonlinux.org/
http://www.gentoo-wiki.com/
Parece Linux, mas na verdade é o OpenSolaris
Se fosse feito um teste cego com uma instalação do FreeBSD ou do
OpenSolaris, configurados com o GNOME e outros softwares, a maioria dos
usuários pensaria se tratar de apenas mais uma distribuição Linux. Um bom
exemplo é o PC-BSD (http://www.pcbsd.org), uma distribuição do FreeBSD
baseada no KDE, que tem como objetivo ser um sistema fácil de usar.
Por bizarro que possa parecer, é possível rodar o KDE e outros aplicativos até
mesmo sobre o Windows, substituindo a interface e os aplicativos padrão. É
o tipo de exercício que não tem muita utilidade prática, já que se a ideia é
usar o KDE, é muito mais fácil simplesmente baixar uma distribuição Linux
que já venha com ele pré-instalado, mas isso mostra até que ponto vai a
criatividade dos desenvolvedores. Outro movimento constante é o port de
aplicativos para o Windows, oferecendo opções open-source de aplicativos
para os que preferem o sistema da Microsoft.
 
A questão dos aplicativos
Por mais importante que seja, o sistema operacional é, na verdade, apenas um
palco que serve como base para os atores principais, que são os aplicativos.
Embora muito se discuta sobre as diferenças entre o Windows, o Mac OS X e
http://www.pcbsd.org/
o Linux, e as vantagens de cada um, no final das contas os argumentos mais
efetivos a favor ou contra uma determinada plataforma se concentram nos
aplicativos para ela. Sem aplicativos, o sistema operacional não passa de um
conjunto de drivers e bibliotecas, sem qualquer utilidade. Ninguém usaria o
Linux se não existissem bons programas disponíveis para ele.
A instalação de novos programas no Linux não é tão complicada quanto pode
parecer à primeira vista. Pelo contrário, muitas vezes é até mais simples que
no Windows, pois raramente você precisará perder tempo comprando e
registrando o programa, retirando banners de propaganda, desativando
spywares e coisas do gênero.
No Linux, temos uma predominância de aplicativos open-source, enquanto
no Windows temos uma predominância de programas proprietários. O fato de
um programa ter o código aberto não significa necessariamente que ele seja
gratuito, mas a grande maioria é. O único custo relacionado a usar o Gimp,
por exemplo, é o "custo" de baixar ou copiar o programa.
A princípio, pode parecer lógico que os programas proprietários tenham uma
qualidade melhor, já que eles são desenvolvidos por equipes de
programadores profissionais, que são pagos para trabalhar em tempo integral
no software. Mas, na realidade, não é bem assim.
De uma forma geral, programas proprietários tendem a ser melhores em
nichos e em áreas especializadas; um exemplo é o AutoCAD, que até hoje
não tem um concorrente aberto à altura. Isso acontece porque estes programas
de nicho são usados por uma fatia pequena dos usuários (o AutoCAD é usado
apenas por engenheiros e assim por diante), que acaba não sendo suficiente
para despertar o interesse de um grupo suficientemente grande de
desenvolvedores.
Por outro lado, para programas de uso geral temos um cenário oposto. A base
de usuários é muito grande e por isso os projetos prosperam, muitas vezes
superando os aplicativos comerciais em qualidade. Veja o caso do Firefox e
do Internet Explorer, por exemplo.
Outro ponto a favor dos aplicativos abertos é o reaproveitamento de código.
Um desenvolvedor pode começar do ponto onde um projeto anterior parou,
trabalhando diretamente nos recursos que deseja adicionar, ao invés de ter
que começar do zero. No mundo proprietário tudo é mais complicado,
envolvendo licenciamento de componentes e assim por diante.A grande
oferta de aplicativos abertos acaba sendo uma grande vantagem do Linux,
pois as distribuições já vêm com um grande número de programas pré-
instalados e você pode instalar outros sem custo.
No Windows, as coisas funcionam de maneira bem diferente: o sistema inclui
apenas alguns aplicativos básicos e, depois de instalá-lo, você precisa
adquirir softwares de terceiros para realizar tarefas mais elaboradas. A chance
de a próxima versão do Windows já vir com o Photoshop e o CorelDraw, por
exemplo, é muito remota.
Isso faz com que muitos usuários (possivelmente a maioria) acabem
recorrendo à pirataria, o que acaba gerando outros problemas. Mesmo
deixando todo o aspecto legal e moral de lado, baixar e instalar programas
piratas também tem seus desafios, já que é necessário procurar um crack,
remover vírus e trojans antes de instalar e assim por diante. No caso do
Linux, a instalação acaba sendo mais simples, já que você precisa apenas
abrir o gerenciador de pacotes e instalar o aplicativo desejado.
A grande dificuldade não está na instalação propriamente dita, mas sim na
dificuldade em encontrar softwares que substituam os que você utiliza no dia
a dia. Conforme você se familiariza com um sistema, você constrói uma base
mental de conhecimento, com aplicativos e soluções para problemas. Quando
você quer editar imagens você usa o aplicativo X, quando quer baixar um
arquivo via bittorrent usa o aplicativo Y, quando tem um problema com o
som você faz Z e assim por diante.
Quando você resolve mudar para outra plataforma, grande parte dessa
biblioteca mental é perdida, pois as dicas não se aplicam mais ao outro
sistema. Isso faz com que a mudança acabe sendo muito mais penosa do que
uma simples mudança de interface, já que você precisará substituir cada um
dos aplicativos que utilizava na outra plataforma e lidar com um conjunto
diferente de problemas. Isso não se aplica apenas ao migrar do Windows pra
o Linux (ou vice-versa), mas também, embora em menor grau, ao migrar de
uma distribuição Linux para outra.
Um bom indicativo disso é que, de uma forma geral, os usuários que
encontram menos dificuldades em migrar do Windows para o Linux são
justamente os mais iniciantes, que usam menos funções do sistema (muitas
vezes apenas o navegador e o player de mídia) e que, por isso, não encontram
dificuldades em substituí-los. No outro extremo, temos os usuários mais
tarimbados, que, por estranho que possa parecer, são justamente os que
encontram mais dificuldades, já que, por possuírem uma "biblioteca mental"
maior, acabam tendo que encontrar substitutos para um volume muito maior
de funções.
Nesse processo é importante mudar um pouco a mentalidade, não procurar
programas "iguais" aos usados no Windows, mas sim pensar nas tarefas que
você deseja realizar e procurar programas que ofereçam um conjunto de
recursos o mais próximo possível do que você precisa. O Office pode ser
substituído pelo OpenOffice, o Photoshop pelo Gimp, o Corel pelo Inkscape,
o IE pelo Firefox, o MSN pelo Pidgin ou pelo Kopete, o Outlook pelo
Evolution, o Media Player pelo Totem, VLC, Mplayer ou Kaffeine, o Nero
pelo K3B, o iTunes pelo Amarok e assim por diante.
É importante enfatizar que no mundo Linux também existem aplicativos
proprietários e aplicativos comercias. Alguns exemplos são o VMware, o
Acrobat Reader, o Cedega, o Skype e jogos como o Quake 4 e Doom 3, que
possuem versão Linux. Também é possível rodar muitos aplicativos
Windows através do Wine, mas na maioria dos casos com pequenas falhas ou
limitações diversas. Outra opção é usar uma máquina virtual, utilizando o
VirtualBox ou o VMware para rodar uma cópia completa do Windows,
instalando os aplicativos desejados sobre ela.
Muito se fala sobre o avanço dos sistemas de virtualização e dos aplicativos
web. Dois bons exemplos disso são os webmails, que eliminaram quase que
inteiramente o uso de leitores de e-mail dedicados, e o assustador crescimento
do uso de virtualização em servidores, com destaque para o Cloud
Computing (computação em nuvem).
Ele nada mais é do que a combinação de duas ideias antigas: o uso de clusters
(vários computadores interligados em rede, trabalhando como se fossem
apenas um) e o uso de virtualização, para que este "super-servidor" rode
várias máquinas virtuais, cada uma funcionando como se fosse um servidor
separado. Estes servidores virtuais armazenam as informações e fazem todo o
processamento, permitindo que os aplicativos rodem dentro do navegador,
como no caso do Gmail e tantos outros web-apps.
Estas duas tecnologias eventualmente eliminarão o problema das diferenças
entre plataformas, já que você poderá rodar qualquer software em qualquer
computador, dentro do navegador ou em uma máquina virtual. Entretanto,
esta é uma mudança que ainda pode demorar um pouco para ocorrer, de
maneira que os aplicativos locais continuam em voga. 
 
Pacotes e instaladores
Chegamos então à questão da instalação de programas, que é outro tema de
dúvidas. Para quem está chegando agora, a instalação de aplicativos no linux
pode parecer algo incompreensível, uma vez que existem muitos
procedimentos diferentes. De acordo com o aplicativo e a distribuição em
uso, o procedimento pode ser incrivelmente simples, como abrir um
gerenciador de programas e clicar no aplicativo desejado, ou incrivelmente
complicado, envolvendo o download de compiladores, edição de arquivos de
texto e comandos manuais. Vamos então a uma tentativa de colocar ordem na
casa.
No começo, existia o código-fonte. Você baixava um pacote .tar.gz, contendo
o código-fonte do programa, e a instalação consistia em compilar e instalar os
executáveis gerados na sua máquina. Esta forma de instalação faz sentido em
se tratando de aplicativos abertos, pois permite que você veja e até mesmo
adapte o código-fonte se necessário. Em muitos casos, é possível instalar o
programa em outro sistema operacional (a maior parte dos programas do
Linux podem ser instalados no BSD, com pequenas adaptações) ou até
mesmo em outras plataformas.
O problema é que instalar programas a partir dos fontes é demorado e nem
sempre simples, já que você precisa ter instalado uma grande quantidade de
compiladores e bibliotecas, necessários para compilar os mais diversos
programas. Existem incontáveis pequenas bibliotecas e ferramentas de
desenvolvimento por aí e não é muito viável tentar manter todas elas
instaladas.
Compilar significa transformar o código-fonte, escrito pelo programador, nos
arquivos binários que são executados pelo sistema. Ao compilar um
programa, são gerados vários executáveis, bibliotecas e arquivos de
configuração, que são copiados para pastas específicas do sistema. Os
executáveis vão para a pasta "/usr/bin", as bibliotecas para a "/usr/lib", os
arquivos de configuração para a "/etc" e assim por diante.
Alguém chegou, então, a uma conclusão óbvia: ao invés de cada um ter o
trabalho de compilar o programa na sua própria máquina, seria mais simples
se alguém compilasse e distribuísse um arquivo pronto, com os componentes
já compilados, em um formato simples de instalar. Nasceram, então, os
pacotes pré-compilados.
Os pacotes surgiram a partir de uma ideia muito simples. Você cria um
arquivo compactado contendo a mesma estrutura de pastas e arquivos que
seria criada ao instalar o programa manualmente. Ao instalar o pacote, os
arquivos são descompactados no diretório raiz, fazendo com que todos os
arquivos sejam colocados nos diretórios corretos. Ao desinstalar o pacote, os
arquivos são removidos, deixando o sistema como estava inicialmente, uma
forma rápida e limpa de instalar programas.
Existem basicamente três formatos de pacotes diferentes: os pacotes .deb,
usados pelas distribuições derivadas do Debian (incluindo o Ubuntu, o
Kubuntu e todas as inúmeras distribuições baseadas neles), os pacotes .rpm,
usados pelas distribuições derivadas do Red Hat (Fedora, Mageia e outros) e
os pacotes .tgz, usados pelo Slackware e derivados.
Não existe nada de fundamentalmente diferente entre os três formatos,e é
inclusive possível transformar um pacote .rpm em um pacote .deb, usando
utilitários como o alien. Entretanto, devido às diferenças que existem entre
uma distribuição e outra, não existe garantia de que um pacote do Fedora
funcionará no Debian, por exemplo. 
O próximo passo foi a criação dos gerenciadores de pacotes, programas que
permitem baixar e instalar novos programas de forma automática, verificando
as dependências e, caso necessário, baixando outros programas e bibliotecas
de que o programa inicial precisa.
O primeiro gerenciador que vem à mente é o apt-get, que é usado em um
número assustador de distribuições. Para instalar o "pidgin", por exemplo,
você precisaria apenas usar o:
# apt-get install pidgin
Existem ainda gerenciadores gráficos, como o Synaptic, que tornam a tarefa
ainda mais amigável. Além do apt-get, outros exemplos de gerenciadores são
o urpmi, usado no Mandriva, o yum, usado no Fedora e o zypper, usado no
OpenSUSE.
Você pode se perguntar por que não fazem como no Windows, onde cada
programa tem seu instalador. Na verdade, muitos programas são distribuídos
desta forma, como o Java, OpenOffice, Firefox, Thunderbird, VMware e
diversos games. Nestes casos, você simplesmente executa o arquivo e o
instalador se encarrega do resto da instalação.
O inconveniente é que estes pacotes são desenvolvidos para funcionarem em
qualquer distribuição, por isso incluem todo tipo de bibliotecas e módulos de
que o programa possa precisar, sem reaproveitar os componentes que você já
tem instalados. Isso faz com que os pacotes sejam práticos de instalar, mas,
em compensação, bem maiores (e mais pesados), assim como muitos dos
programas do Windows.
Outra dificuldade é que não existe no Linux uma biblioteca gráfica padrão,
que esteja disponível em qualquer distribuição. Ao usar um instalador gráfico
que utilize a biblioteca Qt (do KDE), por exemplo, usuários do Ubuntu e de
outras distribuições onde ela não vem pré-instalada precisarão instalar um
conjunto de pacotes adicionais antes de conseguirem abrir o instalador. Se
usar um instalador baseado na biblioteca GTK, os usuários de distribuições
baseadas no KDE (onde o GTK geralmente não vem pré-instalado) é que
terão dificuldades, e assim por diante.
Devido a isso, aplicativos comerciais como o VMware e também alguns
drivers (como os drivers 3D da nVidia) muitas vezes utilizam instaladores em
texto puro, de forma a poderem ser instalados sem dificuldades em qualquer
distribuição.
Naturalmente, existem exceções, como no caso dos jogos que utilizam o
instalador gráfico desenvolvido pela Loki, como o Quake 3, Unreal, Medal of
Honour e outros. Caso esteja curioso, você pode baixar os instaladores e
demos de muitos jogos portados no http://darkstar.ist.utl.pt/pub/games/:
http://darkstar.ist.utl.pt/pub/games/
Estes instaladores quase sempre usam a extensão ".sh" e são fáceis de
instalar, já que basta executar o arquivo no terminal para iniciar a instalação.
Ao baixar o arquivo, ele sempre virá com a permissão de execução
desmarcada, uma medida de segurança para prevenir acidentes com possíveis
arquivos infectados com vírus e trojans.
Apesar de parecer perda de tempo, esta é uma das medidas que mais
contribui para a segurança geral do sistema em um desktop, pois você não
corre o risco de executar um arquivo simplesmente por clicar por acidente em
um link no navegador ou no leitor de e-mails: precisa realmente salvá-lo no
HD, marcar a permissão de execução e finalmente executá-lo. Um vírus que
se propagasse via e-mail encontraria um terreno muito menos fértil no Linux.
Para ativar a permissão de execução, use o comando "chmod +x", como em:
# chmod +x mohaa-lnx-1.11.run
Muitos instaladores podem ser executados diretamente com seu login de
usuário, desde que você instale o programa em uma pasta dentro do seu
diretório home. Outros realmente precisam ser executados como root. Você
pode executar o programa diretamente pelo gerenciador de arquivos, clicando
sobre ele, ou pelo terminal, usando o "./", como em "./mohaa-lnx-1.11.run".
Em resumo, podemos dizer que existem três formas de instalar programas no
Linux:
1- Usar o apt-get ou outro gerenciador para instalar pacotes próprios da
distribuição em uso. Esta é a forma mais simples e menos passível de
problemas, que você deve usar sempre que possível.
2- Programas com instaladores próprios, destinados a funcionar em
várias distribuições. Eles também são simples de instalar, mas não tão
simples quanto usar o apt-get. Muitos aplicativos proprietários são
distribuídos apenas desta forma, como o VMware.
3- Instalar o programa a partir do código-fonte, o que pode ser
necessário no caso de aplicativos pouco comuns, que não estejam
disponíveis de outra forma, e também no caso de muitos drivers, onde é
necessário gerar um módulo personalizado para o kernel em uso.
 
Entendendo o sistema
Os primeiros sistemas Unix foram desenvolvidos na década de 1970, com o
objetivo de serem robustos, simples e utilizarem pouca memória, de forma a
rodarem com um bom desempenho nos computadores limitados da época. O
grande objetivo era reduzir o uso de memória e aproveitar ao máximo os
recursos da máquina, e não a facilidade de uso.
Na época, o simples fato de ter um sistema operacional, por mais complicado
que fosse, já era um enorme avanço sobre os primeiros computadores, onde
os programas eram escritos com papel e lápis e depois gravados em cartões
perfurados, para só então poderem ser executados.
O Linux conserva muitas das características dos sistemas Unix originais. Para
quem vem do Windows, a organização das pastas, a instalação de novos
programas e o uso dos arquivos de configuração parece algo esotérico, mas
no fundo as coisas não são tão complicadas assim. Vamos então a um resumo
dos componentes que compõem o sistema:
 
O kernel
Hoje em dia, quando falamos em "Linux", estamos normalmente nos
referindo à plataforma como um todo, incluindo as diferentes distribuições e
softwares. Mas, no início, o Linux era apenas o kernel desenvolvido pelo
Linus Torvalds.
Mesmo hoje em dia, alguns puristas ainda insistem na ideia de que o "Linux"
é apenas o kernel e todos os outros componentes são softwares que rodam
sobre ele. O principal argumento a favor dessa ideia é que outros sistemas
Unix, como o FreeBSD e o OpenSolaris, são baseados em outros kernels (e
são por isso considerados sistemas diferentes) mas, apesar disso, rodam o X,
KDE, Firefox e outros softwares, assim como no caso das distribuições
Linux. De qualquer forma, a ideia de usar o termo Linux para a plataforma
como um todo é bem mais simples e natural, por isso adoto esta terminologia
no livro.
O kernel é a peça fundamental do sistema, responsável por prover a infra-
estrutura básica necessária para que os programas funcionem, além de ser o
responsável por dar suporte aos mais diferentes periféricos: placas de rede,
som e o que mais você tiver espetado no micro.
Essa é justamente uma das principais diferenças entre o Windows e as
distribuições Linux. No Windows, o sistema inclui um conjunto
relativamente pequeno de drivers e você depende dos CDs de instalação e dos
drivers disponibilizados pelos fabricantes. No Linux, quase todos os drivers
disponíveis são incorporados diretamente no kernel e já vêm pré-instalados
nas distribuições. Isso faz com que os periféricos suportados sejam
detectados automaticamente.
Isso faz com que a importância de usar uma distribuição atual seja muito
maior, já que uma distribuição antiga ou desatualizada incluirá não apenas
softwares antigos, mas também um conjunto desatualizado de drivers, que
farão com que muitos componentes do PC não sejam reconhecidos.
Começando do início, se você der uma olhada dentro da pasta "/boot" de
qualquer distribuição Linux, vai encontrar o executável do kernel no meio de
um pequeno conjunto de arquivos. Ele é o primeiro componente carregado
pelo gerenciador de boot durante a inicialização do sistema:
Você deve estar se perguntando por que o arquivo se chama "vmlinuz" e não
"vmlinux",como seria mais lógico. Na verdade, esta é uma longa história,
mas, em resumo, o "z" no nome é usado porque o arquivo do kernel é
guardado no HD na forma de um arquivo compactado.
Nas primeiras distribuições Linux, todos os drivers e outros componentes
eram compilados diretamente nesse arquivo principal, e você podia escolher
os componentes a ativar na hora de compilar o kernel. Se você habilitasse
tudo, não teria problemas com nenhum dispositivo suportado, tudo iria
funcionar facilmente, mas, por outro lado, você teria um kernel gigantesco,
que rodaria muito devagar no seu 486 com 8 MB de RAM.
Se, por outro lado, você compilasse um kernel enxuto e esquecesse de
habilitar o suporte a algum recurso necessário, teria que recompilar tudo de
novo para ativá-lo. Como resultado disso, as distribuições passaram a incluir
diversas opções de kernel, compiladas com configurações diferentes. Você
tinha então que escolher qual usar, de acordo com os componentes do micro.
Este problema foi resolvido durante o desenvolvimento do kernel 2.0, através
do suporte a módulos. Os módulos são peças independentes que podem ser
ativadas ou desativadas com o sistema em uso. Do kernel 2.2 (lançado em
1999) em diante, quase tudo pode ser compilado como módulo, o que tornou
as coisas muito mais práticas e abriu as portas para os sistemas de detecção
automática de hardware que são usados nas distribuições atuais. 
Os módulos nada mais são do que arquivos, que são armazenados dentro da
pasta "/lib/modules/versão_do_kernel". Veja que os módulos ficam
organizados em pastas: a pasta "kernel/drivers/net/" contém drivers para
placas de rede, a pasta "kernel/drivers/usb/" agrupa os que dão suporte
dispositivos USB, e assim por diante:
Na maioria dos casos, os módulos possuem nomes que dão uma ideia do
dispositivo a que oferecem suporte. O "8139too.ko" dá suporte às placas de
rede com o chipset Realtek 8139, o "sis900.ko" dá suporte às placas SiS 900,
enquanto o "e100.ko" ativa as placas Intel E100, por exemplo. Se você fizer
uma pesquisa pelo nome de um módulo específico no Google, vai quase
sempre chegar à página do projeto ou a alguma página ou manual explicando
o que ele faz.
Para ativar o suporte a um certo dispositivo, você (ou o utilitário de detecção
incluído no sistema) precisa apenas carregar o módulo referente a ele. O resto
é feito pelo próprio kernel, que se encarrega de ativar o dispositivo e criar um
caminho de acesso para ele.
Cada vez mais, o trabalho de detecção e carregamento dos módulos passa a
ser feito de maneira automática pelas distribuições, através dos códigos de
identificação incluídos nos próprios dispositivos. Uma placa de rede com
chipset Realtek, por exemplo, retorna algo como "Ethernet controller: Realtek
Semiconductor Co., Ltd. RTL-8139/8139C/8139C+". Com base nesses
códigos, o sistema pode descobrir quais periféricos estão instalados e carregar
os módulos apropriados, de forma automática.
Você pode checar os códigos de identificação dos dispositivos instalados
usando os comandos "lspci" e "lsusb". Nos casos em que você precisa
carregar um módulo manualmente, é usado o comando "modprobe", seguido
do módulo desejado, como em:
# modprobe ndiswrapper
Para descarregar um módulo, é usado o "modprobe -r", como em:
# modprobe -r ndiswrapper
Você pode ver uma lista com todos os módulos disponíveis usando o
comando "modprobe -l". A lista é muito longa para caber na tela ou mesmo
no buffer do terminal, por isso é interessante adicionar um "| more", que
adiciona quebras de página na exibição. Basta ir pressionando a barra de
espaço para avançar:
# modprobe -l | more
Essa longa lista é mais uma curiosidade, mas os mais curiosos podem usá-la
para tentar entender mais sobre o suporte a hardware e os componentes do
sistema. A lista mostra a estrutura de pastas completa até os módulos, o que
ajuda a descobrir para que cada um serve. Ao ver o "/lib/modules/2.6.29-1-
686/kernel/drivers/net/wireless/ipw2200.ko" na lista, por exemplo, você pode
presumir que se trata do módulo que dá suporte a placas de rede wireless com
chipsets Intel IPW2200.
Algumas distribuições oferecem uma opção de carregar módulos adicionais
durante a instalação, atendendo justamente aos raros casos onde você precisa
de um determinado módulo para ativar a placa SCSI onde está instalado o
HD, por exemplo. 
Os módulos são gerados durante a compilação do kernel. Você não precisa se
preocupar com isso se não quiser, pois as distribuições quase sempre incluem
versões bem completas do kernel por padrão, mas, de qualquer forma, existe
sempre a possibilidade de recompilar o kernel, mexendo nas opções e
ativando ou desativando os módulos que quiser.
Na prática, a situação mais comum onde você precisa lidar com módulos é
quando precisa instalar manualmente algum driver modificado ou
proprietário, necessário para ativar algum dispositivo em particular.
Infelizmente, isso é ainda relativamente comum ao usar componentes recém
lançados, ou em algumas configurações problemáticas, como em alguns
notebooks com chipset SiS ou VIA.
Diferente dos drivers open-source, que são incluídos diretamente no kernel,
os drivers proprietários são distribuídos sob licenças mais restritivas, que
impedem sua inclusão direta. Os desenvolvedores do kernel são
especialmente cuidadosos com relação ao uso de componentes proprietários,
para evitar que o sistema se torne vulnerável a disputas na justiça.
Um bom exemplo de como esta atitude cautelosa é importante, é o caso da
SCO (http://en.wikipedia.org/wiki/SCO_v._IBM), que em 2003 entrou na
justiça contra a IBM, alegando que ela havia contribuído com trechos de
código de propriedade da SCO no kernel Linux e exigindo reparações. No
final, as acusações se provaram falsas e a SCO é que acabou sendo
condenada a pagar reparações (acabando por ir à falência), mas o caso foi um
alerta muito claro.
Em alguns casos, os drivers proprietários são de livre distribuição e (embora
não façam parte do kernel) podem ser incluídos diretamente nas distribuições.
Em outros, você mesmo precisará baixar e instalar o driver. É aqui que
entram os drivers para muitos softmodems, para algumas placas wireless e
também os drivers para placas 3D da nVidia e da ATI.
A psicologia para lidar com eles é a seguinte: instalar um destes drivers
envolve duas tarefas, baixar e instalar o módulo propriamente dito e criar um
"dispositivo" (device), um atalho que aponta para o endereço de hardware
usado por ele. Para facilitar esta tarefa, geralmente os drivers vêm com algum
tipo de instalador, geralmente um script simples de modo texto que cuida
disso para você.
Os módulos são parte integrante do kernel, por isso os módulos compilados
para uso em uma determinada distribuição não funcionam em outra, a menos
que, por uma grande coincidência, as duas utilizem exatamente a mesma
versão do kernel. Isso é bastante improvável, já que o kernel Linux é
atualizado quase que diariamente.
Se você usar uma distribuição popular, Ubuntu, Fedora, OpenSUSE, etc., é
possível que você encontre um driver pré-compilado para download (que
pode ser encontrado com a ajuda do bom e velho Google). Neste caso, você
só vai precisar instalar um pacote RPM ou executar um arquivo de instalação.
Em outras situações, você encontrará apenas um arquivo genérico ainda não
compilado, contendo um instalador que se encarrega de compilar um módulo
sob medida para o kernel em uso.
Como o script de compilação não tem como adivinhar qual distribuição ou
http://en.wikipedia.org/wiki/SCO_v._IBM
kernel você está utilizando, é necessário ter instalado os pacotes "kernel-
source" e "kernel-headers", que acompanham qualquer distribuição. No
Mandriva, por exemplo, você pode instalá-los usando os comandos:
# urpmi kernel-source 
# urpmi kernel-headers
Naturalmente, para conseguir compilar qualquer coisa, você precisará
também de um compilador (o gcc), que também acompanha as distribuições.
Se você tiver estas três coisas, vai conseguir instalar qualquer driver sem
maiores problemas, basta seguiras instruções na página de download ou no
arquivo INSTALL ou README dentro do pacote.
No Ubuntu, por exemplo, o gcc, juntamente com os utilitários básicos de
compilação, podem ser instalados através do pacote "build-essential" (nas
versões recentes os componentes já vêm pré-instalados). Ele é um meta-
pacote (um pacote que, quando instalado, dispara a instalação de vários
outros), que se encarrega de instalar um conjunto básico de compiladores e
bibliotecas.
 
Entendendo os diretórios
O primeiro choque para quem está chegando agora é a estrutura de diretórios
do Linux, que não lembra em nada o que temos no Windows. No Windows
temos os arquivos do sistema concentrados nas pastas "Windows" e
"Arquivos de programas", e você pode criar e organizar suas pastas da forma
que quiser.
No Linux, é basicamente o contrário. O diretório raiz está tomado pelas
pastas do sistema e espera-se que você armazene seus arquivos pessoais
dentro da sua pasta no diretório "/home". Naturalmente, é possível ajustar as
permissões de uma maneira que você possa salvar arquivos em outros locais,
mas isso nem sempre é uma boa ideia.
A primeira coisa com que você precisa se habituar, é que no Linux os discos
e partições não aparecem necessariamente como unidades diferentes, como o
C:\, D:\ e E:\ do Windows. Tudo faz parte de um único diretório, chamado
diretório raiz ou simplesmente "/".
Dentro deste diretório temos não apenas todos os arquivos e as partições de
disco, mas também o CD-ROM, drive de disquete e outros dispositivos,
formando a estrutura que você vê no gerenciador de arquivos:
O diretório "/bin" armazena os executáveis de alguns comandos básicos do
sistema, como o "su", "tar", "cat", "rm", "pwd", etc., um conjunto que na
maioria das distribuições ocupa de 6 a 8 MB, pouca coisa. O principal motivo
de eles ficarem separados dos outros executáveis do sistema (que vão dentro
da pasta /usr) é permitir que eles fiquem acessíveis desde o início do boot,
mesmo que você resolva armazenar a pasta /usr em uma partição separada (o
que é muito comum em servidores).
Ele é complementado pelo diretório "/sbin", que tem a mesma função básica,
mas se diferencia por armazenar aplicativos que podem ser usados apenas
pelo root, como, por exemplo, o "adduser", que permite criar novos usuários.
A maior parte dos aplicativos e outros componentes ficam instalados dentro
do diretório /usr (de "Unix System Resources", ou recursos de sistema Unix).
Este é de longe o diretório com mais arquivos em qualquer distribuição
Linux, pois é aqui que ficam os executáveis e bibliotecas de todos os
principais programas instalados:
A pasta "/usr/bin" (bin de binário), por exemplo, armazena cerca de 2.000
programas e atalhos para programas em uma instalação típica do sistema.
Como os executáveis de quase todos os programas instalados são
armazenados nela, o número só faz crescer conforme você instala novos
pacotes.
Outro diretório com um enorme volume de arquivos é o "/usr/lib", onde
ficam armazenadas as bibliotecas usadas pelos programas. A função destas
bibliotecas lembra um pouco a dos arquivos .dll no Windows. As bibliotecas
com extensão ".a" são bibliotecas estáticas, que fazem parte de um programa
específico, enquanto as terminadas em ".so.versão" (xxx.so.1, yyy.so.3, etc.)
são bibliotecas compartilhadas, usadas por vários programas. Elas são
gerenciadas de maneira automática pelo gerenciador de pacotes; quando uma
biblioteca é atualizada, por exemplo, são deixados links apontando para a
nova versão, o que permite que os aplicativos que utilizavam a versão antiga
continuem funcionando.
Outras pastas dignas de nota são a "/usr/local", que é reservada a programas e
scripts que você instalar manualmente; a "/usr/sbin", que é reservada a
executáveis que podem ser usados apenas pelo root (similar à pasta "/sbin") e
a "/usr/src", que é usada para armazenar o código-fonte de programas e
também o código-fonte do kernel (caso disponível). A pasta "/usr/X11R6" era
originalmente destinada a armazenar os componentes do X, responsável pelo
ambiente gráfico, mas ela está caindo em desuso.
Subindo de novo, a pasta "/boot" armazena o kernel e alguns arquivos usados
na fase inicial do boot, como comentei no tópico anterior. Além do kernel,
ela armazena também a configuração do gerenciador de boot, responsável
pelas opções mostradas na tela de boot e as opções de inicialização aplicadas
a cada uma. A configuração do grub, que é o gerenciador usado na maioria
das distribuições atuais, vai no arquivo "/boot/grub/menu.lst".
Logo a seguir temos o diretório "/dev", que é de longe o exemplo mais
exótico de estrutura de diretório no Linux. Todos os arquivos contidos aqui,
como, por exemplo, "/dev/sda", "/dev/dsp", "/dev/modem", etc., não são
arquivos armazenados no HD, mas sim ponteiros para dispositivos de
hardware. O "arquivo" "/dev/mouse" contém as informações enviadas pelo
mouse, enquanto o "/dev/dsp" permite acessar a placa de som, por exemplo.
Essa organização visa facilitar a vida dos programadores, que podem acessar
o hardware do micro simplesmente fazendo seus programas lerem e gravarem
em arquivos, deixando que o kernel se encarregue da parte complicada.
Ele é complementado pelo diretório "/proc", que não armazena arquivos, mas
sim informações sobre o hardware e sobre a configuração do sistema. Estas
informações são usadas por utilitários de detecção e configuração do sistema,
mas podem ser úteis também quando você quer checar alguma configuração
manualmente. O comando "cat /proc/net/dev" mostra informações sobre as
interfaces de rede, o "cat /proc/cpuinfo" mostra informações sobre o
processador e assim por diante.
O diretório /proc faz par com o "/sys", uma novidade introduzida a partir do
kernel 2.6, que agrupa informações sobre os dispositivos instalados,
incluindo o tipo, fabricante, capacidade, endereços usados e assim por diante.
Estas informações são geradas automaticamente pelo kernel e permitem que
os serviços responsáveis pela detecção de hardware façam seu trabalho,
configurando impressoras e criando ícones no desktop para acesso ao
pendrive, por exemplo.
O diretório "/etc" concentra os arquivos de configuração do sistema,
substituindo de certa forma o registro do Windows. A vantagem é que,
enquanto o registro é uma espécie de caixa preta, os scripts e arquivos de
configuração do diretório "/etc" são desenvolvidos justamente para facilitar a
edição manual. É bem verdade que na maioria dos casos isto não é
necessário, graças aos vários utilitários de configuração disponíveis, mas a
possibilidade continua existindo.
Os arquivos recebem o nome dos programas, seguidos geralmente da
extensão .conf. O arquivo de configuração do servidor DHCP (que pode ser
configurado para atribuir endereços IP aos outros micros da rede) é o
"/etc/dhcpd.conf", enquanto o do servidor FTP é o "/etc/proftpd.conf", por
exemplo. A boa notícia é que, ao contrário do registro do Windows, os
arquivos do "/etc" não se corrompem sozinhos e é fácil fazer cópias de
segurança caso necessário. Falarei mais sobre eles no capítulo sobre o
Slackware, onde o principal objetivo é justamente mostrar como configurar o
sistema manualmente.
Concluindo, o diretório "/mnt" (de "mount") recebe este nome justamente por
servir de ponto de montagem para o drive óptico ("/mnt/cdrom" ou
"/mnt/dvd") e outros dispositivos de armazenamento. Na maioria das
distribuições atuais ele é substituído pelo diretório "/media", que tem a
mesma função. Ao plugar um pendrive no Ubuntu, por exemplo, ele é
montado pelo sistema na pasta "/media/disk"; ao plugar um cartão de
memória, ele é visto como "/media/card" e assim por diante.
Na verdade, o uso do diretório "/media" ou "/mnt" é apenas uma convenção.
Você pode perfeitamente montar o seu pendrive dentro da pasta
"/home/fulano/pendrive", por exemplo, desde que faça a montagem de forma
manual. Os diretórios padrão de montagem das partições são configuráveis
através do "/etc/fstab", que é um dos arquivos básicos de configuração do
sistema.
 
Usandoo terminal
No início, todos os sistemas operacionais usavam interfaces de modo texto, já
que elas são uma forma simples de aceitar comandos e exibir os resultados,
mesmo em máquinas com poucos recursos. Antes do Windows, existiu o
DOS e, antes do KDE, GNOME e todas as outras interfaces que temos
atualmente; o Linux tinha também apenas uma interface de modo texto.
Mesmo com toda a evolução com relação às interfaces e aos utilitários de
configuração gráficos, o bom e velho terminal continua prestando bons
serviços.
O grande atrativo do terminal é que, com exceção de alguns poucos
aplicativos específicos, os comandos são sempre os mesmos. Isso faz com
que ele seja um porto seguro, com o qual você pode contar, sem importar se
você está no Ubuntu ou no Slackware. O terminal é também a forma mais
natural de "conversar" com o sistema, sempre que você precisa de qualquer
coisa além do arroz com feijão.
Por exemplo, imagine que você precisa mover todos os arquivos com
extensão .jpg de uma pasta com muitos arquivos para outra. Em vez de
precisar mover um por um, ou fazer algum malabarismo com a ordem de
exibição dos arquivos (para organizar a exibição com base na extensão dos
arquivos e poder assim selecionar todos os .jpg com o mouse), você poderia
simplesmente abrir o terminal e digitar:
$ mv *.jpg /outra-pasta
Além dos comandos básicos, dois outros recursos que tornam o terminal tão
poderoso são a possibilidade de combinar diferentes comandos para executar
tarefas mais complexas (ou filtrar os resultados para localizar informações
específicas) e a possibilidade de escrever pequenos programas em shell
script.
Por exemplo, para assistir vídeos no meu Nokia E71, preciso convertê-los
para um formato especial, suportado pelo RealPlayer, com o fluxo de vídeo
em MPEG4 e o áudio em AAC. No Windows, precisaria converter os vídeos
um a um, mas no Linux, posso usar um pequeno script para automatizar o
trabalho:
for video in *; do
ffmpeg -i "$video" -f mp4 -vcodec mpeg4 -b 350000 -r 15 -s 320x240 \
-acodec aac -ar 24000 -ab 128 -ac 2 "$video".mp4
done
Quando executado dentro de uma pasta com vários arquivos de vídeo, o
script simplesmente converte todos os arquivos, um a um, gerando os
arquivos .mp4 que posso então copiar para o smartphone. Com isso, preciso
apenas mover todos os vídeos que quero converter para uma pasta, executar o
script e deixar o micro trabalhando durante a noite, fazendo o trabalho
mecânico de conversão, em vez de precisar repetir os mesmos passos para
cada arquivo que quisesse converter.
Os scripts em shell podem ser usados para automatizar qualquer tipo de tarefa
que você precisa executar repetidamente, de atualizações do sistema a
backups. Essencialmente, tudo o que é possível fazer via linha de comando
(ou seja, praticamente tudo), pode ser automatizado através de um shell
script.
Se você chegou a usar o Kurumin 7, deve se lembrar do Clica-Aki, um painel
gráfico com várias funções, que era um dos grandes atrativos do sistema.
Apesar da complexidade, ele nada mais era do que um conjunto de shell
scripts, acionados através das opções e botões dentro da interface. Até mesmo
o instalador do sistema era inteiramente escrito em shell script:
Curiosamente, uma das grandes reivindicações de administradores Windows
sempre foi uma interface de linha de comando, que permitisse administrar o
sistema remotamente (sem a necessidade de usar a interface gráfica) e
automatizar tarefas diversas. Mesmo a contragosto, a Microsoft acabou sendo
obrigada a dar o braço a torcer e desenvolver o PowerShell, que nada mais é
do que uma interface de linha de comando para o Windows.
A grande diferença é que no Linux a interface de modo texto evoluiu junto
com o restante do sistema e se integrou de uma forma bastante consistente
com os aplicativos gráficos. Aprender a usar o modo texto é parecido com
aprender uma segunda língua: é um processo gradual e constante, no qual
você sempre está aprendendo comandos, parâmetros e truques novos. Quanto
mais você aprende, mais tempo você acaba passando no terminal; não por
masoquismo, mas porque ele é realmente mais prático para executar muitas
tarefas.
Um dos usos mais básicos para o terminal é simplesmente abrir aplicativos,
substituindo o uso do iniciar. Você pode chamar qualquer aplicativo gráfico a
partir do terminal: na maioria dos casos o comando é o próprio nome do
programa, como "konqueror" ou "firefox".
Durante o livro, você vai notar que, em muitos exemplos, ensino os passos
para executar tarefas através da linha de comando, pois os atalhos para abrir
os programas, itens nos menus, etc., podem mudar de lugar, mas os
comandos de texto são algo mais ou menos universal, mudam pouco mesmo
entre diferentes distribuições. Esta mesma abordagem é adotada de forma
geral dentro dos livros sobre Linux.
Por exemplo, para descompactar um arquivo com a extensão .tar.gz, pelo
terminal, você usaria o comando:
$ tar -zxvf arquivo.tar.gz
Aqui o "tar" é o comando e o "-zxvf" são parâmetros passados para ele. O tar
permite tanto compactar quanto descompactar arquivos e pode trabalhar com
muitos formatos de arquivos diferentes, por isso é necessário especificar que
ele deve descompactar o arquivo (-x) e que o arquivo está comprimido no
formato gzip (z). O "v" na verdade é opcional, ele ativa o modo verbose,
onde ele lista na tela os arquivos extraídos e para onde foram.
Se você tivesse em mãos um arquivo .tar.bz2 (que usa o bzip2, um formato
de compactação diferente do gzip), mudaria a primeira letra dos parâmetros,
que passaria a ser "j", indicando o formato, como em:
$ tar -jxvf arquivo.tar.bz2
Você poderia também descompactar o arquivo clicando com o botão direito
sobre ele em uma janela do Konqueror e usando a opção "Extrair > Extrair
aqui". Para quem escreve, é normalmente mais fácil e direto incluir o
comando de texto, mas você pode escolher a maneira mais prática na hora de
fazer.
Existem duas formas de usar o terminal. Você pode acessar um terminal
"puro" pressionando as teclas "Ctrl+Alt+F1", mudar entre os terminais
virtuais pressionando "Alt+F2", "Alt+F3", etc. e depois voltar ao modo
gráfico pressionando "Alt+F7" (em muitas distribuições a combinação pode
ser "Alt+F5" ou mesmo "Alt+F3", dependendo do número de terminais de
texto usados por padrão).
Estes terminais são às vezes necessários para manutenção do sistema, nos
casos em que o modo gráfico deixa de abrir; mas, no dia a dia não é prático
usá-los, pois sempre existe uma pequena demora ao mudar para o terminal de
texto e voltar para o ambiente gráfico. Outra limitação é que estes terminais
não permitem usar aplicativos gráficos.
Na maior parte do tempo, usamos a segunda opção, que é usar um "emulador
de terminal", um terminal gráfico que permite rodar tanto os aplicativos de
texto, quanto os gráficos. No KDE, procure o atalho para abrir o Konsole. Ele
possui várias opções de configuração (fontes, cores, múltiplas janelas, etc.).
No GNOME é usado o GNOME Terminal, que oferece recursos similares,
incluindo a possibilidade de abrir diversas abas, onde cada uma se comporta
como um terminal separado (similar às abas do Firefox). Se você preferir
uma alternativa mais simples, procure pelo Xterm.
Um pequeno complicador com relação ao uso do terminal, e também de
editores de texto de uma maneira geral, foi a recente mudança do ISO-8859-
15 (o bom a velho ASCII) para o UTF8 como padrão de codificação padrão
na maioria das distribuições.
Sempre que você executar scripts, ou acessar outras máquinas remotamente e
o terminal passar a exibir caracteres estranhos no lugar dos caracteres
acentuados, mude o padrão de codificação na configuração do terminal:
Na maioria dos casos, ao chamar um programa gráfico através do terminal,
você pode passar parâmetros para ele, fazendo com que ele abra diretamente
algum arquivo ou pasta. Para abrir o arquivo "/etc/fstab" no Kedit, por
exemplo, use:
$ kedit /etc/fstab
Para abrir o arquivo "imagem.png" no Gimp, use:
$ gimp imagem.png
Ao chamar algum aplicativo, oterminal ficará bloqueado até que o aplicativo
seja finalizado. Você pode evitar isso adicionando um "&" no final do
comando, o que faz com que ele seja executado em segundo plano, mantendo
o terminal livre.
Se você esquecer de acrescentar o "&" ao abrir um programa, ainda pode
"destravar" o terminal pressionando "Ctrl+Z" (que paralisa o programa e te
devolve o controle do terminal) e depois usar o comando "bg", que reinicia o
programa em background. Outra opção é simplesmente abrir outro terminal,
ou (se estiver usando o konsole ou o gnome-terminal), abrir outra aba. :)
Alguns aplicativos exibem mensagens diversas e avisos depois de serem
abertos, o que "suja" o terminal, mas sem comprometer o que você estiver
fazendo. Se isto te incomodar, você pode adicionar um "&>/dev/null" ao
comando, o que descarta todas as mensagens, como em "konqueror /etc &
&>/dev/null".
No começo, faz realmente pouco sentido ficar tentando lembrar do comando
para chamar um determinado aplicativo ao invés de simplesmente clicar de
uma vez no ícone do iniciar. Entretanto, depois de algum tempo você vai
perceber que muitas tarefas são realmente mais práticas de fazer via terminal.
É mais rápido digitar "kedit /etc/fstab" do que abrir o kedit pelo menu, clicar
no "Arquivo > Abrir" e ir até o arquivo usando o menu, por exemplo. É uma
questão de costume e gosto. O importante é que você veja o terminal como
mais uma opção, que pode ser utilizada quando conveniente, para melhorar
sua produtividade, e não simplesmente como algo arcaico ou ultrapassado,
como muitos pregam.
Vamos então a algumas dicas básicas:
Completando com a tecla tab: Um dos recursos que torna o terminal um
ambiente dinâmico é a possibilidade de completar comandos e nomes de
arquivos usando a tecla tab do teclado, o famoso autocompletar.
Além de facilitar o uso do terminal, reduzindo brutalmente o volume de
caracteres digitados, o autocompletar previne erros nos comandos (afinal,
você pode se enganar, mas o computador não) e evita que você precise
lembrar dos nomes exatos dos arquivos e dos comandos, já que você pode
digitar apenas as primeiras letras e pressionar a tecla tab. Por exemplo, em
vez de precisar digitar:
$ md5sum ubuntu-12.04-desktop-i386.iso
... você poderia digitar apenas md5<tab> ub<tab>, ou seja, apenas 8 toques,
incluindo o espaço.
Se, por acaso, houver outro comando começado com "md5" ou outro arquivo
na mesma pasta começado com "ub", então o autocompletar completará o
comando ou arquivo até o ponto em que as opções forem iguais.
Pressionando o tab pela segunda vez, ele exibe uma lista com as
possibilidades para que você termine de completar o comando.
Se tivesse os arquivos "ubuntu-12.04-desktop-i386" e "ubuntu-10.10-
desktop-i386.iso" na mesma pasta, por exemplo, ele completaria até o
"md5sum ubuntu-1." onde os nomes diferem, e deixaria que você
completasse o comando a partir daí.
Histórico: O terminal mantém um histórico dos últimos 500 comandos
digitados, o que também acaba sendo muito útil, já que é normal que você
repita comandos similares, mudando apenas o nome do arquivo ou outro
detalhe.
Para repetir um comando recente, simplesmente pressione as setas para cima
ou para baixo até encontrá-lo. Para fazer uma busca, use o comando "history |
grep comando", como em "history | grep cp" para mostrar todas as entradas
onde foi usado o comando "cp".
O "|" (ou "pipe", que pronunciamos como "páipi") é muito usado no shell,
pois permite combinar vários comandos, fazendo com que a saída de um seja
processada pelo outro. No comando anterior, por exemplo, o "history" gera
uma longa lista de todos os comandos anteriormente digitados, enquanto o "|
grep cp" faz com que o texto seja processado pelo grep, que deixa passar
apenas as linhas que incluem o "cp".
Colando com o terceiro botão: O botão central do mouse, que não tem
muita serventia no Windows, permite copiar e colar entre aplicativos ou até
mesmo entre aplicativos gráficos e terminais abertos dentro da interface
gráfica. Isso substitui o Ctrl+C, Ctrl+V, com a vantagem do comando ser
dado com um único clique do mouse. Basta selecionar o trecho de texto, a
imagem, ou o que quiser copiar e clicar com o botão central na janela onde
quiser colar a seleção. Se você não tiver um mouse de três botões (como no
caso de um notebook), pressione simultaneamente os dois botões para obter o
mesmo resultado.
Este recurso acaba sendo extremamente útil ao seguir tutoriais ou executar
listas de comandos, já que você pode selecionar o comando a executar no
navegador ou no editor de textos e colar diretamente no terminal, usando o
botão central.
Outra dica é que você pode usar o botão central para colar nomes de
arquivos, sempre que precisar usá-los em comandos. Use o "ls" para listar os
arquivos da pasta e, em seguida, use o mouse para selecionar e colar os
nomes, completando os comandos.
As limitações são que o botão central não funciona muito bem para copiar
grandes quantidades de texto, e o texto a ser copiado precisa ficar selecionado
durante a operação. Basicamente, você consegue copiar o que puder ser
visualizado na tela. Não funciona para copiar 120 páginas de texto do
Abiword para o OpenOffice, por exemplo.
Pensando nisso, os desenvolvedores do KDE e do GNOME se preocuparam
em incluir sistemas de copiar e colar com um funcionamento semelhante ao
do Windows. Você pode selecionar várias páginas de texto do Kword e colar
no Kmail, por exemplo, usando o bom e velho Ctrl+C, Ctrl+V. O KDE inclui
até um Applet, o Klipper, que multiplica a área de transferência. Você tem
vários slots que armazenam todas as últimas operações e pode colar qualquer
uma das anteriores, selecionando a desejada através do ícone ao lado do
relógio, de maneira bem prática.
Case Sensitive: Salvo poucas exceções, todos os comandos e parâmetros
dentro de arquivos de configuração são case-sensitive, ou seja, precisam ser
digitados literalmente, respeitando as maiúsculas e minúsculas.
Na maioria dos casos, tanto os comandos quanto os parâmetros suportados
por eles utilizam letras minúsculas, mas existem alguns casos de comandos
que suportam parâmetros com letras maiúsculas e minúsculas, com resultados
diferentes. O comando "ls -s", por exemplo, mostra o tamanho dos arquivos
na listagem, enquanto o "ls -S" mostra os arquivos organizados por tamanho
(o maior primeiro), por isso é sempre importante prestar atenção.
Man: Como comentei no início, ninguém pode dizer que sabe tudo sobre
todos os comandos do terminal. Para facilitar as coisas, cada comando possui
um manual, onde são citados todos os parâmetros e vários exemplos de uso.
Todos estes manuais são acessados através de um comando único, o "man".
Para ver as (muitas) opções do "ls", por exemplo, use "man ls". Use as setas
para rolar a tela e, para sair do manual, pressione a tecla "q".
O man acaba sendo um componente essencial para quem usa muito a linha de
comando, pois mesmo comandos simples, como o "ls", o "cat" e o "grep",
usados no dia a dia, possuem mais parâmetros do que é possível memorizar,
de forma que o man acaba servindo como um guia de consulta rápida.
Entretanto, devido à quantidade de parâmetros disponíveis, os manuais de
muitos programas são muito longos e complicados. Por isso, muitos suportam
o parâmetro "--help", que exibe uma ajuda resumida, contendo apenas os
parâmetros mais usados. Experimente, por exemplo, o "ls --help".
 
Comandos do prompt
Apesar da interface gráfica ser muito mais fácil de usar, é bom você ter pelo
menos uma boa noção de como as coisas funcionam pelo prompt de
comando. Isso vai lhe dar um domínio muito maior sobre o sistema.
Em vários pontos deste livro, sem falar de outros tipos de documentação
sobre Linux, você verá receitas com longas listas de comandos que devem ser
digitados para configurar ou alterar algo. Em muitos casos existe algum
utilitário gráfico que permite fazer o mesmo, mas os autores geralmente
preferem dar a receita de como fazer via linha de comando, pois nem todo
mundo terá os utilitários à mão emuitas vezes existem diferenças entre as
opções disponíveis nas diferentes distribuições. Vamos então a um guia
rápido dos comandos básicos do terminal, que iremos aprofundar ao longo do
livro:
Comandos básicos: Começando do básico, o comando "cd" permite navegar
entre os diretórios. Ao abrir o terminal, você começa dentro do seu diretório
home (como "/home/gdh") e pode acessar outros diretórios diretamente,
especificando-os no comando, como em "cd /etc" ou "cd /mnt/cdrom".
Para subir um diretório use "cd .." e, para voltar ao home, digite
simplesmente "cd", sem parâmetro algum. Sempre que quiser confirmar em
qual diretório está, use o comando "pwd". 
Em seguida temos o "ls", que serve para listar os arquivos dentro da pasta. Na
maioria das distribuições, a listagem aparece colorida, permitindo diferenciar
as pastas e os diferentes tipos de arquivos. As pastas aparecem em azul, os
links em azul claro, os arquivos compactados em vermelho, as imagens em
rosa, os executáveis em verde e os arquivos de texto e outros formatos em
preto (ou em branco, de acordo com o esquema de cores usado). 
Para incluir os arquivos ocultos (que no Linux começam com "."), use "ls -a".
Para ver mais detalhes sobre cada arquivo, incluindo o tamanho, permissões
de acesso e dono, use "ls -lh". Para incluir os ocultos, adicione o "a", como
em "ls -lha". A ordem dos parâmetros não altera o resultado do comando.
Tanto faz digitar "ls -lha" ou "ls -alh", você pode simplesmente decorar os
parâmetros na ordem que achar mais fácil de lembrar.
Para copiar arquivos de uma pasta para outra usamos o "cp", especificando o
nome do arquivo e a pasta para onde ele vai, como em "cp arquivo.zip
/mnt/sda1/". Se você quiser copiar um arquivo que está em outra pasta para o
diretório atual, inclua a localização completa do arquivo e em seguida o "./"
(que representa o diretório atual), como em "cp /mnt/cdrom/video.avi ./".
Você pode também usar o "*" como curinga para copiar vários arquivos. Para
copiar todos os arquivos da pasta atual para a pasta "/mnt/hda6", por
exemplo, use "cp * /mnt/hda6".
O "cp" é por padrão um comando bastante chato e difícil de entender, já que
por default ele omite pastas, altera a permissão dos arquivos e assim por
diante. Um parâmetro bastante útil é o "-a", que faz com que o cp sempre
copie recursivamente (ou seja, copie todos os arquivos e sub-pastas),
mantenha as permissões do arquivo original e preserve os links simbólicos
que encontrar pelo caminho. Em resumo, faz o cp se comportar de uma forma
mais simples e lógica. Para copiar uma pasta do CD-ROM para o diretório
atual, por exemplo, você poderia usar "cp -a /mnt/cdrom/musicas ./".
O cp faz par com o "mv", que serve tanto para mover quanto para renomear
arquivos. Para mover o arquivo foto.png para a pasta "/mnt/hda6/", o
comando seria "mv foto.png /mnt/hda6". Para renomear um arquivo, basta
especificar o nome original e o novo, como em "mv antigo.txt novo.txt".
Para criar diretórios, usamos o comando "mkdir", como em "mkdir arquivos"
(que cria a pasta arquivos no diretório atual) ou "mkdir /mnt/sda6/arquivos".
É possível também criar pastas recursivamente (criando todas as pastas
necessárias até chegar a que você pediu) adicionando o parâmetro "-p" como
em "mkdir -p /mnt/hda6/arquivos/novos/2009". Mesmo que a pasta
"arquivos" e a pasta "novos" não existam, elas serão criadas.
Em seguida temos o "rm", que serve tanto para remover arquivos quanto
diretórios, de acordo com os parâmetros usados. Para remover um arquivo
simples, basta usá-lo diretamente, como em "rm arquivo". Para que ele
remova sem pedir a confirmação, adicione o parâmetro "-f", como em "rm -f
arquivo". Para remover uma pasta e todos os arquivos e diretórios dentro
dela, adicione o parâmetro "-r", como em "rm -rf arquivos/".
Tome cuidado ao usar o "-rf", pois ele não pede confirmação, deleta os
arquivos diretamente, sem escalas. Respire fundo e verifique se realmente
está deletando a pasta certa antes de confirmar o comando.
É possível também usar caracteres curingas na hora de remover arquivos.
Para remover todos que possuírem a extensão ".jpg", use "rm -f *.jpg". Para
remover todos os arquivos que começarem com "img", use "rm -f img*".
Você pode usar também o "?" quando quiser usar o curinga para apenas um
caractere específico. Se você quiser remover os arquivos "doc1.txt",
"doc2.txt" e "doc3.txt", você poderia usar o comando "rm -f doc?.txt".
Temos também o comando "rmdir", uma variação do mkdir, que permite
remover diretórios. A diferença entre ele e o "rm -rf" é que o rmdir só remove
diretórios vazios. Acostume-se a usá-lo no lugar do "rm -rf" ao deletar uma
pasta que acha que está vazia, assim você evita acidentes.
Para verificar o espaço em disco disponível, use o "df". Ele mostra o espaço
disponível (assim como outras informações, incluindo a capacidade e o
diretório de montagem) de cada uma das partições do sistema, incluindo
pendrives e outros dispositivos de armazenamento que estejam montados. Ele
faz par com o "free", que permite checar rapidamente o uso da memória
RAM (ignore a primeira linha e veja diretamente a linha "-/+ buffers/cache",
que mostra o uso real, descartando o usado pelo cache de disco).
Outro comando útil é o "du", que permite ver uma lista com o espaço
ocupado por cada pasta dentro do diretório atual. Para facilitar, use sempre o
"du -h", que exibe o tamanho dos arquivos de forma amigável, escrevendo
"2,8G" ao invés de "2876322", por exemplo.
Você também pode executar uma fila de comandos de uma vez. Basta separá-
los por ponto e vírgula, como em "ls; pwd" ou "cd /mnt/arquivos; ls".
Localizando arquivos e comandos: Uma maneira rápida de localizar
arquivos é usar o comando "locate", que permite realizar buscas de forma
quase instantânea. Para procurar um arquivo, simplesmente use "locate
arquivo" (funciona também se você especificar apenas parte do nome, ou usar
o asterisco para encontrar arquivos de determinadas extensões).
O locate é muito rápido, pois executa a busca dentro de uma base de dados,
que é gerada ao rodar o comando "updatedb". A desvantagem dessa
abordagem é que você precisa rodar o updatedb (como root) de vez em
quando, a fim de incluir as últimas modificações.
Se você está procurando por um programa, experimente o comando "which",
uma variante do locate que mostra apenas executáveis.
Temos também o "find", que também permite localizar arquivos, mas
funciona da forma tradicional, realmente vasculhando os diretórios em busca
dos arquivos. Embora seja lento ao procurar em diretórios com muitos
arquivos e subdiretórios, o find é eficiente se você souber previamente onde
procurar. Por exemplo, o diretório "/etc" concentra as configurações do
sistema. Se você estiver procurando pelo arquivo "smb.conf" (onde é
armazenada a configuração do Samba), você poderia ir direto à fonte, usando
o comando "find /etc -name smb.conf".
Note que além do diretório onde ele vai procurar (/etc no exemplo), você
deve usar o parâmetro "-name" antes de indicar o nome do arquivo que está
procurando. Omitindo o diretório, ele simplesmente procura dentro do
diretório atual. Você pode também fazer buscas por todos os arquivos com
uma determinada extensão, como em "find /mnt/hda6 -name *.mp3".
Assim como outros comandos do terminal, o find pode ser usado de forma
mais amigável através de ferramentas gráficas. No KDE, por exemplo, você
pode usar o "kfind". Através dele você pode procurar pelo nome ou tipo de
arquivo (você pode fazer uma busca incluindo apenas arquivos de imagem,
por exemplo), procurar dentro de pastas específicas ou localizar arquivos
pertencentes a um determinado usuário ou grupo do sistema, ou até mesmo
procurar por arquivos modificados recentemente:
No GNOME, você pode utilizar o "gnome-search-tool", disponível no
"Locais > Pesquisar por arquivos", que cumpre uma função similar.
Assim como no caso dos nomes de arquivos, você pode completar os
comandos usando a tecla TAB, o que reduz a necessidade de realmente
decorá-los. Outra dica é usaro comando "apropos" para ajudar a localizar
comandos quando você tem apenas uma vaga ideia do nome. Basta chamá-lo
incluindo algumas letras que façam parte do comando (não importa se do
começo ou do final), como em "apropos keyg" ou "apropos ogg". Ele mostra
uma lista com todos os comandos que contêm os caracteres especificados no
nome, juntamente com uma pequena descrição.
Desligando: Assim como no Windows, você precisa desligar o sistema
corretamente para evitar perda de arquivos e danos à estrutura das partições
(sem falar em evitar o chato fsck no boot seguinte). Além das opções nos
menus do KDE ou GNOME, você pode desligar via terminal, usando os
comandos "halt" (desligar) e "reboot" (reiniciar). Existe também o
Ctrl+Alt+Del, que se executado em um dos terminais de texto puro reinicia o
micro e, se pressionado dentro do ambiente gráfico abre (na maioria das
distribuições) o diálogo com as opções de desligar e reiniciar.
Informações sobre o hardware: Como comentei no tópico sobre os
diretórios, a pasta "/proc" não armazena arquivos, mas sim informações sobre
o hardware e sobre a configuração do sistema. Embora seja possível ver o
conteúdo dos arquivos usando qualquer editor de texto (como no caso do "cat
/proc/cpuinfo"), a maior parte das informações são crípticas demais para
qualquer ser humano normal.
Se você quer apenas descobrir qual é o chipset da placa wireless ou da placa
de som, por exemplo, pode ver uma listagem resumida do hardware da
máquina usando o comando "lspci". Para os dispositivos USB (que não
aparecem na lista do lspci), temos o "lsusb".
Dois outros comandos relacionados são o "lshal" (que mostra todos os
componentes detectados pelo HAL, responsável por detectar o hardware e
carregar os módulos apropriados) e o "lshw" que mostra uma longa lista de
detalhes sobre a máquina, lembrando um pouco o gerenciador de dispositivos
do Windows, porém em modo texto. Complementando, temos o clássico
"uname -a", que permite verificar rapidamente qual versão do kernel está
sendo usada.
Rede: O comando básico para gerenciar a configuração de rede no Linux é o
"ifconfig". Quando chamado sem argumentos, ele mostra a configuração
atual da rede (o que o torna uma opção rápida para verificar qual endereço IP
seu PC está usando, ou se ele obteve a configuração corretamente a partir do
servidor DHCP), mas ele pode ser usado também para alterar a configuração
da rede rapidamente. Ao digitar "ifconfig eth0 192.168.1.2", por exemplo,
você troca o endereço da placa "eth0".
Ele é complementado pelo "iwconfig", que se aplica às placas wireless. Ao
chamá-lo sem argumentos, ele mostra a configuração atual, incluindo o SSID
da rede, o endereço MAC do ponto de acesso, a qualidade do sinal e a
velocidade atual de transmissão, mas ele pode ser usado também para
configurar a rede Wi-Fi manualmente, como veremos em detalhes no capítulo
sobre o Slackware.
Outro comando proeminente, que agrupa as funções de vários outros
comandos de configuração é o comando "ip".
Por exemplo, para listar todas as interfaces de rede presentes no sistema
(incluindo as que não tiverem endereços associados), você usaria o comando
"ip link show". Para ver detalhes sobre uma determinada interface, usaria o
"ip addr show dev eth0" (onde o "eth0" é a interface) e para ver detalhes
sobre todas as interfaces usaria o "ip addr show", sem especificar uma
interface específica.
Para ver os endereços MAC das interfaces de outros PCs da rede (equivalente
ao comando "arp -n"), você usaria o "ip neigh show", para ver informações
sobre as rotas (similar ao "route -n") usaria o "ip route show" e assim por
diante.
 
O su, o sux e o sudo
O Linux nasceu como um sistema multiusuário, mantendo a tradição dos
sistemas Unix. Ele oferece um sistema de permissões bastante simples,
porém ao mesmo tempo bastante efetivo, atendendo tanto a desktops
domésticos, usados por apenas duas ou três pessoas, quanto a servidores com
centenas de usuários.
No Linux, o root é o único que tem acesso a todos os arquivos e
configurações do sistema. Os usuários normais têm, por padrão, acesso
apenas a seus arquivos dentro do diretório /home e alguns outros arquivos
específicos. Em um desktop, a ideia básica é que você use um login normal
de usuário para rodar programas e executar as tarefas do dia a dia e logue-se
como root quando precisar instalar programas ou alterar a configuração do
sistema.
Todos os programas salvam suas configurações dentro de pastas ocultas,
dentro do diretório home, como a ".gnome2", que armazena a maior parte das
configurações relacionadas ao GNOME e a ".kde", que guarda as
configurações do KDE e dos aplicativos baseados nele. Cada usuário tem
suas próprias pastas de configuração e pode alterar apenas seus próprios
arquivos, o que evita confusão em PCs ou servidores compartilhados entre
vários usuários. O máximo que poderia acontecer seria um usuário deletar
seus próprios arquivos, ou bagunçar suas próprias configurações.
Em qualquer distribuição, você pode se logar como root usando o comando
"su" no terminal, fornecendo a senha de root. De uma forma geral,
recomenda-se usá-lo com o parâmetro "-", que atualiza as variáveis de
ambiente:
$ su -
O símbolo do terminal muda de um "$" para um "#", indicando que, a partir
daí, todos os comandos digitados nesse terminal específico serão executados
como root.
Um problema comum é você não conseguir rodar aplicativos gráficos depois
de logado como root, recebendo um "konqueror: cannot connect to X server "
ou um "Error: no display specified". Isso acontece por que, na maioria das
distribuições, as permissões do X não são atualizadas, fazendo com que, por
paradoxal que possa parecer, o root não tenha permissão para usar o ambiente
gráfico. Isso acaba sendo um grande empecilho, já que você não pode usar
editores de texto como o gedit ou o kwrite para editar arquivos de
configuração, por exemplo.
A solução mais simples é instalar o pacote "sux" e passar a usar o comando
no lugar do su. O "sux" atualiza as permissões do ambiente gráfico,
solucionando o problema. Basta passar a usá-lo no lugar do "su" quando
quiser rodar aplicativos gráficos:
$ sux
Outra opção é rodar os programas gráficos usando o "gksudo" (no GNOME)
ou o "kdesu" (no KDE), seguidos do comando desejado, como em:
$ gksudo gedit
ou:
$ kdesu konqueror /etc
Assim como no caso do sux, eles ajustam as permissões do X
automaticamente. Uma forma prática de usá-los, é rodar os comandos usando
o "Alt+F2" que abre a janela do "Executar comando", onde você pode rodar o
comando diretamente, sem precisar primeiro abrir um terminal.
Em algumas distribuições (como no caso do OpenSUSE), o gksudo é
substituído pelo "gnomesu", mas a função é a mesma.
Continuando, as distribuições atuais têm adotado cada vez mais o uso do
"sudo" como uma forma de facilitar o uso do sistema, permitindo que você
execute aplicativos como root quando precisar.
Muita gente associa o uso do sudo ao Ubuntu, mas ele, na verdade, começou
a ser usado em larga escala um pouco antes, no Knoppix e em outros live-
CDs baseados nele, como o Kurumin. No caso dos live-CDs, o sudo é usado
como um facilitador, para que o sistema permita a execução de comandos
como root sem a necessidade de definir uma senha default para o root.
Quando você precisa abrir uma janela do gerenciador de arquivos como root,
para recuperar arquivos dentro de uma partição do HD, por exemplo, você
precisa apenas chamá-lo colocando um "sudo" antes do comando, como em:
$ sudo konqueror /mnt/sda2
O sudo pode ser usado até mesmo para alterar a senha de root, permitindo
que você defina uma senha para o live-CD, mesmo sem saber a senha
anterior:
$ sudo passwd
O Ubuntu (depois de instalado) usa uma abordagem mais conservadora,
confirmando sua senha de usuário antes de executar o comando. Essa é uma
precaução básica de segurança, que evita que alguém possa alterar a senha de
root e assumir o controle do seu PC enquanto você estiver tomando um
cafezinho, por exemplo.
Em qualquer um dos casos, a configuraçãodo sudo vai no arquivo
"/etc/sudoers", onde são especificados os usuários que poderão usar o
comando. No Ubuntu, por exemplo, é usada a seguinte configuração:
%admin ALL=(ALL) ALL
O "%admin" indica que a regra não se aplica a um usuário específico, mas
sim a todos os usuários que fazem parte do grupo "admin". Por default,
apenas o usuário criado durante a instalação faz parte do grupo e somante ele
pode usar o sudo, mas você pode criar outros usuários administrativos
posteriormente simplesmente adicionando-os ao grupo, como em:
# addgroup gdh admin
Devido ao " ALL=(ALL) ALL ", o sistema permite que o sudo seja usado
para executar qualquer comando (com algumas poucas exceções), mas
apenas depois de confirmada a senha do usuário.
Para poder executar comandos sem precisar confirmar a senha (como ao
rodar usando o live-CD), você precisaria apenas alterar a linha, substituindo o
"(ALL)" por um "NOPASSWD:", como em:
%admin ALL=NOPASSWD: ALL
No caso do Ubuntu, o arquivo vem com a linha "%sudo ALL=NOPASSWD:
ALL" comentada, que tem um efeito semelhante, permitindo que os usuários
incluídos no grupo "sudo" possam usar o sudo sem senha.
Por ser um arquivo essencial dentro do sistema de permissões, o
"/etc/sudoers" é um arquivo extremamente sensível. Qualquer erro dentro da
configuração, ou qualquer alteração nas permissões do arquivo (que devem
ser, obrigatoriamente, "0440"), fazem com que o sudo deixe de funcionar,
bloqueando parcialmente o sistema até que o problema seja resolvido.
É por isso que é recomendado que você edite o arquivo usando o comando
"visudo", que não permite que você salve o arquivo caso existam erros na
configuração. O grande problema é que ele é complicado de usar, o que faz
com que muitos dispensem o conselho e usem outros editores de texto. Não
existe nada de errado nisso, desde que você cheque e recheque a configuração
antes de salvar.
Outra dica é que você sempre destrave a conta de root usando o "sudo
passwd" antes de tentar editar o arquivo. Isso garante que você continue
conseguindo se logar como root no sistema caso o sudo fique travado por um
erro na configuração do arquivo.
 
A questão das permissões
Clicando sobre as propriedades de qualquer pasta ou arquivo dentro do
gerenciador de arquivos, você encontra um menu com o ajuste de permissões,
onde pode definir individualmente as permissões para o dono do arquivo,
para usuários que façam parte do mesmo grupo e para os outros, que inclui
todos os demais usuários com acesso ao sistema:
Cada um dos campos aceita três possibilidades: "Nenhum", "Apenas leitura"
e "Leitura e escrita". Por default, o dono é o único que pode ler e escrever, os
demais (grupo e outros) podem apenas ler o arquivo, sem modificá-lo.
No caso dos arquivos, existe uma quarta permissão, que é o campo "Permitir
execução do arquivo como um programa". Esta é uma daquelas diferenças
fundamentais entre o Linux e o Windows: o sistema não decide quais
arquivos são programas pela extensão, mas sim pelas permissões. Isso
aumenta bastante a segurança do sistema, mas, por outro lado, causa um
pouco de dor de cabeça em algumas situações. Sempre que você baixar um
instalador qualquer via web (o driver da nVidia, por exemplo), vai precisar
primeiro ativar a permissão de execução nas propriedades do arquivo antes de
conseguir instalá-lo.
O "dono" do arquivo é por default o usuário que o criou. Apenas este usuário
pode alterar as permissões de acesso ao arquivo ou à pasta. Em seguida, vem
a configuração do grupo, que permite que vários usuários tenham acesso a
um arquivo ou pasta, sem ter que apelar para o campo "outros" que daria
acesso a qualquer um.
Imagine o caso de um servidor de arquivos, usado por diversos usuários
diferentes, onde você precise fazer com que um determinado arquivo fique
acessível apenas para três usuários específicos. Uma maneira simples de
resolver o problema seria criar um novo grupo, adicionar a ele os usuários
que devem ter acesso e, em seguida, alterar as permissões de acesso, para que
o grupo passe a ser dono do arquivo e os integrantes sejam os únicos com
permissão para ler e fazer alterações.
Você pode criar novos grupos e adicionar usuários a eles através do "users-
admin" ("Sistema > Administração > Usuários e Grupos", nas distribuições
derivadas do GNOME), ou usando outra ferramenta gráfica incluída na
distribuição, como o UserDrake (disponível no Mandriva) ou o Kuser
(disponível em muitas distribuições com o KDE).
Configuração dos grupos com o users-admin
Para criar um novo grupo usando o users-admin, clique em "Gerenciar Grupo
> Adicionar Grupo". Na janela que será aberta, especifique o nome do grupo
e os usuários que farão parte dele. Um mesmo usuário pode fazer parte de
vários grupos simultaneamente. Muita gente cria um grupo diferente para
cada pasta importante, de forma a poder definir individualmente quem terá
acesso a ela.
Você notará que nesta tela aparecem vários usuários que não são mostrados
na tela principal, como o "bin", "daemon" e "mail". Estes são usuários ocultos
do sistema, contas sem privilégios e que não possuem senhas definidas (é
simplesmente impossível fazer login com qualquer uma delas), que são
usadas para isolar os programas, fazendo com que cada um tenha acesso
apenas a seus próprios arquivos. Isso limita muito os danos que um aplicativo
ou serviço com bugs ou falhas de segurança pode causar quando alguma
coisa dá errado.
De fato, a configuração default da maior parte das distribuições Linux atuais,
é dar acesso de leitura para a maioria das pastas (com exceção, naturalmente,
dos arquivos de senha e outros arquivos críticos do sistema) para todos os
usuários, mas, ao mesmo tempo, dar acesso de gravação apenas para o
diretório home de cada um. 
 
 Por default, o único que pode alterar o dono das pastas é o próprio root (os usuários podem alterar
apenas o grupo e ainda assim somente entre os grupos de que fazem parte). Um dos motivos para isso é o
suporte a quotas, que (embora não seja muito usado em desktops) está disponível em qualquer distribuição
Linux. Se qualquer usuário pudesse alterar a posse dos arquivos, transferindo-os para outros usuários, o
sistema de quotas seria muito fácil de burlar.
A maneira mais simples de alterar os donos e grupos dos arquivos e pastas é
simplesmente abrir uma janela do gerenciador de arquivos como root, como
em:
$ gksudo nautilus
Diferente do que temos ao rodar o gerenciador de arquivos como usuário, ao
acessar as propriedades dos arquivos como root os campos do dono e do
grupo ficam desbloqueados, permitindo que você ajuste as permissões
livremente.
Como de praxe, você pode também ajustar as permissões via linha de
comando, usando os comandos "chmod" e "chown". O primeiro permite
ajustar as permissões dos arquivos e pastas, enquanto o segundo permite
transferir a posse, dizendo a qual usuário e a qual grupo determinada pasta ou
arquivo pertence.
Um exemplo comum é quando você cria ou copia uma pasta como root e,
devido a isso, fica sem poder modificar os arquivos usando seu login de
usuário. Uma maneira simples de resolver o problema seria usar o comando
"chown" (como root) para transferir a posse da pasta, como em:
# chown -R gdh /home/gdh/arquivos/
O "-R" no comando faz com que ele seja aplicado recursivamente, ou seja,
altere as permissões não apenas da pasta, mas de todo o conteúdo. Sem ele,
você passaria a conseguir escrever dentro da pasta, mas ainda continuaria sem
acesso às subpastas dentro dela. Em seguida, temos o "gdh", que indica o
usuário e a pasta que será modificada.
Outro uso comum é especificar também o grupo, como em:
# chown -R gdh:gdh /home/gdh/arquivos/
Você pode também criar novos usuários e alterar as senhas usando o
"adduser" e o "passwd", que permitem, respectivamente, adicionar novos
usuários e alterar as senhas de acesso posteriormente, como em:
# adduser joao
(cria o usuário)
# passwd joao
(altera a senha posteriormente)
O próprio usuário pode alterar a senha usando o comando "passwd", desde
que ele saibaa senha antiga. Se o usuário esqueceu a senha, você pode definir
uma nova executando o comando como root; nesse caso, o sistema pede a
nova senha diretamente, sem solicitar a antiga.
Bem antigamente, as senhas eram salvas no próprio arquivo "/etc/passwd",
juntamente com as demais informações da conta, o que abria brecha para
diversos tipos de ataques. A partir de um certo ponto (por volta de 1996),
todas as distribuições passaram a utilizar o sistema shadow, onde as senhas
são armazenadas de forma encriptada em um arquivo separado, o
"/etc/shadow".
As senhas são encriptadas usando um algoritmo de mão única, que permite
apenas encriptá-las, mas não recuperá-las. Durante o login, o sistema aplica o
mesmo algoritmo à senha digitada pelo usuário e compara a string resultante
com a armazenada no arquivo. Se o resultado for o mesmo, o sistema sabe
que a senha confere e o acesso é autorizado.
Continuando, para remover um usuário anteriormente criado, utilize o
comando "deluser", como em:
# deluser joao
Por questão de segurança, o comando remove apenas a conta, sem apagar o
diretório home ou outras pastas com dados do usuário. O diretório home é
especialmente importante, pois ele guarda todas as configurações e os
arquivos do usuário, de forma que você só deve removê-lo depois de ter
realmente certeza do que está fazendo.
Concluindo, você pode alterar as permissões de acesso de arquivos e pastas
usando o comando chmod. A sintaxe dele parece um pouco complicada à
primeira vista (justamente por isso a maioria acaba preferindo usar
diretamente o gerenciador de arquivos), mas nada que um pouco de prática
não possa resolver.
Um exemplo típico seria:
# chmod 744 arquivo
Os três números indicam, respectivamente, as permissões para o dono do
arquivo, para o grupo e para os demais usuários.
Temos três permissões: leitura, gravação e execução. Cada uma é
representada por um número:
4: Ler.
2: Alterar o conteúdo, criar novos arquivos (no caso de uma pasta).
1: Execução (no caso dos arquivos) ou listar os arquivos (no caso das
pastas).
Você simplesmente soma estes números para ter o número referente ao
conjunto de permissões que deseja:
0: Sem permissão alguma. Se for uma pasta, o usuário sequer pode ver
o conteúdo.
1: Permissão apenas para executar (não é possível ler o arquivo ou
alterá-lo, apenas executar um programa). No caso de uma pasta, o "1"
permite que se liste os arquivos dentro dela, mas sem ler ou alterar os
arquivos.
4: Apenas leitura.
5 (4+1): Ler e executar (no caso de um arquivo) ou ver os arquivos e
abri-los, no caso de uma pasta. 
6 (4+2): Leitura + gravação.
7 (4+2+1): Controle total: leitura + gravação + permissão para executar.
Uma observação importante é que, ao configurar as permissões de acesso de
uma pasta, você sempre deve usar 5 (4+1) ou 7 (4+2+1), pois, sem permissão
para listar o conteúdo da pasta, você não consegue ver os arquivos dentro
dela. 
Se você quisesse dar controle total do arquivo ou pasta para o dono e para o
grupo, mas permissão de apenas leitura para os demais usuários, usaria o
número 774; se você quisesse que todos os usuários tivessem permissão de
leitura e gravação, mas sem poder executar nada, usaria o número 666; se
quisesse dar controle total para todo mundo, usaria 777 e assim por diante.
Outra configuração que não deve ser subestimada é a dos privilégios de
usuário, que fica disponível dentro das propriedades da conta, no "users-
admin":
Como você pode ver, ela inclui opções para usar diversos componentes do
sistema, incluindo o uso da placa de som, compartilhamento de arquivos e
assim por diante. Estas permissões são na verdade definidas de uma maneira
bastante simples, através de grupos. Quando você marca a permissão para
usar dispositivos de áudio, por exemplo, tudo o que o users-admin faz é
adicionar o usuário ao grupo correspondente.
No caso do Ubuntu, está disponível também a opção "Administrar o sistema",
que adiciona o usuário ao grupo "admin", permitindo que ele use o sudo e
altere as configurações do sistema. Por default, o único administrador é o
usuário criado durante a instalação, mas você pode criar outros.
Sempre que você adiciona um novo login de usuário e, ao logar com ele, não
consegue ouvir sons, usar a impressora ou outros recursos do sistema,
verifique antes de mais nada se as opções correspondentes estão marcadas
dentro da aba de privilégios do usuário.
 
Uma introdução ao shell-script
Imagine que, em um futuro distante, o Google decida transformar o Android
em um sistema para robôs pessoais. Seu robô com o Android poderia ser
então instruído a executar qualquer tipo de tarefa, desde que você
conseguisse explicar para ele o que precisa fazer na forma de instruções
simples. Uma ida até a geladeira para pegar uma lata de refrigerante poderia
ser explicada dessa forma:
Ir até a cozinha.
Abrir a geladeira.
Olhar a prateleira da direita.
Se encontrar uma lata de coca-cola, trazer para mim.
Senão, trazer a lata de guaraná.
Se não encontrar lata alguma, fechar a geladeira e voltar.
Este mesmo princípio, de dividir a tarefa a ser feita em instruções simples, é
comum a todas as linguagens de programação. Elas podem variar em
complexidade, mas a ideia central é sempre a mesma: explicar ao sistema o
que fazer, em uma linguagem que ele seja capaz de entender.
No caso do shell-script, você precisa apenas pensar em uma maneira de
"explicar" o que você quer que seja feito através de comandos de terminal.
Conforme você vai adquirindo mais familiaridade com o sistema, este acaba
se tornando um processo natural, já que qualquer conjunto de comandos para
executar uma determinada tarefa pode ser transformado em um script
rapidamente. Vamos então a alguns exemplos básicos para quebrar o gelo. 
O tipo mais simples de script consiste em um bloco de comandos, que
automatiza alguma tarefa repetitiva. Estes scripts "burros" são uma excelente
forma de simplificar o uso do sistema, evitando que você precise memorizar
sequências de comandos. Um bom exemplo é este mini-script que uso para
conectar um mouse bluetooth:
#!/bin/sh
# Checagem para ter certeza que o suporte a bluetooth está ativado:
hciconfig hci0 down
/etc/init.d/bluetooth restart
hciconfig hci0 up
# Ativa o mouse:
hidd --connect 00:07:61:62:cb:bb
Estes quatro comandos permitem ativar o mouse em qualquer distribuição, de
forma que preciso apenas executar o script e colocá-lo para ser inicializado
automaticamente, sem precisar me preocupar com as peculiaridades de cada
uma.
Para usá-lo, é necessário apenas criar um arquivo de texto chamado
"btmouse.sh" (ou qualquer outro nome que escolher), colocá-lo dentro do seu
home, ou da sua partição de dados (para que ele não seja perdido ao reinstalar
o sistema) e marcar a permissão de execução ("chmod +x btmouse.sh").
A partir daí, você pode passar a executar o script quando precisar ativar o
mouse:
# /mnt/sda6/btmouse.sh
... ou adicionar o comando no final do arquivo "/etc/rc.d/rc.local" (ou outro
arquivo de inicialização) para que ele passe a ser executado automaticamente.
O problema com esses scripts simples é que eles servem para propósitos bem
específicos, já que os passos executados são sempre os mesmos. Este script
para ativar o mouse bluetooth, por exemplo, funciona apenas com o meu
mouse, já que o endereço de conexão está gravado dentro do próprio script.
Scripts mais complexos começam quase sempre com alguma pergunta. Um
gerenciador de downloads precisa saber qual é a URL do arquivo a baixar,
um discador precisa saber qual modem será utilizado e qual o número de
acesso do provedor, um instalador de programas precisa saber qual programa
deve ser instalado e assim por diante.
Dependendo da situação, as perguntas podem ser feitas diretamente, no estilo
"digite a URL do arquivo a baixar", ou através de um menu de seleção, onde
você lista as funções oferecidas pelo script e o usuário clica na opção
desejada.
Para fazer uma pergunta direta (que é o formato mais simples), usamos o
comando "read", que lê uma resposta e a armazenaem uma variável. Quase
sempre ele é usado em conjunto com o "echo", que permite escrever texto na
tela, fazendo a pergunta, como em:
echo "Digite a URL do arquivo a baixar"
read arquivo
wget -c $arquivo
Com estes três comandos, criamos um gerenciador de downloads primitivo,
que pede a URL do arquivo (que você poderia colar no terminal usando o
botão central do mouse) e faz o download usando o wget, que é um
gerenciador em modo texto, muito usado em scripts.
A URL digitada é armazenada na variável "arquivo", que pode ser usada ao
longo do script. Ao usá-la, é necessário incluir um "$", que faz com que o
shell entenda que se trata da variável "arquivo" e não de um trecho de texto
qualquer. Quando o script fosse executado, o " wget -c $arquivo " seria
transformado em algo como "wget -c http://gdhpress.com.br/arquivo.zip",
iniciando o download.
O "-c" é uma opção para o wget, que faz com que ele continue o download
caso interrompido. Se você pressionasse "Ctrl+C" durante o download para
encerrar o script e o executasse novamente, fornecendo a mesma URL, ele
continuaria o download de onde parou.
Você poderia incrementar o script, incluindo mais perguntas e usando mais
opções do wget. A primeira parada nesse caso seria o "man wget", onde você
poderia garimpar as opções suportadas pelo comando e selecionar algumas
que poderiam ser úteis dentro do script. Um bom exemplo é a opção "--limit-
rate=" que permite limitar a taxa de download. Você poderia incluir a opção
no script adicionando mais uma pergunta, como em:
echo "Digite a URL do arquivo a baixar"
read arquivo
echo "Digite a taxa máxima de download, em kbytes. ex: 48"
read taxa
wget -c --limit-rate=$taxa $arquivo
Este formato simples funciona bem para scripts rudimentares, destinados a
simplesmente automatizarem alguma tarefa específica, a partir de algumas
perguntas simples. Para scripts mais completos, precisamos começar a usar as
operações lógicas, que permitem que o script tome decisões. O formato mais
básico é o "se, então, senão", que no shell script é representado pelos
operadores "if", "then" e "else".
Imagine que você está fazendo um script conversor de vídeos, que é capaz de
gerar arquivos em quatro diferentes formatos. O script começa perguntando
qual formato usar e, de acordo com a resposta, executa os comandos
apropriados para fazer a conversão.
Para simplificar, vamos fazer com que o script simplesmente converta todos
os arquivos dentro do diretório atual, em vez de perguntar quais arquivos
converter ou de exibir uma caixa de seleção.
A parte da pergunta poderia ser feita com o "echo", como no exemplo
anterior. Como agora são várias linhas de texto, usei aspas simples ( ' ) em
vez de aspas duplas. As aspas simples permitem que você inclua quebras de
linha e caracteres especiais dentro do texto, fazendo com que o shell
simplesmente escreva tudo literalmente:
echo 'Escolha o formato de saída:
1) MPEG4, 320x240 (vídeos no formato 4:3)
2) MPEG4, 320x176 (vídeos em formato wide)
3) Real Player, 320x240 (vídeos no formato 4:3)
4) Real Player, 320x176 (vídeos em formato wide)
(Responda 1, 2, 3 ou 4, ou qualquer outra tecla para sair)'
read resposta
No final deste trecho, teríamos a variável "resposta", que armazenaria um
número de 1 a 4. Precisamos agora fazer com que o script decida o que fazer
de acordo com a resposta.
O jeito mais simples de fazer isso seria simplesmente colocar um bloco com
4 comandos "if" (se), um para cada possibilidade. Cada "if" é sempre
acompanhado por um "then" (então) e um "fi" (fim do se), como em:
if [ "$resposta" = "1" ]; then
 [comandos ...]
fi
if [ "$resposta" = "2" ]; then
 [comandos ...]
fi
if [ "$resposta" = "3" ]; then
 [comandos ...]
fi
if [ "$resposta" = "4" ]; then
 [comandos ...]
fi
Uma forma mais elegante (e mais à prova de falhas), seria usar o "elif" (que
poderia ser traduzido para "senão se") e o "else" (senão), como em:
if [ "$resposta" = "1" ]; then
 [comandos ...]
elif [ "$resposta" = "2" ]; then
 [comandos ...]
elif [ "$resposta" = "3" ]; then
 [comandos ...]
elif [ "$resposta" = "4" ]; then
 [comandos ...]
else
 echo "Você digitou uma opção inválida. O script termina aqui."
fi
Como pode ver, ao usar o elif você não precisa mais incluir um "fi" para cada
possibilidade. Outra vantagem é que você pode agora incluir um "else" no
final, que faz com que o script responda com uma mensagem de erro ao
receber alguma resposta que não estava esperando. Dentro de cada uma das
condições, você incluiria um bloco de comandos destinado a gerar os
arquivos convertidos com os parâmetros correspondentes, como em:
if [ "$resposta" = "1" ]; then
 for i in *; do
 mencoder -oac mp3lame -lameopts cbr:br=128 -ovc lavc -lavcopts \
 vcodec=mpeg4:vbitrate=512 -ofps 16 -vf scale=320:176 -o "c-$i" "$i"
 done
elif [ "$resposta" = "2" ]; then
 [o resto do script...]
Esse comando gigante que se esparrama pela terceira e a quarta linha é um
comando de conversão do mencoder (um pequeno utilitário de conversão de
arquivos de mídia em modo texto, que é bastante flexível), que gera um
arquivo de vídeo otimizado para ser assistido em smartphones. Esse é o tipo
de comando que é longo demais para ser escrito manualmente, mas que pode
perfeitamente ser usado através de um script.
Veja que a variável "i" é usada no final da quarta linha, para indicar o nome
do arquivo. O "c-$i" "$i" faz com que o script adicione o prefixo "c-" no
nome dos arquivos convertidos, permitindo que eles sejam incluídos na pasta
sem apagar os arquivos originais.
O comando do mencoder é colocado dentro de outra condicional, agora
usando o "for" (enquanto), que permite que o script execute um conjunto de
comandos repetidamente.
No exemplo, ele é usado para fazer com que o comando de conversão do
mencoder seja executado uma vez para cada arquivo dentro da pasta. Ao ser
executado, a variável "i" (poderia ser qualquer outro nome) recebe o nome do
primeiro arquivo, o que faz com que ele seja convertido.
Ao chegar no "done", o interpretador volta à linha inicial e a variável "i"
recebe agora o nome do segundo arquivo. O processo é então repetido para
cada um dos arquivos da pasta, até o último (a lista dos arquivos a converter é
gerada pelo interpretador no início do script, por isso não existe o risco do
conversor ficar em loop). O "for i in *; do" poderia ser traduzido como "para
cada arquivo dentro da pasta atual, execute".
Você pode baixar o script pronto, incluindo os comandos de conversão no: 
http://www.gdhpress.com.br/blog/converter-video/
Outro exemplo de uso para o "for" seria baixar uma lista de arquivos ISO
especificada em um arquivo de texto. Imagine que você goste de testar novas
distribuições e, de vez em quando, queira deixar o PC ligado durante a
madrugada colocando os downloads em dia. Você poderia facilitar as coisas
http://www.gdhpress.com.br/blog/converter-video/
usando um script como:
#!/bin/sh
echo "Digite a taxa máxima de download, em kbytes. ex: 48"
read taxa
for i in `cat /home/$USER/downloads.txt`; do
 wget -c --limit-rate=$taxa $i
done
Para usá-lo, você precisaria apenas criar um arquivo "downloads.txt" dentro
do seu diretório home, colocando os links de download dos ISOs das
distribuições, um por linha, como em:
http://ftp.heanet.ie/pub/linuxmint.com/stable/6/LinuxMint-6.iso
ftp://ftp.nluug.nl/pub/os/Linux/distr/dreamlinux/stable/DL3.5_20092802.iso
http://sidux.c3sl.ufpr.br/release/sidux-2009-01-ouranos-kde-lite-i386.iso
Ao executar o script, ele começaria perguntando a taxa máxima de download
(com a resposta sendo armazenada na variável "taxa"), leria o arquivo e
baixaria os arquivos listados para o diretório atual. A linha do wget inclui
duas variáveis: a taxa de download e o arquivo a baixar. Por causa do "for", o
comando é repetido para cada um dos links listados no arquivo, fazendo com
que eles sejam baixados um de cada vez.
Embora simples, este script introduz algumas idéias novas. A primeira é o
uso das crases (``), que permitem usar o resultado de um comando. Graças a
elas,podemos usar o "cat" para ler o arquivo de texto e assim fazer com que
o script carregue as URLs dentro da variável "i", uma de cada vez.
Outra novidade é o uso do "/home/$USER", uma variável de sistema que
contém sempre o diretório home do usuário que executou o script. Isso faz
com que o script procure pelo arquivo "downloads.txt" dentro do seu
diretório home, e não em uma localização específica.
Uma prática um pouco mais avançada é o uso de funções. Elas permitem que
você crie blocos de código destinados a executarem tarefas específicas que
podem ser usados ao longo do script. Em outras palavras, as funções são
pequenos scripts dentro do script.
A grande vantagem de criar funções (em vez de simplesmente repetir os
comandos quando precisar) é que, ao atualizar o script, você precisa alterar
apenas um bloco de comandos, em vez de precisar procurar e alterar os
comandos manuais em vários pontos do script. Por permitirem reaproveitar o
código, as funções fazem com que o script seja mais organizado e fique com
menos linhas, o que facilita muito a manutenção em scripts complexos.
Imagine, por exemplo, que você precisa repetir uma mesma mensagem de
erro várias vezes ao longo do script. Você poderia usar uma função como
esta:
msgerro()
{
 echo "Algo deu errado durante a conexão. O erro foi:"
 echo "$msg"
}
Veja que a função começa com uma declaração ("msgerro()"), onde você
especifica um nome e adiciona o "()", que faz com que o sistema entenda que
se trata de uma função e não de um outro bloco de comandos qualquer. Os
comandos são, em seguida, colocados dentro de um par de chaves ( { .... } ),
que indicam o início e o final. A partir daí, você pode executar os comandos
dentro do script chamando o nome da função (msgerro), como se fosse um
comando qualquer.
Um exemplo é o script para conectar usando modems e smartphones 3G que
escrevi em 2008, que está disponível no:
http://www.gdhpress.com.br/blog/script-vivo-zap/
Ele prevê o uso de diversos tipos de conexão e inclui várias funções de
checagem e solução de problemas (que são usadas repetidamente ao longo do
script), por isso ele é bastante longo e complexo, com quase 900 linhas. Se
tiver curiosidade em acessar o tópico e olhar o código, vai ver que crio
diversas funções no início do script (a "bpairing()" contém os comandos para
fazer o pareamento com smartphones e conectar via Bluetooth, enquanto a
"checaporta()" verifica em que porta o modem ou smartphone está conectado,
por exemplo) que são usadas ao longo do script.
Outra necessidade comum é salvar parâmetros e configurações, evitando que
o script precise perguntar tudo novamente cada vez que for executado. Uma
forma simples de implementar isso é fazer com que o script salve as variáveis
com as configurações usadas em arquivo de texto (é geralmente usado um
arquivo oculto dentro do diretório home), como em:
echo "tel=\"$tel\"" > /home/$USER/.myscript
echo "porta=\"$porta\"" >> /home/$USER/.myscript
Esses comandos criariam o arquivo ".myscript" dentro do diretório home do
usuário que executou o script. Graças ao uso do ponto, ele se torna um
http://www.gdhpress.com.br/blog/script-vivo-zap/
arquivo oculto, assim como os demais arquivos de configuração do sistema.
O arquivo de configuração pode ser carregado dentro do script com um ".
/home/$USER/.myscript" (ou seja, ponto, espaço e a localização do arquivo),
o que faz com que o interpretador processe os comandos dentro do arquivo
como se fossem parte do script principal.
Um exemplo de uso seria uma versão aperfeiçoada do script para ativar
mouses Bluetooth que mostrei a pouco, que perguntasse o endereço do mouse
da primeira vez que fosse executado e passasse a usar a configuração salva
daí em diante:
#!/bin/sh
if [ -e "/home/$USER/.btmouse" ]; then
 echo "Carregando configuração salva no arquivo /home/$USER/.btmouse."
 . /home/$USER/.btmouse
else
 # Se o arquivo não existir, pergunta o endereço e salva a configuração.
 echo "Digite o endereço do mouse que será usado (ex: 00:07:61:62:cb:bb):"
 read addr
 echo "addr=\"$addr\"" > /home/$USER/.btmouse
fi
# Mensagem explicativa:
echo "Conectando a $addr"
echo "Delete o arquivo /home/$USER/.btmouse para trocar o endereço."
# O script propriamente dito:
hciconfig hci0 down
/etc/init.d/bluetooth restart
hciconfig hci0 up
hidd --connect $addr
Embora estes exemplos utilizem apenas perguntas simples, em texto, os
shell-scripts podem também exibir janelas, avisos, perguntas e menus de
seleção gráficos de maneira muito simples, utilizando o Xdialog, Kdialog ou
o Zenity, que permitem mostrar janelas gráficas de forma
surpreendentemente fácil.
Para mostrar uma mensagem de texto, por exemplo, você usaria o "zenity --
info --text" seguido da mensagem a mostrar, como em:
zenity --info --text "Conexão ativa."
Para abrir uma janela de seleção de arquivo, você usaria o "zenity --file-
selection", que exibe uma janela similar à do gerenciador de arquivos,
permitindo escolher o arquivo que será usado.
Normalmente, a localização do arquivo seria simplesmente escrita no
terminal. Para que ela seja armazenada em uma variável (permitindo que
você a use posteriormente ao longo do script), você usaria:
arquivo=`zenity --file-selection --title "Escolha o arquivo"`
Estes dois comandos simples poderiam ser usados para criar um aplicativo
rudimentar de gravação de CDs, veja só:
#!/bin/sh
zenity --info --text "Coloque uma mídia virgem no drive"
iso=`zenity --file-selection --title "Escolha o arquivo ISO para gravar:"`
wodim dev=/dev/scd0 speed=16 -dao -eject -v $iso
Quando executado, o script mostraria as duas janelas e gravaria o arquivo
ISO selecionado usado o wodim, que é um aplicativo de gravação de CDs via
linha de comando, usado por diversos outros aplicativos. Quando você
queima um CD usando o Brasero ou o K3B, é o wodim quem faz o trabalho
pesado, assim como no caso do nosso script:
 
Graças à opção "-eject" adicionada à linha de gravação, o script ejeta a mídia
depois de gravada, o que torna desnecessário incluir mais uma janela
avisando que a gravação foi concluída. O wodim suporta diversas outras
opções de gravação (que você pode consultar no "man wodim"), que
poderiam ser usadas para aperfeiçoar o script. Você precisaria apenas incluir
algumas perguntas adicionais, salvar as respostas em variáveis e incluí-las na
linha de gravação. 
Concluindo essa breve introdução, dois outros comandos fundamentais em se
tratando de shell-scripts são o pipe e o grep. Aqui vai uma explicação
resumida sobre eles:
pipe: Junto com as setas de redirecionamento (> e >>), o pipe ( | ) é
muito usado em scripts e comandos diversos. Ele permite fazer com que
a saída de um comando seja enviada para outro ao invés de ser mostrada
na tela. Parece uma coisa muito exótica, mas acaba sendo incrivelmente
útil, pois permite "combinar" diversos comandos que originalmente não
teriam nenhuma relação entre si, de forma que eles façam alguma coisa
específica. Um exemplo simples é o "modprobe -l | more", que vimos
no tópico sobre o kernel, onde o pipe é usado para que a enorme lista
gerada pelo comando "modprobe -l" seja enviada ao "more", que se
encarrega de criar as quebras de página.
grep: O grep permite filtrar a saída de um determinado comando, de
forma que ao invés de um monte de linhas, você veja apenas a
informação que está procurando. Ele é frequentemente usado em
conjunto com o pipe, sobretudo em scripts.
Um exemplo simples: sua placa de rede não está funcionando e você
quer saber se o módulo de kernel "sis900", que dá suporte a ela, está
carregado. Você pode ver os módulos que estão carregados usando o
comando "lsmod", mas a lista é um pouco longa. Você poderia
completar o lsmod com o "| grep sis900", que vai filtrar usando o grep,
mostrando na tela apenas as linhas contendo "sis900". O comando
ficaria então "lsmod | grep sis900".
Se não aparecer nada na tela, você sabe de antemão que o módulo não
está ativo. Neste caso, você poderia tentar carregá-lo manualmente
usando o comando "modprobe sis900",como root.
Em um script, o mesmo comando poderia ser usado para detectar se o
módulo está carregado ou não e, a partir daí, mostrar uma mensagem na
tela, ou carregá-lo automaticamente.
Ao longo do livro, veremos mais alguns exemplos de uso do shell-script, esta
foi apenas uma introdução rápida destinada a apresentar alguns dos conceitos
básicos. Uma característica importante do shell-script é que assim que você
toma coragem e começa a escrever alguns scripts básicos, você acaba se
empolgando e passa a, gradualmente, incorporar novos truques, aprendendo
uma coisa aqui e outra ali, mesmo sem estudar especificamente sobre o
assunto.
 
Montando e desmontando
Antigamente, existia a concorrência entre HDs IDE (que eram vistos no
Linux como /dev/hdX) e HDs SCSI, vistos pelo sistema como "/dev/sdX". O
primeiro HD IDE seria detectado pelo sistema como "/dev/hda", o segundo
como "/dev/hdb" e assim por diante. Entretanto, mudanças feitas nas versões
recentes do kernel derrubaram essa divisão, fazendo com que todos os HDs,
independentemente de serem IDE ou SATA, passassem a ser vistos pelo
sistema como "/dev/sdX", como se fossem HDs SCSI. O HD principal passou
então a ser sempre visto como "/dev/sda".
Isso inclui até mesmo os pendrives, que são detectados pelo sistema como se
fossem HDs adicionais. Ao plugar dois pendrives, o primeiro seria
reconhecido como "/dev/sdb" e o segundo como "/dev/sdc".
Antes de instalar qualquer sistema operacional, é necessário particionar o
HD, criando as partições de instalação. Devido a uma limitação nos
endereços que vem desde a época dos primeiros PCs, é possível criar apenas
4 partições primárias, ou até três partições primárias e uma partição
estendida, que pode ser usada para criar mais partições.
Neste screenshot do Gparted, por exemplo, temos um HD dividido em 5
partições: /dev/sda1 (com uma instalação do Windows), /dev/sda2 (com uma
instalação do Ubuntu), /dev/sda3 (reservada à instalação de mais uma
distribuição), /dev/sda5 (swap) e /dev/sda6 (para arquivos).
A "/dev/sda4" é a partição estendida, que é criada automaticamente pelo
particionador quando você usa a opção de criar uma partição lógica, como
uma espécie de "container" para as demais partições. Você pode notar que o
tamanho especificado pelo particionador é o das duas partições somadas:
Embora não seja obrigatória em micros com um volume suficiente de
memória RAM, a partição swap é sempre recomendada, pois permite que o
sistema disponha de uma área adicional para situações em que precisa de uma
quantidade muito grande de memória RAM, como (por exemplo) ao editar
vídeos. A memória swap pode ser usada também para mover arquivos e
bibliotecas que não estão em uso, liberando mais memória RAM para uso dos
programas e do cache de disco.
A propensão do sistema a utilizar memória swap é configurável através de
uma opção do kernel, a "vm.swappiness", que aceita valores de 0 a 100,
sendo que um valor baixo orienta o sistema a usar swap apenas quando não
houver mais memória disponível e um valor mais alto faz com que o sistema
a utilize de maneira mais liberal, usando mais swap e tentando manter mais
memória RAM livre para outros usos.
O default na maioria das distribuições é "60", o que faz com que o sistema
use um pouco de swap mesmo quando tem memória de sobra disponível.
Você pode evitar isso alterando o valor para "20" (ou menos, de acordo com
o gosto do freguês).
Para isso, execute, como root, o comando:
# sysctl vm.swappiness=20
Para que a alteração se torne permanente, edite o arquivo "/etc/sysctl.conf" e
adicione a linha "vm.swappiness=20". Este arquivo contém variáveis para o
kernel, que são carregadas durante o boot. Ele pode ser usado também para
salvar outras configurações, como, por exemplo, as opções para ativar o
roteamento de pacotes, que são usadas ao compartilhar a conexão.
 
 Você pode ativar uma imagem de memória swap temporária criando um arquivo com a capacidade
desejada e montando-o como se fosse uma partição de memória swap. O desempenho será mais baixo do
que ao usar uma partição swap real, mas ainda assim é um bom truque, que você pode usar em emergências.
O primeiro passo é criar o arquivo vazio, usando o comando dd, especificando o tamanho, em kbytes. No
exemplo, estou criando um arquivo com 512 MB:
# dd if=/dev/zero of=swap.img bs=1024 count=512000
Ele simplesmente escreverá zeros dentro do arquivo "swap.img" (criado dentro do diretório atual), até
atingir o tamanho indicado. Apesar de simples, o dd é um comando bastante poderoso, que pode ser usado
para clonar HDs, destruir dados em partições e assim por diante, por isso tome sempre muito cuidado ao
usá-lo.
Com o arquivo criado, use o comando "mkswap" para formatá-lo e em seguida o "swapon" para que ele seja
ativado:
# mkswap swap.img 
# swapon swap.img
Rodando o comando "free", você verá que o total de memória swap terá aumentando, já que o arquivo passa
a ser usado como um swap complementar. O arquivo temporário é desativado automaticamente ao reiniciar
o micro, mas você pode fazê-lo a qualquer momento usando (dentro do diretório onde foi criado o arquivo)
o comando "swapoff swap.img".
Voltando à questão das partições, o sistema nunca acessa os dados dentro da
partição diretamente. Ao invés disso, ele permite que você "monte" a partição
em uma determinada pasta e acesse os arquivos dentro da partição através
dela, o que nos leva ao comando "mount".
A sintaxe básica inclui o dispositivo e a pasta onde ele será acessado, como
em:
# mount /dev/sdb1 /mnt/sdb1
Na hora de desmontar a partição, você pode especificar tanto o dispositivo,
quando a pasta onde ele foi montado, como em:
# umount /mnt/sdb1
No caso do CD-ROM, citamos apenas o dispositivo, sem incluir a partição (já
que, diferente de um HD, um CD-ROM não pode ser particionado). Você
pode tanto usar o dispositivo correto, como "/dev/hdc" ou "/dev/hdd", quanto
usar o "/dev/cdrom", um link que é criado pelo sistema apontando para a
localização correta:
# mount /dev/cdrom /mnt/cdrom
Se quiser trocar o CD que está na bandeja, você deve primeiro "desmontar" o
CD-ROM, com o comando "umount /mnt/cdrom". O mesmo se aplica a
pendrives e HDs externos: é sempre necessário desmontar antes de remover o
dispositivo. No caso dos pendrives e HDs, desmontar é fundamental, pois as
alterações não são necessariamente salvas imediatamente por causa do cache
de disco. Removendo sem desmontar, existe uma probabilidade muito grande
das últimas alterações serem perdidas. É muito comum as pessoas gravarem
arquivos no pendrive, desplugarem logo depois (sem desmontar) e, ao tentar
acessá-los depois, perceberem que os arquivos simplesmente não foram
gravados.
Os pontos de montagem, ou seja, as pastas onde as partições serão montadas,
podem ser configurados através do arquivo "/etc/fstab". Quase sempre este
arquivo é configurado durante a instalação do sistema, incluindo referências a
todas as partições e CD-ROMs disponíveis, de forma que você pode montar
as partições digitando apenas "mount /dev/sdb1" (por exemplo), sem precisar
usar o comando completo.
Uma dúvida comum é a mensagem "device is busy", que é muitas vezes
exibida ao tentar desmontar um pendrive, ejetar um CD-ROM ou desmontar
uma partição de arquivos do HD, como em:
# umount /mnt/sdb1
 umount: /: device is busy.
Este erro acontece sempre que existe algum programa acessando a partição
como, por exemplo, uma janela do gerenciador de arquivos, um player de
áudio tocando músicas salvas dentro dela, ou mesmo uma janela de terminal
acessando a pasta.
Você pode descobrir o culpado usando o comando "lsof", que lista os
programas que estão acessando a pasta e impedindo a desmontagem. Você
pode chamá-lo tanto especificando a partição, como em "/dev/sdb1", quanto
especificando a pasta onde ela está montada, como em:
$ lsof /mnt/sdb1
Na primeira coluna da lista, você encontra o nome dos programas e na
segunda coluna, o PID, que é o número do processo, que pode ser usado
como último recurso para fechar o programa "na marra",usando o comando
"kill -9".
Outra opção é usar o comando "fuser -k", que tenta finalizar à força todos os
programas que estiverem acessando a pasta. Ele não é muito recomendável,
pois os resultados são mais imprevisíveis, mas ele pode ser usado em
emergências quando, por exemplo, você não consegue ejetar o CD-ROM por
que o sistema se recusa a desmontá-lo. Basta especificar a pasta, como em:
$ fuser -k /media/cdrom
Embora continuem sendo importantes e bastante úteis na hora de solucionar
problemas ou criar configurações personalizadas, os comandos manuais são
cada vez menos usados no dia a dia, devido aos sistemas de montagem
automática utilizados nas distribuições.
O princípio é simples: o kernel detecta automaticamente quando novos
dispositivos de armazenamento são conectados, criando os dispositivos de
acesso e gerando mensagens que disparam a criação de ícones no desktop e
outras funções. Ao plugar uma câmera digital em modo de transferência de
dados, por exemplo, são inseridas mensagens como estas no log do sistema
(que você pode ver usando o comando "dmesg"):
[254728.281982] scsi 8:0:0:0: Direct-Access Sony Sony DSC 6.00 PQ: 0 ANSI: 0 CCS 
[254728.286070] sd 8:0:0:0: [sdb] 3973120 512-byte hardware sectors (2034 MB) 
[254728.287330] sd 8:0:0:0: [sdb] Write Protect is off 
[254728.287336] sd 8:0:0:0: [sdb] Mode Sense: 00 00 00 00 
[254728.287342] sd 8:0:0:0: [sdb] Assuming drive cache: write through 
[254728.298707] sd 8:0:0:0: [sdb] 3973120 512-byte hardware sectors (2034 MB) 
[254728.299830] sd 8:0:0:0: [sdb] Write Protect is off 
[254728.299836] sd 8:0:0:0: [sdb] Mode Sense: 00 00 00 00 
[254728.299840] sd 8:0:0:0: [sdb] Assuming drive cache: write through 
[254728.299850] sdb: sdb1
Pelas mensagens, é possível descobrir que foi plugada uma câmera digital da
Sony, com um cartão de memória de 2 GB com uma única partição de dados,
que foi detectada pelo sistema como "/dev/sdb1". Juntamente com a geração
das mensagens, o kernel cria uma pasta dentro do diretório /sys
("/sys/block/sdb/sdb1 " no exemplo), contendo mais informações sobre o
dispositivo.
Naturalmente, essas informações não interessam muito ao usuário, que está
apenas querendo acessar as fotos, e não ver detalhes sobre o número de
blocos do cartão ou sobre os endereços usados. Entram em cena então
sistemas de detecção, que monitoram estas informações e executam as ações
apropriadas.
Em distribuições antigas o trabalho era feito através de shell-scripts, mas nas
atuais entra em cena o HAL (Hardware Abstraction Layer), um serviço de
sistema que se encarrega de fazer o "trabalho sujo", monitorando as
informações disponibilizadas pelo kernel (e não mais simplesmente
monitorando os arquivos de log) e transmitindo as informações para os
aplicativos.
Ele é representado pelo serviço "hald" (que fica ativo por padrão na maior
parte das distribuições atuais) e trabalha em conjunto com o serviço "dbus",
que controla a comunicação entre ele e os aplicativos. Caso esteja curioso, as
informações coletadas por ele podem ser exibidas usando o comando "lshal",
que exibe a longa lista de informações que é monitorada pelos aplicativos.
Se você rodar o comando "ps aux | grep hald" em uma distribuição atual, vai
perceber que existem várias ramificações do hald, responsáveis por monitorar
diferentes dispositivos da máquina. O "pooling /dev/sdb (every 2 sec)" no
screenshot, por exemplo, indica que ele está monitorando o dispositivo da
câmera, realizando checagens a cada dois segundos:
O HAL é integrado a componentes do GNOME e do KDE, que se
encarregam de mostrar mensagens quando novos dispositivos são plugados e
executar outras funções. Ao plugar uma câmera digital, por exemplo, a
presença de arquivos de imagem faz com que o utilitário ofereça a opção de
abrí-las diretamente com um gerenciador de fotos, em vez de simplesmente
mostrar os arquivos:
No caso dos cartões de memória, pendrives e outros dispositivos de
armazenamento removíveis, as partições são montadas automaticamente em
pastas dentro do diretório "/media" e (na maioria das distribuições) é criado
um ícone no desktop, acompanhado pela abertura de uma janela do
gerenciador de arquivos. Ao clicar com o botão direito sobre o ícone, você
tem a opção de desmontar a partição.
As partições são montadas de forma automática conforme você clica sobre os
ícones, sem que você precise fornecer a senha de root. O HAL se encarrega
de ajustar as permissões de acesso, de forma que os arquivos fiquem
disponíveis apenas para o seu login (os parâmetros são detalhados no arquivo
"/media/.hal-mtab"). Este sistema permite também manter a segurança em
servidores de terminais e outros sistemas usados por diversos usuários
simultaneamente.
Você vai notar ainda que as entradas referentes às partições de dispositivos
removíveis não são mais inseridas no fstab, uma vez que a montagem e a
desmontagem é feita diretamente pelo HAL.
 
 Além de ser responsável pelo acesso a dados em dispositivos removíveis, o HAL é utilizado em
diversas outras funções do sistema. É ele o responsável por detectar quando um cabo de rede é plugado e
transmitir a informação ao NetworkManager, para que ele possa ativar a rede automaticamente, ou por
fornecer as informações sobre o hardware da máquina para que o gerenciador de drivers restritos do Ubuntu
possa instalar os módulos necessários, por exemplo.
Outro sistema que permite que as partições sejam montadas e desmontadas
sem que você precise fornecer a senha de root é o "fuse", um módulo do
kernel que permite fazer uma montagem "particular". Ele é usado por
diversos aplicativos, entre eles o sshfs, que é usado para montar pastas em
servidores remotos via SSH.
Concluindo, de vez em quando (sobretudo em máquinas com vários HDs ou
com um HD dividido em várias partições de dados), você vai notar que o
boot demora bem mais do que o normal. Se você desativar o splash (para ter
acesso às mensagens exibidas no terminal), verá que a demora é causada por
mensagens como esta:
/dev/sdb1 has been mounted 60 times without being checked, check
forced.
Ela ocorre devido a uma precaução do sistema contra a possibilidade de perda
de arquivos devido a problemas na estrutura da partição. Todos os sistemas
de arquivos atuais utilizam um sistema de journaling, que armazena uma lista
das alterações feitas. Sempre que a partição é montada, o sistema verifica o
journal, concluindo qualquer operação pendente, um teste rápido que não é
inteiramente à prova de falhas.
Para evitar a possibilidade de que pequenos problemas na estrutura da
partição se acumulem até se tornarem um problema maior, o sistema executa
um teste mais demorado periodicamente, sempre que a partição é montada
um determinado número de vezes. Como as partições são geralmente
montadas durante o boot, é nele que a demora se manifesta.
É possível aumentar ou mesmo desativar o contador (usando o comando
"tune2fs"), mas isso não é muito recomendável. O melhor nesse caso é ter
paciência e simplesmente deixar o sistema fazer seu trabalho.
 
Usando o Gparted
O Gparted é uma espécie de particionador default no Linux. Ele vem pré-
instalado em diversas distribuições, incluindo o Ubuntu, onde fica disponível
através do "Sistema > Administração > Editor de Partições". Está disponível
também o Gparted Live, um live-CD enxuto, destinado unicamente a rodar o
Gparted e assim oferecer uma ferramenta simples de particionamento do HD.
Você pode baixá-lo no: http://gparted.sourceforge.net/download.php
Por segurança, o Gparted se recusa a fazer modificações em partições que
estão montadas, o que é um problema ao rodá-lo a partir de uma instalação do
sistema no HD, já que você não tem como fazer alterações na partição de
instalação ou na partição home. A solução é utilizá-lo a partir de um live-CD,
onde você pode editar as partições sem limitações.
 
http://gparted.sourceforge.net/download.php
 Se o HD possuir uma partição swap, é bem provável que ela seja montada pelo live-CD durante o
boot e fique bloqueada no Gparted. Para solucionar isso,use (como root) o comando "swapoff" seguido pela
partição swap, como em:
# sudo swapoff /dev/sda5
De volta ao Gparted, clique no "Gparted > Atualizar Dispositivos" para que ele detecte a alteração e
desbloqueie a edição. O mesmo se aplica a pendrives e cartões de memória, que são montados
automaticamente quando plugados na maioria das distribuições atuais. É necessário desmontar as partições
antes que você consiga alterá-las no Gparted.
Assim como em outros particionadores, a interface é baseada em um "mapa"
do HD, que mostra as partições disponíveis e o espaço ocupado em cada
uma; informação bastante útil na hora de redimensionar partições. Clicando
com o botão direito sobre a partição, você tem acesso ao menu de ações, que
inclui as opções para deletar a partição, reformatá-la em outro sistema de
arquivos ou redimensioná-la.
Você pode usar o gparted para redimensionar a partição do Windows e
liberar espaço para a criação das partições Linux, que é, justamente, um dos
usos mais comuns. Para redimensionar, clique na partição e em seguida sobre
a opção "Redimensionar/Mover", onde você pode ajustar o novo tamanho da
partição.
Ele é capaz de redimensionar tanto partições FAT32 quanto NTFS e o
processo é bastante seguro. A única exigência é que, antes de redimensionar,
você precisa desfragmentar a partição (reinicie e use o defrag do próprio
Windows) para que os dados fiquem agrupados no início da partição e o
Gparted possa fazer seu trabalho sem riscos. Caso a partição não esteja
desfragmentada, ou contenha erros diversos, ele aborta a operação para evitar
qualquer possibilidade de perda de dados.
No Windows XP, o processo de redimensionamento é bastante tranquilo,
com o sistema continuando a iniciar normalmente depois da alteração. No
Windows Vista, entretanto, a checagem de hardware executada pelo sistema a
cada boot dispara uma mensagem de erro no boot seguinte, reclamando que a
inicialização do sistema falhou e que uma mudança no hardware da máquina
pode ser a causa.
Para resolver o problema, é necessário recuperar o sistema usando o DVD de
instalação. Dê um boot normal, como se fosse reinstalar o sistema e, depois
da seleção de linguagem, use a opção "Reparar o computador". Isso faz com
que ele verifique a partição e faça as atualizações necessárias. A partir daí,
basta clicar no "Reparar e reiniciar".
Continuando, você notará que, na maioria dos casos, algumas das opções de
sistemas de arquivos ficam desativadas no menu. Isso acontece por que o
Gparted é, na verdade, uma interface gráfica para vários aplicativos de modo
texto, que fazem o trabalho pesado. Ele precisa do pacote "ntfsprogs" para
manipular partições NTFS, do "reiserfsprogs" para manipular partições
ReiserFS e assim por diante. Ao ser aberto, ele verifica quais são os sistemas
de arquivos suportados pelo sistema e desativa os demais:
Ao criar novas partições, você tem a opção de criar uma partição primária ou
uma partição lógica. Como comentei anteriormente, a regra básica é que você
pode ter apenas 4 partições primárias, ou até 3 partições primárias e mais uma
partição estendida, contendo várias partições lógicas.
O mais comum é criar uma partição para a instalação do sistema no início do
HD, seguida pela partição swap e pela partição home (ou outras partições
destinadas a armazenarem arquivos).
No caso do Linux, não faz muita diferença se o sistema é instalado em uma
partição primária ou em uma partição lógica, mas ao instalar o Windows em
dual-boot, é sempre importante instalá-lo em uma partição logo no início do
HD (caso contrário ele atribuirá letras às partições Linux no início do HD,
criando problemas na instalação de diversos programas, que esperam que o
Windows esteja instalado no C:\).
As alterações não são feitas automaticamente. Depois de revisar tudo, clique
no "Aplicar" para que as modificações sejam aplicadas. Clicando no
"Detalhes", você pode acompanhar os passos que estão sendo executados.
Outra dica é que você pode "limpar" a MBR de pendrives e HDs, eliminando
todas as partições e qualquer gerenciador de boot instalado anteriormente,
limpando os primeiros 512 bytes do dispositivo, que correspondem ao MBR.
Isso pode ser feito rapidamente usando o comando dd, como em:
# dd if=/dev/zero of=/dev/sdd bs=512 count=1
Esse comando faz com que o dd escreva, cirurgicamente, 512 bytes no
primeiro setor do dispositivo indicado, limpando o setor de boot e a tabela de
partições.
É preciso tomar extremo cuidado ao usar este comando, pois se usado no seu
HD de trabalho, você vai simplesmente apagar todas as partições. Cheque e
recheque qual é o device correto da unidade que deseja limpar antes de
executar o comando. 
 
 É possível também remover apenas o gerenciador de boot (em casos em que você instalou o sistema
em um pendrive e agora não consegue se livrar da cópia do grub instalada nele, por exemplo), limpando
apenas os primeiros 446 bytes. Nesse caso, é preservada a tabela de particionamento, que é armazenada nos
66 bytes seguintes: dd if=/dev/zero of=/dev/sdd bs=446 count=1
Ao acessar o dispositivo no Gparted (após usar o comando), ele aparecerá
como "espaço não alocado". Para particioná-lo novamente e voltar a usá-lo,
use a opção "Dispositivo > Criar Tabela de Partição...", para que ele recrie a
tabela de partições:
Outra dica é que, em muitos micros, é preciso reiniciar depois de modificar o
particionamento do HD para que o sistema seja capaz de perceber as
alterações. A limitação neste caso é o BIOS da placa-mãe, que em muitos
casos só é capaz de ler a tabela de partições do HD durante o boot.
Concluindo, os sistemas de arquivos são sempre uma fonte comum de
dúvidas, vamos então a um resumo rápido sobre o tema:
FAT16: O FAT16 é um dos sistemas de arquivos mais simples ainda na
ativa. Devido ao uso de endereços de 16 bits, ele pode ser usado em
partições de no máximo 2 GB. Devido à simplicidade, ele é suportado
por câmeras, mp3players, celulares e diversos outros tipos de
dispositivos, daí o uso em cartões de memória.
FAT32: É similar ao FAT16, mas usa endereços de 32 bits, o que
permite o uso de partições maiores. O FAT32 é uma espécie de mínimo
múltiplo comum entre os sistemas de arquivos, pois as partições podem
ser acessadas sem dificuldades tanto no Windows quanto no Linux. Por
outro lado, ele possui diversas limitações, incluindo a ausência de
suporte à permissões, enorme tendência à fragmentação e o limite de 4
GB para o tamanho dos arquivos.
EXT2: Foi o primeiro sistema de arquivos a ser usado em larga escala
no Linux. O grande defeito é que ele não possui suporte a journaling, o
que obriga o sistema a fazer uma demorada verificação cada vez que o
PC é desligado incorretamente, além de aumentar a possibilidade de
perda de dados. É considerado obsoleto e raramente usado hoje em dia.
EXT3: É o sucessor do EXT2 e o sistema de arquivos usado por padrão
em praticamente todas as distribuições Linux atuais. A principal
diferença entre os dois é que o EXT3 suporta o uso de journaling, que
permite que o sistema de arquivos mantenha um relatório de todas as
operações e possa ser recuperado muito rapidamente em caso de pane,
ou quando o PC é desligado no botão. Ele é também um dos sistemas de
arquivos mais rápidos e oferece uma boa segurança contra perda de
dados.
ReiserFS: O ReiserFS foi o principal concorrente do EXT3 nos
primeiros anos. Ele oferece uma boa tolerância contra falhas, um bom
desempenho e um bom gerenciamento de arquivos pequenos. O grande
problema é que o ReiserFS v3 (a versão usada na maioria das
distribuições) não recebe grandes atualizações há muitos anos e o
desenvolvimento da versão 4 está paralisado. Isso faz com que ele não
seja uma boa opção hoje em dia.
NTFS: É o sistema de arquivos usado por padrão a partir do Windows
XP. Ele oferece muitas melhorias sobre o antigo FAT32 e suporta o uso
de partições maiores. Até recentemente, não existia suporte de escrita
em partições NTFS no Linux, o que dificultava a vida de quem usava os
dois sistemas em dual-boot, mas isso foisolucionado com o NTFS-3G,
que é usado por padrão na maioria das distribuições atuais.
XFS e JFS: Estes são dois sistemas de arquivos muito usados em
servidores, que oferecem vantagens sobre o EXT3 em algumas áreas. O
XFS permite redimensionar partições sem desligar o sistema e oferece
um suporte aprimorado a quotas de disco, enquanto o JFS oferece um
melhor desempenho em algumas tarefas comuns em servidores, por
exemplo. Entretanto, eles não são muito recomendáveis para uso em
desktops, onde o EXT3 é uma solução muito mais simples.
EXT4: É o sucessor do EXT3, que começou a ser usado a partir do
início de 2009. Ele incorpora diversas melhorias, incluindo um novo
sistema de alocação de espaço, que reduz a fragmentação dos arquivos,
melhorias no desempenho e suporte a arquivos de até 16 terabytes
(contra o máximo de 2 terabytes do EXT3). É prudente aguardar até que
ele comece a ser usado por default nas principais distribuições antes de
começar a usá-lo.
Linux-Swap: É a opção destinada a criar uma partição swap. Diferente
do Windows, onde o swap é feito em um arquivo, no Linux é usada um
partição separada, que utiliza um sistema de arquivos otimizado para a
tarefa.
 
O X e as interfaces
Outro componente base do sistema, usado em todas as distribuições, é o
servidor gráfico, o famoso "X". Antes do X, o Linux tinha apenas a velha
interface de modo texto, o que explicava o fato de ele ser popular apenas
entre programadores e administradores de sistemas.
Diferentemente do que temos no Windows, onde a interface gráfica é um
componente essencial do sistema, no Linux o modo gráfico é uma camada
independente. Temos um "servidor gráfico", o X, que provê a infra-estrutura
necessária. É ele que controla o acesso à placa de vídeo, lê as teclas digitadas
no teclado e os clicks do mouse, e oferece todos os recursos necessários para
os programas criarem janelas e mostrarem conteúdo na tela.
Se você chamar o X sozinho, a partir do modo texto (o que pode ser feito
com o comando "X" ou "X :2" caso você queira abrir uma segunda seção),
você verá apenas uma tela cinza, com um X que representa o cursor do
mouse. Em outras palavras, o X é apenas uma base, ele sozinho não faz muita
coisa:
Se você chamá-lo com o comando "xinit" ou "xinit -- :2", ele abrirá junto
uma janela de terminal, que poderá ser usada para abrir programas. Porém, ao
abrir qualquer programa gráfico, você perceberá que algo está estranho. A
janela do programa é aberta, mas fica fixa na tela; você não tem como
minimizá-la, alternar para outra janela, nem nenhuma outra opção.
Isto acontece porque estas tarefas são controladas pelo gerenciador de
janelas, que (em quase todas as distribuições) não é carregado com o
comando xinit. Chamando o X através do comando "startx", ou configurando
o sistema para carregar o X automaticamente durante a inicialização (que é o
default em praticamente todas as distribuições), finalmente carregamos o
conjunto completo, com o X e um desktop completo rodando sobre ele; um
ambiente de trabalho mais produtivo:
Existem inúmeros gerenciadores de janelas diferentes para o Linux, uma lista
que inclui o LXDE, FluxBox, Window Maker, XFCE, Enlightenment e
muitos outros. Depois deles, temos o KDE e o GNOME, que se enquadram
em uma categoria à parte: a dos ambientes desktop (desktop environment, ou
DE).
Em vez de se limitarem a serem apenas gerenciadores de janelas, eles
incluem um enorme conjunto de componentes e de aplicativos, desenvolvidos
de forma a oferecerem um ambiente de trabalho consistente, onde todos os
aplicativos se comportam de forma similar, compartilham do mesmo tema
visual, utilizam os mesmos atalhos de teclado e assim por diante. Eles
incluem também bibliotecas e ferramentas de desenvolvimento, que oferecem
um ambiente completo para quem desenvolve aplicativos.
O KDE segue uma abordagem mais configurável, oferecendo um grande
volume de opções de configuração e uma interface mais parecida com a do
Windows. O GNOME, por outro lado, segue a linha do Mac OS X,
oferecendo um ambiente mais simples (porém não necessariamente mais
leve), com menos opções de configuração. A vantagem da abordagem do
GNOME é que o ambiente é mais amigável para novos usuários, mas, por
outro lado, ele acaba desagradando muitos usuários antigos, que sentem falta
de um ambiente mais configurável, como no KDE.
A vantagem de ter dois ambientes diferentes é que você pode escolher qual
usar, exercitando sua liberdade de escolha. Nada impede também que você
rode aplicativos do KDE (como o Konqueror e o K3B) sobre o GNOME, ou
vice-versa, utilizando os melhores componentes de cada ambiente.
O problema em misturar aplicativos é que seu ambiente de trabalho deixa de
ser consistente, já que os aplicativos do KDE utilizam um conjunto de
configurações diferentes das do GNOME. Você acaba tendo então que
configurar os aplicativos das duas famílias de forma distinta, usando o
kcontrol ou o Systemsettings para ajustar as configurações dos aplicativos do
KDE e o gnome-appearance-properties (e os demais aplicativos do painel de
preferencias do GNOME) para ajustar as configurações dos aplicativos do
GNOME:
Configurações diferentes para os aplicativos do GNOME e do KDE
Existe ainda o problema do desempenho. Misturando aplicativos dos dois
ambientes o sistema precisa manter as duas bibliotecas carregadas, o que
consome mais memória RAM e processamento. Os próprios aplicativos
demoram mais para carregar "fora de casa", pois é preciso primeiro carregar
as bibliotecas e outros componentes necessários para depois começar o
carregamento do aplicativo em si. Um exemplo clássico é o Konqueror, que
abre quase que instantaneamente no KDE, mas pode demorar quase 10
segundos para carregar no GNOME.
Essas dificuldades fazem com que a maioria das distribuições dêem
preferência para um dos dois ambientes, priorizando os aplicativos e
ferramentas de configuração desenvolvidas para ele.
Isso explica por que o Ubuntu é centralizado em torno de aplicativos do
GNOME (mesmo as versões recentes continuam usando os componentes do
GNOME, apesar do uso do Unity como interface), enquanto no Kubuntu eles
são substituídos por aplicativos similares da família do KDE, por exemplo.
Isso acaba pesando na escolha da distribuição: se você prefere o KDE, vai se
sentir mais à vontade usando o Mageia ou o Kubuntu do que usando o
Ubuntu ou o Fedora, por exemplo; e vice-versa.
Pesquisando sobre o KDE por aí, você encontrará referências a um problema
relacionado à licença da biblioteca Qt, que leva muitos a dizerem que o KDE
"não é livre" até os dias de hoje. Em 1997, quando o KDE começou a ser
desenvolvido, a biblioteca Qt era de uso gratuito, mas não tinha o código
aberto, o que gerou uma grande polêmica e levou ao surgimento do GNOME,
baseado na biblioteca GTK (que já era largamente utilizada em aplicativos
como o Gimp).
Com o crescimento do KDE e a possibilidade de formar uma grande
comunidade de desenvolvedores, que impulsionariam o desenvolvimento e o
uso da sua biblioteca, a TrollTech resolveu liberar a Qt sob a GPL em
setembro de 2000, o que removeu este entrave inicial. Em 2009, a Qt foi
licenciada sob a LGPL, que é uma licença ainda mais liberal, que permite o
uso também em aplicativos de código fechado.
Assim como em outros casos, tanto o KDE quanto o GNOME passaram por
muitas mudanças ao longo de sua história. O KDE passou por 3 grandes
transformações: do KDE 1 para o KDE 2, do KDE 2 para o KDE 3 e, mais
recentemente, do KDE 3 para o KDE 4, que trouxe uma interface quase que
completamente redesenhada e um novo painel de controle. Por ser baseado
em uma versão diferente da biblioteca Qt, o KDE 4 trouxe também versões
diferentes dos aplicativos, que precisaram ser portados. Muitos dos
aplicativos usados no KDE 3 foram abandonados no processo, sendo
substituídos por outros.
O GNOME também passou por uma grande transformação com o lançamento
do GNOME 2 em 2002, que marcou a migração da biblioteca GTK para a
GTK2, uma versão atualizada que, embora mais pesada, oferecebem mais
funções. Assim como no caso do KDE 4, a migração resultou em grandes
mudanças na interface e nas opções de configuração. De lá pra cá, o GNOME
passou a evoluir de maneira gradual, mantendo um ambiente mais ou menos
consistente entre as versões. Esta estabilidade foi um fator que ajudou no
crescimento e na popularização da interface.
 
Gerenciador de login
Antigamente, era muito comum dar boot em modo texto e deixar para abrir o
X manualmente rodando o comando "startx" apenas quando necessário, pois
os PCs eram lentos e o X demorava para abrir.
Atualmente, o mais comum é usar um gerenciador de login, como o KDM
(do KDE) ou o GDM (do GNOME). O gerenciador de login tem a
importante função de carregar o X, mostrar uma tela de login gráfica e, a
partir dela, carregar o ambiente gráfico. Quando o gerenciador de login é
fechado (ou deixa de funcionar por qualquer motivo), todo o ambiente
gráfico deixa de funcionar, jogando-o de volta ao terminal em texto.
O gerenciador de login é aberto como um serviço de sistema, da mesma
forma que o Apache e outros servidores. Você pode parar o KDM e assim
fechar o modo gráfico usando o comando "/etc/init.d/kdm stop" e reabri-lo a
partir do modo texto com o comando "/etc/init.d/kdm start". No caso do
GDM, são usados os comandos "/etc/init.d/gdm stop" e "/etc/init.d/gdm
start".
Como sempre, tudo é aberto através de um conjunto de scripts. O KDM
guarda a base das configurações no arquivo "/etc/kde3/kdm/kdmrc" (ou
"/usr/share/config/kdm/kdmrc", dependendo da distribuição) e coloca um
conjunto de scripts de inicialização, um para cada interface instalada, dentro
da pasta "/usr/share/apps/kdm/sessions/".
A configuração do kdmrc permite as opções da tela de login, que vão desde
opções cosméticas até a opção de aceitar que outras máquinas da rede rodem
aplicativos remotamente, via XDMCP. Ao fazer login, é executado o script
correspondente à interface escolhida. Ao usar o KDE, por exemplo, é
executado o script "/usr/share/apps/kdm/sessions/kde".
Até mesmo o comando startx é um script, que geralmente vai na pasta
"/usr/X11R6/bin/". Você pode alterá-lo para carregar o que quiser, mas
normalmente ele carrega o gerenciador especificado no arquivo .xinitrc,
dentro da pasta home do usuário.
Naturalmente, tudo isso se aplica apenas a situações onde você quer alterar a
configuração do sistema manualmente. Você pode também alterar as
configurações do KDM através do systemsettings, no "Avançado > Gestor de
Autenticação". No GNOME, você pode alterar as configurações do GDM
usando o "gdmsetup", disponível no "Sistema > Administração > Janela de
início de sessão":
Ele permite ativar o login automático, liberar o login como root (o que não é
aconselhável do ponto de vista da segurança, mas acaba sendo uma questão
de honra para alguns), alterar o aspecto visual ou mesmo ativar o uso do
XDMCP, que é o sistema de acesso remoto suportado nativamente pelo X.
Embora tenha caído em popularidade devido ao uso do SSH, ele é ainda
bastante usado. 
 
 Em geral, as distribuições que utilizam o KDE como interface padrão usam o KDM, enquanto as que
utilizam o GNOME preferem o GDM. Isto tem a ver com o problema das bibliotecas: ao carregar apenas um
programa baseado nas bibliotecas do KDE dentro do GNOME ou vice-versa, são carregadas todas as
bibliotecas correspondentes, não há o que fazer. O programa demora mais para abrir, e no final, o sistema
acaba consumindo muito mais memória.
 
Xkill e processos
Embora o kernel Linux seja extremamente estável, a ponto de ser usado em
sistemas de missão crítica, o mesmo não se aplica, necessariamente, a todos
os inúmeros aplicativos que usamos no dia a dia. Tanto o GNOME quanto o
KDE são plataformas bastante complexas, compostas por um número muito
grande de componentes que trocam informações entre si. Não é de se
estranhar que, às vezes, algo dê errado.
Para complicar, o rápido desenvolvimento do sistema e a necessidade por
novos aplicativos acabam fazendo com que, muitas vezes, as distribuições
tragam aplicativos ainda em estágio beta, ou que ainda não estejam
completamente estáveis, o que acaba resultando em travamentos ou em
outros problemas diversos.
A vantagem do Linux neste ponto é que você quase nunca precisará reiniciar
todo o sistema, basta matar o aplicativo problemático, ou, no pior dos casos,
reiniciar o ambiente gráfico.
A forma mais prática de finalizar aplicativos é usar o xkill, o "matador de
programas" incluído no X. Ele pode ser chamado pressionando
"Ctrl+Alt+Esc", chamando o comando "xkill" usando o "Alt+F2" (que abre
a janela do "Executar aplicativo") ou diretamente através do terminal.
Ao ativar o xkill, o cursor do mouse vira um X (ou uma caveira, de acordo
com a distribuição) e basta clicar sobre a janela do aplicativo travado para
encerrá-lo na marra:
O xkill simplesmente finaliza a primeira janela sobre a qual clicar, sem
nenhuma confirmação adicional, por isso é importante chamá-lo com a janela
em vista. Você pode "desarmar" o xkill depois de ativado, usando o botão
direito do mouse.
Uma observação importante é que, por default, o Ubuntu não oferece um
atalho de teclado para matar aplicativos travados usando o xkill, diferente de
outras distribuições, onde é usado o "Ctrl+Alt+Esc". Com isso, você acaba
sendo obrigado a pressionar Alt+F2 e rodar o comando "xkill" manualmente,
o que não é muito prático.
Aplicativos travados são um problema que ocorre mesmo nas melhores
famílias, por isso uma forma rápida de acabar com eles acaba sendo
importante. Vamos então à explicação de como recriar o atalho para o xkill
no Ubuntu, aproveitando para falar sobre a configuração de atalhos no
GNOME.
A maneira tradicional de definir atalhos no GNOME é usar o "System >
Preferências > Atalhos de teclado", onde você pode especificar as teclas de
atalho para um conjunto de ações pré-definidas:
O problema é que o atalho para o xkill não está disponível na lista, o que nos
obriga a adotar o procedimento manual.
Para isso, comece abrindo o "gconf-editor" usando o Alt+F2 (ou através do
terminal). Dentro dele, acesse o "/apps/metacity/keybinding_commands" e,
no campo "command_1" especifique "/usr/bin/xkill", que é o caminho
completo para o comando:
Em seguida, acesse o "/apps/metacity/global_keybindings" e especifique o
atalho de teclas que acionará o comando, como em "<Ctrl>Escape"
(Ctrl+Esc), "<Ctrl><Shift>K" (Ctrl+Shift+K) ou outro atalho que preferir.
Como comentei anteriormente, o default é o "Ctrl+Alt+Esc", mas no
GNOME o atalho já é usado para alternar entre as janelas, por isso você vai
primeiro precisar redefiní-lo se quiser dedicá-lo ao xkill):
Você pode usar essa mesma dica para definir atalhos para outros aplicativos,
basta usar outros campos disponíveis no
"apps/metacity/keybinding_commands" para indicar o comando e, em
seguida, especificar o atalho de teclado no
"apps/metacity/global_keybindings".
Voltando à questão dos aplicativos travados, em situações mais graves, onde
o mouse parar de responder e o ambiente gráfico ficar congelado, você pode
reiniciar o X (o que reabre toda a parte gráfica) pressionando
"Ctrl+Alt+Backspace". Embora você possa perder arquivos não salvos, esta é
uma solução muito menos radical (e mais rápida) do que reiniciar o micro no
botão.
Outra opção é mudar para um dos terminais de texto puro, pressionando
Ctrl+Alt+F1 (ou qualquer outra das teclas F, até a F6) e finalizar o aplicativo
que está bloqueando o ambiente gráfico. Se você sabe qual é o culpado (ou
pelo menos suspeita quem seja), pode finalizá-lo usando o comando "killall",
como em "killall totem" ou "killall firefox" 
O problema com o killall é que, em muitos casos, o comando para fechar o
programa não é o mesmo que seu nome. Para os casos onde você não souber
o nome correto do programa, existe o comando "ps", que mostra todos os
processos abertos. Existem várias opções para este comando; a que costumo
usar mais frequentemente é "ps x | more", que mostra todos os processos
iniciados usando o seu login de usuário, sempredando uma pausa quando a
lista encher a tela:
Na lista, os nomes dos aplicativos aparecem na coluna da direita. Veja que,
em muitos casos, o mesmo programa aparece várias vezes; seja porque você
abriu várias instâncias, seja por ele realmente ser dividido em vários
processos diferentes. A boa notícia é que o killall se encarrega de acabar com
todos.
Na coluna da esquerda está o PID de cada processo, um número de
identificação que pode ser usado em conjunto com o comando kill para matar
um processo específico, como em "kill 4060". Muitos aplicativos aparecem
na lista com nomes gigantes, de forma que é mais fácil fechá-los pelo
número.
Em casos mais extremos, de aplicativos rebelados que não respondam ao
chamado do killall ou do kill, você pode resolver o problema adicionando um
"-9" no comando, como em:
# kill -9 6340
A diferença entre o "kill" ou o "killall" e o "kill -9" é que no primeiro caso o
sistema envia um "bilhete azul" ao aplicativo, solicitando que ele desocupe o
lugar. O "kill -9", por sua vez, é um comando que orienta o sistema a fechar o
aplicativo na marra, mandando os seguranças para removê-lo à força.
Além do "ps -x", você pode tentar o "ps -aux", que inclui todos os processos
ativos. A lista é sempre longa, pois inclui todos os serviços e componentes do
sistema que são carregados automaticamente durante o boot. Outro programa
de texto com a mesma função é o pstree. Ele mostra os processos na forma
de uma árvore, permitindo que você veja como eles se relacionam.
Como em outros casos, você pode também acompanhar os aplicativos de uma
maneira mais amigável usando os monitores de sistema. Se você estiver no
KDE, pode gerenciar os processos de uma forma muito mais amigável
usando o Ksysguard. Basta procurar por ele no iniciar ou pressionar
"Ctrl+Esc" para abri-lo. 
No GNOME, está disponível o "Monitor de Sistema", que pode ser aberto
através do "Sistema > Administração", ou usando o comando "gnome-
system-monitor". Além de mostrar os aplicativos ativos e oferecer a opção de
finalizá-los, ele inclui também informações sobre o uso do processador, uso
de memória e até mesmo sobre o espaço livre nas partições:
Outra opção importante é a "Alterar prioridade", que serve como uma
interface para o comando "nice", que permite ajustar o nível de prioridade do
aplicativo em relação aos demais. Por default, todos os aplicativos (com
exceção de alguns componentes do sistema) utilizam o valor "0", o que os
coloca todos no mesmo nível.
Uma boa maneira de evitar que aplicativos que consumam muito
processamento (como ao converter vídeos) deixem o sistema lento, é
simplesmente ajustar a opção, usando um valor mais alto, entre 5 e 10. Isso
faz com que o aplicativo seja mais bonzinho e passe a usar os ciclos ociosos
de processamento, sem atrapalhar os outros:
 
Boot, serviços e arquivos de inicialização
Ao ligar o micro, o primeiro software que é carregado é o BIOS da placa-
mãe. Ele faz a contagem da memória RAM e realiza uma checagem rápida
dos dispositivos instalados.
Depois de fazer seu trabalho, o BIOS carrega o sistema operacional, que pode
ser carregado a partir de diversas fontes, incluindo o HD, um CD-ROM ou
DVD, um pendrive, ou até mesmo via rede (como é feito no LTSP e em
outros sistemas de terminais leves), respeitando a ordem definida na
configuração do Setup.
No caso dos HDs, é lido o primeiro setor do disco rígido, o famoso "Master
Boot Record" ou MBR. Nele é gravado o gerenciador de boot, que é o
responsável pelo carregamento do sistema. É a presença dele que permite que
você instale mais de um sistema operacional no mesmo micro e possa
escolher entre eles na hora do boot.
No Linux, o gerenciador mais usado é o grub (com uma pequena
participação do lilo), enquanto no Windows, é usado o NTLDR. O MBR tem
espaço para apenas um gerenciador de boot, por isso é preciso prestar atenção
na configuração ao instalar vários sistemas, já que, por default, cada sistema
subscreve o gerenciador de boot do anterior ao ser instalado.
Apesar de sua vital importância, o MBR engloba um único setor do HD,
meros 512 bytes. Devido a isso, ele é, na verdade, usado para armazenar
apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o
executável do gerenciador de boot em um ponto específico do HD.
O bootstrap do gerenciador de boot utiliza os primeiros 446 bytes do MBR.
Os 66 bytes restantes são usados para armazenar a tabela de partições, que
guarda informações sobre onde cada partição começa e termina. Programas
de particionamento, como o cfdisk, nada mais fazem do que alterar as
informações na tabela de partições. Quando ela é perdida ou danificada (seja
qual for o motivo), todas as partições desaparecem e você precisa ir atrás de
um programa de recuperação de dados.
O gerenciador de boot tem a função de carregar o kernel e, a partir dele, todo
o restante do sistema. Tanto o grub quando o lilo podem ser configurados
para carregar também o Windows ou outros sistemas instalados em dual-boot
ou multi-boot. A maioria das distribuições atuais configuram isso
automaticamente durante a instalação. 
Inicialmente, o kernel é um arquivo compactado e somente-leitura, o
"/boot/vmlinuz". Logo no início do boot, ele é descompactado em uma área
reservada da memória RAM e roda a partir daí, aproveitando o fato de que a
memória RAM é muito mais rápida que o HD. Este executável principal do
kernel nunca é alterado durante o uso normal do sistema, ele muda apenas
quando você recompila o kernel manualmente ou instala uma nova versão.
Depois de carregado, a primeira coisa que o kernel faz é montar a partição
raiz, onde o sistema está instalado, inicialmente como somente-leitura. Neste
estágio ele carrega o init, o software que inicia o boot normal do sistema,
lendo os scripts de inicialização e carregando os módulos e softwares
especificados neles. O arquivo de configuração do init é o "/etc/inittab". Ele
é geralmente o primeiro arquivo de configuração lido durante o boot.
Todas essas etapas são realizadas por scripts, localizados na pasta
"/etc/init.d", que executam os comandos apropriados para inicializar os
serviços e executar as demais operações necessárias. Alguns deles são
executados apenas durante o boot (verificando alguma configuração, por
exemplo), enquanto outros inicializam serviços que ficam ativos
continuamente.
Um bom exemplo é o cups, que é o serviço responsável pelo suporte a
impressão. Ele é usado tanto para imprimir em impressoras locais quando em
impressoras de rede e é usado também quando você precisa compartilhar a
impressora com outras máquinas da rede. Ele vem instalado por padrão em
quase todas as distribuições e é controlado através do script "/etc/init.d/cups"
(ou "/etc/init.d/cupsys", dependendo da distribuição).
Se você quisesse desativá-lo temporariamente, por exemplo, usaria:
# /etc/init.d/cups stop
Para ativá-lo novamente depois, usaria:
# /etc/init.d/cups start
O mesmo se aplica a quase todos os outros serviços, como no caso do
"samba" (responsável pelo compartilhamento de arquivos), o "bluetooth"
(responsável pelo suporte a transmissores Bluetooth) e assim por diante. Eles
são também chamados de "daemons", um termo usado em relação a serviços
que ficam ativos continuamente, executando alguma função.
O que determina se cada serviço vai ser ou não ativado durante o boot, não é
o fato de estar ou não instalado, mas sim, a presença de um link simbólico
criado dentro de uma das pastas de inicialização do sistema. Por padrão, são
executados primeiro os links que estão dentro da pasta "/etc/rcS.d/" (que
inclui os serviços essenciais, executados logo no início do boot) e, em
seguida, os links dentro da pasta "/etc/rc5.d/", que inclui os demais serviços.
O número (5 no exemplo) indica o runlevel que será usado, que pode ser um
valor de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto
diferente de scripts de inicialização. Esta foi uma forma encontrada pelas
distribuições para ter vários "profiles", que podem ser usados de acordo com
a situação.A configuração mais comum é usar o runlevel 1 como um modo de
recuperação, no qual apenas os serviços essenciais para concluir o boot são
carregados, sem ambiente gráfico e sem suporte a rede. Hoje em dia, o
runlevel 1 é pouco usado, pois é mais fácil corrigir problemas dando boot
com um live-CD e resolvendo os problemas através dele, mas a possibilidade
continua disponível.
Em seguida temos o runlevel 3, onde quase todos os serviços são carregados,
com exceção do ambiente gráfico (este modo é muito usado em servidores).
Finalmente, temos o runlevel 5, que corresponde ao modo "normal", onde o
ambiente gráfico é carregado, junto com todos os outros serviços. Como em
outros casos, existem variações; o Slackware, por exemplo, utiliza o runlevel
4 para carregamento do ambiente gráfico, enquanto o Ubuntu usa um sistema
completamente diferente.
Usando o runlevel 5, são carregados os scripts colocados dentro da pasta
"/etc/rc5.d/", enquanto que, usando o runlevel 3, são carregados os scripts
dentro da pasta "/etc/rc3.d/". Nada impede que você modifique a organização
dos arquivos manualmente, de forma a fazer o X carregar também no
runlevel 3, ou qualquer outra coisa que quiser. São apenas pastas com scripts
e links simbólicos e não uma caixa preta.
 
 É possível executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por
isso os passos executados durante o boot mudam de distribuição para distribuição, de acordo com o que os
desenvolvedores consideram mais adequado. Uma distribuição que carregue mais serviços, pode oferecer
mais recursos e executar mais funções automaticamente, enquanto outra, que inicialize apenas os
componentes essenciais, pode consumir menos memória e oferecer um melhor desempenho em micros
antigos, por exemplo.
Para desativar os serviços manualmente no Debian e em outras distribuições
derivadas dele, use o comando "update-rc.d -f nome remove", como em:
# update-rc.d -f cups remove
Ele remove os links que apontarem para o serviço em todas as pastas de
inicialização, fazendo com que ele deixe de ser carregado durante o boot. Se
você quiser desativar o serviço na hora, pode desativá-lo usando o comando
"/etc/init.d/nome stop", como em "/etc/init.d/cups stop".
Para reativar a inicialização do serviço posteriormente, use o comando
"update-rc.d -f nome defaults", como em:
# update-rc.d -f cups defaults
Ele recria os links simbólicos, restaurando a configuração original. Estes
mesmos comandos podem ser usados em outras distribuições derivadas do
Debian. No caso do Mandriva e do Fedora, é usado o comando "chkconfig",
como em "chkconfig nome on" (ativa) e "chkconfig nome off" (desativa).
O Ubuntu inaugurou o uso de um novo sistema de inicialização, batizado de
Upstart (http://upstart.ubuntu.com/). Nele, o processo de inicialização é
simplificado (embora também perca parte da flexibilidade) e deixa de existir
diferença entre os runlevels de 2 a 5, que passam a utilizar a mesma
configuração, carregando o ambiente gráfico por default, o que
essencialmente elimina a diferenciação entre os modos. Se você tiver a
curiosidade de rodar o comando "runlevel", que mostra qual runlevel está
http://upstart.ubuntu.com/
sendo usado, ele reportará:
$ runlevel
N 2
Em outras distribuições, o runlevel 2 é configurado como um modo de
recuperação, sem suporte a rede nem ambiente gráfico, mas no Ubuntu ele é
o nível padrão, onde são carregados todos os serviços. Se você verificar a
configuração dos modos 3, 4 e 5, vai perceber que a configuração é a mesma
em todos eles.
Outro sintoma do uso do Upstart é que o arquivo "/etc/inittab" deixa de
existir, dando lugar ao à pasta "/etc/init/" (/etc/event.d/rc-default" em versões
antigas), cujos scripts passam a ser lidos pelos Upstart durante o boot,
disparando o processo de inicialização. Veremos mais sobre a configuração
do Upstart e dos serviços no Ubuntu no capítulo sobre ele.
 
Opções para solucionar problemas
Em quase todas as distribuições, é possível especificar opções adicionais
durante o boot. Estas opções são repassadas diretamente ao kernel, alterando
seu comportamento ou desativando recursos que podem fazer com que o
sistema trave durante o boot, ou que façam determinados componentes não
serem reconhecidos. No Ubuntu, por exemplo, você pode acessar a linha de
opções para o kernel pressionando a tecla F6 na tela de boot:
Você pode combinar várias opções, caso necessário, especificando de uma
vez várias opções para solucionar problemas comuns (acpi=off, noapic,
nolapic, etc.) de maneira a tentar fazer a máquina terminar o boot e, a partir
daí, ir testando uma a uma para descobrir qual delas resolveu o problema.
Todas estas opções possuem efeitos colaterais, de forma que elas não servem
para otimizar ou melhorar o desempenho do sistema, são apenas uma forma
de solucionar problemas em casos específicos. Vamos então a uma lista das
opções disponíveis, que você pode usar como fonte de consulta para quando
tiver problemas:
acpi=off: Esta opção desativa o ACPI, corrigindo problemas diversos de boot
em muitas máquinas. O ACPI é o responsável pelo monitoramento da carga
da bateria, ajuste da frequência do processador e muitas outras funções
importantes, de maneira que você deve deixar para desativá-lo apenas em
último caso.
acpi=noirq: Esta é uma versão mais light da opção "acpi=off", que ao invés
de desativar completamente a função, desativa apenas a atribuição dinâmica
de endereços, que é a causa de uma grande parte dos problemas relacionados
ao ACPI.
Esta opção corrige problemas na detecção da placa de rede, placa de som e
placa wireless em diversos notebooks da Acer, Positivo e de outros
fabricantes, além de problemas em diversas placas-mãe com chipset SiS ou
ATI, causados por bugs na atribuição de endereços por parte do BIOS.
Uma observação importante é que, embora corrija problemas em algumas
placas e notebooks, esta opção cria problemas de detecção de componentes e
conflitos em outros, fazendo com que a placa wireless ou periféricos USB
não sejam detectados, por exemplo. Você deve usá-la apenas como forma de
solucionar problemas, nunca como uma opção de rotina.
noapic: O APIC é um recurso usado nos micros modernos para atribuir
endereços de IRQ, evitando conflitos entre os dispositivos. Entretanto, muitos
PCs usam BIOS com bugs diversos, que atribuem os endereços
incorretamente. O resultado mais comum é que alguns periféricos não sejam
detectados pelo sistema, como nos misteriosos casos onde a placa de som ou
a placa de rede não são detectados no Linux. Usar esta opção soluciona o
problema em muitas situações.
Note que, em muitos casos, a melhor forma de corrigir de forma definitiva
este tipo de problema é atualizar o BIOS da placa-mãe, já que uma versão
corrigida pode solucionar o problema direto na fonte. Muitos fabricantes,
como a Gigabyte e a Asus, oferecem um bom suporte com relação a isso;
vale a pena verificar se não existe uma atualização disponível para sua placa.
Normalmente, o upgrade de BIOS é feito dando boot através de um disquete
ou CD-ROM gravado com uma imagem baixada na página do fabricante.
Atualizar o BIOS é um procedimento potencialmente perigoso, por isso não
deixe de ler as instruções do fabricante e checar se o arquivo baixado é
realmente para a sua placa.
nolapic: O LAPIC (local APIC) é uma variação do APIC, que é usado em
máquinas com processadores dual-core ou quad-core. Assim como a
"noapic", a opção "nolapic" é usada para solucionar problemas relacionados
ao boot ou à detecção de periféricos. Embora as duas possam ser usadas em
conjunto enquanto você está atirando para todos os lados, normalmente
apenas uma delas é necessária.
nosmp: Em máquinas com processadores dual-core, esta opção desativa o
segundo núcleo, o que soluciona problemas de boot em muitas máquinas.
Naturalmente, sem um dos núcleos o desempenho da máquina será mais
baixo, mas ela serve como uma solução temporária, até que você descubra
uma solução definitiva para o problema, que pode ser uma atualização de
BIOS,uma nova versão do kernel, ou, simplesmente, uma versão atualizada
da distribuição em uso.
pci=biosirq: Esta é mais uma opção que resolve problemas de detecção da
placa de rede ou som em algumas máquinas. Ela faz com que o sistema siga a
configuração de endereços definida pelo BIOS, em vez de usar o
procedimento normal de detecção.
pci=bios: Mais uma opção de compatibilidade, desta vez destinada a burlar
problemas com a controladora PCI da placa mãe. Embora raro, pode ser
necessário usá-la para que o sistema consiga completar o boot em alguns
notebooks.
pnpbios=off: Desativa o suporte a plug-and-play por parte do BIOS da placa-
mãe, deixando que o Kernel se encarregue da detecção de todos os
componentes. Esta é mais uma opção que resolve problemas de
compatibilidade em algumas placas.
irqpoll: Esta opção modifica a forma como o sistema detecta os dispositivos
da máquina, corrigindo uma série de problemas em PCs e notebooks recentes,
sobretudo quando usados em conjunto com distribuições antigas, anteriores a
2008.
Ela é necessária para a placa wireless funcionar em alguns notebooks Acer
com placas Broadcom; resolve problemas relacionados com a placa de som
(ou com a placa de rede) em diversas configurações; e, soluciona um
problema relacionado à detecção de HDs SATA em placas baseadas no
chipset K8T890 (como a Asus A8V-E), entre outras. Esta opção causa
poucos efeitos colaterais, se comparada com as demais.
reboot=b: Essa opção faz com que seja usada uma função alternativa para
reiniciar o micro via software, resolvendo alguns casos em que a máquina
não reinicia sozinha ao usar o comando "reboot".
generic.all_generic_ide=1: Esta opção soluciona problemas de
compatibilidade com as controladoras IDE ou SATA de algumas placas-mãe,
sobretudo nas placas com o infame chipset SiS 761GX/965L (ao usar um HD
SATA), como a PC-Chips K8 A31G. Esta opção deve ser usada em casos
onde o sistema não consegue detectar os HDs do micro (o que, além de
impedir que você acesse os arquivos, impossibilita a instalação). Ao usar a
opção de boot, o sistema utiliza um modo de acesso genérico para os HDs, o
que soluciona o problema na maioria dos casos.
Esta opção causa uma redução significativa no desempenho do sistema, por
isso só deve ser usada quando realmente necessário. Uma peculiaridade é que
ela faz o sistema detectar o HD SATA como "/dev/hde" e não "/dev/sda",
como seria usual. Apesar disso, a instalação do sistema ocorre de forma
normal. Outra dica é que, em algumas placas com chipset VIA, pode ser
necessário combiná-la com a opção "irqpoll", solucionando também um
problema com a atribuição dos endereços.
Em distribuições com versões antigas do Kernel, a opção é escrita como "all-
generic-ide" (com traços em vez de underlines). Você encontrará referências
também à "all_generic_ide", que é uma versão curta da mesma opção.
Capítulo 2: Aprofundando os estudos com o
Slackware
 
As distribuições Linux são um bom exemplo da ação da lei de seleção
natural. Novas distribuições surgem praticamente a cada dia, mas poucas
continuam ativas por mais do que alguns meses. O motivo é bastante simples:
qualquer um com conhecimentos técnicos suficientes pode criar uma nova
distribuição, tomando como base alguma já existente. Entretanto, apenas as
que conseguem reunir um grupo suficientemente grande de usuários e
desenvolvedores, conseguem sobreviver a longo prazo.
Conforme o Linux passou a ser usado por cada vez mais pessoas e a atingir
usuários com cada vez menos conhecimentos técnicos, as distribuições foram
se tornando também cada vez mais fáceis de usar, atendendo ao público que
quer apenas usar o micro, sem perder tempo configurando o sistema ou
resolvendo problemas. Desde que não exista nenhuma incompatibilidade com
o hardware da máquina, ou algum outro imprevisto, muitas distribuições
praticamente se instalam sozinhas.
Entretanto, se você se deu ao trabalho de comprar este livro e lê-lo até aqui, é
bem provável que esteja interessado em se aprofundar e entender como o
sistema funciona por baixo da superfície. É nesse ponto que chegamos ao
Slackware, que, justamente por ser uma das distribuições mais espartanas,
abre brecha para falar sobre muitos detalhes que passariam despercebidos por
uma distribuição mais automatizada.
À primeira vista, o Slackware parece ser um sistema extremamente
complicado. Ele é uma das poucas distribuições Linux que ainda não possui
instalador gráfico e toda a configuração do sistema é feita manualmente, com
a ajuda de alguns poucos scripts simples de configuração. Entretanto, o
Slackware oferece uma estrutura de arquivos de configuração e de pacotes
muito mais simples que outras distribuições, o que o torna ideal para entender
mais profundamente como o sistema funciona.
Se as distribuições fossem carros, o Slackware seria o Fusca. Ele não possui
nenhum dos confortos encontrados em outros carros atuais, mas, em
compensação, possui uma mecânica extremamente simples, o que também o
torna fácil de modificar e de consertar. É justamente por isso que o Slackware
possui tantos fãs, apesar da idade avançada. Ele é complicado na superfície,
porém simples e confiável no interior.
Ele é também uma distribuição interessante para uso em PCs com poucos
recursos, já que usa configurações bastante otimizadas na compilação dos
pacotes e mantém poucos serviços ativos por padrão. Ele é uma das poucas
distribuições que ainda podem ser utilizadas sem grandes percalços em
micros com apenas 128 MB de memória RAM, bastando para isso fazer
algumas otimizações simples e utilizar um ambiente gráfico leve, como o
LXDE.
 
As origens
O Slackware é o exemplo mais proeminente de "distribuição de um homem
só". Ele foi desenvolvido desde o início por uma única pessoa, Patrick
Volkerding, que esporadicamente conta com a ajuda de outros
desenvolvedores. Ele se encarrega de testar e incluir novos pacotes,
aperfeiçoar o instalador e outras ferramentas e, periodicamente, lança uma
nova versão incluindo todo o trabalho feito até então.
A primeira versão foi disponibilizada em julho de 1993 (época em que a
instalação era ainda feita usando disquetes :o) e novas versões vem sendo
lançadas uma ou duas vezes por ano desde então. A versão 11.0 foi lançada
em outubro de 2006, a 12.0 foi lançada em julho de 2007, a 12.1 em maio de
2008, 12.2 em dezembro de 2008, a 13.0 em agosto de 2009, a 13.1 em maio
de 2010 e a 13.37 em abril de 2011. A próxima versão (provavelmente o
14.0), que enquanto escrevo forma o Slackware-current será lançada ao longo
de 2012.
Uma curiosidade dentro da história do Slackware é que as versões 5 e 6 não
existiram, já que a numeração pulou do 4.0 (lançado em maio de 1999) para o
7.0 (outubro de 1999), para acompanhar os números de versão usados no Red
Hat Desktop (que era na época a distribuição mais popular), evitando assim
que o Slackware parecesse desatualizado.
Embora tenha uma estrutura interna relativamente simples, o Slackware
intencionalmente conta com poucas ferramentas de configuração, e por isso é
considerado uma das distribuições mais difíceis, já que quase tudo, desde as
configurações mais básicas, precisa ser feito manualmente.
Ao contrário da maioria das distribuições atuais, o foco do desenvolvimento é
manter o sistema fiel às suas raízes, ao invés de tentar facilitar o uso
automatizando funções. Mesmo a inclusão do suporte a HAL, um recurso
utilizado pelo KDE (e também pelo GNOME e outros ambientes gráficos)
para mostrar janelas de ação quando pendrives e outros dispositivos
removíveis são inseridos, foi intencionalmente postergado durante várias
versões.
Em termos de configuração e detecção de componentes, o Slackware é uma
espécie de "denominador comum" entre as distribuições: ele inclui apenas as
ferramentas mais básicas, o que permite que você trace uma linha imaginária
entre o que é detectado pelos serviços padrão do sistema e o que é
automatizado por ferramentas específicas incluídas em outras distribuições.
Pode parecer estranho começar abordando logo uma das distribuiçõesmais
difíceis. Minha ideia é aproveitar o ânimo inicial para lhe mostrar a estrutura
interna e a configuração manual do sistema, usando o Slackware como
exemplo e em seguida mostrar os utilitários e abordagens usadas por outras
distribuições para automatizar a configuração. É como fazer dieta: o mais
difícil é na primeira semana. :-)
Ao contrário do que se costuma ouvir, a instalação do Slackware pode ser tão
simples quanto a do Mageia ou do Fedora, o problema é justamente o que
fazer depois da instalação. Quase nada é automático: som, impressora,
montagem das partições, quase tudo precisa ser configurado manualmente. O
"Slack" no nome significa "preguiçoso" no sentido de que o software não fará
muita coisa por você. A proposta da distribuição é justamente lhe
proporcionar problemas, para que você possa aprender pesquisando soluções
para eles. Esta acaba sendo a principal limitação, mas, ao mesmo tempo, o
diferencial que mantém a distribuição relevante.
 
Instalando o Slackware
O modo mais prático de instalar o Slackware é dando boot pelos CDs (ou
pelo DVD) de instalação, assim como em outras distribuições. Apesar do
instalador ser em modo texto, as opções são razoavelmente simples.
O primeiro passo é baixar os CDs de instalação no
http://slackware.com/getslack/, onde estão listados os vários mirrors
disponíveis. Alguns sempre estão lotados, mas bastam algumas poucas
tentativas para encontrar um rápido e atualizado. O mirror primário para o
Brasil é o ftp://ftp.slackware-brasil.com.br/.
Dentro de cada mirror temos os pacotes inicialmente divididos por versão.
Para cada uma existem duas pastas, como em "Slackware-13.37" e
"Slackware-13.37-iso", sendo que a primeira contém os pacotes avulsos e a
segunda contém as imagens dos CDs de instalação, que é o que estamos
procurando. Em alguns dos mirrors, você encontrará também versões antigas,
que podem ser úteis em micros antigos.
A pasta "slackware-current" contém a versão de desenvolvimento do
Slackware, onde você poderá encontrar as versões mais atualizadas dos
pacotes, mas sem garantia de estabilidade. Tipicamente, o slackware-current
é disponibilizado apenas na forma dos pacotes individuais, limitando a
instalação apenas aos usuários mais tarimbados, que sabem como atualizar
para ele a partir da versão estável, ou gerar um ISO manualmente. Entretanto,
para quem não quer ter este trabalho, existe a possibilidade de baixar um ISO
do slackware-current (atualizado semanalmente) no:
http://ftp.ntua.gr/pub/linux/slackware/slackware-current-iso/
http://slackware.com/getslack/
ftp://ftp.slackware-brasil.com.br/
http://ftp.ntua.gr/pub/linux/slackware/slackware-current-iso/
 
 
O Slackware é composto por nada menos do que 6 CDs, mas na verdade você
precisa apenas dos três primeiros, já que os outros três contém o código-fonte
de todos os pacotes. O primeiro CD contém os pacotes básicos do sistema, o
segundo contém os pacotes do X e a maior parte dos programas gráficos
enquanto o terceiro contém os pacotes de internacionalização (incluindo as
traduções para o português do Brasil). Como de praxe, está disponível
também um DVD, que agrupa o conteúdo de todos os CDs, incluindo o
código-fonte.
 
Boot e particionamento
Ao dar boot com a mídia de instalação, a primeira pergunta é sobre os
parâmetros de boot, onde você pode adicionar opções destinadas a solucionar
problemas, como o tradicional "apci=off" ou o "noapic" (como vimos no final
do primeiro capítulo). Estas opções são na realidade interpretadas diretamente
pelo kernel, permitindo alterar seu comportamento ou desativar recursos que
estejam criando problemas na sua máquina.
No caso do Slackware 12.2, a principal observação é que estão disponíveis
duas versões diferentes do kernel: uma para máquinas atuais e outra para
máquinas muito antigas, anteriores ao Pentium Pro. Se você por acaso estiver
tentando instalar o sistema em um Pentium 1 ou em um Pentium MMX, use a
opção "huge.s" para que seja usado o kernel para máquinas antigas, caso
contrário simplesmente pressione Enter para que seja usado o "hugesmp.s",
que é a versão para máquinas atuais, incluindo suporte a processadores dual-
core e outros recursos:
A pergunta seguinte é sobre o layout do teclado, que no nosso caso é o
"qwerty/br-abnt2.map". O instalador pede para você pressionar "1" para
acessar o menu de seleção e depois confirmar pressionando novamente "1".
Em outras distribuições, o layout é definido automaticamente de acordo com
a indicação do país ou da língua (no Ubuntu, ao escolher o português do
Brasil, por exemplo, o sistema presume que você está usando um teclado
ABNT2). O Slackware, por sua vez, ainda utiliza um sistema primitivo, onde
tudo é especificado separadamente.
Tanto faz definir o layout logo no início do boot ou durante a instalação, pois
a função dentro do instalador que faz a configuração, é a mesma:
Depois deste pequeno aquecimento, você cai na tela inicial, onde você vê a
mensagem "You may now login as 'root'" onde, seguindo as instruções, você
se loga como root (sem senha) e cai num prompt inicial de comando, de onde
pode chamar o instalador:
O Slackware não inclui nenhum assistente ou particionador gráfico, o que lhe
obriga a fazer as alterações utilizando diretamente o cfdisk, que (fora o fdisk,
que poucos usam atualmente) é o único particionador incluído. Ele é um
aplicativo bastante simples, em modo texto, com uma interface bastante
similar à do fdisk do Windows 95/98 e de outros programas de
particionamento da velha guarda. Quem é das antigas acaba se sentindo
bastante confortável com ele, já que, embora simples, o cfdisk é bastante
robusto e confiável.
O grande problema é que ele se limita a criar as partições, sem oferecer
opções de redimensionamento ou reparação. Se você está na clássica situação
de precisar redimensionar a partição do Windows para instalar o sistema em
dual-boot, você pode dar boot usando um CD de outra distribuição, de forma
a usar o Gparted.
Uma boa opção nesse caso é o Gparted Live (que comentei no primeiro
capítulo), que você pode baixar no http://gparted.sourceforge.net/. Outra
opção é usar um live-CD do Ubuntu, que também traz o Gparted pré-
instalado.
Para abrir o cfdisk, basta chamá-lo pelo nome, especificando o dispositivo do
HD que será particionado, como em:
# cfdisk /dev/sda
Na maioria dos casos, também funciona se você usar apenas "cfdisk", sem
especificar o device (já que ele abrirá o primeiro dispositivo que encontrar,
seja o "/dev/hda" ou o "/dev/sda"), mas isso abre margem para enganos em
situações em que você tem mais de um HD, ou onde o drive de CD/DVD está
http://gparted.sourceforge.net/
instalado como master na primeira porta IDE. Outra dica é que, em caso de
dúvida, você pode listar os HDs e partições que foram detectados pelo
sistema usando o comando "cat /proc/partitions".
Dentro da interface do cfdisk, use as setas para cima e para baixo para
selecionar uma partição ou trecho de espaço livre, as setas para a direita e
para a esquerda para navegar entre as opções e a tecla Enter para selecionar.
As opções disponíveis incluem:
Delete: Deletar uma partição, transformando-a em espaço livre. Use
esta opção para deletar partições já existentes no HD e assim poder criar
novas.
Create: Cria uma partição usando um trecho de espaço livre. O
assistente perguntará sobre o tamanho da partição, em MB. Você terá
ainda a opção de criar uma partição primária e uma partição estendida.
Você pode criar no máximo quatro partições primárias, mas, por outro
lado, pode criar várias partições lógicas dentro de uma partição
estendida. As diferentes versões do Windows exigem a instalação em
uma partição primária, mas no Linux não existe esta limitação.
Maximize: Redimensiona uma partição, para que ela ocupe todo o
espaço disponível no HD. O processo não é destrutivo, pois o sistema
simplesmente inclui o espaço adicional no final da partição, sem mexer
no que está gravado. Essa opção permite apenas aumentar o tamanho da
partições (e não reduzir), por isso ela não ajudacaso você precise
redimensionar partições para liberar espaço.
Type: Altera o sistema de arquivos da partição (Linux, FAT, Linux
Swap, etc.). Ao criar uma nova partição, o default é que ela seja criada
como "Linux". Para transformá-la em uma partição swap (dúvida
comum ao usar o cfdisk), acesse a opção "Type" e mude para "82".
Bootable: Esta é mais uma opção necessária para partições do
Windows ou do antigo MS-DOS, mas não para o Linux. No caso deles,
a partição onde o sistema operacional está instalado deve ser marcada
com este atributo.
Write: Salva as alterações. Assim como em outros particionadores, as
alterações são salvas apenas ao acionar esta opção, de forma que se
mudar de ideia, basta sair sem salvar.
Como em outras distribuições, você precisa de no mínimo uma partição
Linux e uma partição Linux swap. Lembre-se de que a partição swap não é
realmente obrigatória se você tem 1 GB de RAM ou mais, mas é sempre
recomendável usá-la pois ela permite que o sistema mova bibliotecas e
arquivos que não estão sendo utilizados, liberando mais memória RAM para
o cache de disco e mantendo memória livre para abrir novos programas.
Sem swap, o resultado final é quase sempre o oposto do que se espera, com o
sistema ficando mais lento (menos RAM disponível) e menos estável, já que
ao abrir muitos programas ele pode ficar sem memória disponível, fazendo
com que os programas fiquem lentos, travem ou sejam fechados. Uma
partição swap de 1 ou 2 GB atende bem ao propósito, sem sacrificar tanto
espaço no HD.
Outra recomendação é que você use, sempre que possível, uma partição
separada para o diretório home, criando uma divisão entre seus arquivos
pessoais e os arquivos do sistema. Fazendo isso, os diretórios home de todos
os usuários ("/home/tux", "/home/gdh", etc.) serão gravados dentro desta
partição separada, ao invés de irem parar na partição principal.
Como no Linux todas as configurações e arquivos referentes a cada usuário
são armazenados dentro do home; essa divisão facilita bastante as coisas na
hora de reinstalar o sistema ou migrar para outra distribuição, já que você
pode formatar a partição do sistema, mantendo a partição home intacta:
Ao deletar uma partição antiga, você seleciona o trecho de espaço livre e
acessa a opção Create para criar uma partição Linux para a instalação do
sistema. Para criar a partição swap, você repete o procedimento, criando uma
segunda partição Linux, mas em seguida você acessa a opção Type e
pressiona Enter duas vezes para que o cfdisk a transforme em uma partição
swap. Criadas as duas partições, é só salvar e sair.
Se você tem um notebook e pretende usar o recurso de hibernar (o suporte no
Linux é ainda problemático, mas é possível usá-lo em muitos modelos), a
partição swap deve ter pelo menos o dobro do tamanho da memória RAM,
pois, quando o notebook é colocado para dormir, todos os dados da memória
RAM são salvos na partição swap (que, diferente da memória RAM, é salva
no HD e por isso não perde os dados quando o micro é desligado). Graças a
isso, eles podem ser copiados de volta quando ele é ligado novamente,
permitindo que você continue do ponto em que parou. Isso vale também para
outras distribuições.
Outra dica é que alguns programas de particionamento (como o do instalador
usado em versões antigas do Mandriva) criam tabelas de partição que não são
entendidas pelo cfdisk. Neste caso, ao abrir o cfdisk você receberá uma
mensagem de erro sobre a tabela de partição. Isso não significa
necessariamente que exista algo errado com o particionamento do HD, mas
apenas que o cfdisk não conseguiu entender a tabela de partição atual.
Nesse caso, você tem duas opções: testar outros programas de
particionamento, até encontrar um que entenda o particionamento atual e
permita que você edite as partições como desejado, ou fazer backup dos
dados e descartar o particionamento antigo, começando do zero.
Para a segunda opção você pode utilizar o comando "cfdisk -z dispositivo"
(como em "cfdisk -z /dev/sda"), que faz com que o cfdisk ignore o
particionamento atual, criando uma nova tabela em branco. Uma última dica
é que, em alguns micros antigos, pode ser que seja necessário reiniciar depois
do particionamento, devido a um bug em versões antigas de BIOS da Phoenix
e da AMI, que faz com que o BIOS leia a tabela de particionamento apenas
durante o boot. Se por acaso o instalador reclamar que não encontrou
partições válidas, pode ser o seu caso.
Depois de sair do cfdisk, chame o script de instalação, usando o comando
"setup".
 
O instalador
O processo de instalação do Slackware (assim como o de qualquer outra
distribuição), segue um processo relativamente simples, que consiste em
coletar informações sobre as partições que serão utilizadas, as configurações
desejadas e os pacotes que serão instalados, copiar os arquivos do sistema
para a partição de instalação, instalar o gerenciador de boot e gerar os
arquivos de configuração necessários, de foma que o sistema possa funcionar
sozinho depois de concluída a instalação.
Imagine que você queira construir uma casa usando materiais pré-fabricados,
por exemplo. A empresa contratada começaria coletando informações sobre
que tipo de casa você quer, o terreno que será utilizado e assim por diante e
criaria um projeto para a obra, com base nos componentes disponíveis. Os
materiais seriam então transportados até o local e a casa montada. Depois de
feito o acabamento e os últimos ajustes, o projeto é finalizado e você pode
fazer a mudança.
No caso de uma distribuição Linux, o sistema é originalmente distribuído na
forma de um conjunto de pacotes, cada um contendo um determinado
aplicativo, biblioteca ou outro componente do sistema, como se fossem lajes
e paredes pré-fabricadas. O instalador faz então o trabalho do empreiteiro,
coletando informações, elaborando um projeto e combinando os pacotes
disponíveis para obter o resultado desejado.
Por estranho que possa parecer, o instalador do Slackware é na verdade um
shell-script bastante simples (no Slackware 12.2 ele tem apenas 384 linhas),
que coleta algumas informações, monta as partições onde o sistema será
instalado, faz a cópia dos arquivos e executa alguns passos adicionais para
que ele seja capaz de dar boot sozinho.
Ao dar boot através do CD ou DVD, é carregada uma versão minimalista do
sistema, sobre a qual roda o instalador. Os instaladores de outras distribuições
seguem esta mesma ideia, carregando primeiro uma versão simplificada do
sistema, usada para rodar o instalador. Ou seja, usamos o próprio Linux para
instalar o Linux.
Se você acessar os arquivos dentro do DVD ou do primeiro CD de instalação,
vai encontrar, dentro da pasta "isolinux/", o arquivo "initrd.img", que contém
justamente a imagem binária dessa distribuição minimalista.
Caso esteja curioso, é possível ver o conteúdo desse arquivo e fuçar no
código do instalador, desde que você tenha acesso a alguma outra
distribuição já instalada (um live-CD também serve). Copie o arquivo
initrd.img para uma pasta qualquer do sistema, e (dentro dela) use os
comandos a seguir para descompactá-lo e poder ver seu conteúdo:
$ mkdir slackboot
$ cd slackboot
$ gzip -dc ../initrd.img | cpio -i -d -H newc --no-absolute-filenames
Isso faz com que o arquivo seja descompactado e o conteúdo fique disponível
dentro da pasta "slackboot" que foi criada:
Essa é justamente uma mini-distribuição, contendo um conjunto de
executáveis, módulos e scripts que são usados para criar o ambiente inicial,
onde você loga e roda o cfdisk. O script do instalador vai dentro da
"usr/lib/setup/". Basta acessá-la e abrir o arquivo "setup" usando o editor de
textos. Este é o tão famoso instalador do Slackware, que continua sendo
usado desde 1993, com poucas alterações:
Agora que estamos devidamente apresentados, vamos então ao que realmente
interessa. Afinal, escovação de bits não enche a barriga de ninguém. :)
Selecionando as partições
Presumindo que você já tenha definido o layout do teclado na etapa inicial, o
próximo passo é especificar aspartições de instalação, começando pela
terceira opção, "Addswap":
A partição swap é detectada automaticamente pelo instalador, sempre que
estiver presente. Em seguida o instalador pergunta qual será a partição raiz
(/), ou seja, em qual partição o sistema será instalado. Se você tiver apenas
uma partição Linux, ela fica pré-selecionada, caso contrário você pode
escolher qual usar na lista:
Em seguida, você pode definir pontos de montagem para as demais partições
do HD, incluindo a partição home (caso usada) e partições usadas pelo
Windows ou outra distribuição Linux instalada em dual-boot. Ao selecionar a
partição na lista, o instalador pergunta em qual diretório ela deve ser montada
e, em seguida, se a partição deve ser formatada, ou se ela deve simplesmente
ficar acessível, sem alterações:
Ao usar uma partição home separada, basta indicá-la na lista e definir o ponto
de montagem "/home" para ela. Se você criou a partição no início da
instalação, não esqueça de formatá-la, já que o cfdisk apenas cria as
partições, deixando a formatação a cargo do instalador.
Ao formatar cada partição, o instalador oferece a opção de fazer um exame de
superfície, em busca de setores defeituosos (opção "Check"). Esta é, na
verdade, uma opção obsoleta, que é necessária apenas em HDs antigos. Nos
atuais (praticamente qualquer HD com a partir de 4 GB), o exame de
superfície é desnecessário, pois a controladora é capaz de marcar os setores
defeituosos automaticamente, monitorando os erros de leitura:
O instalador continua repetindo o menu de seleção das partições até você
selecionar a opção "Continue" na tela principal. Ao finalizar, é mostrado um
diálogo com as linhas que serão incluídas no arquivo "/etc/fstab", dentro da
partição de instalação.
Ao contrário do que pode parecer à primeira vista, o que o instalador faz
nesse ponto é simplesmente montar as partições (como você faria ao acessá-
las através do terminal), de forma que elas sejam usadas durante a instalação
e, em seguida, adicionar as linhas correspondentes no fstab, para que elas
sejam montadas durante o boot daí em diante. Instaladores de outras
distribuições seguem esta mesma ideia, muito embora geralmente de forma
mais elaborada.
Caso você esteja instalando em dual-boot, o instalador (a partir do Slackware
12.1) detecta a partição do Windows e pergunta se você quer montá-la
usando o NTFS-3g.
Você precisa apenas indicar em que pasta a partição deve ser montada
("/mnt/windows", por exemplo) e escolher o modo de acesso. Use o "umask
000" para poder acessar os arquivos sem restrição usando seu login de
usuário.
Em seguida, o instalador pergunta sobre a mídia de instalação. Normalmente,
basta manter a opção padrão "Install from a Slackware CD or DVD" e, em
seguida a opção "auto" pra que ele localize o drive sozinho. Entretanto, o
instalador também suporta instalar a partir de uma partição do HD, para onde
tenham sido copiados os arquivos dos CDs de instalação, ou mesmo via rede,
o que pode ser útil em casos em que você tem apenas o primeiro CD (ou está
instalando a partir de um pendrive) e quer que o instalador busque os demais
pacotes em um compartilhamento de rede:
Antigamente, era possível instalar o Slackware através de disquetes, o que
naturalmente não é mais possível hoje em dia, devido ao tamanho do kernel e
de muitos pacotes. Em vez deles, a mídia alternativa de instalação para
máquinas sem CD-ROM passou a ser o pendrive. A grande maioria das
placas-mãe atuais suportam o boot através da porta USB, o que permite que
os pendrives substituam os antiquados disquetes com diversas vantagens.
Com a popularização de máquinas sem drive de CD/DVD, como no caso dos
Netbooks, instalar o sistema usando um pendrive tem se tornado uma opção
cada vez mais comum.
 
Seleção dos pacotes
Continuando, temos a seleção dos pacotes, que é feita em duas etapas.
Primeiro você escolhe as categorias que serão instaladas e, em seguida, indica
como quer selecionar os pacotes dentro de cada uma:
Essa mesma divisão é encontrada dentro das mídias de instalação e dentro
dos repositórios de pacotes (como no ftp://ftp.slackware-
brasil.com.br/slackware-12.2/slackware/), servindo como uma maneira de
organizar os pacotes.
Ela surgiu nas primeiras versões do Slackware, quando o sistema ainda era
instalado através de disquetes. Naquela época, cada categoria cabia em um
disquete, de forma que ao copiar o sistema você precisava gravar apenas os
disquetes das categorias que pretendia instalar.
De lá pra cá, muita coisa mudou, mas a divisão em categorias persiste como o
meio de definir rapidamente o que deve ser instalado. Entender a organização
destas categorias e conhecer os pacotes principais ajuda bastante a entender
como o sistema funciona. Vamos então a uma descrição mais detalhada de
cada uma:
A - Esta é a categoria que inclui os pacotes básicos do sistema,
incluindo o kernel, o interpretador de comandos e um conjunto de
bibliotecas básicas. Ela é a única categoria realmente obrigatória dentro
da instalação. Mesmo desmarcando todas as outras, você ainda terá uma
instalação enxuta do sistema, em modo texto.
Alguns pacotes que podem ser desmarcados com segurança são o
"cups" (necessário apenas se você vai usar impressoras), o
"reiserfsprogs" e o "xfsprogs" (necessários apenas se você pretende usar
partições formatadas em reiserfs ou XFS).
AP - Esta categoria contém vários aplicativos de modo texto (vou
ftp://ftp.slackware-brasil.com.br/slackware-12.1/slackware/
abordar muitos deles ao longo do livro). Alguns que você não deve
deixar de instalar são o "alsautils", que contém utilitários para
configurar a placa de som e o "cdparanoia", "cdrdao", "cdrtools" e
"dvd+rw-tools", que são necessários para gravar CDs e DVDs. Talvez
você se sinta tentado a desmarcar o "ghostscript", que é o maior pacote
dentro da categoria, mas ele é mais importante do que parece,
necessário para o suporte a impressão e visualização de arquivos PDF.
D - Um dos problemas do Slackware é que o repositório inclui um
volume relativamente modesto de pacotes, deixando de fora muitos
aplicativos que estão disponíveis em distribuições baseadas no Debian
ou no Fedora, por exemplo. Isso faz com que, em muitos casos, a única
solução para instalar um determinado programa seja compilá-lo a partir
do código-fonte. Esta não é necessariamente uma tarefa difícil, desde
que você tenha instalados os compiladores e bibliotecas necessários,
incluídos nesta categoria. Como todos acabam sendo necessários em
uma situação ou outra, é conveniente manter todos marcados.
TCL - O TCL é uma biblioteca gráfica usada por alguns aplicativos,
como o Amsn (cliente do MSN) e o Nicotine (um programa P2P). Estes
programas são fáceis de reconhecer, pois possuem um visual distinto
(um pouco ao estilo do Windows 95), diferente dos programas do KDE
e do GNOME. Os pacotes do TCL/TK não são grandes, por isso vale a
pena mantê-los instalados, mas, não são obrigatórios; você pode
desmarcar a categoria se não for usar nenhum destes programas.
K - Esta categoria contém um único pacote, o "kernel-source", que
contém o código-fonte do kernel instalado. Você vai precisar dele se
resolver brincar de recompilar o kernel e também para instalar alguns
drivers de placas wireless e modems. Para outros, o pacote "kernel-
headers" (que faz parte da categoria D) é suficiente.
KDE - Esta categoria contém os pacotes do KDE, misturando as
bibliotecas básicas e diversos programas. Os pacotes base do KDE são
o "kdebase", "kdelibs", "kdeutils" e "qt-3" (que faz parte da categoria
L).
Outros pacotes importantes são o "kdeaddons" (utilitários e applets),
"kdeadmin" (que contém o painel de controle e outras ferramentas de
configuração), "kdenetwork" (utilitários e suporte a vários protocolos de
rede através do Konqueror) e o "koffice", que contém o Kword,
Kspread e os outros aplicativos que compõe a suíte.
Alguns pacotes são inteiramente opcionais, como o "kdegames" (jogos),
"kdeedu" (programas educativos), "kdetoys" (bobagens em geral),
"kdepim"(agenda de compromissos e alarme) e o "kdevelop", que é útil
apenas para desenvolvedores.
KDEI - Estes são os pacotes de internacionalização do KDE. Você
precisa instalar o pacote "kde-i18n-pt_BR" para ter suporte ao
português do Brasil. Ao contrário das outras categorias, todos os
pacotes ficam desmarcados e você pode escolher apenas as traduções
que for usar. Se desejar, você pode instalar mais de uma e alternar entre
elas através do painel de controle do KDE. Marque também o "k3b-
18n", que inclui as traduções do K3B (para todas as linguagens) e, caso
pretenda usar o Koffice, marque o "koffice-l10n-pt_br".
L - Esta é uma das categorias mais importantes, pois concentra
bibliotecas usadas pela maior parte dos aplicativos. Alguns pacotes
especialmente importantes são o "alsa-driver", "alsa-lib" e "alsa-oss"
(que inclui drivers e bibliotecas necessários para ativar a placa de som
usando os drivers alsa), "gtk+-1.2" e "gtk+-2.2" (que compõe a
biblioteca GTK, base de muitos aplicativos) e o "libusb" (a biblioteca
base para suporte a dispositivos USB). Esta categoria contém também o
pacote "jre-6u6", que instala o interpretador Java, incluindo o plugin
para o Firefox.
N - Esta categoria mistura bibliotecas, clientes e servidores de rede.
Você não pode desmarcá-la completamente, caso contrário você
simplesmente ficará desconectado, mas é importante analisar o
conteúdo e desmarcar servidores (como o Apache, Samba, SSH e
Sendmail) que não for explicitamente usar, caso contrário você criará
brechas de segurança.
Alguns pacotes importantes são: "tcpip" (suporte a TCP/IP, necessário
para se conectar à Internet ou qualquer tipo de rede), "wireless-tools"
(suporte a redes Wireless, incluindo bibliotecas e ferramentas de
configuração), "wpa_supplicant" (necessário para se conectar à redes
Wireless com encriptação WPA ou WPA2), "ppp" (suporte genérico a
conexões discadas, incluindo modem, ISDN e ADSL PPPoE), "rp-
pppoe" (ferramentas para se conectar via ADSL com autenticação),
"openssl" (bibliotecas de encriptação, usadas por muitos programas),
"dhcpcd" (cliente para configurar a rede via DHCP) e "iptables" (o
firewall padrão do sistema, que pode ser tanto configurado
manualmente, quanto através de programas como o Firestarter).
Os pacotes que contém servidores, que você deve instalar apenas
quando realmente for utilizá-los são: "apache" (servidor web), "bind"
(servidor DNS), "dhcp" (neste caso o servidor DHCP, não o cliente),
"openssh" (o servidor SSH), "proftpd" (servidor FTP), "samba"
(servidor de arquivos), "sendmail" (servidor SMTP), "imapd" (servidor
IMAP), "pop3d" (servidor POP) e o "vsftp" (outro servidor FTP).
Outros pacotes, como o "bitchx", "elm", "pine", "irssi", "lftp", "tin" e
"wget" são aplicativos clientes, em modo texto, que você pode instalar
ou não, de acordo com seu uso. Abordo alguns deles ao longo do livro.
X - Esta categoria contém os pacotes do X.org, o servidor gráfico base
do sistema. Sem estes pacotes, você fica restrito ao modo texto.
Normalmente, você só desmarca esta categoria ao configurar um
servidor dedicado, onde todos os componentes não essenciais são
removidos, para eliminar potenciais brechas de segurança e deixar todo
o espaço em disco, memória e processamento disponíveis para uso dos
serviços instalados.
XAP - Esta categoria concentra aplicativos gráficos que não fazem
parte do KDE, como o "abiword" (processador de texto), "gimp" (o
editor de imagens), "gxine" (player de vídeo), "mozilla-firefox" e
"mozilla-thunderbird" (o navegador e cliente de e-mails), "xchat"
(cliente de IRC) e o xmms (o player de áudio), junto com outros
gerenciadores de janelas, como o "fluxbox", "windowmaker" e o "xfce".
Esta categoria contém também o pacote "xine-lib" (que contém as
bibliotecas com suporte a vários formatos de vídeo, usadas como base
para o gXine, Kaffeine e outros players de vídeo), o "imagemagick"
(uma coleção de ferramentas para processamento e manipulação de
imagens, usada por diversos aplicativos) e o "sane" (a biblioteca que
provê suporte a scanners no Linux). O Sane trabalha em conjunto com o
Xsane (instalado através do pacote "xsane"), que se encarrega de
detectar scanners compatíveis e escanear imagens.
As categorias com pacotes mais específicos, que você pode remover
com segurança são:
E (Emacs): O Emacs é um dos editores mais usados por quem programa
em C. Ele é bastante poderoso, mas também muito complexo e grande:
ele sozinho consome mais de 60 MB de espaço no HD. Se você não
pretende utilizá-lo, não existe nenhum motivo para instalá-lo.
F- Esta categoria contém dois pacotes, o "linux-faqs" e o "linux-
howtos", que instalam uma coleção de howtos e faqs técnicos sobre o
sistema, que ficam disponíveis na pasta "/usr/doc". Você também pode
ler as versões atualizadas dos textos no http://tldp.org.
T - O Tex é uma linguagem de formatação (como o html, mas muito
mais elaborado) muito usada no meio acadêmico, principalmente dentro
da área de exatas. Esta categoria contém os editores, fontes e manuais
necessários pra produzir documentos neste formato.
Y - Esta categoria contém apenas um pacote, o "bsdgames" (composto
por um conjunto de jogos de modo texto). Ela é na verdade apenas um
fóssil das primeiras versões do sistema, que por algum motivo continua
sendo incluído.
Depois de marcar as categorias, você tem a chance de escolher os pacotes
disponíveis dentro de cada uma. Se você tiver um HD grande e não se
importar em sacrificar um pouco de espaço, você pode simplesmente manter
os pacotes padrão e adicionar mais algumas coisas específicas de que precise.
Fazer uma instalação mais parruda do Slackware não faz muita diferença do
ponto de vista do desempenho, pois mesmo instalados, os vários serviços
podem ser desabilitados no final da instalação. Ou seja, só ocuparão um
pouco mais de espaço em disco.
Além de não ter a preocupação de ter de ficar imaginando quais pacotes você
precisa ou não (acredite, nem quem trabalha diariamente com Linux conhece
a função de todos os pacotes incluídos em uma distribuição atual), você vai
ter uma facilidade muito maior em usar o sistema e, principalmente, instalar
novos programas, pois todas as bibliotecas e outros componentes
eventualmente necessários já estarão à mão.
http://tldp.org/
A opção "Full" é a mais rápida, você simplesmente instala quase todos os
pacotes dentro das categorias marcadas, mantendo a configuração default do
sistema. A opção "Expert" é o oposto, ela exibe a descrição de cada pacote e
vai perguntando (um por um!) se o pacote em questão deve ser instalado ou
não. Ela torna a instalação um processo muito mais demorado e propenso a
erro (já que a ausência de um sistema de verificação de dependências faz com
que o instalador não se manifeste nem mesmo se você desmarcar um pacote
essencial, como o kernel), o que faz com que ela seja raramente usada.
A opção "Menu" é a ideal para fazer um ajuste fino, pois você poderá
escolher quais pacotes instalar dentro de cada categoria através de um sistema
de menus. A opção "Newbie" por sua vez é uma versão simplificada da
opção Expert. Ela instala a maior parte dos pacotes automaticamente (dentro
das categorias marcadas), mas pergunta sobre os pacotes considerados
opcionais, exibindo a descrição de cada um. Se você lê em inglês, esta opção
é interessante para aprender um pouco mais sobre os pacotes que compõe o
sistema.
Qualquer que seja a escolha, é importante que você marque a categoria
"KDEI", que inclui os pacotes de internacionalização para o KDE e, dentro
dela, o pacote "kde-i18n-pt_BR", que inclui as traduções para o português do
Brasil:
Durante a cópia dos arquivos, são exibidas as descrições de todos os pacotes,
conforme eles são instalados. Na época dos 486, a instalação demorava muito
mais e realmente dava tempo de ler todas as descrições, o que acabava sendo
um bom passatempo; mas, hoje em dia, tudo acontece muito rápido.
 
Gerenciador de boot
Depois de concluída a cópia, chegamos à segunda parte da instalação, onde é
gerada a configuração inicialdo sistema e é instalado o gerenciador de boot:
A primeira pergunta é sobre a geração de um pendrive de boot, que pode ser
usado para inicializar o sistema caso, por qualquer motivo, o gerenciador de
boot seja sobrescrito ou desativado posteriormente, como no clássico caso do
Windows instalado em dual-boot que é reinstalado, sobrescrevendo o lilo.
Nas versões antigas, o instalador se oferecia para gerar um disquete de boot,
mas a opção se tornou obsoleta a partir do Slackware 12. 
 
 Além do pendrive de boot, outra forma simples de recuperar o sistema em caso de problemas é dar
boot usando um live-CD, onde você tem acesso à internet e outras ferramentas úteis para solucionar o
problema.
A partir dele, você pode montar a partição onde o sistema principal está instalado e até mesmo obter um
prompt de comando, que pode ser usado para regravar o lilo, instalar pacotes ou alterar a senha de root, por
exemplo. Basicamente, qualquer distribuição live-CD desempenha bem essa tarefa, incluindo o Ubuntu e o
Mandriva One. Você pode também utilizar o Slax (veja mais detalhes no capítulo 8), que é um live-CD
baseado no Slackware.
Para montar a partição, a partir do live-CD, use o comando "mount", especificando o sistema de arquivos em
que a partição está formatada, como em:
# mount -t ext3 /dev/sda1 /mnt/sda1
Para ter acesso ao prompt, use o comando chroot, especificando a pasta onde a partição foi montada, como
em:
# chroot /mnt/sda1
Se precisar regravar o lilo, edite o arquivo "/etc/lilo.conf", usando um editor em modo texto (como o mcedit
ou o vi) e rode o comando "lilo" no terminal para salvar as alterações.
Para instalar pacotes (ou reinstalá-los, a fim de corrigir arquivos corrompidos), copie os arquivos para uma
pasta dentro da partição do sistema principal e instale-os usando os comandos de praxe. No caso do
Slackware, você pode instalar pacotes usando o comando "installpkg".
Finalmente, para alterar a senha de root, basta usar o comando "passwd" dentro do chroot. De dentro do
terminal você tem acesso a outros comandos de modo texto que estejam disponíveis na instalação, como se
realmente estivesse usando o sistema principal.
O passo seguinte é a configuração do lilo, o gerenciador de boot responsável
por carregar o sistema na hora do boot. Para gerar a configuração, o
instalador precisa reunir uma série de informações, que são pauta para as
perguntas seguintes:
Usando a opção "simple", o arquivo de configuração é criado
automaticamente e você precisa escolher apenas entre gravar o lilo na MBR
(de forma que o Slackware seja o sistema padrão), ou gravar o lilo no
primeiro setor da partição (Root), opção que é usada caso você esteja
instalando o Slackware junto com outras distribuições e prefira configurar
uma delas para carregá-lo.
A opção "expert" vai um pouco além (oferecendo também a opção de revisar
a configuração no final do processo), mas as escolhas são basicamente as
mesmas. A grande armadilha é a opção "skip", que aborta a instalação do
gerenciador de boot e faz com que o sistema simplesmente não inicialize
depois de instalado, deixando apenas a possibilidade de usar o pendrive de
boot, caso gerado no passo anterior.
A primeira pergunta dentro da configuração do lilo é sobre o uso do frame-
buffer, que melhora bastante o aspecto do terminal de modo texto e permite
usar resoluções maiores. O sintoma de que ele está ativo é a exibição do Tux
no topo da tela durante o boot:
O frame-buffer é uma espécie de driver de vídeo rudimentar, onde o sistema
operacional manipula diretamente a memória da placa de vídeo, gravando e
atualizando a imagem que será mostrada por ela no monitor. Ele não oferece
nenhum tipo de aceleração, nem usa qualquer recurso especial disponível na
placa de vídeo, mas, em compensação, é um sistema bastante simples e por
isso funciona diretamente a partir do kernel, logo no início do boot, sem
precisar do X ou de outras camadas adicionais. Os splashes e animações
exibidas durante o boot em outras distribuições funcionam justamente
utilizando o frame-buffer.
É importante enfatizar que a resolução do frame-buffer afeta apenas o
terminal, sem qualquer efeito sobre a resolução dentro do ambiente gráfico.
Antigamente, existia a opção de usar o módulo "fbdev" na configuração do
X, o que permitia usar o frame-buffer também no X, como uma forma de
resolver problemas de compatibilidade com placas diversas, mas hoje em dia
isso é feito usando o driver "vesa".
A maioria das placas de vídeo suportam 1024x768x64k (1024x768 com 16
bits de cor), mas muitos modelos (incluindo muitas placas atuais, sobretudo
com chipset nVidia) ficam restritos a 800x600. Apenas algumas placas
antigas não suportam frame-buffer completamente. Ao usar uma resolução
não suportada, você verá uma mensagem de erro durante o boot, mas nada
que impeça a inicialização normal.
Esta opção pode ser alterada posteriormente editando o arquivo de
configuração do lilo (o "/etc/lilo.conf"). Use "vga=791" para 1024x768,
"vga=788" para 800x600 ou "vga=785" para 640x480:
A próxima pergunta é sobre o kernel. Em versões antigas, você tinha a opção
de escolher qual kernel utilizar, entre várias opções, como "bare.i", "scsi.s"
ou "sata.i". Estas diferentes opções ofereciam versões do kernel equipadas
com diferentes conjuntos de drivers e recursos, destinados a oferecerem o
melhor desempenho em configurações específicas.
O problema óbvio com essa abordagem é que era necessário um certo nível
de conhecimento para saber escolher a versão correta e, em muitos casos,
escolher a versão incorreta do kernel resultava em um sistema inoperante.
Com a adoção do kernel 2.6 a partir do Slackware 12, a escolha foi
simplificada, restando apenas a opção de usar o "huge.s" (na etapa inicial do
boot), destinado a máquinas antigas.
Durante a instalação, resta apenas a opção de especificar parâmetros para o
kernel, da qual você pode lançar mão caso precise usar o "acpi=off", "noapic"
ou outra opção de boot:
A partir do Slackware 12.1, você tem também a opção de desativar o uso do
UTF-8 no console, o que permite solucionar problemas diversos com a
exibição dos caracteres. O UTF-8 é um novo sistema de codificação, que
oferece um melhor suporte a caracteres especiais e caracteres de línguas
asiáticas. O grande problema é que os códigos para caracteres acentuados e
caracteres especiais do UTF-8 causam problemas de exibição em programas
que não estão preparados para lidar com eles, fazendo com que você veja
quadrados ou outros caracteres estranhos no lugar de caracteres acentuados e
aspas.
A migração para o UTF-8 tem causado muitos problemas para quem mantém
um site ou blog e as dores do parto se estendem a muitos aplicativos.
Entretanto, é importante ter em mente que a opção mostrada durante a
instalação afeta apenas o comportamento do terminal (sem nenhum efeito
sobre os aplicativos gráficos), ou seja, ela é bastante específica:
Finalmente, chegamos à instalação do lilo propriamente dita. Nunca deixe de
instalar o lilo na MBR caso o Slackware seja o único sistema instalado, ou
caso esteja instalando em dual boot com o Windows. Caso contrário, você
simplesmente ficará trancado do lado de fora, sem ter como inicializar o
sistema depois da instalação:
 
Passos finais
Antes do final da instalação, existe ainda a opção de "configurar" o mouse,
criando mais um link simbólico, o "/dev/mouse", apontando para a
localização correta. Você pode indicar o tipo de mouse usado, onde o "ps2"
indica um mouse de dois botões, ligado à porta PS/2, o "imps2" um mouse
PS/2 com roda e o "usb" server para mouses ligados à porta USB de uma
forma geral. Existem outros tipos de mouse menos usados e até mesmo a
opção de usar um tablet como mouse:
A principal questão aqui é que esta configuração na verdade não serve para o
modo gráfico, mas sim para o gpm, um pequeno serviço que controla o
suporte a mouse no terminal. Muitos programas de modo texto, como o links
e o mc suportam o uso do mouse, mesmo com o sistema trabalhando em
modo texto puro, mas,naturalmente, pouca gente usa o sistema deste modo
atualmente. É muito mais prático abrir diversas janelas de terminal dentro do
ambiente gráfico.
Em seguida, você tem a opção de ativar ou não o gpm. Em alguns casos o
gpm interfere com a configuração do mouse no modo gráfico, por isso se
você não pretender realmente usar o sistema em modo texto puro, é
aconselhável desativá-lo.
Em seguida, você tem a opção de criar o link "/dev/modem", que apontaria
para a porta do modem, facilitando seu uso nos discadores. Digo "apontaria"
pois esta opção é útil apenas para as poucas pessoas que ainda utilizam um
hardmodem ISA, ou um modem externo ligado em uma porta serial,
configuração na qual o modem é acessado diretamente e basta criar o link
"/dev/modem" apontando para a porta correta.
Todos os modems discados atuais são softmodems, que precisam de algum
driver adicional para funcionar. Alguns possuem drivers para Linux, outros
não, mas em qualquer caso a instalação não se resume a apenas criar um link
simbólico.
Como de praxe, o instalador pergunta também sobre a configuração da rede,
oferecendo as tradicionais opções de usar endereços estáticos ou DHCP. Se
você acessa através de uma conexão compartilhada, ou via cabo, precisa
apenas ativar a configuração via DHCP; se acessa através de uma conexão
wireless, será necessário primeiro ativar e configurar os parâmetros da rede
wireless, o que só pode ser feito depois de concluída a instalação. Finalmente,
se você acessa via ADSL com autenticação, a dica é não configurar nada
aqui, deixando para configurar o ADSL depois do primeiro boot, usando o
comando "adsl-setup".
Caso você tenha instalado algum dos servidores disponíveis na categoria "n"
(o padrão do instalador é instalar vários), você tem uma última chance de
desativá-los na configuração dos serviços, que determina quais serão
carregados na inicialização do sistema.
A configuração é muito mais simples do que parece: consiste apenas em fazer
com que o script correspondente, salvo dentro da pasta "/etc/rc.d/", seja
executável ou não. Esta opção do instalador simplesmente se oferece para
fazer isso para você.
É importante notar que, em uma instalação padrão, tanto o "rc.ssh" (que
permite acessar sua máquina remotamente) quanto o "rc.sendmail" (um
servidor de e-mails) ficam habilitados. É importante desmarcar ambos, caso
você não tenha nenhum motivo em especial para mantê-los abertos. O
"rc.pcmcia" oferece suporte a placas PCMCIA, é importante mantê-lo ativo
ao instalar em um notebook.
Continuando a sabatina, o instalador pergunta se você deseja mudar a fonte
do terminal (Would you like to try out some custom screen fonts?). Estas
fontes de tela alteram apenas o visual do terminal de texto. Algumas fontes
são menores e permitem exibir mais texto na tela, enquanto outras possuem
visuais estranhos, para todos os gostos.
Novamente, esta configuração afeta apenas o uso do terminal de texto, se
você, como todas as pessoas normais, vai passar a maior parte do seu tempo
usando o modo gráfico, não existe motivo para perder tempo aqui. Algumas
das fontes estouram os limites do terminal, fazendo com que as últimas linhas
não sejam exibidas e muitas fontes não suportam acentuação.
Existe ainda a configuração do fuso horário do sistema. Apesar de não
parecer, esta configuração é muito importante em servidores e mesmo em
alguns tipos de desktop. No Linux é possível manter o relógio do sistema
sincronizado em relação a diversos servidores disponíveis na Internet, usando
o protocolo NTP. Os servidores principais utilizam relógios atômicos ou
GPS, por isso são extremamente precisos.
O uso UTC (horário universal) permite que o mesmo servidor possa atender
clientes de todo o mundo, independentemente do fuso horário usado. O
sistema subtrai o fuso horário do horário universal, chegando à hora certa na
sua cidade.
A configuração consiste em duas perguntas: a primeira é se o relógio do
sistema (o relógio do CMOS) está configurado em relação ao UTC, ou não. O
padrão no Windows é que o relógio é configurado para o horário local
(resposta "No"). O efeito prático é que se você tem o Windows em dual boot
e responder "Yes" aqui, o instalador vai atrasar o relógio em duas ou três
horas (de acordo com o fuso horário escolhido).
Em outras palavras, quando ele pergunta se "O relógio de hardware está
configurado para UTC", ele está perguntando se o relógio está mostrando a
hora certa (independente do fuso horário), ou se ele está mostrando o horário
UTC, de onde ele ainda vai subtrair três horas para chegar ao horário de
Brasília:
Para usar o horário de Brasília, escolha "America/Sao_Paulo" na tela
seguinte. Se precisar alterar a configuração posteriormente, use o timeconfig,
que chama este mesmo script usado na instalação.
A última pergunta é sobre a interface gráfica que será usada. Por padrão, o
Slackware inicia em modo texto e você precisa rodar o comando "startx" para
abrir o modo gráfico. Nessa opção você escolhe qual interface será aberta por
padrão.
Aqui entra um fator cultural. Na época em que foram lançadas as primeiras
versões do Slackware (versão 1.0 saiu em 1993), o Linux sequer possuía
interface gráfica, já que o X foi portado para o sistema apenas em 1994. Por
volta de 1995, muitos dos aplicativos mais usados ainda eram de modo texto,
de forma que muita gente preferia continuar usando o terminal puro (já que o
ambiente gráfico era muito pesado para os PCs da época) e abrir o X apenas
quando realmente necessário.
Pouca coisa mudou no instalador e na configuração padrão do Slackware de
lá até hoje, de forma que muitas perguntas feitas pelo instalador são
exclusivamente relacionadas ao modo texto. De qualquer forma, é fácil
configurar o Slackware para abrir o modo gráfico por padrão, como em
outras distribuições. Veremos a configuração em detalhes mais adiante.
Concluindo a instalação, você tem a chance de definir uma senha para o root,
que é absolutamente necessária em qualquer máquina conectada a qualquer
tipo de rede.
Em vez de reiniciar a máquina automaticamente, o instalador volta à tela
inicial. Para sair, use a opção "exit" e em seguida reinicie o sistema usando o
comando "reboot" ou pressionando "Ctrl+Alt+Del".
 
Sobrevivendo ao primeiro boot
Depois de instalado o sistema, vem o primeiro susto. Diferente de outras
distribuições, o Slackware não carrega o ambiente gráfico por padrão, se
limitando a pedir o login em modo texto.
Inicialmente, você se loga como root, usando a senha definida durante a
instalação. O próximo passo é criar um login de usuário usando o comando
"adduser", como em:
# adduser gdh
Você vai perceber que no Slackware o adduser oferece bem mais opções ao
criar a conta do que em outras distribuições, confirmando até mesmo o shell
padrão e o diretório home. Assim como outras ferramentas, o adduser é na
verdade um shell script, que utiliza o useradd e outras ferramentas do
sistema. O Slackware usa uma versão modificada do script, o que leva às
diferenças no comportamento.
A maioria dos detalhes exibidos durante a criação dos usuários são
configurações padrão (que são alteradas apenas em casos específicos), ou
opções cosméticas, de forma que você pode simplesmente aceitar os valores
default. Entretanto, o Slackware tem uma peculiaridade, que é a seleção dos
grupos.
Todas as distribuições utilizam os grupos como uma forma de permitir a
restrição a determinados recursos do sistema para contas de usuário, caso
desejado. Ao remover um usuário do grupo "audio", por exemplo, ele deixa
de conseguir usar o som; ao removê-lo do grupo "cdrom", ele deixa de
conseguir montar CDs colocados no drive; e assim por diante.
No caso do Slackware, o padrão é que os novos usuários façam parte apenas
do grupo "users", o que cria uma série de restrições, fazendo com que você
não consiga usar o som e outros recursos. Para evitar isso, preste atenção nas
mensagens e, quando ele perguntar:
Press ENTER to continue without adding any additional groups
Or press the UP arrow to add/select/edit additionalgroups:
... pressione a seta para cima para mudar a opção, que ficará ":audio cdrom
floppy plugdev video". Isso faz com que a conta seja cadastrada nos grupos e
tenha acesso normal ao sistema:
Depois de criado o usuário, você pode se logar usando a nova conta e abrir o
ambiente gráfico usando o "startx", como faziam os pioneiros:
# su gdh
$ startx
Em vez de exibir uma tela de login ou perguntar qual interface usar, ele
simplesmente carrega o ambiente gráfico default, que você definiu durante a
instalação. Você pode mudar a escolha usando (como root) o comando
"xwmconfig", que é o mesmo script usado durante a instalação.
O que ele faz é simplesmente verificar quais são os gerenciadores instalados
(o que é feito verificando os arquivos disponíveis na pasta "/etc/X11/xinit") e
criar o link "/etc/X11/xinit/xinitrc", apontando para o escolhido.
Assim como outras das ferramentas do Slackware, o xwmconfig é um shell
script grosseiramente simples, que se limita a examinar o conteúdo da pasta
"/etc/X11/xinit" (onde é colocado um script de inicialização para cada
gerenciador instalado) e criar o link "/etc/X11/xinit/xinitrc", apontando para o
escolhido.
Quando o comando "startx" é executado, ele executa o conteúdo do script,
fazendo com que o KDE, Fluxbox ou outro gerenciador especificado, seja
carregado. Se souber o que está fazendo, você pode até mesmo editar
manualmente o script, fazendo com que ele execute outros comandos.
Embora o Slackware não possua uma interface padrão, se limitando a
oferecer um conjunto de opções e deixando que você escolha qual usar, a
maioria dos usuários da distribuição opta por utilizar o KDE, por isso vou
concentrar as dicas em torno dele, deixando para falar sobre a configuração
do GNOME no capítulo do Ubuntu.
Da primeira vez que é aberto, o KDE exibe um assistente rápido, onde você
pode ajustar o nível de efeitos visuais e escolher a língua padrão do sistema:
A opção do login automático é configurada através do Centro de Controle do
KDE (através da opção "Gerenciador de Login > Conveniência > Habilitar
login automático") e não através de algum arquivo de configuração do
sistema, pois o login é feito através do KDM, que é um componente do KDE.
Ele permite que você escolha qual usuário usar, verifica a senha e carrega o
KDE ou outro ambiente de trabalho escolhido.
Caso esteja curioso, o gerenciador de login que será usado é definido através
do arquivo "/etc/rc.d/rc.4", que é o script responsável por disparar o
carregamento do ambiente gráfico. Seguindo a tradição do Slackware, ele é
um script bem simples, que (descontando os comentários) inclui apenas as
linhas:
echo "Starting up X11 session manager..."
if [ -x /opt/kde/bin/kdm ]; then
exec /opt/kde/bin/kdm -nodaemon
elif [ -x /usr/bin/gdm ]; then
exec /usr/bin/gdm -nodaemon
elif [ -x /usr/X11R6/bin/xdm ]; then
exec /usr/X11R6/bin/xdm -nodaemon
fi
echo "Hey, you don't have KDM, GDM, or XDM. Can't use runlevel 4 without"
echo "one of those installed."
sleep 30
Como pode ver, ele inclui um "se, então, senão se" que tenta primeiro
carregar o KDM, passando em seguida para o GDM (o gerenciador do
GNOME) e o XDM (o gerenciador padrão do X), caso ele não esteja
instalado. No final, ele inclui uma mensagem de erro, que é mostrada se
nenhum dos três estiver instalado.
Voltando ao assistente de boas vindas, o português aparece na lista apenas se
você marcou a categoria "KDEI" e o pacote "kde-i18n-pt_BR" durante a
instalação, mas, se for o caso, você pode instalar o pacote posteriormente
usando o installpkg (como veremos em mais detalhes a seguir) e alterar a
linguagem usando o Kcontrol.
Esse assistente não é exibido na maioria das outras distribuições, pois nelas o
KDE já vem pré-configurado. No Slackware, o KDE simplesmente é
compilado a partir do código-fonte original, sem nenhum tipo de
personalização. Um bom exercício para começar é fuçar um pouco nas
opções, abrindo o kcontrol e o kmenuedit e personalizando o visual a seu
gosto:
Caso esteja curioso, toda a configuração do KDE, incluindo a configuração
dos aplicativos da família K, é salva em arquivos dentro das pastas ".kde" (a
pasta principal) e ".config" (auxiliar, usada principalmente pelos menus).
Elas são pastas ocultas do sistema, por isso não aparecem no gerenciador de
arquivos. Para vê-las, você precisa marcar a opção de ver todos os arquivos
ou usar o comando "ls -a". Se você deletar estas duas pastas, toda a
configuração é revertida para os padrões, incluindo a exibição do assistente
inicial na próxima abertura.
Assim como o KDE, todos os aplicativos salvam, via de regra, suas
configurações dentro de pastas ocultas dentro do diretório home. É
justamente por isso que, ao preservar os arquivos do diretório home, o
sistema continua se comportando quase da mesma forma depois de
reinstalado.
Por enquanto, ainda estamos usando a inicialização manual do X, de forma
que se você reiniciar o micro, volta ao prompt de comando e precisa fazer
login e usar o "startx" para abrir a interface. Muita gente gosta dessa
configuração default e continua utilizando-a por opção, mas, naturalmente, a
maioria torce o nariz para a ideia, o que nos leva à próxima dica.
Para que o Slackware carregue o modo gráfico por padrão durante o boot,
exibindo a tela de login do KDM, como em outras distribuições, edite o
arquivo "/etc/inittab" e altere a linha "id:3:initdefault:", substituindo o
número "3" por "4", como em:
id:4:initdefault:
Essa configuração controla o runlevel padrão do sistema, ou seja, o conjunto
de serviços que serão carregados na hora de boot. No Slackware, o runlevel 3
faz com que o sistema inicialize em modo texto, enquanto o runlevel 4
carrega os mesmos serviços, acrescentando o KDM, responsável por abrir o
modo gráfico e exibir a tela de login. Com isso, você passa a ver a tela de
boot do KDM, onde pode fazer login e escolher qual interface usar:
Assim como em outras distribuições, você pode também ativar o uso do auto-
login, fazendo com que o sistema carregue o KDE automaticamente durante o
boot, já logado em uma conta de usuário escolhida. Entretanto, a
configuração não vai em nenhuma opção dentro da tela de login (nem em
nenhum arquivo de configuração do sistema), mas sim dentro do painel de
controle do KDE, como veremos no tópico sobre ele.
Outro detalhe digno de nota é que ao alterar a linha no inittab para
"id:4:initdefault:" o sistema passa a abrir apenas um terminal de texto puro
(acessível através do Ctrl+Alt+F6) em vez de 6 terminais de texto, como seria
normal. Isso acontece devido a outra configuração incluída no arquivo
"/etc/inittab", que corresponde às linhas abaixo:
# These are the standard console login getties in multiuser mode: 
c1:1235:respawn:/sbin/agetty 38400 tty1 linux 
c2:1235:respawn:/sbin/agetty 38400 tty2 linux 
c3:1235:respawn:/sbin/agetty 38400 tty3 linux 
c4:1235:respawn:/sbin/agetty 38400 tty4 linux 
c5:1235:respawn:/sbin/agetty 38400 tty5 linux 
c6:12345:respawn:/sbin/agetty 38400 tty6 linux
Estas 6 linhas são, como pode imaginar, as responsáveis por iniciar os 6
terminais em modo texto. Note que apenas a última inclui o número "4", de
forma que apenas o terminal referente a ela é carregado ao usar o runlevel 4.
Essa configuração surgiu na época dos micros 486 (quando o X começou a
ser usado), com o objetivo de economizar memória, desativando os terminais
de texto quando o X era usado por padrão.
Apenas um terminal era mantido, para que você pudesse reparar o sistema em
caso de problemas com o X. Naturalmente, isso não faz muita diferença hoje
em dia (já que cada terminal adicional consome 500 KB de memória, ou
menos), mas o ajuste permanece, servindo como uma curiosidade histórica.
Continuando, a próxima parada é a configuração do som, que é feita usando o
"alsaconf". Ele se encarrega de detectar a placa, carregar os módulos
apropriados e executar as demais etapas necessárias para ativá-la. Nas
versões atuais do Slackware, a detecção da placa de som passou a ser feita
automaticamente (na maioria dos casos),mas, de qualquer maneira, o script
continua disponível.
Diferente de scripts como o "liloconf" e o "xwmconfig", que são específicos
do Slackware, o alsaconf faz parte do Alsa, que é o conjunto de drivers para
placas de som usado na grande maioria das distribuições atuais. Você pode
utilizá-lo também em outras distribuições, sempre que a placa de som não for
detectada automaticamente. Para usá-lo, basta chamar o comando como root:
# alsaconf
Deixe que ele detecte a placa e responda "sim" quando ele perguntar se você
deseja ajustar a configuração do arquivo "modprobe.conf". O processo é todo
automático:
Por padrão, o alsaconf deixa o som mudo; uma precaução contra eventuais
bugs nos drivers, que possam estourar seus tímpanos com algum barulho
ensurdecedor. Para finalmente usar o som, é necessário ajustar o volume, o
que pode ser feito usando o "aumix" e o "kmix" (ou outro controlador de
volume) ou no próprio terminal, usando o "alsamixer", outro pequeno
utilitário da suíte Alsa.
Ele é mais um utilitário em modo texto, onde você ajusta os volumes usando
as setas e pode sair usando a tecla Esc:
# alsamixer
Depois de ajustar o volume e testar, use o comando "alsactl store" para salvar
a configuração e fazer com que o volume definido passe a ser carregado
automaticamente durante o boot:
# alsactl store
Este mesmo comando pode ser usado em outras distribuições, resolvendo
casos em que o sistema não ajusta o volume do som corretamente durante o
boot.
A configuração da placa de rede pode ser feita rapidamente usando o
"netconfig", um utilitário que pergunta o endereço IP e outros dados da rede
e, no final, se encarrega de detectar a placa de rede e ativar o módulo
correspondente. Ele é o mesmo utilitário de configuração mostrado no final
da instalação:
# netconfig
A pegadinha é que o netconfig apenas altera a configuração da rede (salva no
arquivo "/etc/rc.d/rc.inet1.conf"), sem aplicá-la no final do processo. Para que
a nova configuração seja realmente aplicada, é necessário reiniciar o serviço
responsável pela configuração da rede, usando o comando:
# /etc/rc.d/rc.inet1 restart
Se você conecta usando um model ADSL configurado como bridge (ADSL
PPPoE), pode configurar a conexão usando o comando "pppoe-setup":
# pppoe-setup
Ele faz a configuração inicial, detectando o modem e pedindo o login e senha
de acesso. Ele se oferece também para compartilhar a conexão com outros
micros da rede local. Uma vez configurada a conexão, use os comandos
"pppoe-start" e "pppoe-stop" para conectar e desconectar.
Para que estes comandos estejam disponíveis, você precisa ter instalado o
pacote "rp-pppoe", disponível na categoria "n". Este mesmo pacote é
encontrado no Fedora, Mandriva e em outras distribuições, com exceção do
Debian (e outras distribuições baseadas nele), onde é usado o "pppoeconf".
Nas versões antigas do rp-pppoe (usadas até o Slackware 10.1) os comandos
começam com "adsl" ao invés de "pppoe". Nestes casos, ao invés de "pppoe-
setup" você usa "adsl-setup", e assim por diante.
Acesso à partições: A partir da versão 12.1, o Slackware vem pré-
configurado para usar o HAL em conjunto com o KDE, oferecendo o recurso
de detecção automática de pendrives e CD-ROMs, onde os ícones de acesso
aparecem diretamente no desktop, sem que você precise fazer a montagem
manual.
Para que o recurso seja ativado, é necessário apenas que, ao criar a conta de
usuário, você a adicione aos grupos "cdrom" e "plugdev", que fazem parte
dos grupos que aparecem ao pressionar a seta para cima, como fizemos ao
adicionar o "gdh".
De qualquer forma, é interessante entender também o processo de montagem
manual, que permite solucionar problemas diversos.
A primeira dica é sobre o acesso ao CD-ROM ou DVD. Normalmente, você
pode montar o CD-ROM usando o comando "mount /mnt/cdrom" (o
comando tradicional) ou "mount /media/cdrom" (usado em muitas
distribuições atuais) que faz com que os arquivos fiquem acessíveis através
da pasta. Da mesma forma, ao terminar de usar, você pode desmontar usando
o "umount /mnt/cdrom" ou "umount /media/cdrom".
Estes comandos funcionam devido a uma linha incluída no arquivo
"/etc/fstab", que inclui as outras informações que o sistema precisa para
acessar o drive. Aqui temos um exemplo de entrada usada em uma instalação
do Ubuntu:
/dev/scd0 /media/cdrom udf,iso9660 user,noauto,exec,utf8 0 0
No caso do Slackware, a linha referente ao drive óptico vem comentada no
fstab, o que faz com que você não consiga acessar os arquivos usando os
ícones no KDE nem o tradicional "mount /mnt/cdrom". Para resolver o
problema, abra o arquivo "/etc/fstab" e remova o comentário (#) da linha:
/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
Como pode ver, ela referencia o device "/dev/cdrom", que é na verdade um
link simbólico, que deve apontar para o dispositivo correto do drive. No
Slackware o link não é criado por padrão, por isso é necessário criá-lo
manualmente, usando o comando "ln -s", como em:
# ln -s /dev/hdc /dev/cdrom
O "/dev/hdc" no exemplo, indica um drive instalado como master na segunda
porta IDE. Naturalmente, você deve substituí-lo pelo dispositivo correto, caso
diferente. Em muitos micros atuais, o drive é instalado na primeira porta IDE
(já que a maioria das placas atuais possui apenas uma) e é visto pelo sistema
como "/dev/hda".
A partir daí, você pode montar o CD usando o "mount /mnt/cdrom" e
desmontar usando o "umount /mnt/cdrom", ou simplesmente usar o ícone
dentro do KDE.
Para acessar pendrives, câmeras e outros dispositivos de armazenamento
USB, o processo é similar. Quando você pluga um pendrive na porta USB o
sistema detecta a nova unidade e atribui um device a ele, quase sempre
sequencial ao atribuído ao HD. Se seu HD é visto pelo sistema como
"/dev/sda", por exemplo, o pendrive seria visto como "/dev/sdb".
Assim como em um HD, o pendrive possui partições. Normalmente usamos
apenas uma, que no exemplo seria a "/dev/sdb1", mas nada impede que você
divida o pendrive em várias partições, como faria em um HD.
Para acessar os arquivos, você precisa apenas criar uma pasta e montar a
partição, como em:
# mount /dev/sdb1 /mnt/sdb1
Para verificar como o sistema detectou o pendrive, use o comando "cat
/proc/partitions", ele lista todos os dispositivos e as partições disponíveis,
incluindo o pendrive, que aparecerá no final da lista.
Você pode também ver as mensagens geradas pelo sistema durante a ativação
do dispositivo usando o comando "dmesg". Além de mostrarem algumas
informações interessantes sobre o dispositivo, elas podem ajudar em casos de
problemas de detecção.
Outra dica é que existem alguns obstáculos em rodar aplicativos como root
ao se logar como usuário. Usando o comando "su" para virar root, você vai
perceber que o path (as pastas onde o sistema procura pelos executáveis dos
comandos executados no terminal) fica diferente, o que faz com que o bash
não encontre muitos comandos. A solução para este primeiro problema é usar
o comando "su -" (que configura o path corretamente) para virar root, ao
invés do "su".
O segundo problema é que mesmo ao se logar como root, você não
conseguirá abrir aplicativos gráficos, ficando limitado a usar os aplicativos de
modo texto. É difícil entender esta configuração padrão (que estimula o uso
do root, dificultando as coisas para quem usa uma conta de usuário), mas
existe uma forma simples de resolver questão. Ao invés de abrir o terminal
como usuário e rodar o comando "su -" para virar root, abra diretamente o
terminal como root, usando o kdesu, como em:
$ kdesu konsole
Você pode também executar o comando pressionando "Ctrl+F2". O kdesu
configura corretamente as variáveis e permissões, permitindo que você
consiga abrir qualquer aplicativo, como root, dentro do terminal.
Concluindo, é importante que você pratique essas dicas na frente do micro, já
que é quase impossível entender todos estes detalhes sem realmente ir
aplicando os passos e vendo o resultado de cada um. Não é preciso que você
tenha um segundo micro ou que instale o Slackwareem dual-boot: você pode
simplesmente praticar instalando-o em uma máquina virtual, que pode rodar
até mesmo sobre o Windows, como vimos na introdução.
 
Configurando o X
Diferente do que temos em praticamente todas as outras distribuições atuais,
o Slackware não configura automaticamente o vídeo durante a instalação,
mantendo a cultura de deixar que você quebre a cabeça e aprenda a fazer as
coisas sozinho.
Você pode estar se perguntando como é que foi então possível usar o X no
tópico anterior chamando o "startx", sem que fosse necessário fazer alguma
configuração prévia. A resposta é simples: embora não faça nada para
detectar a placa de vídeo ou o monitor, o Slackware utiliza um arquivo de
configuração genérico, configurado para usar o driver vesa, um mínimo
múltiplo comum, que utiliza apenas funções básicas que são (com poucas
exceções) suportadas por qualquer placa de vídeo.
Isso faz com que a configuração padrão funcione em quase todos os micros,
embora com um desempenho ruim e nem sempre na resolução de tela ideal,
já que o driver vesa suporta apenas 800x600, 1024x768 e (em algumas
placas) 1280x1024. Além disso, o driver não oferece recursos de aceleração,
o que faz com que o uso do processador ao assistir vídeos ou rodar programas
que fazem uso intenso do vídeo, seja bem maior que o normal, sem falar na
ausência de qualquer suporte a 3D. Com isso, o próximo item no checklist
pós-instalação é configurar o vídeo corretamente.
Para isso, o primeiro passo é executar o "xorgsetup", um pequeno script de
configuração, incluído a partir do Slackware 12, que se encarrega de detectar
a configuração, evitando que você precise fazer toda a configuração
manualmente, como nas versões antigas.
Na verdade, a detecção é feita pelo próprio X.org (através do comando "X -
configure" que é usado durante a configuração), o script apenas faz algumas
verificações adicionais e pergunta sobre as opções relacionadas ao layout do
teclado, que não é detectado automaticamente. Basta chamá-lo como root:
# xorgsetup
Para um teclado ABNT2, use as seguintes configurações:
Keyboard model: abnt2 
Keybaord layout: br 
Layout variant: none
Second layout: none
Additional keyboard options: none
Ele não pergunta nada sobre o mouse, o modelo da placa de vídeo e nem
mesmo sobre o monitor, pois essas configurações são detectadas
automaticamente pelo X. Ele confirma apenas a profundidade de cor que será
usada. No final, ele salva a configuração no arquivo "/etc/X11/xorg.conf",
criando um backup do arquivo original.
Na maioria dos casos, a configuração gerada por ele funciona bem, mas não
custa entender melhor as opções e aprender assim como solucionar
problemas.
Em primeiro lugar, o arquivo é dividido em seções. Basicamente, temos (não
necessariamente nesta ordem) uma seção "Server" (com parâmetros gerais),
a seção "Files" (que é opcional nas versões atuais), com a localização das
fontes de tela e bibliotecas, duas seções "InputDevice" (uma com a
configuração do teclado e outra com a do mouse), uma seção "Monitor" e
outra "Device" (com a configuração do monitor e placa de vídeo) e, por
último, a seção "Screen", onde é dito qual resolução e qual profundidade de
cor será usada.
A ordem com que estas configurações aparecem no arquivo pode mudar de
distribuição para distribuição, mas a ordem não importa muito, desde que
estejam todas lá. Como em outros arquivos de configuração, você pode
incluir comentários, usando um "#" no início das linhas. Linhas em branco,
espaços e tabs também são ignorados e podem ser usados para melhorar a
formatação do arquivo e a organização das informações.
A configuração do teclado que indicamos ao rodar o xorgsetup, por exemplo,
é salva como:
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "abnt2"
Option "XkbLayout" "br"
EndSection
Uma curiosidade é que a configuração de teclado especificada no arquivo, na
verdade não é usada nem no KDE nem no GNOME, que utilizam módulos
próprios para a configuração, independentes da configuração do X. No KDE,
a configuração do teclado é definida quando você indica a
linguagem/localização na tela de boas-vindas.
Ele utiliza o Kxkb, que possui uma configuração de teclado independente da
do X, que você ajusta através do painel de controle do KDE. É por isso que o
teclado fica corretamente configurado dentro do KDE mesmo antes de
configurar o vídeo usando o xorgconfig. Na verdade, a configuração
especificada no xorg.conf é usada apenas dentro do Fluxbox, Icewm e outras
interfaces.
Continuando, temos a configuração do mouse, que é detectada
automaticamente. Na maioria dos casos é usada uma configuração como essa:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection
O "/dev/input/mice" é um device criado pelo próprio kernel, apontando para a
porta do mouse (funciona tanto para mouses USB quanto PS/2). Essa é uma
novidade das versões recentes do kernel, que permite também o uso de dois
ou mais mouses simultaneamente (como ao usar um mouse USB em um
notebook, junto com o touchpad). Em distribuições antigas, era necessário
indicar a porta manualmente, como em "/dev/ttyS0" (COM0) ou "/dev/psaux"
(porta PS/2).
A linha Option "ZAxisMapping" "4 5 6 7", ou "ZAxisMapping" "4 5" ativa a
rodinha do mouse, quando disponível. Do ponto de vista do sistema
operacional, a rodinha é um conjunto de dois botões extras (botões 4 e 5) e os
giros da roda correspondem a cliques neles.
A diferença entre as duas opções é que a "ZAxisMapping" "4 5 6 7" oferece
também suporte a mouses com duas rodas (os modelos com scroll vertical e
horizontal), enquanto a "ZAxisMapping" "4 5" se limita a ativar a roda de
scroll vertical.
Nem todos os mouses são iguais, por isso o X inclui um conjunto de drivers
(ou protocolos), que são usados de acordo com o modelo. Entra em cena
então a opção "Protocol" "auto", que ativa a detecção automática do X.
Em casos específicos, onde o mouse não funcione corretamente, você pode
substituir o "Protocol" "auto" por "Protocol" "IMPS/2" (que é o protocolo
padrão para mouses de três botões, com roda), ou "Option "Protocol" "PS/2",
que é o protocolo para mouses PS/2 antigos, sem roda.
Um terceiro protocolo é o "ExplorerPS/2", que é usado pelo IntelliMouse
Explorer e outros modelos com 5 botões (incluindo os dois botões laterais
para avançar e retroceder). Um exemplo de configuração, caso esteja tendo
problemas com eles é:
Section "InputDevice"
Identifier "Mouse"
Driver "mouse"
Option "Protocol" "ExplorerPS/2"
Option "ZAxisMapping" "4 5"
Option "Buttons" "7"
Option "Device" "/dev/input/mice"
EndSection
Se a função dos dois botões extra e da roda ficarem trocadas, substitua a linha
"Option "ZAxisMapping" "4 5" por "Option "ZAxisMapping" "6 7".
Temos em seguida a configuração do monitor, que é especificada na seção
"Monitor". Você notará que a configuração gerada pelo xorgsetup (e por
outras ferramentas atuais) não inclui as taxas de varredura do monitor, se
limitando a gerar uma seção semi-vazia, como neste exemplo:
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Isso acontece por que as configurações do monitor são detectadas via DDC
(Display Data Channel), que permite que o próprio monitor forneça as
resoluções e as taxas de varredura suportadas. O DDC é um sistema bastante
seguro de detecção, pois permite que o X utilize as próprias especificações do
fabricante, sem o risco de deixar a imagem fora de sincronia, como acontecia
em monitores antigos.
De qualquer maneira, em caso de problemas é possível especificar as taxas de
varredura horizontal e vertical usadas pelo monitor incluindo as opções
HorizSync e VertRefresh, como nesse exemplo:
Section "Monitor"
Identifier "Monitor0"
VendorName "GSM"
ModelName "GSM3b60"
HorizSync 30 - 63 
VertRefresh 50 - 75 
EndSection
As opções VendorName e ModelName são apenas descritivas, podem conter
qualquer texto, enquantoa Identifier é uma string de identificação que é
usada para referenciar o monitor em outras partes do arquivo (e que não deve
ser alterada, a menos que você altere junto as outras referências a ela). Se
você não souber as taxas de varredura usadas pelo seu monitor e quiser
alguma configuração genérica que funcione em qualquer monitor
contemporâneo, experimente usar esta, que permite trabalhar a até 1024x768
com 60 Hz de atualização:
Section "Monitor"
Identifier "Monitor0"
HorizSync 31.5 - 50.0
VertRefresh 40-90
EndSection
Em alguns casos, pode ser preciso adicionar manualmente opções
"Modeline" dentro da seção, indicando diretamente as taxas suportadas.
Estas informações são necessárias apenas em casos de monitores que não
suportem a detecção via DDC, como é o caso de monitores muito antigos, e
também de algumas HDTVs, quando ligadas ao PC através da entrada VGA.
Em outras palavras, eles são um último recurso a usar em casos em que tudo
mais falhou.
Este é um exemplo de configuração para um monitor de 17", incluindo os
modelines para resoluções de 1280x1024, 1024x768 e 800x600:
Section "Monitor"
Identifier "Monitor0"
VendorNam "GSM"
ModelName "GSM3b60"
HorizSync 30 - 63 
VertRefresh 50 - 75 
ModeLine "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync
+vsync
ModeLine "1024x768" 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync
ModeLine "800x600" 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync
EndSection
Os modelines parecem uma configuração bastante arcana, mas, na verdade,
eles são gerados automaticamente usando o "cvt", que é um pequeno
utilitário de terminal. Você precisa apenas chamá-lo indicando a resolução e a
taxa de refresh que será usada (em hz) e ele devolve o modeline
correspondente, como em:
# cvt 1280 800 60
# 1280x800 59.81 Hz (CVT 1.02MA) hsync: 49.70 kHz; pclk: 83.50 MHz 
Modeline "1280x800_60.00" 83.50 1280 1352 1480 1680 800 803 809 831 -hsync +vsync
Se você estiver fazendo isso via terminal, deve estar se perguntando como
fazer para colocar a linha dentro da configuração, já que você não tem como
copiar e colar o texto usando o mouse.
A solução é simples: adicione um ">> /etc/X11/xorg.conf" para que ele
escreva a saída no final do arquivo (em vez de exibi-la no terminal). A partir
daí, você pode usar o editor de texto para copiar e colar as linhas no local
correto, dentro do arquivo.
Em seguida, vem a seção "Device" que indica a configuração da placa de
vídeo, como em:
Section "Device" 
Identifier "card0" 
VendorName "ATI Technologies, Inc."
BoardName "Radeon X800 (R430 UO)"
Driver "ati" 
BusID "PCI:1:0:0" 
EndSection
As opções Identifier, VendorName e BoardName são apenas descrições e a
"BusID" (que é preenchida automaticamente) é necessária apenas em
configurações para duas placas de vídeo e dois monitores. O que interessa
mesmo é o driver usado.
A placa de vídeo é detectada pelo sistema através da identificação fornecida
por ela (a mesma que é exibida ao executar o comando "lspci"). Diferente do
que tínhamos na época do Xfree 3.3.6, onde cada chipset de vídeo utilizava
um módulo diferente, nas versões atuais é usado um pequeno número de
drivers (os arquivos são salvos na pasta "/usr/lib/xorg/modules/drivers/"),
sendo que cada driver oferece suporte a todos os chipsets de um mesmo
fabricante.
A detecção de hardware é um campo em que o Linux, de uma forma geral,
evoluiu bastante de alguns anos para cá. Antigamente, toda a configuração
precisava ser feita manualmente, ou através de utilitários que tentavam (nem
sempre com sucesso) detectar os componentes da máquina. Hoje em dia, a
maior parte da detecção é feita diretamente pelo kernel, com a ajuda do udev
e de outros componentes. Este é um dos motivos das diferenças entre as
distribuições terem diminuído.
No caso dos drivers de vídeo, além do vesa, que é o driver failsafe, outros
drivers disponíveis são:
i810: Este é o driver usado por todas as placas de vídeo onboard com
chipset Intel. A lista de compatibilidade inclui quase todos os chipsets
com vídeo onboard da Intel, incluindo as placas com o chipset Intel 900
e o Intel Extreme e todos os notebooks baseados em chipset Intel (com
exceção dos poucos modelos que utilizam placas offboard da ATI ou da
nVidia). Em versões recentes do X.org, ele mudou de nome e passou a
se chamar "intel".
ati: Este é o driver open-source que dá suporte às placas da ATI. Existe
uma certa confusão com relação à diferença entre o "ati" e o "radeon",
já que usando um ou outro na configuração, o vídeo funciona da mesma
forma. A resposta é que o "ati" é um wrapper, ou seja, um pseudo-
driver, que detecta a placa e carrega o driver correto. Ele é usado por
que existem na verdade dois drivers diferentes para placas ATI: o
radeon, que dá suporte às placas atuais e o r128, que dá suporte às
antigas Riva 128.
O driver oferece aceleração 3D para a maioria dos modelos, que você
pode testar abrindo qualquer game 3D, como o Chromium ou o Tux
Racer. Além do driver open-source, existe também a opção de usar o
driver proprietário da ATI, que oferece um desempenho 3D superior
(quando funciona).
nv: É o driver genérico para placas nVidia. Ele funciona bem e oferece
os recursos básicos de aceleração de vídeo, mas possui a pesada
limitação de ser apenas 2D. Para ativar os recursos 3D da placa, é
preciso instalar o driver proprietário da nVidia.
sis: Este é o driver genérico para placas da SiS, que é mantido pelo
Thomas Winischhofer (http://www.winischhofer.at/linuxsisvga.shtml),
sem qualquer tipo de apoio por parte da SiS. O driver não suporta
muitas das placas atuais (com destaque para as baseadas no chipset
Mirage 3) e não possui suporte 3D.
tdfx: Driver para as placas da 3Dfx, as famosas Voodoo. Se você tiver
alguma Voodoo 2 ou 3 perdida por aí, pode usá-la no Linux, com
direito a suporte 3D.
trident: Driver para as antigas placas da Trident.
via: Este é o driver que dá suporte ao chipset VIA Unicrome, usado
como vídeo onboard na maior parte das placas-mãe com chipset VIA e
também em alguns notebooks. Originalmente, este driver era apenas
2D, como o nv e o sis, mas a partir de abril de 2005 a VIA passou a
publicar um driver 3D open-source, que pode ser encontrado nas
http://www.winischhofer.at/linuxsisvga.shtml
versões recentes do X.org. Para que a aceleração 3D oferecida por ele
funcione, é necessário que os módulos "via-agp" e "via" estejam
carregados. Caso necessário, você pode carregá-los manualmente
usando o comando modprobe.
vmware: Este é o driver otimizado para uso no VMware, usado quando
você instala o sistema dentro de uma máquina virtual.
No final do arquivo vai a seção "Screen", que indica a resolução e a
profundidade de cores que será usada. Tudo começa com a opção
"DefaultDepth", que indica a configuração de cor. Ao usar 24 bits, por
exemplo, ela será:
DefaultDepth 24
Em seguida, temos várias seções que especificam as resoluções disponíveis
para cada modo (1, 4, 8, 16, etc.), como em:
SubSection "Display"
Viewport 0 0
Depth 4
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 8
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
EndSubSection
Ter tantas seções repetidas gera dúvidas, mas, na verdade, a única que
interessa é a seção referente à profundidade de cor escolhida (24 no
exemplo). Todas as demais são irrelevantes e podem até mesmo ser
removidas do arquivo, se preferir.
No arquivo gerado pelo xorgsetup, não é especificada a resolução, pois o X
tenta sempre detectar a resolução do monitor via DDC. Nos casos em que a
detecção falhar, ou em que você queira usar uma resolução diferente da
padrão, adicione uma linha "Modes", especificando a resolução que quer
usar, como em:
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x800" "1024x768" "800x600" "640x480"
EndSubSection
Nesse exemplo, estou especificando todas as resoluções suportadas pelo
monitor. A que vale mesmo é a primeira (1280x800) que é sempre usada por
padrão. As demaissão usadas apenas em casos de problemas (imagine que
em um belo dia você troque o monitor por outro que suporte apenas
1024x768, por exemplo) ou no caso de aplicativos que precisem alterar a
resolução do vídeo (como no caso dos jogos).
Se você quer uma resposta simples de como fazer com que o Slackware
detecte corretamente a resolução da tela wide do seu monitor ou notebook, o
caminho é justamente esse: indicar corretamente o driver na seção "Device" e
inserir a resolução manualmente na seção "Display", como nesse exemplo:
Section "Device"
Identifier "Card0"
Driver "radeon"
VendorName "ATI Technologies Inc"
BoardName "RS485 [Radeon Xpress 1100 IGP]"
BusID "PCI:1:5:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x800"
EndSubSection
EndSection
Quase sempre, o xorgsetup detectará corretamente o driver de vídeo, faltando
apenas incluir a linha "Modes" na seção "Display", especificando a resolução
correta. Como pode observar, neste segundo exemplo incluí apenas a
resolução default, que é a efetivamente usada.
Continuando, sempre que você fizer alterações no arquivo e quiser testar a
configuração, pode reiniciar o X rapidamente pressionando
"Ctrl+Alt+Backspace". Via de regra, a única situação em que é realmente
necessário reiniciar o sistema no Linux é no caso de uma atualização do
kernel. Em outros casos, basta reiniciar o serviço ou o aplicativo que foi
alterado ou atualizado, como no caso do X.
Além do xorgsetup, outros utilitários de configuração que você pode testar
são o "kxconfig" (que é um configurador gráfico, incluído no KDE) e o
"xorgcfg", outro configurador gráfico, um pouco mais simples que o
kxconfig que também pode ser chamado a partir do modo texto. Ele é útil nos
famosos casos em que o X não sobe devido a alguma configuração incorreta.
Uma última opção é o xorgconfig, uma ferramenta de configuração
rudimentar, em modo texto, que está disponível desde as primeiras
distribuições. O xorgconfig é na verdade um wizard, que faz uma série de
perguntas, incluindo o tipo de mouse e porta onde ele está instalado, layout e
linguagem do teclado, resolução e taxa de atualização do monitor, chipset da
placa de vídeo, além da resolução e profundidade de cores desejadas e utiliza
as respostas para gerar o arquivo de configuração.
Em qualquer um dos casos, a principal dica é sempre salvar cópias dos
arquivos anteriores antes de fazer alterações. Dessa forma, você pode sempre
restaurar a configuração antiga e começar de novo, em caso de erros.
Concluindo, você vai perceber que em muitas distribuições atuais, com
destaque para o Ubuntu e o Fedora, o arquivo xorg.conf praticamente não
contém opções, incluindo apenas as seções vazias. Isso acontece por que
nelas a placa de vídeo e a resolução do monitor são detectados
automaticamente a cada boot.
O arquivo xorg.conf passa então a servir apenas como uma forma de forçar o
uso de determinadas opções, para ser usado nos casos em que a configuração
automática não funciona. A partir do Fedora 10, os desenvolvedores foram
longe a ponto de remover o arquivo completamente (embora o sistema
continue lendo a configuração caso você crie o arquivo manualmente).
Se tudo mais falhar, você pode usar este exemplo de arquivo de configuração
como um failsafe. Ele inclui uma configuração o mais simples possível, que
faz com que o sistema não tente detectar a placa de vídeo, utilizando
diretamente o driver "vesa" com resolução de 1024x768, 800x600 ou
640x480, de acordo com o suportado pela placa. Ele é um arquivo similar ao
usado por padrão no Slackware, mas simplificado de forma a funcionar em
qualquer distribuição.
Salve-o em um pendrive junto com outros drivers e arquivos de manutenção
e use-o em situações onde o sistema não consiga detectar a placa e o
carregamento do modo gráfico seja abortado:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "abnt2"
Option "XkbLayout" "br"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
EndSection
Section "Monitor"
Identifier "Monitor0"
EndSection
Section "Device"
Identifier "Card0"
Driver "vesa"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "1024x768" "800x600" "640x480" 
EndSubSection
EndSection
 
Drivers 3D da nVidia e da ATI
Além dos drivers open-source, temos também os drivers 3D proprietários da
nVidia e da ATI, que podem ser instalados posteriormente. O driver da
nVidia é prioritário, já que o driver "nv" (a opção open-source incluída no X)
oferece apenas suporte 2D, enquanto o driver da ATI só é realmente
necessário em alguns casos.
nVidia: Embora sejam proprietários e sejam distribuídos apenas em formato
binário (o que faz com que não sejam incluídos por padrão na maioria dos
distribuições), os drivers da nVidia são bem desenvolvidos e relativamente
fáceis de instalar. Você pode baixá-los no: 
http://www.nvidia.com/object/unix.html
Em 90% dos casos, você deve baixar a versão Linux IA32, a versão
"padrão". A versão "AMD64/EM64T" é reservada para distribuições Linux
compiladas para processadores de 64 bits, que não é o caso do Slackware
12.2.
Se você tem uma placa nVidia antiga, baixe uma das versões do driver
Legacy, que estão disponíveis logo abaixo do link principal. As versões mais
antigas oferecem suporte até mesmo a placas como a GeForce 256 e a
GeForce2 GTS.
Para instalar, a única dificuldade é que você precisa encerrar o modo gráfico
e executar o arquivo a partir de um terminal de texto puro. Se você tiver
ativado a abertura automática do ambiente gráfico, basta usar o comando
"init 3" como root. Ele fecha o KDM, devolvendo-o ao terminal em texto.
http://www.nvidia.com/object/unix.html
A partir daí, logue-se como root no terminal, marque a permissão de
execução para o arquivo e execute-o, como em:
# chmod +x NVIDIA-Linux-x86-180.29.pkg1.run
# ./NVIDIA-Linux-x86-180.29.pkg1.run
Além de instalar o driver, é necessário alterar a configuração do vídeo, para
que ele seja usado. Responda "yes" quando o instalador perguntar sobre a
configuração do vídeo, deixando que ele faça as alterações necessárias no
arquivo "/etc/X11/xorg.conf" de forma automática.
Se você gostou de editar a configuração do X manualmente, é possível
também fazer a configuração manualmente, já que ela consiste em apenas
algumas alterações simples.
Para isso, edite o "/etc/X11/xorg.conf". Perto do início do arquivo (na seção
"Module"), comente ou apague as linhas Load "GLcore" e Load "dri" e
verifique se a linha "Load "glx" está descomentada.
Mais abaixo (na seção "Device"), procure pela linha Driver "nv" (ou Driver
"vesa") e substitua-a por Driver "nvidia", indicando que o X deve usar o
novo driver. Basicamente, são estas três alterações que o instalador faz ao
modificar o arquivo.
Depois de concluído, reabra o ambiente gráfico usando o comando "init 4".
Em caso de problemas, basta desfazer as alterações para desativar o driver e
voltar a usar o driver "nv".
Uma opção relacionada ao driver que causa problemas em conjunto com
algumas placas AGP (ela não se aplica às placas PCI Express), é a opção
"NvAGP", que pode ser adicionada dentro da seção "Device", acima da linha
Driver "nvidia", como em:
Section "Device"
Option "NvAGP" "1" 
Identifier "Card0"
Driver "nvidia"
VendorName "All"
BoardName "All"
EndSection
Se o vídeo não está abrindo, ou o micro está travando ao rodar aplicativos
3D, experimente substituir o "1" por um "0". Isso faz com que a placa de
vídeo seja acessada como se fosse uma placa PCI, sem armazenar texturas na
memória e outros recursos permitidos pelo AGP.
O desempenho naturalmente cai, principalmente nosgames mais pesados ou
ao usar resoluções mais altas, mas os problemas são minimizados. Você pode
experimentar também substituir o "1" por "2", de forma que a linha fique:
Option "NvAGP" "2"
Assim, você usa o driver "agpgart", que é o driver AGP padrão, incluído no
próprio kernel. Este é um driver genérico, que ativa todas as funções do
barramento AGP, sem nenhuma otimização em especial. É um meio termo
entre usar o módulo da nVidia e usar o NvAGP "0".
Concluindo, existe também um projeto de desenvolvimento de drivers 3D
open-source para placas da nVidia, o "Nouveau" (pronuncia-se "novô"). Ele
é desenvolvido sem o apoio da nVidia e, no início de 2009, ainda oferece
suporte 3D para poucas placas, mas, apesar disso, ele já é utilizado por
default no Fedora 11. Pode ser que se torne uma alternativa viável aos drivers
binários da nVidia no futuro.
ATI: As placas da ATI sempre foram relativamente bem suportadas pelo
Xfree. Tanto as antigas Riva 128 quanto as Radeon possuem drivers nativos a
partir do Xfree 4.3 e em todas as versões do X.org, através dos drivers "r128"
e "ati" (ou "radeon", nas versões anteriores do X). Estes drivers oferecem um
desempenho 3D razoável, em parte graças à própria ATI, que contribuiu no
desenvolvimento e abriu parte das especificações das placas, de forma a
facilitar o trabalho da equipe de desenvolvimento.
Entretanto, em 2003, a ATI resolveu seguir o mesmo caminho da nVidia,
passando a desenvolver um driver 3D proprietário e parou de contribuir com
o desenvolvimento do driver open-source. O grande problema era que a ATI
dedicava apenas uma pequena equipe ao desenvolvimento dos drivers, o que
resultava em muitos problemas de instalação em versões recentes do X, ou
em distribuições diversas, o que deu origem à má fama das placas ATI entre
usuários Linux, que persiste até os dias de hoje.
Essencialmente, você podia se conformar com as limitações de desempenho
do driver open-source (que em compensação funcionava em quase todas as
placas), ou instalar o driver proprietário da ATI, que oferecia a possibilidade
de obter um desempenho mais próximo do oferecido pelos drivers do
Windows, mas que, em compensação, não funcionava corretamente em
muitas situações.
No final de 2006, a ATI foi comprada pela AMD, que decidiu abrir
gradualmente o código-fonte dos drivers, mantendo uma equipe de
desenvolvimento própria (em parceria com a Novell); mas, ao mesmo tempo,
facilitando o desenvolvimento do driver open-source, com a liberação das
especificações de mais placas e de trechos de código-fonte.
Enquanto escrevo (início de 2009), a abertura ainda não rendeu muitas
mudanças. O driver open-source melhorou em vários aspectos, mas no geral
continua sendo deficiente, enquanto o driver binário continua apresentando
muitos problemas, de forma que a escolha continua sendo essencialmente a
mesma.
Se você decidir tentar a sorte com o driver binário da ATI, pode baixá-lo no
http://ati.amd.com/support/driver.html. Escolha o "Linux X86" e indique o
modelo da sua placa. Na tela a seguir, baixe o "ATI Driver Installer".
Ao contrário do driver da nVidia, a instalação é feita dentro do modo gráfico.
Basta marcar a permissão de execução e rodar o instalador, como em:
# chmod +x ati-driver-installer-9.2-x86.x86_64.run
# ./ati-driver-installer-9.2-x86.x86_64.run
Depois de concluída a instalação, falta ainda alterar a configuração no
"/etc/X11/xorg.conf". A maneira mais simples é alterar a linha Driver "ati"
(ou Driver "radeon") próximo ao final do arquivo por:
Driver "fglrx"
Adicione também estas duas linhas logo abaixo. Sem elas, o TV Time não
funciona, o Kaffeine não consegue exibir legendas, entre outros pequenos
problemas:
Option "VideoOverlay" "on"
Option "OpenGLOverlay" "off"
Você pode também usar o configurador da ATI, através o comando:
# aticonfig --initial
Neste caso, você vai precisar revisar o arquivo, pois ele costuma deixar
sessões duplicadas. Muitas vezes, o configurador se perde e a configuração
antiga continua sendo usada. Depois das alterações, você precisa sempre
http://ati.amd.com/support/driver.html
reiniciar o X, pressionando Ctrl+Alt+Backspace.
Um problema recorrente é que a aceleração 3D não funcione, embora o driver
esteja ativado corretamente. A causa mais comum é que módulo "fglrx" não
esteja carregado. Você pode forçar o carregamento usando os comandos a
seguir. Caso necessário, adicione-os no final do arquivo "/etc/rc.d/rc.local",
para que sejam executados automaticamente durante o boot:
# modprobe -r radeon
# modprobe -r drm
# modprobe fglrx
Outro recurso utilizado pelo driver é o device "/dev/shm" (que ativa o suporte
ao padrão POSIX de memória compartilhada), que deve estar disponível e
montado. Caso necessário, adicione esta linha no final do arquivo
"/etc/fstab":
tmpfs /dev/shm tmpfs defaults 0 0
Para que ele seja montado sem precisar reiniciar, use o comando "mount
/dev/shm", como root.
 
Configurando o KDE 3.x
O Slackware possui a tradição de incluir os softwares da forma como são
disponibilizados pelos desenvolvedores, com um mínimo de personalização.
É exatamente o oposto do que temos na maioria das outras distribuições, que
oferecem versões fortemente personalizadas do ambiente de trabalho.
Outra característica do Slackware é o extremo conservadorismo com relação
ao uso de novas versões dos softwares. Isso faz com que sejam usadas
versões mais antigas dos softwares que em outras distribuições, mas que, em
compensação, o sistema seja de uma forma geral bastante estável.
O Slackware 12.2 é uma das últimas distribuições a utilizarem o KDE 3.5.x
(em vez do novo KDE 4), o que me dá a oportunidade de incluir um tópico
sobre a personalização do ambiente.
Mesmo com o lançamento da nova safra de distribuições baseadas no KDE 4,
incluindo aí o Slackware 13 (ou 14, caso decidam pular o número do azar)
que utilizará o KDE 4.2 por padrão, o KDE 3.x continua sendo bastante
utilizado e permanece como uma opção de ambiente de trabalho leve e
estável, o que explica o fato de ele ser usado também no Debian Lenny e em
diversas outras distribuições lançadas no primeiro semestre de 2009.
 
Opções do Kcontrol
As configurações do KDE são organizadas em um utilitário central, o
Kcontrol. Ele tem vários quartos escuros e passagens secretas; então, mesmo
que você já use o sistema há algum tempo, é provável que você não conheça
muitas das opções. Vamos então a algumas dicas gerais sobre a
personalização e sobre os componentes do KDE 3, que você pode usar
também em outras distribuições baseadas nele.
Para começar, existem dois modos de exibição para as opções dentro do
Painel, em Árvore ou em Ícones, que você define na opção "Ver > Modo", na
janela principal. Como são muitas opções, muita gente prefere o modo de
exibição em ícones, onde ao clicar sobre uma seção, você passa a ver apenas
as opções referentes a ela. Você pode também ajustar o tamanho dos ícones e
definir atalhos de teclado para estas opções.
Aqui vai um resumo de algumas opções importantes:
Administração do Sistema: Algumas partes desta seção podem ser
acessadas apenas pelo root, já que alteram aspectos sensíveis do sistema. Para
ter acesso a elas, clique no botão "Modo Administrador". A seção
"Gerenciador de Login" permite configurar a tela de login do sistema,
alterando as cores, papel de parede, etc. É aqui que você pode também ativar
ou desativar o autologin, que faz com que o usuário selecionado seja logado
automaticamente ao colocar o sistema em modo init 4 (no "/etc/inittab"), ou
seja, com o ambiente gráfico sendo carregado por padrão, como em outras
distribuições.
O módulo "Instalador de Fontes" permite que você instale fontes truetype que
passam a ser usadas automaticamente pelos programas instalados. Ele é bem
simples de usar: clique no "Adicionar Fontes", indique a pasta e onde estão as
fontes, selecione os arquivos e confirme.
Você pode tanto instalar as fontes logado como usuário normal (de modo que
elas fiquem disponíveis apenas para o seu login) quanto como root, tornando-
asdisponíveis para todos os usuários. Não é difícil encontrar vários sites que
disponibilizam fontes por aí. Você também pode copiar as pastas de fontes do
Windows (C:\Windows\Fonts) ou de programas como o Corel Draw.
Instalar as fontes do Windows permite que os documentos escritos no
Microsoft Office sejam exibidos com formatação perfeita no OpenOffice, por
exemplo, pois você terá instaladas as mesmas fontes que o autor original
usou.
As fontes ficam automaticamente disponíveis para os navegadores e também
para programas como o OpenOffice/BrOffice. Você pode inclusive usar as
novas fontes para personalizar o visual do sistema, acessando a seção
"Aparência > Fontes" dentro do painel de controle.
Desde o KDE 3.3, existe uma forma ainda mais simples de instalar novas
fontes. Abra uma janela do Konqueror e digite "fonts:/" na barra de
endereços. Você verá duas pastas: "Pessoal" e "System". Para instalar novas
fontes, você só precisa arrastar os arquivos para dentro de uma das pastas
para que elas sejam automaticamente reconhecidas pelo sistema, como você
faz no Windows ao copiar novas fontes para a pasta "C:\Windows\Fonts".
Copiando as fontes para a pasta "Pessoal", você faz uma instalação particular,
válida apenas para o seu usuário. Copiando para a pasta "System", você
instala de uma vez para todos os usuários cadastrados no sistema. Neste caso,
o Konqueror vai pedir a senha de root.
Para ativar o login automático (que serve como um bom complemento para a
abertura automática do X), marque a opção "Gerenciador de Login >
Conveniência > Habilitar login automático", indicando o usuário que será
logado e (opcionalmente) um tempo de atraso, para que você tenha a opção
de mudar o usuário quando quiser se logar com outro:
A opção do login automático é configurada através do Centro de Controle do
KDE (e não por meio de algum arquivo de configuração do sistema) porque o
login é feito através do KDM, que é um componente do KDE. Ele permite
que você escolha qual usuário usar, verifica a senha e carrega o KDE ou
outro ambiente de trabalho escolhido.
Aparência & Temas: Esta é provavelmente a área mais acessada do
kcontrol. Parece que todo mundo gosta de personalizar o seu desktop e o
KDE oferece uma grande flexibilidade neste sentido. Você pode alterar a
decoração das janelas, o tamanho da barra de tarefas, o conjunto de ícones do
sistema e assim por diante. Além dos componentes que vêm pré-instalados no
sistema, existem centenas de conjuntos de ícones, papéis de parede, conjuntos
de sons de sistema, etc. que você pode baixar no http://www.kde-look.org.
Para instalar um conjunto de ícones, baixe o arquivo .tar.gz (neste caso um
simples arquivo compactado contendo os ícones e não um pacote com
código-fonte), acesse a seção "Ícones" e clique no "Instalar Tema". A partir
daí, você pode escolher qual tema usar através da lista. O tema padrão do
KDE 3.x é o "Crystal SVG", um conjunto de ícones bonito e neutro, que
agrada a maioria. Outros temas populares são o Slick, o Crystal Clear, o
Nuvola e o Noia.
O Wallpaper é a personalização mais simples. Para alterar vá em "Fundo de
Tela > Papel de Parede". O KDE suporta imagens em vários formatos,
incluindo .jpg, .gif, .png e .bmp. Você pode usar também a opção "show de
slides", onde você aponta uma pasta com várias imagens e ele troca a imagem
periodicamente. Você pode ter um papel de parede diferente a cada minuto,
por exemplo, ou criar um show de slides com diferentes fotos (amanhecer,
meio-dia, pôr-do-sol, etc.) e ajustar o sistema para alternar entre elas
seguindo o horário do dia.
Nos menus Cores, Fontes, Estilo, Painéis e Decoração de Janela você pode
configurar várias opções relacionadas ao visual do sistema. A "Decoração da
Janela" é a moldura com a barra de arrastar (e os ícones para maximizar,
minimizar e fechar) usada em todas as janelas abertas. Você pode trocar a
decoração de janela por outra, com ícones parecidos com os do Windows ou
MacOS X, por exemplo.
Uma opção que você provavelmente vai querer alterar é a "Decorações de
Janela > Tamanho da Borda". Usando "Tamanho da borda > Minúsculo" e
desmarcando o "Borda da janela colorida" você elimina a borda azul em
torno das janelas.
O estilo determina a aparência dos botões, barras de rolagem e outros
componentes da tela, e todos suportam configurações adicionais através das
opções na aba. Você pode ativar o efeito (2D) de sombra de menu através do
"Efeitos > Sombra de menu", por exemplo.
http://www.kde-look.org/
A opção "Fontes" (que à primeira vista parece uma duplicação da opção para
instalar fontes disponível na seção anterior) esconde uma das configurações
mais importantes, que é justamente a configuração das fontes de exibição.
Além da tradicional escolha das fontes e dos tamanhos, não deixe de ativar o
uso do antialiasing, desmarcando a opção "Excluir intervalo" dentro da
configuração. Sem o antialiasing, as fontes ficarão serrilhadas, com um
aspecto realmente ruim.
Outra dica é que, de acordo com a geometria do monitor, o X pode decidir
utilizar 120 DPI por padrão, em vez de 96 DPI. Isso faz com que todas as
fontes de tela fiquem dois pontos maiores. Para resolver isso, basta ajustar a
opção manualmente:
A "Tela de Apresentação", que é a animação exibida durante a abertura do
KDE, é, na verdade, um conjunto de imagens que fica na pasta
"/usr/share/apps/ksplash/pics/". Assim como no caso dos ícones, você pode
baixar novos temas no kde-look e instalá-los usando a opção "Tela de
Apresentação > Adicionar".
Área de Trabalho: Nesta seção estão opções relacionadas à barra de tarefas,
menu iniciar e ao comportamento das janelas. Um exemplo: no Windows um
clique duplo sobre uma janela faz com que ela seja maximizada, enquanto
que no KDE o padrão é ocultar a janela, deixando apenas a barra de títulos,
um comportamento natural para quem está acostumado com outros
gerenciadores de janela, mas bem estranho para quem vem do Windows.
Você pode alterar isso na opção "Comportamento de Janela > Ações da barra
de título". Para ficar como no Windows, configure a opção "Clique duplo na
barra de títulos:" como "Maximizar".
Como você pode ver no screenshot, é possível definir funções para os outros
botões. Na configuração padrão, o botão do meio serve para rebaixar a janela,
ou seja, fazer com que ela fique abaixo das outras janelas abertas:
Um recurso interessante, oferecido não apenas pelo KDE, mas pelas
interfaces do Linux em geral, são os desktops virtuais. Cada desktop funciona
como uma área independente e você pode alternar entre eles usando atalhos
de teclado.
No KDE você pode alternar entre as áreas de trabalho virtuais pressionando
Ctrl + uma das teclas de função (da F1 à F12), como em Ctrl+F2 (para
mudar para o segundo desktop), Ctrl+F1 (para voltar para o primeiro), etc.
Para enviar um programa aberto para outro desktop virtual, clique sobre a
barra com o botão direito do mouse e use a opção "Para o ambiente...".
Os desktops virtuais permitem organizar melhor os programas abertos e
alternar entre eles com mais facilidade. Você pode organizar os programas
"por tema", por exemplo; deixando todas as janelas do navegador no primeiro
desktop, as janelas do editor de textos e o leitor de e-mails no segundo, e
assim por adiante.
Você pode ajustar o número de desktops virtuais através da opção "Múltiplas
Áreas de Trabalho". Uma observação é que cada desktop virtual faz com que
o sistema passe a consumir entre 2 e 4 MB a mais de memória RAM (de
acordo com a resolução de vídeo usada), o que pode ser um problema em
micros com 256 MB ou menos. O KDE usa 4 ambientes virtuais por padrão,
um número que você pode aumentar ou reduzir no "Área de Trabalho >
Múltiplas áreas de trabalho".
Como um complemento, temos o pager, que é exibido por padrão na barra de
tarefas. Ele é um applet que permite alternar entre as áreas de trabalho. O
KDE oferece um grande número de outros applets similares, que podem ser
adicionados à barra de tarefas. Para isso, clique com o botão direito sobre a
área vazia. No menu, cliqueno "Adicionar > Mini-aplicativo ao painel". Vale
a pena perder um pouco de tempo testando as opções disponíveis:
Voltando ao Kcontrol, você encontra mais opções de personalização da barra
de tarefas na opção "Painéis", incluindo seu tamanho, pano de fundo (a barra
pode ficar transparente ou usar uma imagem qualquer como fundo), entre
várias outras configurações. Você pode até mesmo ativar uma segunda barra
de tarefas, exibida no topo da tela, como usado no GNOME e no Mac OS.
Componentes do KDE: Esta seção concentra algumas opções "Avançadas"
relacionadas ao funcionamento do KDE. A mais importante é provavelmente
a seção "Associações de Arquivos", onde você define quais programas serão
usados para abrir cada extensão de arquivo. Você pode atribuir a mesma
extensão para dois ou mais programas e definir uma ordem de prioridade,
onde o primeiro abre os arquivos por default, mas você pode escolher um dos
outros clicando com o botão direito sobre o arquivo.
Muitos programas alteram as associações padrão ao serem instalados,
assumindo a posse dos formatos de arquivos que suportam, mas você sempre
pode alterar as configurações, além de criar novas associações de arquivos
através do painel:
O KDE usa o Ispell como corretor ortográfico. O mesmo corretor é usado em
vários programas do KDE, incluindo o Konqueror, Kedit, Kword e outros. O
corretor entra em ação até mesmo ao postar uma mensagem em um fórum ou
blog através do Konqueror, grifando em vermelho as palavras incorretas.
Se esta opção não estiver habilitada por padrão, clique com o botão direito
sobre o texto escrito dentro do Konqueror e marque a opção "Verificar
ortografia automaticamente". A grande limitação é que o corretor não é
integrado ao OpenOffice, de forma que você fica com dois corretores
diferentes, cada um usando uma lista de palavras própria.
Na opção "Gerenciador de arquivos" existem algumas opções referentes ao
Konqueror, como as fontes usadas e os tipos de arquivos para os quais ele
exibe previews. Na opção "Performance do KDE" existe um item importante,
relacionado ao uso de memória. Selecione a opção "Minimizar uso de
memória > Nunca" se você tem 256 MB de RAM ou mais, isso melhora o
desempenho geral do KDE e evita alguns problemas esporádicos.
Internet & Rede: Esta seção concentra opções relacionadas à configuração
da rede. A opção "Compartilhamento de Arquivos" permite criar
compartilhamentos de rede Samba e NFS (os dois simultaneamente) de uma
forma simples. Naturalmente, para compartilhar arquivos com máquinas
Windows, é preciso que o servidor Samba esteja instalado, o que no
Slackware é feito através da instalação do pacote "samba", que faz parte da
categoria N.
A opção "Compartilhamento do desktop" abre a tela de configuração do krfb,
que permite compartilhar a imagem do desktop com outras máquinas da rede,
para fins de suporte, enquanto a "Rede sem fio" mostra a configuração do
kwifimanager. Ambos estão disponíveis através do iniciar.
As opções "Navegador Web", "Navegação em Rede Local" e "Proxy" estão
relacionadas ao Konqueror. A primeira contém opções diversas relacionadas
ao navegador, incluindo as opções de cache e as relacionadas à segurança. A
segunda permite configurar um usuário e senha padrão para o acesso a
compartilhamentos de outras máquinas da rede, ao usar o módulo "smb:/" do
Konqueror. A última contém a configuração de proxy, caso você esteja
dentro de uma rede que utilize um.
Periféricos: Nesta seção você encontra configurações relacionadas ao mouse,
joystick e monitor, além de poder ver e gerenciar as impressoras instaladas.
Ao contrário do que seria de se esperar, a maioria das configurações do
teclado vão na seção "Regional e Acessibilidade". Aqui você encontra apenas
as opções de ajustar a taxa de repetição e o comportamento da tecla
NumLock.
As opções para economia de energia do monitor estão escondidas dentro da
opção "Tela > Controle de Energia", onde você configura a economia de
energia para o monitor entre as opções Standby, Suspend e Power Off. Estas
opções podem desligar também o HD, caso você tenha configurado isso no
setup do micro.
Um monitor de CRT 17" consome cerca de 110 Watts de energia, então é
sempre importante fazer com que ele desligue quando o PC não estiver em
uso. Mesmo os monitores de LCD consomem de 30 a 50 watts (de acordo
com o tamanho), por isso a economia acaba também sendo significativa.
Bem antigamente, se recomendava que o monitor só deveria ser desligado
quando o micro fosse ficar sem uso por mais de uma hora, mas os modelos
fabricados de 2001 para cá podem ser desligados mais frequentemente, sem
prejuízo para a vida útil. Você pode configurar o Suspend para 5 minutos de
inatividade e o Power Off para 15 minutos, por exemplo.
No caso dos monitores de LCD, os desligamentos depois de 15 minutos de
inatividade ajudam a prolongar a vida útil. Basicamente, a tela de um monitor
de LCD é como um chip, ela não tem vida útil definida, pode trabalhar
durante décadas sem problemas.
O que pode eventualmente queimar depois de alguns anos de uso são as
lâmpadas de catodo frio que iluminam a tela. Nos modelos atuais elas têm
uma vida útil estimada em cerca de 20 mil horas. Estas lâmpadas podem ser
substituídas, mas não é exatamente um conserto barato, então o ideal é fazê-
las durar o máximo possível. Outra fonte comum de problemas é a fonte de
alimentação, mas ela pode ser trocada facilmente, ao contrário dos
componentes internos.
Na opção "Tela > Tamanho e Orientação", você encontra um pequeno
utilitário que permite alterar rapidamente entre as resoluções e taxas de
atualização suportadas pelo monitor. Esta opção depende da distribuição em
uso ter detectado corretamente o monitor e ter configurado corretamente o
arquivo "/etc/X11/xorg.conf". Na opção "Gama" você pode ajustar via
software o brilho do monitor, complementando as funções dos botões.
Regional & Acessibilidade: O KDE possui um projeto bastante abrangente
de internacionalização, que consiste não apenas em traduzir a interface para
os mais diversos idiomas, mas também incluir suporte a diversos layouts de
teclado e outras particularidades de cada região.
O suporte ao português do Brasil está entre os mais completos, concentrado
no pacote "kde-i18n-ptbr". Existem dezenas de outros pacotes de
internacionalização: você pode inclusive instalar vários e configurar a língua
padrão do sistema no "País/Região & Idioma > Localização". Esta seção
inclui também a configuração do teclado e a configuração dos atalhos de
sistema, feita através do "Atalhos de teclado".
O KDE permite associar atalhos de teclados para a maioria das funções do
sistema, o que você configura na seção "Atalhos de Teclado". Se você é da
velha guarda e tem saudades da época do modo texto, onde tudo era feito
através de atalhos de teclado, se sentirá em casa.
Além dos atalhos de teclado relacionados às janelas e ao uso do sistema, você
pode definir atalhos para abrir programas ou executar comandos diversos na
seção "Teclas de Atalho" (ou "Ações de Entrada", dependendo da versão do
KDE que estiver utilizando). Parece estranho ter duas seções separadas para
definir teclas de atalho, mas esta divisão até que faz um certo sentido,
separando os atalhos do KDE dos atalhos "gerais" definidos para outros
comandos e programas.
Por exemplo, no Windows a tecla "Print Screen" serve para tirar um
screenshot da tela. No KDE você pode usar o Ksnapshot, que além de
oferecer várias opções, também pode salvar diretamente a imagem no
formato de sua preferência, sem ter que colar em algum programa de edição
de imagens e salvar através dele. Para configurar o KDE para abrir o
Ksnapshot ao pressionar a tecla Print Screen, acesse o "Ações de entrada >
Preset Actions > Nova Ação".
Dê um nome à nova ação, como "PrintScreen". Na aba "Gatilhos", clique em
"Novo > Disparo de Atalho" e, na janela que define o atalho de teclado,
pressione a tecla Print Screen. Na aba "Ações", clique em "Novo >
Comando/URL" e coloque o "ksnapshot" como comando a ser executado.
Este utilitáriopermite definir atalhos bastante sofisticados, inclusive
transmitindo comandos para outros aplicativos abertos (como fazer o
Audacious avançar ou retroceder a música, por exemplo). Veja a categoria
"Examples" dentro da janela para ver mais exemplos de uso:
Som & Multimídia: O KDE 3 possui seu próprio servidor de som, o Arts.
Ele coordena o acesso à placa de som, permitindo que vários programas
toquem sons simultaneamente (mesmo que a placa de som não ofereça esse
recurso via hardware), entre outros recursos.
Apesar de ter sido um "mal necessário" durante muito tempo, o Arts é
atualmente pouco usado, pois o Alsa e, consequentemente, os drivers de som
do Linux de uma forma geral, evoluíram bastante nos últimos anos e
passaram a oferecer suporte a múltiplos fluxos de áudio e outros recursos
nativamente.
O Arts vem desativado por padrão na maioria das distribuições, deixando
com que os programas acessem a placa de som diretamente. Se você tiver
problemas relacionados à reprodução em alguns programas específicos,
experimente ativá-lo e marcar a opção "Suspensão automática se ocioso
por...", deixando o tempo de espera em 4 segundos. Isso faz com que o Arts
fique ativo apenas quando algum programa tentar usá-lo, sem ficar
bloqueando a placa de som o tempo todo.
Ao ativar o Arts, você pode ajustar a prioridade do servidor de som e também
o tamanho do buffer de áudio (opção Buffer de Som). Você pode diminuir
bastante a utilização do processador ao ouvir música, e de quebra ganhar
imunidade contra eventuais falhas nos momentos de atividade, simplesmente
aumentando o buffer para 400 ms ou mais. Assim o sistema passa a contar
com uma reserva maior e pode utilizar melhor os tempos ociosos do
processador para decodificar o áudio.
O KDE é capaz de ripar CDs de música nativamente. Experimente colocar
um CD de música no drive e acessar o endereço "audiocd:/" no Konqueror.
Ele exibe as faixas de um CD de áudio na forma de arquivos .mp3, .ogg e
.wav, em pastas separadas. Arraste a pasta com o formato desejado para o
desktop e o CD de música é ripado e convertido automaticamente. O mesmo
pode ser feito através do Kaudiocdcreator, que oferece uma interface mais
parecida com um ripador de CDs. Em qualquer um dos dois casos, você pode
ajustar a qualidade dos arquivos .mp3 ou .ogg gerados através da opção "CDs
de Áudio".
Na seção "Notificações do Sistema", estão disponíveis também as opções de
avisos sonoros e visuais do sistema, de uma forma geral.
 
Barra de tarefas e dicas
A barra de tarefas e menu iniciar do KDE é batizada de "kicker". Por default,
a barra tem 46 pixels de altura (o que é mais do que o dobro da altura da
barra do Windows XP, por exemplo) e exibe duas colunas de botões de
aplicativos na barra de tarefas, uma configuração que a maioria dos usuários
acha estranha e até desconfortável.
Entretanto, a configuração pode ser alterada rapidamente clicando com o
botão direito sobre uma área livre da barra e acessando o "Configurar Painel".
Ajustando o tamanho como "pequeno" a barra fica com 30 pixels de altura (o
tamanho preferido pela maioria), mas você tem a opção de ganhar alguns
pixels de área útil na tela usando o "minúsculo", que deixa a barra com
apenas 24 pixels:
Se você quiser que a barra fique centralizada (no estilo da barra do XFCE ou
do Dock do OS X) reduza o comprimento para 80% e centralize usando os
retângulos no "Posição". Nesse caso, você talvez queira marcar a opção
"Ocultação > Permitir que outras janelas cubram o painel", para que as
janelas possam sobrepor o painel quando maximizadas.
Na seção "Menus" você pode desativar a exibição dos últimos aplicativos
usados no topo do iniciar e também remover os ícones de ações que você não
utiliza, como o "Executar Comando" (que você pode acessar mais
rapidamente pressionando Alt+F2) ou o "Ajuda".
Similarmente, você pode remover o applet para o Pager (que permite chavear
entre as diferentes áreas de trabalho) na barra de tarefas, e passar a alternar
entre elas usando o Ctrl+F2, Ctrl+F3, etc. O pager ocupa muito espaço na
barra e os atalhos de teclado acabam sendo mais rápidos.
Voltando às opções, por default são exibidos pop-ups com dicas quando você
passa o mouse sobre os botões na barra, o que é uma ajuda bem-vinda para
quem está se familiarizando com o sistema, mas acaba se tornando um
incômodo com o tempo. Você pode desativá-los desmarcando o "Habilitar
efeitos quando o mouse passar" na seção "Aparência".
Clicando no "Opções Avançadas", você tem a opção de ocultar ou de deixar
visíveis os separadores (que permitem arrastar os componentes da barra). O
ideal é que, depois de ajustar tudo a seu gosto, você remova os separadores
usando o "ocultar", aumentando o espaço útil na barra.
Aproveite para reduzir também o tamanho do botão de ocultação para 3
pixels. Como ele fica no canto da tela, você não precisa vê-lo para ativá-lo, já
que basta levar o mouse até o extremo da tela e clicar. Caso você tenha
marcado o "Habilitar transparência" no menu anterior, as opções com a cor e
a quantidade de tinta permitem ajustar o nível de opacidade do menu:
Concluindo, aproveite para desmarcar a opção "Mostrar janelas de todas as
áreas de trabalho" na seção "Barra de tarefas", já que ela elimina o propósito
de usar várias áreas de trabalho como uma maneira de dividir os aplicativos
abertos. Outra opção polêmica é a "Agrupar tarefas similares" (que faz com
que o Kicker agrupe diferentes janelas de um mesmo aplicativo em um
menu), que a maioria prefere manter como "Nunca". Concluindo, você pode
querer mudar a opção "Aparência" de "Elegante" para "Clássico", o que faz
com que os aplicativos na barra de tarefas sejam exibidos como botões:
Um item de que você provavelmente sentirá falta é o botão para mostrar a
área de trabalho, que permite que você volte ao desktop sem precisar
minimizar cada uma das janelas abertas. Para adicioná-lo, basta clicar sobre a
barra, usar o "Adicionar mini-aplicativo ao painel" e escolher o "Mostrar área
de trabalho". Aproveite para adicionar outros applets que você costuma
utilizar, como os botões para travar e sair e o relatório do tempo. Você pode
também arrastar ícones do iniciar para a barra, deixando as funções mais
usadas à mão.
Se a fonte terrivelmente feia dos números do relógio estiver te incomodando,
clique sobre ele para acessar o "Configurar relógio" e mude o tipo de relógio
para "Relógio Comum". Desative a exibição de data e ajuste a fonte a seu
gosto.
Mais dicas: Embora à primeira vista pareça ser um pacote único, o KDE é na
verdade composto por um conjunto de aplicativos mais ou menos
independentes. O componente que mostra a barra de tarefas, onde vai o
relógio, iniciar e outros applets, é o kicker. O componente que mostra os
ícones, papel de parede e outros componentes do desktop é o kdesktop,
enquanto que o kwin é responsável pelo gerenciamento e exibição das janelas
dos programas.
Você pode brincar um pouco com estes componentes experimentando ver o
que acontece ao desativar cada um. Pressione Alt+F2 para abrir o "Executar
Comando" do KDE e execute o comando "killall kicker". Você vai notar que
a barra de tarefas sumiu. Você não tem mais a lista de janelas e os programas
desaparecem ao serem minimizados. Pressione Ctrl+F2 novamente e execute
o comando "kicker". Tudo volta à normalidade.
Experimente fazer o mesmo com o kwin. Ao fechá-lo, as janelas ficam
"grudadas" na tela, você não consegue mais minimizar nem movê-las, mas ao
reabri-lo tudo volta ao normal. Fazendo o mesmo com o kdesktop, você vai
perceber que os ícones e o papel de parede do desktop desaparecem.
Às vezes acontece de um destes componentes travar (principalmente o
kicker), causando os mesmos sintomas que você acabou de ver. Nestes casos,
ao invés de reiniciar o X ou, pior, reiniciar o micro, você pode simplesmente
pressionar Alt+F2 e reabrir o componente, sem prejudicar o que estava
fazendo.
Você pode ver mais detalhes sobre os componentes e arquivos de
inicialização do KDE no: http://www.kde.org/areas/sysadmin/.
Abrindovárias seções do X: No Linux, o ambiente gráfico é bastante
flexível. Você pode executar aplicativos de outras máquinas via rede, abrir
várias instâncias do X simultaneamente ou, até mesmo, usar mais de um
monitor e teclado independentes, no mesmo micro. Toda esta flexibilidade
permite a existência dos vários sistemas de administração remota e de
recursos avançados, como o LTSP e pode também ser útil em situações mais
cotidianas.
Uma situação comum é quando você precisa deixar outra pessoa usar seu
micro para checar os e-mails ou fazer qualquer coisa "urgente". Você pode
criar um usuário separado para ela e assim não correr o risco de ver arquivos
apagados ou o seu desktop desconfigurado. Mas, como fazer isso sem
precisar fechar as 30 abas do Firefox e as 5 janelas do OpenOffice em que
você está trabalhando? Simples: abra uma segunda sessão do X.
O jeito mais espartano de fazer isso é iniciar a segunda sessão manualmente,
a partir de um terminal de texto. A maioria das distribuições abre por padrão
6 terminais de texto e uma sessão gráfica. Estes terminais de texto são
chamados de "vt" (virtual terminal) e são numeradas de 1 a 6.
A sessão gráfica ocupa a posição que seria do sétimo terminal e por isso é
chamada de vt7. Todas estas seções são independentes e você pode alternar
entre elas pressionando as teclas "Ctrl+Alt+Fx", onde o "Fx" é a tecla F
correspondente ao terminal. Para mudar para o primeiro terminal de texto,
pressione "Ctrl+Alt+F1" e para voltar ao ambiente gráfico, pressione
"Ctrl+Alt+F7".
Você pode chavear entre os terminais usando também o comando "chvt",
incluindo o número do terminal desejado, como em "chvt 1" ou "chvt 7"
mas, ao contrário do atalho de teclado, ele só funciona se executado como
root.
Para iniciar uma segunda sessão gráfica, mude para um dos terminais de texto
http://www.kde.org/areas/sysadmin/
e use o comando "startx -- :2 vt8".
Na verdade, o "vt8" não é realmente necessário, ele apenas força o X a abrir
ocupando a posição desejada, ao invés de simplesmente assumir a próxima
posição disponível.
A partir daí, além dos terminais de texto você terá dois ambientes gráficos
independentes abertos. Para mudar para a segunda sessão gráfica, pressione
"Ctrl+Alt+F8" e, para voltar para a primeira, pressione "Ctrl+Alt+F7".
Esta segunda sessão gráfica pode ser iniciada por um usuário diferente, rodar
uma interface gráfica diferente (você pode usar o KDE na primeira e o
GNOME na segunda) ou até mesmo exibir o ambiente gráfico de outra
máquina da rede, via XDMCP.
Para resolver o problema do amigo precisando usar o micro, crie um usuário
para ele, usando o comando "adduser", como em "adduser joao", mude para
um terminal de texto (Ctrl+Alt+F2), logue-se usando o usuário criado e rode
o comando "startx -- :2 vt8" para abrir a segunda sessão do X, usando o
login separado.
Depois que seu amigo terminar, pressione "Ctrl+Alt+Backspace" para
fechar a sessão e retornar ao seu ambiente de trabalho. Se preferir, você pode
usar o comando "xinit -- :2" no lugar do startx, ele abre uma instância do X
sem gerenciador de janelas, permitindo que você abra a interface que quiser.
Este é o procedimento manual, como os pioneiros faziam no começo dos
tempos. Uma forma mais prática e elegante de fazer isso hoje em dia é
configurar o KDM ou GDM para abrir a segunda sessão automaticamente.
Ao usar o KDM, abra o arquivo "Xservers", que dependendo da distribuição
pode ser encontrado na pasta "/etc/kde3/kdm/", ou
"/usr/share/config/kdm/". Neste arquivo vai a configuração das instâncias
do X que são abertas durante o boot. Normalmente, este arquivo contém
apenas uma linha descomentada, que inicializa a sessão principal:
:0 local@tty1 /etc/X11/X -dpi 75 -nolisten tcp vt7
Para ativar as seções adicionais, edite o arquivo adicionado as linhas:
:1 local@tty2 reserve /etc/X11/X :1 vt8 -deferglyphs 16
:2 local@tty3 reserve /etc/X11/X :2 vt9 -deferglyphs 16
:3 local@tty4 reserve /etc/X11/X :3 vt10 -deferglyphs 16
Estamos aqui adicionando mais três seções. Para evitar que elas fiquem
abertas, consumindo memória enquanto não estão sendo usadas, adicionamos
a opção "reserve". Depois de salvar o arquivo, reinicie o KDM usando o
comando "/etc/init.d/kdm restart" a partir de um dos terminais de texto.
Uma observação é que o comando que abre o X ("/etc/X11/X") pode variar
de acordo com a distribuição. No Mandriva por exemplo é
"/usr/X11R6/bin/X". Lembre-se de modificar as linhas caso necessário,
seguindo o exemplo da primeira linha.
A partir daí, aparecerá uma função "Iniciar nova Sessão" ao clicar sobre o
desktop ou acionar o menu iniciar. Clicando sobre ela, é aberta a segunda
sessão do X, mostrando a tela de login do KDM. A partir da tela de login
você pode efetuar login usando o usuário e interface que quiser. É uma boa
maneira de ter o KDE e o GNOME rodando ao mesmo tempo, por exemplo.
A sessão inicial continua aberta e você pode alternar entre as duas
pressionando "Ctrl+Alt+F7" e "Ctrl+Alt+F8". Para o caso do amigo usando o
seu micro, existe a opção de travar a primeira sessão. Com as linhas que
adicionamos, você pode abrir até quatro sessões ao mesmo tempo. Nada
impede que você adicione mais linhas e abra mais sessões, mas lembre-se de
que cada sessão adicional consome uma quantidade generosa de memória
RAM.
Nas distribuições que usam o GDM, edite o arquivo
"/etc/X11/gdm/gdm.conf" e procure pela sessão "Servers", que normalmente
vai no final do arquivo. Adicione as sessões adicionais desejadas, como em:
[servers]
2=/usr/bin/X11/X vt9 -deferglyphs 16
1=/usr/bin/X11/X vt8 -deferglyphs 16
0=/usr/bin/X11/X vt7 -nolisten tcp -dpi 75
No caso do GDM, não existe a opção de carregar as sessões adicionais sob
demanda: elas são abertas automaticamente durante o boot e ficam abertas
continuamente, esperando serem usadas. Assim como no caso do KDM, é
preciso reiniciar o gerenciador de login para que a alteração entre em vigor.
Mude para um dos terminais de texto e use o comando "/etc/init.d/gdm
restart".
 
Arquivos de configuração
Aproveitando que um dos objetivos desse capítulo é mostrar como as
configurações do sistema são armazenadas em arquivos de configuração,
vamos a uma rápida explicação sobre como são armazenadas as
configurações do KDE, que definimos através do Centro de Controle.
Como comentei no primeiro capítulo, as configurações dos aplicativos são
salvas em diretórios ocultos (começados com ponto) dentro do seu diretório
home. Para vê-los, é necessário marcar a opção "mostrar arquivos ocultos" no
Konqueror ou usar o "ls -a". As configurações do KDE (e da maioria dos
aplicativos relacionados a ele) são armazenados na pasta
".kde/share/config":
Em situações normais, você não precisa se preocupar com esses arquivos, já
que eles são gerados e atualizados automaticamente conforme você
personaliza o ambiente, mas se você tiver curiosidade em fuçar dentro do
conteúdo deles, vai acabar aprendendo muita coisa sobre o funcionamento do
sistema, além de encontrar algumas opções de configuração que não estão
disponíveis no Kcontrol. Embora não pareça à primeira vista, os arquivos de
configuração do KDE são bastante organizados e legíveis.
Uma dica, caso você queira estudar mais sobre a edição manual dos arquivos,
é usar a função "Procurar por arquivos modificados > Nos últimos xx
minutos" dentro do "Iniciar > Procurar arquivos/pastas" (kfind), usando-o
para localizar os arquivos modificados depois de cada alteração feita pelo
Kcontrol.
O menu iniciar do KDE é gerado a partir da combinação dos links do
diretório "/usr/share/applications/", onde a maior parte dos pacotes
instalados coloca seus ícones (os ícones do KDE são arquivos de texto
normais, salvos com a extensão .desktop) e do diretório "/usr/share/applnk",
onde podem ser colocados ícones personalizados, que ficam disponíveis para
todos os usuários.
As alterações feitas usando o editor de menus são salvas no arquivo
".config/menus/applications-kmenuedit.menu" (dentro do home), que é um
arquivo de configuração que descreve as mudançasfeitas (os ícones que
foram deletados ou movidos, novos ícones criados, etc.). Este arquivo é
processado pelo KDE durante o carregamento do desktop, que aplica as
mudanças e faz com que o menu seja exibido da forma que deixou.
Os ícones que aparecem no desktop do KDE vão na pasta "Desktop", dentro
do home. No KDE 3, o desktop nada mais é do que uma pasta como outra
qualquer, que é exibida por uma instância oculta do gerenciador de arquivos.
Se você desativar a opção "Área de trabalho > Comportamento > Exibir
ícones na área de trabalho", essa instância do gerenciador de arquivos é
fechada, fazendo com que o KDE não exiba mais os ícones no desktop, assim
como ocorre no Fluxbox e em outros gerenciadores mais simples.
Finalmente, temos os aplicativos que são executados durante o boot, que são
configurados através de ícones colocados na pasta ".kde/Autostart". A
sintaxe dos arquivos .desktop é a mesma em todas estas pastas; você pode
arrastar um ícone do iniciar diretamente para uma janela do Konqueror
exibindo a pasta .kde/Autostart, por exemplo.
Quando você usa a opção "Componentes do KDE > Gerenciador de Sessão >
Restaurar sessão anterior" (ou "Restaurar sessão salva manualmente"), o que
o sistema faz é simplesmente colocar atalhos para os aplicativos abertos
dentro da pasta ".kde/Autostart", de maneira que eles sejam abertos
automaticamente na próxima sessão.
Assim como o KDE, os demais programas sempre criam pastas de
configuração dentro do home. As configurações do XMMS por exemplo, vão
dentro da pasta ".xmms", as do gMplayer vão dentro da ".mplayer", e assim
por diante. Como vimos, as configurações dos aplicativos do KDE ficam
centralizadas dentro da pasta ".kde/share/config", também dentro do home.
Outra dica é que quando você cria novos usuários, o sistema cria a
configuração inicial copiando o conteúdo da pasta "/etc/skel" para o diretório
home do novo usuário. Em um PC usado por várias pessoas, você pode fazer
com que novos usuários sejam criados com um conjunto de configurações
específicas simplesmente copiando as pastas de configuração para dentro do
diretório.
 
Instalação de programas
O Slackware trabalha com um formato próprio de pacotes, o .tgz, que é
provavelmente o sistema de gerenciamento de pacotes mais simples ainda em
uso. Os pacotes .tgz são simplesmente arquivos compactados, que ao serem
instalados são descompactados no diretório raiz do sistema. Se o pacote
contém o arquivo "usr/bin/adsl-setup", por exemplo, ao instalá-lo será criado
o arquivo "/usr/bin/adsl-setup".
Ao contrário de outras distribuições, os pacotes do Slackware não utilizam
nenhum sistema de controle de dependências. Você poderia remover alguma
peça fundamental do sistema, como o libc ou o kernel e o gerenciador de
pacotes não emitiria nenhum tipo de alerta (você só perceberia o erro quando
o sistema parasse de funcionar).
O mesmo acontece ao instalar novos pacotes: nada impede que você instale
um novo programa sem instalar junto outros pacotes com bibliotecas e
componentes adicionais dos quais ele precise para funcionar, mas, por outro
lado, não existe nenhuma garantia de que ele vá realmente funcionar sem
eles.
Isso é ao mesmo tempo uma vantagem e uma desvantagem. Desvantagem no
sentido de que é necessário muito mais conhecimento sobre as relações entre
os pacotes para instalar ou remover programas sem destruir nada, e vantagem
por que você tem liberdade para fazer o que quiser (inclusive destruir o
sistema) sem nenhum gerenciador de pacotes chato reclamando sobre
dependências não satisfeitas e pacotes quebrados. Você pode aprender na
prática o que acontece ao remover o pacote X ou ao instalar o pacote Y sem
instalar junto o pacote Z, e assim aprofundar seus conhecimentos sobre a
estrutura do sistema.
Do ponto de vista do aprendizado (que, afinal, é o grande objetivo deste
livro), o sistema do Slackware é interessante, pois lhe dá uma liberdade muito
maior para fuçar no sistema e aprender, se necessário destruindo e
reinstalando o sistema sucessivas vezes. Porém, em um PC de trabalho, a
ideia não é tão boa assim.
A questão das dependências é minimizada no Slackware através de uma
política de redução no número de pacotes, agrupando os componentes em
pacotes maiores. Por exemplo, no Debian o Samba é composto por 5 pacotes
separados: samba (o servidor), smbclient (o cliente), samba-common, samba-
doc e smbfs, enquanto no Slackware existe um único pacote (o "samba", que
faz parte da categoria "N"), que agrupa todos os componentes.
A vantagem dessa abordagem é que a configuração é simplificada, evitando
casos como a montagem de compartilhamentos do Samba via linha de
comando no Ubuntu, que só funciona depois de instalar o pacote "smbfs". No
Slackware, você simplesmente instala o pacote principal e tem acesso a todos
os componentes. A desvantagem, por outro lado, é que você perde em
flexibilidade, já que não é possível instalar apenas o smbclient, sem precisar
instalar junto o servidor e a documentação.
Para gerenciar os pacotes instalados, o Slackware conta com o pkgtool, um
utilitário de modo texto que permite instalar e remover pacotes, verificar o
conteúdo dos pacotes instalados e ver detalhes sobre eles. Para usá-lo, basta
chamá-lo em um terminal, como root:
# pkgtool
Na opção "Current" são mostrados os arquivos .tgz presentes no diretório a
partir da onde o comando foi executado. Se você executar o pkgtool dentro
de um diretório com vários pacotes, o instalador mostra o nome e descrição
de cada um e vai perguntando se cada pacote deve ser instalado (assim como
ao escolher a opção "Advanced" durante a instalação do sistema). A opção
"Other" é similar, mas permite que você especifique manualmente o
diretório onde estão os pacotes.
A opção "Remove" é provavelmente a mais usada. Ela mostra um menu com
os pacotes atualmente instalados, permitindo que você marque pacotes que
deseja desinstalar. Note que o gerenciador não emite nenhum aviso ao tentar
remover pacotes essenciais, por isso tome nota dos pacotes que remover, para
poder reinstalá-los depois, caso perceba a falta de alguma função importante.
Instalar e remover pacotes e ir pesquisando detalhes sobre eles é um bom
exercício para entender melhor os componentes do sistema. Como comentei,
o Slackware utiliza uma estrutura mais simples do que em outras
distribuições, o que faz com que seja composto por um número muito menor
de pacotes e seja, por isso, muito mais fácil de entender. Você pode começar,
removendo pacotes de que não vai precisar, como o "kdeedu", "kdetoys", e o
"kdevelop" e a partir daí ir vasculhando a lista em busca de outros que
possam ser removidos:
Desde que você mantenha uma lista dos pacotes que está removendo, não
existem grandes riscos para a integridade do sistema, já que você pode
instalá-los novamente usando o installpkg. Se você remover o pacote
"kdebase" (que inclui as bibliotecas básicas do KDE), por exemplo, o KDE
vai deixar de abrir, até que você o instale novamente. :)
Os únicos pacotes que você realmente não pode remover, sob pena de
realmente quebrar o sistema são os pacotes do kernel e os pacotes que fazem
parte da categoria "a", que inclui os componentes básicos do sistema.
Continuando, você pode também instalar pacotes diretamente a partir da linha
de comando. Para isso, acesse o diretório onde está o pacote e use o comando
installpkg, seguido pelo nome do arquivo, como em:
# installpkg amarok-1.4.9.1-i486-1.tgz
Os nomes dos pacotes sempre são um pouco longos, pois incluem a versão,
arquitetura e número de revisão. Para facilitar, use a tecla TAB para
completar o comando, depois de digitar as primeiras letras.
Para remover um pacote, use o comando "removepkg", seguido pelo nome do
pacote (sem a extensão), como em:
# removepkg amarok
Para instalar uma versão mais recente de um pacote, atualizando a versão
atualmente instalada no sistema, você usa o comando upgradepkg. Ele se
encarrega de remover o pacote antigo e instalar o novo. Se, por exemplo,
você baixou uma nova versão do Amarok, disponívelna pasta "xap/" do
slackware-current, o comando para atualizar a versão atual seria:
# upgradepkg amarok-1.4.10-i486-1_slack12.1.tgz
Por não ser baseado num utilitário gráfico, o sistema de gerenciamento do
Slackware parece um pouco desconfortável no início, mas com a prática ele
se revela bastante fácil de usar. Por exemplo, para instalar a versão mais
recente do bittorrent (que não faz parte da instalação padrão) você visitaria o
http://www.slackware.com e acessaria um dos mirrors listados na página "Get
Slack", como o ftp://ftp.slackware-brasil.com.br/.
Dentro de cada mirror estão disponíveis os pacotes de várias versões, mas os
que interessam são os da pasta referente à versão atual (os estáveis) ou os
pacotes experimentais, disponíveis na pasta "slackware-current".
O pacote do bittorrent está na pasta "extra/bittorrent/". Enquanto escrevo, o
pacote disponível é o "bittorrent-4.4.0-noarch-2.tgz". Note que o "4.4.0" no
nome corresponde à versão: é por ele que você sabe se o pacote é mais
recente ou não do que o que você já tem instalado.
Depois de baixar o pacote, bastaria acessar o diretório onde ele foi salvo e
instalá-lo usando o comando do installpkg, como root:
# installpkg bittorrent-4.4.0-noarch-2.tgz
Se por acaso amanhã aparecer uma versão mais recente no slackware-current,
o "bittorrent-5.0.1-noarch-1.tgz" por exemplo, você usaria o:
# upgradepkg bittorrent-5.0.1-noarch-1.tgz
... para atualizar a versão que tiver instalada, mantendo todas as
configurações.
Se depois você mudar de ideia e resolver remover o pacote, é só usar o
removepkg para sumir com ele do mapa:
# removepkg bittorrent
http://www.slackware.com/
ftp://ftp.slackware-brasil.com.br/
Se você não lembrar qual era exatamente o nome do pacote, basta chamar o
pkgtool, acessar a opção Remove e selecioná-lo na lista.
Na grande maioria dos casos, o comando para chamar um programa é o
próprio nome do pacote: "firefox", "thunderbird", "kwrite", "konqueror" etc.
A maior parte dos programas cria um ícone no iniciar (pelo menos no KDE e
no GNOME) ao serem instalados, mas sempre existem exceções. Nesses
casos, você pode criar o ícone manualmente usando o kmenuedit, que você
acessa clicando com o botão direito sobre o ícone do iniciar.
Concluindo, temos a questão da atualização do sistema. Diferente do Ubuntu
e outras distribuições, onde um gerenciador fica disponível ao lado do
relógio, avisando (muitas vezes de forma até irritante) quando existem
atualizações disponíveis, no Slackware elas são discretamente
disponibilizadas através do diretório "patches/packages/" disponível nos
mirrors, de onde precisam ser baixados manualmente, como em:
ftp://ftp.slackware-brasil.com.br/slackware-12.2/patches/packages
Dependendo da época, o diretório pode conter um bom volume de pacotes,
mas você precisa se preocupar apenas com os que estão instalados no seu
micro (afinal, não existe por que se preocupar com atualizações para um
software que não está instalado em primeiro lugar :). Você pode
simplesmente baixar todos os pacotes que vai atualizar para um diretório e
instalá-los usando o installpkg:
# installpkg *.tgz
 
Repositórios adicionais
O repositório principal do Slackware é bastante espartano, incluindo apenas
os pacotes mais comuns. Um bom exemplo disso é que todos os pacotes do
Slackware 12.2 (incluindo a pasta "extras/") somam pouco mais de 2.2 GB,
enquanto os repositórios oficiais do Debian Lenny somam mais de 23 GB (10
vezes mais!).
Devido a isso, surgiram diversos grupos de usuários e voluntários dedicados
a disponibilizar pacotes adicionais para o Slackware. Os dois mais
conhecidos são o Slacky e o LinuxPackages (que, apesar do nome, é
ftp://ftp.slackware-brasil.com.br/slackware-12.1/patches/packages
especializado em pacotes para o Slackware):
http://www.slacky.eu/
http://www.linuxpackages.net/
Para encontrar pacotes dentro do repositório principal (e assim saber se ele
inclui o que procura, ou se precisa procurar em outro lugar), uma boa opção é
o localizador de pacotes do Slackware.it, disponível no:
http://packages.slackware.it/
Outro repositório bastante conhecido é o Dropline, que inclui pacotes para a
instalação do GNOME: http://www.droplinegnome.org/
A maneira mais simples de instalar os pacotes é baixar o pacote do dropline-
installer, instalá-lo usando o installpkg e executá-lo (como root) usando o
"dropline-installer", deixando que ele detecte a versão do Slackware em uso e
baixe os pacotes via web.
Ele possui uma série de dependências, entre elas o "aspell", "perl" e o
"textutils". Se algum dos pacotes não estiver instalado, ele exibe uma lista
dos faltantes e pede que você os instale manualmente antes de continuar.
Outro projeto importante é o Slackbuilds, que disponibiliza scripts de
compilação para diversos outros aplicativos, permitindo que você os compile
diretamente na sua máquina, em vez de esperar que algum grupo
disponibilize um pacote pré-compilado:
http://www.slackbuilds.org/
A instalação de aplicativos através do código-fonte no Slackware é bastante
simples em relação a outras distribuições; já que, ao marcar a categoria "D"
durante a instalação, quase todos os compiladores e bibliotecas necessários
são instalados automaticamente, evitando que você precise ficar caçando os
componentes na hora de tentar compilar cada pacote, como é comum em
outros sistemas.
Ao usar os scripts do Slackbuilds o processo se torna quase automático, você
precisa apenas baixar o SalckBuild do pacote desejado, descompactar o
arquivo, baixar o pacote com o código-fonte (salvando-o na mesma pasta) e
em seguida executar o script de instalação, deixando que ele se encarregue do
restante da instalação.
Para instalar o SlackBuild do Ndiswrapper, disponível no:
http://www.slacky.eu/
http://www.linuxpackages.net/
http://packages.slackware.it/
http://www.droplinegnome.org/
http://www.slackbuilds.org/
http://www.slackbuilds.org/repository/12.2/network/ndiswrapper/
... por exemplo, os passos seriam:
a) Baixar o arquivo "ndiswrapper.tar.gz" disponível na página
(contendo o SlackBuild) e descompactá-lo na pasta atual:
$ tar -zxvf ndiswrapper.tar.gz
b) Acessar a pasta "ndiswrapper" que será criada e baixar para dentro
dela o arquivo "ndiswrapper-1.53.tar.gz" (também disponível na página)
que contém o código-fonte do pacote.
c) Executar, como root, o script "ndiswrapper.SlackBuild" disponível
dentro da pasta:
# ./ndiswrapper.SlackBuild
d) Depois de feito o processo de compilação, será gerado o pacote
"ndiswrapper-1.53_2.6.24.5_smp-i486-1_SBo.tgz", salvo no diretório
"/tmp". Este é o pacote compilado, que pode ser instalado usando o
installpkg:
# installpkg /tmp/ndiswrapper-1.53_2.6.24.5_smp-i486-1_SBo.tgz
Se você desmarcou a categoria "D" durante a instalação, o jeito mais prático
de instalar os pacotes posteriormente é montar o DVD de instalação, acessar
a pasta com os pacotes ("cd /mnt/cdrom/slackware/d/") e usar o comando
" installpkg *.tgz " para instalar de uma vez todos os pacotes do diretório.
Outra opção é usar o pkgtool dentro do diretório, o que permite revisar a
instalação de cada um:
http://www.slackbuilds.org/repository/12.1/network/ndiswrapper/
Uma curiosidade é que o formato Slackbuild é adotado também para a
compilação dos pacotes principais do repositório do Slackware. Acessando a
pasta "source" dentro de qualquer um dos repositórios (ftp://ftp.slackware-
brasil.com.br/slackware-12.2/source/, por exemplo), você encontra os
Slackbuilds dos pacotes incluídos nos CDs de instalação, que você pode
compilar manualmente seguindo os mesmos passos que acabamos de ver.
 
Instalando a partir do código-fonte
Se tudo mais falhar, existe também a opção de instalar programas a partir do
código-fonte, distribuídos na forma dos famosos pacotes .tar.gz ou .tar.bz2.
Eles são o formato mais universal, porém ao mesmo tempo o mais
complicado de instalar, que você deixa como um último recurso a lançar mão
quando não encontrar um pacote atualizado do programa desejado. Embora a
instalação nem sempre esteja livre deproblemas (já que muitas vezes você
precisará sair caçando algum compilador ou biblioteca específica), instalá-los
no Slackware é mais simples do que em outras distribuições (desde que você
tenha instalado os pacotes da categoria D, naturalmente), pois o sistema
oferece um conjunto bastante completo de compiladores.
Uma dica é que todos os pacotes cujo nome termina com "-dev" são
justamente bibliotecas de desenvolvimento, que podem ser necessárias ao
compilar determinados programas. Quando o instalador reclama da falta de
bibliotecas ou arquivos do X, provavelmente ele está dando falta do pacote
"xlibs-dev"; quando reclama da falta de arquivos do KDE, provavelmente
está pedindo o pacote "libqt3-dev", e assim por diante.
A maior dificuldade em compilar programas complexos está justamente em
localizar e instalar o conjunto de bibliotecas de que ele precisa. Desde que
você instale todos os pacotes da categoria D, as instalações ocorrem sem
grandes dificuldades.
Se os pré-requisitos estiverem em ordem, a compilação em si é feita
descompactado o arquivo (usando o comando "tar -zxvf pacote.tar.gz" ou "tar
-jxvf pacote.tar.bz2"), acessando a pasta que será criada e rodando três
comandos básicos:
ftp://ftp.slackware-brasil.com.br/slackware-12.2/source/
$ ./configure
$ make
$ su
# make install
O "./configure" executa um script (dentro da pasta do programa), que verifica
o sistema, em busca dos componentes de que precisa. Ele avisa caso algo
esteja faltando, permitindo que você tente solucionar o problema, instalando
o componente faltoso.
O "make" cuida do trabalho pesado, fazendo a compilação propriamente dita.
Ele se baseia nas informações deixadas pelo "./configure" para encontrar os
componentes de que precisa.
Finalmente, temos o "make install", que finalmente instala o programa,
copiando os arquivos gerados pelo make para as pastas corretas do sistema.
Ao contrário dos dois primeiros comandos, ele precisa ser executado como
root, já que envolve fazer alterações no sistema.
Apesar destes três comandos serem um padrão adotado na maioria dos
pacotes, eles não são necessariamente uma regra. Muitos programas usam
sistemas simplificados de instalação ou mesmo scripts próprios, por isso é
sempre bom dar uma olhada no arquivo "INSTALL" ou "README" dentro
da pasta, que explica os passos necessários. Em geral, os programas
instalados a partir dos fontes não criam os ícones no menu. Você precisa
chamar o programa via linha de comando ou criar os ícones manualmente.
 
Configurando o Slackware como desktop
Agora que já estudamos sobre a configuração e o gerenciamento de pacotes
no Slackware, vamos a algumas dicas sobre os aplicativos do KDE e a
instalação de plugins, seguindo agora uma abordagem mais leve, voltada para
as tarefas a executar. Este é apenas um resumo rápido voltado para o
Slackware; teremos uma explicação mais elaborada sobre os aplicativos no
próximo capítulo.
Como sempre, o mais básico é a navegação web. Versões antigas do
Slackware utilizavam o antiquíssimo Netscape como suíte de navegação, mas
nas atuais encontramos o Firefox, que dispensa apresentações. O Slackware
não vem com o suporte a flash pré-instalado, o que dispara o "libnullplugin",
que é plugin padrão do firefox, responsável por instalar os plugins
automaticamente:
Ele não funciona corretamente no Slackware, reclamando que o plugin não
foi encontrado, mas basta clicar no botão de instalação manual para que ele o
encaminhe ao site da Adobe, onde você pode baixar o arquivo manualmente.
Faça download da versão ".tar.gz" do arquivo e copie o arquivo
"libflashplayer.so" para dentro da pasta ".mozilla/plugins" dentro do diretório
home. Essa pasta não existe por padrão no Slackware, mas basta criá-la:
$ mkdir ~/.mozilla/plugins
Da primeira vez que abrir o Firefox, você vai perceber que o estilo da janela é
realmente feio, um problema que no Slackware se estende a todos os outros
aplicativos baseados na biblioteca GTK2. Felizmente, a solução é simples,
basta ativar o gerenciador de temas do XFCE. Ele se encarrega de ajustar o
tema usado pelos aplicativos GTK2:
$ xfce-mcs-manager
A partir daí, você pode ajustar as fontes e o tema visual utilizando o comando
"xfce-setting-show" (que também é chamado usando seu login de usuário,
não o root), na opção "User Interface".
Para que ele seja executado automaticamente na abertura do KDE, crie um
link para aplicativo apontando para o comando "xfce-mcs-manager" (você
pode criar novos links clicando com o botão direito sobre o desktop e usando
a opção "Criar novo > Link para aplicativo") e copie o atalho para dentro da
pasta ".kde/Autostart" dentro do diretório home.
Se você tem o hábito de sempre trabalhar com um terminal aberto, outra
opção é adicionar o comando ao arquivo .bashrc (também dentro do home).
Como ele é executado sempre que um terminal é aberto, o problema também
é resolvido:
$ echo "xfce-mcs-manager" >> ~/.bashrc
 
 Preste atenção ao usar comandos que escrevem diretamente em arquivos, como este. As duas setas
">>" fazem que que ele adicione a linha no final do arquivo (que é o que queremos nesse caso), mas se você
usar apenas uma (>) o comportamento muda e ele apaga todo o conteúdo do arquivo, deixando apenas a
nova linha.
Além do Firefox, estão disponíveis mais dois navegadores: o SeaMonkey e o
Konqueror. O SeaMonkey (pronuncia-se "si-monquei") é uma versão
atualizada do "Mozillão", que inclui o cliente de e-mails, livro de endereços e
o editor HTML herdados do Netscape. Não é muito recomendável utilizá-lo
hoje em dia, já que como navegador ele está bastante defasado em relação às
versões recentes do Firefox, mas ele pode ser uma opção para máquinas
antigas, já que é um pouco mais leve.
O Konqueror, por sua vez, é o navegador padrão do KDE 3, que faz também
o papel de gerenciador de arquivos. O Konqueror oferece todos os recursos
básicos de navegação, incluindo o suporte a tabs, suporte a plugins e (por ser
integrado aos componentes do KDE) oferece um consumo de memória
relativamente baixo ao navegar.
Você não precisa se preocupar em instalar os plugins separadamente para o
Konqueror, pois ele é capaz de utilizar os plugins do Firefox
automaticamente. Para que isso funcione, acesse as "Configurações >
Configurar Konqueror > Plugins" e marque a opção "Procurar por novos
plugins durante a inicialização do KDE":
Como gerenciador de arquivos, o Konqueror também oferece muitos
recursos. Se você tem um monte de imagens dentro de uma pasta e quer fazer
um álbum de fotos, por exemplo, use o "Ferramentas > Criar Álbum de
Imagens". Clicando com o botão direito sobre um arquivo e indo em
"Ações", você abre um menu de contexto com opções relacionadas ao tipo de
arquivo, permitindo compactar arquivos, converter imagens para outros
formatos e assim por diante. Você pode também dividir a janela em duas
(muito útil ao copiar arquivos de uma pasta para a outra) usando o "Janela >
Separar visão" e abrir um terminal para executar comandos de texto dentro da
pasta atual usando o "Ferramentas > Abrir Terminal".
Uma curiosidade é que o KHTML (a engine de renderização do Konqueror)
deu origem ao WebKit, o framework que é usado como base para o
desenvolvimento do Safari (o navegador do MacOS X, usado também no
iPhone) e do Google Chrome, sem falar do S60 Browser, que é o navegador
usado nos smartphones da Nokia.
Ou seja, embora à primeira vista pareça apenas um navegador alternativo, o
Konqueror é na verdade o pai de diversos projetos importantes. No KDE 4,
ele perdeu o cargo de gerenciador de arquivos default para o Dolphin, mas
apesar disso ele continua disponível como opção.
Como cliente de IM, você pode escolher entre o Kopete (que é o cliente
nativo do KDE) ou o Pidgin, que é a opção mais popular atualmente. Ambos
suportam o MSN e o Google Talk/Jabber (entre diversos outros protocolos) e
são capazes de se conectar a várias redes simultaneamente.
Apesar de ser baseado na biblioteca GTK2, o Pidgin roda com um bom
desempenho sobre o KDE, de forma que a escolha recai sobre