Entendendo como o Linux funciona

As distribuies Linux sempre vm de fbrica com suporte a muitos dispositivos, em geral quase tudo detectado automaticamente. Os maiores problemas em geral so os softmodems que precisam ser instalados manualmente depois da instalao. O mesmo se aplica se voc tiver uma placa de vdeo da nVidia ou da ATI ou outros dispositivos cujos fabricantes disponibilizam drivers proprietrios. Mas, afinal, como a instalao destes drivers no Linux? Cad o assistente para a instalao de novo hardware? Onde que eu aponto a pasta onde esto os arquivos? Calma, vamos chegar l :-) O suporte a dispositivos no Linux feito atravs de mdulos includos no Kernel, arquivos que ficam dentro da pasta /lib/modules/. Estes mdulos so a coisas mais parecida com um "driver" dentro da concepo que temos no Windows. Para ativar suporte a um certo dispositivo voc precisa apenas carregar o mdulo referente a ele. Veja que os mdulos ficam organizados em pastas: a pasta "net" contm drivers para placas de rede, a pasta "ieee1394" agrupa os que do suporte a controladoras e dispositivos firewire e assim por diante.

Os mdulos podem ser carregados e descarregados a qualquer momento usando os comandos "modprobe" e "modprobe -r"; no apenas na inicializao do sistema. Os mdulos so gerados durante a compilao do Kernel.

Voc no precisa se preocupar com isso se no quiser, pois as distribuies quase sempre incluem Kernels bem completos por padro. Mas, de qualquer forma, existe sempre a possibilidade de recompilar o Kernel, mexendo nas opes e ativando ou desativando os mdulos que quiser. Voc pode incluir mdulos para todo tipo de dispositivos, de marcas e modelos diferentes, eles no atrapalham em nada, pois apenas alguns deles (os que voc estiver usando no momento) ficaro carregados. Estes mdulos geralmente so pequenos, um conjunto completo com os mdulos para todo tipo de dispositivos geralmente ocupa de 30 a 50 MB no HD. Podemos dividir os drivers de dispositivo para o Linux em dois grupos. O primeiro o dos drivers de cdigo aberto, que podem tanto ser desenvolvidos pelos prprios fabricantes quanto por voluntrios em cantos remotos do mundo. Desenvolver drivers usando engenharia reversa sem ajuda dos fabricantes parece ser um passatempo bastante popular :-) Estes drivers open-source so includos diretamente no Kernel, o que faz com que sejam includos diretamente nas distribuies e voc no precise se preocupar muito com eles. Sua placa funciona e todo mundo fica feliz. A segunda categoria a dos drivers proprietrios, que so desenvolvidos pelos prprios fabricantes. Em alguns casos os drivers so de livre distribuio e tambm podem ser includos diretamente nas distribuies. Em outros voc mesmo precisar baixar e instalar o driver. aqui que entram os drivers para softmodems, para muitas placas wireless e tambm 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, criar e instalar o mdulo propriamente dito e criar um "dispositivo" (device), um atalho que aponta para o endereo de hardware usado por ele. Ao instalar um modem Lucent por exemplo criado um dispositivo "/dev/ttyLT0" por onde o modem acessado. Para facilitar esta tarefa geralmente os drivers vm com algum tipo de instalador, geralmente um script simples de modo texto que cuida disso pra voc. Os mdulos so parte integrante do Kernel, por isso os mdulos para uma determinada distribuio no funcionam em outra, a menos que por uma grande coincidncia as duas utilizem exatamente a mesma verso do Kernel, o que bastante improvvel j que o Kernel do Linux atualizado quase que diariamente. Se voc usar uma distribuio popular, Mandrake, Red Hat, SuSe, etc. provvel que voc j encontre um driver pr-compilado. Neste casos voc s vai precisar instalar um pacote RPM ou executar um arquivo de instalao. Em outros casos voc encontrar apenas um arquivo genrico ainda no compilado. Nestes casos o instalador se encarregar de compilar um mdulo sob medida para o Kernel que estiver em uso. Como ele no tem como adivinhar qual distribuio ou Kernel voc est utilizando voc precisar ter instalados dois pacotes que acompanham

qualquer distribuio: kernel-source e kernel-headers. No Mandrake por exemplo voc pode instal-los usando os comandos "urpmi kernel-source" e "urpmi kernel-headers". Naturalmente, para que ele possa compilar qualquer coisa voc precisar tambm de um compilador, o gcc, que tambm acompanha as distribuies. Se voc tiver estas trs coisas, vai conseguir instalar qualquer driver sem maiores problemas, basta seguir as instrues na pgina de download ou no arquivo INSTALL ou README dentro do pacote.

Os componentes do sistema
Todas as coisas grandes comeam pequenas e com o Linux no foi diferente. Para entender melhor os componentes que formam o sistema, nada melhor do que falar um pouco sobre a histria do Linux, sobre como e por que eles foram introduzidos e tentar entender o processo de boot do sistema.
Kernel

Tudo comeou em 1991, com a primeira verso do Kernel disponibilizada por Linus Torvalds. O "Freax" (renomeado para "Linux" pelo responsvel pelo FTP, uma alma sbia e caridosa :) ainda estava na verso 0.02 e era um sistema monoltico, um grande bloco de cdigo que alm do ncleo do sistema, continha drivers de dispositivos e tudo mais. Para compilar o cdigo fonte do Kernel, era necessrio usar o Minix, outro sistema baseado em Unix que na poca era popular entre os estudantes. Voc comeava compilando o Kernel e em seguida algumas ferramentas bsicas como o gerenciador de boot, o bash (o interpretador de comandos) e o gcc (o compilador). A partir de um certo ponto voc podia bootar no prprio Linux e compilar os demais programas a partir dele mesmo. Isso tudo muito antes das primeiras distribuies Linux comearem a surgir no horizonte. Este procedimento e usar outro sistema operacional instalado para compilar uma instalao do Linux de certa forma usada at hoje para gerar verses do sistema destinadas a serem usadas em dispositivos embarcados, como palms e celulares, onde voc usa uma cpia do Linux instalada num PC para "montar" o sistema que vai rodar no dispositivo, compilando primeiro o Kernel e depois os demais aplicativos necessrios, deixando para finalmente transferir para o dispositivo no final do processo. Isto chamado de "cross-compiling". Atualmente o Kernel, junto com vrios aplicativos podem ser compilados para rodar em vrias plataformas diferentes. O cdigo fonte do Kernel, disponvel no http://kernel.org e diversos mirrors inclui o cdigo necessrio para gerar um Kernel para qualquer arquitetura suportada. Na verdade, quase 95% do cdigo Kernel independente da arquitetura, por isso portar o Kernel para uma nova plataforma um trabalho relativamente simples (pelo menos se levarmos em conta a complexidade do cdigo envolvido :-). As partes que mudam de uma arquitetura a outra so organizadas na pasta "/usr/src/linux/arch/" .

 um trabalho relativamente complexo e tedioso, muitas coisas precisam ser ajustadas e preciso encontrar programas especficos, que se ajustem configurao de hardware da plataforma alvo. Voc pode rodar Linux num celular com 2 MB de memria, mas com certeza no vai conseguir rodar o Firefox nele. Vai precisar encontrar um navegador mais leve, que rode confortavelmente com pouca memria e a tela minscula do aparelho. ;-) Aqui temos um screenshot do Familiar, uma distribuio Linux para o Compaq Ipaq, que pode ser instalado em substituio ao Pocket PC Windows que vem originalmente instalado. Veja que ele bem diferente das distribuies para micros PC:

Voc pode entender melhor sobre como isto funciona instalando o "Linux from Scratch", uma distribuio Linux toda compilada manualmente a partir dos pacotes com cdigo fonte: http://www.linuxfromscratch.org/ Voltando histria, no incio o projeto ainda no tinha muita utilidade prtica. O conjunto de aplicativos que funcionavam no sistema era pequena. Era muito mais fcil usar o Minix, ou, se voc tivesse condies financeiras, uma verso comercial do Unix, como o SunOS (que mais tarde deu origem ao Solaris, que desenvolvido at hoje). O que fez com que o Linux acrescesse at o ponto em que est hoje foi principalmente o fato de no apenas o cdigo fonte do sistema ser aberto e estar disponvel, mas tambm a forma aberta como o sistema foi desenvolvido desde o incio. normal encontrar muitos problemas e deficincias ao tentar usar um software em estgio primrio de desenvolvimento. Se voc for um programador vai acabar dando uma olhada no cdigo e fazendo algumas modificaes. Se voc estiver desenvolvendo algum projeto parecido, provvel que voc resolva aproveitar algumas idias e pedaos de cdigo para implementar alguma nova funo e assim por diante.

No caso do Linux, estas modificaes eram bem vindas e acabavam sendo includas no sistema muito rapidamente. Isto criou uma comunidade bastante ativa, gente usando o sistema nos mais diversos ambientes e ajudando a torn-lo adequado para todo tipo de tarefa. Inicialmente era tudo um grande hobby. Mas logo o sistema comeou a ficar maduro o suficiente para concorrer com as vrias verses do Unix e mais tarde com o Windows. Inicialmente nos servidores, depois nos dispositivos embarcados e finalmente no desktop. Com isso, mesmo grandes empresas como a IBM e a Novell comearam a contribuir com o desenvolvimento do Kernel, a fim de tornar o sistema mais robusto e adicionar recursos necessrios para determinadas tarefas. Este modelo diferente do adotado pela Microsoft por exemplo, que vende caixinhas do Windows e Office. Estas empresas ganham mais vendendo solues, onde fornecido um pacote, com o sistema operacional, aplicativos, suporte e garantias. Neste caso faz sentido contribuir para a construo de uma base comum (o Kernel), o que sai muito mais barato do que investir em um sistema prprio e diferenciar-se das demais investindo nos outros componentes do pacote. Originalmente o termo "Linux" era usado especificamente com relao ao Kernel desenvolvido por Linus Torvalds, mas hoje em dia mais comum nos referirmos plataforma como um todo, incluindo o Kernel, ferramentas e aplicativos. Muitos dos aplicativos que usamos hoje no Linux vieram de outras verses do Unix e este fluxo continua at hoje, nos dois sentidos. O Kernel a base do sistema. Ele controla o acesso memria, ao HD e os demais componentes do micro, dividindo os recursos disponveis entre os programas. Todos os demais programas, desde os aplicativos de linha de comando, at os aplicativos grficos rodam sobre o Kernel. Por exemplo, imagine que voc est desenvolvendo um aplicativo de edio de udio. Voc precisa incluir no seu programa vrias funes de edio, filtros e assim por diante. Mas, voc no precisa se preocupar diretamente em oferecer suporte aos diferentes modelos de placas de som que temos no mercado, pois o Kernel cuida disso. Ao tocar um arquivo qualquer, o seu programa precisa apenas mandar o fluxo de udio para o device /dev/dsp. O Kernel recebe o fluxo de udio e se encarrega de envi-la placa de som. Quando preciso ajustar o volume, seu programa acessa o dispositivo "/dev/mixer" e assim por diante. Naturalmente uma SB Live e uma placa AC'97 onboard por exemplo oferecem conjuntos diferentes de recursos e se comunicam com o sistema de uma forma particular, ou seja, falam lnguas diferentes. Por isso o Kernel inclui vrios intrpretes, os drivers de dispositivos. Driver em ingls significa "motorista". Cada chipset de placa de som, vdeo, rede ou modem possui um driver prprio.

Podemos dizer que os mdulos so as partes do Kernel mais intimamente ligadas ao hardware. Os mdulos so as partes do Kernel que mudam de mquina para mquina. Depois vem o bloco principal, "genrico" do Kernel. Sobre ele roda o shell, o interpretador de comandos responsvel por executar os aplicativos de modo texto e servidores, como o Samba e o Apache. Estes aplicativos so independentes do modo grfico, voc no precisa manter o X aberto para instalar e configurar um servidor Samba por exemplo, embora as ferramentas grficas possam ajudar bastante. Quando voc executa o comando "cat arquivo.txt" por exemplo, o bash entende que deve usar o programa "cat" para ler o "arquivo.txt". O Kernel oferece uma srie de servios e comandos que podem ser usados pelos aplicativos. Neste caso o bash d a ordem para que o executvel "cat", junto com o arquivo sejam carregados na memria. Para que isso acontea, o Kernel precisa ler os dois arquivos no HD e carreg-los na memria RAM. No processo so usadas chamadas de vrios mdulos diferentes, como o responsvel pelo acesso porta IDE onde o HD est conectado, o responsvel pelo sistema de arquivos em que o HD est formatado e mdulo responsvel pelo suporte ao controlador de memria da placa me. No caso de programas grandes, a memria RAM pode ficar lotada, obrigando o Kernel a usar o sub-sistema de memria virtual para gravar as informaes na partio swap. S depois de tudo isso que o "cat" pode ser executado e mostrar o contedo do arquivo na tela (usando mais um comando do Kernel, que aciona a placa de vdeo). Graas ao trabalho do Kernel, voc no precisa se preocupar com nada disso, apenas com os programas que precisa executar. Depois vem o X, o servidor grfico, responsvel por acessar a placa de vdeo e mostrar imagens no monitor. Ele serve como base para os aplicativos grficos, que podem ser divididos em duas categorias. Primeiro temos os gerenciadores, como o KDE e o Gnome que so responsveis por gerenciar as janelas, mostrar a barra de tarefas e assim por diante. Eles servem como uma base para que voc possa abrir e controlar os demais aplicativos grficos. Mesmo dentro do modo grfico voc continua tendo acesso aos recursos do modo texto. Programas como o xterm e o konsole so usados para rodar uma instncia do bash dentro do modo grfico, permitindo executar todos os aplicativos de linha de comando e scripts. Ou seja, o X roda com uma perna no Kernel e outra no interpretador de comandos.

Mesmo dentro do modo grfico voc continua tendo acesso aos recursos do modo texto. Programas como o xterm e o konsole so usados para rodar uma instncia do bash dentro do modo grfico, permitindo executar todos os aplicativos de linha de comando e scripts. Ou seja, o X roda com uma perna no Kernel e outra no interpretador de comandos.

Mdulos
Como vimos, uma das tarefas mais importantes do Kernel oferecer suporte ao hardware da mquina. No comeo, a questo era mais simples, pois no existiam perifricos USB, softmodems e muito menos placas Wireless. O Kernel oferecia suporte apenas ao arroz com feijo, como HD, placa de vdeo e drive de disquetes. Como tempo foi sendo adicionado suporte a muitos outros dispositivos: placas de som, placas de rede, controladoras SCSI, etc. O fato do Kernel ser monoltico comeou a atrapalhar bastante. Voc podia escolher os componentes a ativar na hora de compilar o Kernel. Se voc habilitasse tudo, no 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 voc compilasse um Kernel enxuto e esquecesse de habilitar o suporte algum recurso necessrio, teria que recompilar tudo de novo para ativ-lo. Este problema foi resolvido durante o desenvolvimento do Kernel 2.0, atravs do suporte a mdulos. Os mdulos so peas independentes que podem ser ativadas ou

desativadas com o sistema em uso. Do Kernel 2.2 em diante, quase tudo pode ser compilado como mdulo. Isso tornou as coisas muito mais prticas, pois passou ser possvel compilar um Kernel com suporte a quase tudo, com todas as partes no essenciais compiladas como mdulos. O Kernel em s um executvel pequeno, que consome pouca RAM e roda rpido, enquanto os mdulos ficam guardados numa pasta do HD at que voc precise deles. Voc podia carregar o mdulo para a SoundBlaster 16 (do 486 que voc usava na poca ;-)) por exemplo, com um: # modprobe sb E descarreg-lo com um: # modprobe -r sb Esta idia dos mdulos deu to certo que usada at hoje e num nvel cada vez mais extremo. Para voc ter uma idia, no Kernel 2.6 at mesmo o suporte a teclado pode ser desativado ou compilado como mdulo, uma modificao que parece besteira num PC, mas que til para quem desenvolve verses para roteadores e outros dispositivos que realmente no possuem teclado :-). As distribuies passaram ento a vir com verses do Kernel cada vez mais completas, incluindo em muitos casos um grande nmero de patches para adicionar suporte a ainda mais dispositivos, naturalmente quase tudo compilado como mdulo. Nas distribuies atuais, o hardware da mquina detectado durante a instalao e o sistema configurado para carregar os mdulos necessrios durante o boot. Isto pode ser feito de duas formas: 1- Os mdulos para ativar a placa de som, rede, modem e qualquer outro dispositivo "no essencial" so especificados no arquivo /etc/modules. Programas de deteco, como o hotplug e udev, ficam de olho nas mensagens do Kernel e carregam mdulos adicionais conforme novos dispositivos (uma cmera digital USB, em modo de transferncia, por exemplo) so detectados. A sua placa de som seria ativada durante o boot atravs de um mdulo especificado no /etc/modules, assim como o suporte genrico a dispositivos USB. Mas, o seu pendrive, que voc pluga e despluga toda hora ativado e desativado dinamicamente atravs da deteco feita pelo hotplug. A deteco de novos perifricos (principalmente ao usar o Kernel 2.6) muito simplificada graas ao prprio Kernel, que gera mensagens sempre que um novo dispositivo encontrado. Voc pode acompanhar este log rodando o comando "dmesg". Por exemplo, ao plugar um pendrive USB, voc ver algo como: usb 2-2: new high speed USB device using address scsi1 : SCSI emulation for USB Mass Storage devices

Vendor: LG CNS Model: Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 249856 512-byte hdwr sectors (128 MB) sda: Write Protect is off sda: Mode Sense: 03 00 00 00 sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0 Attached scsi generic sg0 at scsi1, channel 0, id 0, lun 0, type 0 USB Mass Storage device found at 5 Veja que aqui esto quase todas as informaes referentes a ele. O fabricante (LG), o dispositivo pelo qual ele ser acessado pelo sistema (sda), a capacidade (128 MB) e at as parties existentes (neste caso uma nica partio, nomeada como sda1) Um segundo arquivo, o /etc/modules.conf (ou /etc/conf.modules>, dependendo da distribuio usada) especifica opes e parmetros para os mdulos, quando necessrio. Este arquivo normalmente gerado automaticamente pelas ferramentas de deteco de hardware ou ao rodar o comando "update-modules", mas pode tambm ser editado manualmente caso necessrio. Outra pea importante o arquivo /lib/modules/2.x.xx/modules.dep, que guarda uma tabela com as dependncias dos mdulos, ou seja, de quais outros mdulos cada um precisa para ser carregado corretamente. Este ltimo arquivo gerado automaticamente ao rodar o comando "depmod -a". Em geral este comando executado automaticamente durante o boot, quando necessrio. 2- Se o suporte a algo essencial nas etapas iniciais do boot no est carregado no Kernel criado um initrd, uma imagem com os mdulos necessrios, que diferentemente dos mdulos especificados no /etc/modules, so carregados logo no incio do boot. O initrd guardado na pasta /boot, junto com o executvel principal do Kernel: o arquivo vmlinuz. Imagine por exemplo que voc est usando uma distribuio onde o suporte ao sistema de arquivos ReiserFS foi compilado como mdulo, mas quer instalar o sistema numa partio reiserfs. Isso gera um problema do tipo o ovo e a galinha, j que o sistema precisa do mdulo para acessar a partio, mas precisa de acesso partio para poder ler o mdulo. Para evitar este tipo de problema, o prprio instalador da distribuio, ao perceber que voc formatou a partio raiz em ReiserFS, vai se encarregar de gerar o arquivo initrd, que embora no seja obrigatrio ( possvel compilar tudo diretamente no Kernel) bastante usado.

O processo de boot e os arquivos de inicializao

Quando voc liga o micro, o primeiro software que carregado o BIOS da placa me, que faz a contagem da memria RAM, uma deteco rpida dos dispositivos instalados e por fim carrega o sistema operacional principal a partir do HD, CDROM, disquete, rede, ou o que seja. Este procedimento inicial chamado de POST (Power-on self test). Seria bom se a funo do BIOS se limitasse a isso, mas na verdade ele continua residente, mesmo depois que o sistema operacional carregado. Na poca do MS-DOS era bem conhecida a diviso entre memria real (os primeiros 640 KB da memria RAM) e memria extendida (do primeiro MB em diante, englobando quase toda a memria instalada). O MS-DOS rodava em modo real, onde o processador trabalha simulando um 8088 (o processador usado no XT) que era capaz de acessar apenas 640 KB de memria. Mesmo os processadores modernos conservam este modo de operao, mas os sistemas operacionais modernos rodam inteiramente em modo protegido, onde so usados todos os recursos da mquina. O espao entre os primeiros 640 KB, onde termina a memria real e os 1024 KB onde comea a memria extendida justamente reservado para o BIOS da placa me. Ele originalmente gravado de forma compactada num chip de memria flash instalado na placa me e fica descompactado neste espao reservado (chamado de shadow RAM) durante o uso. O BIOS oferece funes prontas para acessar o HD, acionar recursos de gerenciamento de energia e muitas outras coisas. Mas, os sistemas operacionais quase no utilizam estas funes, pois existem muitas diferenas na forma como BIOS de diferentes placas me trabalham, e em muitos casos as funes simplesmente no funcionam ou produzem erros inesperados. Os fabricantes de placas me disponibilizam upgrades de BIOS freqentemente para corrigir estes problemas, mas a maior parte dos usurios nem chega a procura-los. Fazendo com que exista um enorme contingente de placas bugadas por a, com problemas no ACPI, DMA e outros outros recursos bsicos. Existe at mesmo um projeto para substituir o BIOS da placa me por uma verso compacta do Kernel do Linux, que executa as mesmas funes, mas de uma forma mais confivel e flexvel: http://www.linuxbios.org/ De qualquer forma, depois de fazer seu trabalho, o BIOS carrega o sistema operacional, lendo o primeiro setor do disco rgido o "Master Boot Record" (MBR), tambm conhecido como trilha zero ou trilha MBR. No MBR vai o gerenciador de boot. Os dois mais usados no Linux so o lilo e o grub. Na verdade, no MBR mesmo vai apenas um bootstrap, um pequeno software que instrui o BIOS a carregar o executvel do lilo ou grub em um ponto especfico do HD. Lembrese que o MBR propriamente dito ocupa um nico setor do HD, apenas 512 bytes. No possvel armazenar muita coisa diretamente nele. O gerenciador de boot utiliza os primeiros 446 bytes do MBR. Os 66 bytes restantes so usados para armazenar a tabela de parties, que guarda informaes sobre onde cada

partio comea e termina. Alguns vrus e acidentes em geral podem danificar os dados armazenados na tabela de partio, fazendo com que parea que o HD foi formatado, mas na maioria dos casos os dados continuam l. Voltando ao tema inicial, o gerenciador de boot tem a funo de carregar o kernel e, a partir dele todo o restante do sistema. O lilo e o grub podem ser configurados ainda para carregar o Windows ou outros sistema instalados em dual boot. Muitas distribuies configuram isso automaticamente durante a instalao. Inicialmente, o kernel um arquivo compactado e somente-leitura, o arquivo /boot/vmlinuz. Ele descompactado em uma rea reservada da memria RAM e roda a partir dal, aproveitando o fato de que a memria RAM muito mais rpida que o HD. Este executvel principal do kernel nunca alterado durante o uso normal do sistema, ele muda apenas quando voc recompila o kernel manualmente ou instala uma nova verso. Se voc prestou ateno quando citei a necessidade de usar um initrd quando a partio raiz do sistema est formatada num sistema de arquivos que no est compilado diretamente no kernel, deve ter notado uma contradio aqui. Afinal o que est sendo feito at agora. Nem o BIOS, nem o lilo possuem suporte a reiserfs e o Kernel precisa ser carregado antes que ele tenha a chance de carregar o initrd. E alm do mais, para carregar o initrd, o prprio Kernel precisa ler o arquivo dentro da partio. Isto tudo funciona por que tanto o BIOS quanto o lilo no procuram entender o sistema de arquivos em que o HD est formatado. Pode ser EXT2, ReiserFS, XFS, ou o que seja, para eles no faz diferena. Eles simplesmente lem os uns e zeros gravados numa rea especfica do HD e assim carregam o kernel e o initrd. Eles no fazem alteraes nos dados gravados, por isso este "acesso direto" no traz possibilidade de danos s estruturas do sistema de arquivos. Depois de carregado, a primeira coisa que o kernel faz montar a partio raiz, onde o sistema est instalado, inicialmente como somente leitura. Neste estgio ele carrega o init, o software que inicia o boot normal do sistema, lendo os scripts de inicializao e carregando os mdulos e softwares especificados neles. O arquivo de configurao do init o /etc/inittab. Ele geralmente o primeiro arquivo de configurao lido durante o boot. A principal tarefa dele carregar os demais scripts de inicializao, usados para carregar os demais componentes do sistema e fazer todas as operaes de checagem, necessrias durante o boot. No /etc/inittab do Debian por exemplo, voc ver a linha: # Boot-time system configuration/initialization script. si::sysinit:/etc/init.d/rcS Esta linha executa o script /etc/init.d/rcS. Se voc examin-lo tambm, vai encontrar o seguinte:

for i in /etc/rcS.d/S??* do ... $i start .... done Os "..." indicam partes dos script que removi para deixar apenas as partes que interessam aqui. Estas linhas so um shell script, que vai executar os scripts dentro da pasta /etc/rcS.d. Esta pasta contm scripts que devem ser executados sempre, a cada boot e so responsveis por etapas fundamentais do boot. Alguns exemplos de scripts e programas que so executados nesta etapa so:

keymap.sh: Carrega o layout do teclado que ser usado no modo texto. Voc no gostaria que seu teclado estivesse com as teclas trocadas para o Russo quando precisar arrumar qualquer coisa no modo texto, no ? ;-) O KDE possui um configurador prprio, o kxkb, que configurado dentro do painel de controle. O layout usado pelo kxkb subscreve o configurado pelo keymap.sh checkroot.sh: Este script roda o fsck, reiserfsck ou outro programa adequado para verificar a estrutura da partio raiz (a partio onde o sistema est instalado), corrigindo erros causados por desligamentos incorretos do sistema. Este processo anlogo ao scandisk do Windows. S depois da verificao que a partio raiz passa a ser acessada em modo leitura e escrita. modutils: Este o script que l os arquivos /etc/modules e /etc/modules.conf, ativando a placa de som, rede e todos os outros dispositivos de hardware "no essenciais", para os quais o suporte no foi habilitado diretamente no Kernel. checkfs.sh: Este script parecido com o checkroot.sh, ele se destina a checar as demais parties do HD. mountall.sh: aqui que lido o arquivo /etc/fstab e as demais parties, unidades de rede e tudo mais que estiver especificado nele ativado. Se voc estiver usando uma partio home separada ou um compartilhamento de rede via NFS para guardar arquivos, por exemplo, a partir deste ponto que eles ficaro disponveis. networking: Ativa a rede, carregando a configurao de IP, DNS, gateway, etc. ou obtendo a configurao via DHCP. A configurao da rede geralmente armazenada dentro da pasta /etc/sysconfig/network-scripts/ ou no arquivo /etc/network/interfaces.

De acordo com a distribuio usada, so carregados neste ponto outros servios, para ativar suporte a placas PCMCIA, placas ISA, ou outros tipos de hardware, ativar o suporte a compartilhamentos de rede e assim por diante. possvel executar praticamente qualquer tipo de comando ou programa nesta etapa, justamente por isso os passos executados durante o boot mudam de distribuio para distribuio, de acordo

com o que os desenvolvedores consideram mais adequado. A idia aqui apenas dar uma base, mostrando alguns passos essenciais que so sempre executados. Depois desta rodada inicial, so executados os scripts correspondentes ao runlevel padro do sistema, que configurado no /etc/inittab, na linha: # The default runlevel. id:5:initdefault: O nmero (5 no exemplo) indica o runlevel que ser usado, que pode ser um nmero de 1 a 5. Cada runlevel corresponde a uma pasta, com um conjunto diferente de scripts de inicializao. uma forma de ter vrios "profiles", para uso do sistema em diferentes situaes. A configurao mais comum a seguinte:

Runlevel 1 - Single user. um modo de recuperao onde nem o modo grfico, nem o suporte a rede, nem nenhum outro servio "no essencial" carregado, de forma a minimizar a possibilidade de problemas. A idia que o sistema "d boot" para que voc possa corrigir o que est errado. Atualmente, uma forma mais prtica para corrigir problemas dar boot com uma distribuio em liveCD (como o Kurumin), onde voc tem acesso internet e vrios programas, montar a partio onde o sistema est instalado e corrigir o problema a partir da. Runlevel 3 - Boot em modo texto. Neste modo todos os servios so carregados, com exceo do gerenciador de boot (KDM ou GDM), que responsvel por carregar o modo grfico. Este modo muito usado em servidores. Runlevel 5 - o modo padro na maioria das distribuies, onde voc tem o sistema "completo", com modo grfico e todos os demais servios. Uma exceo importante o Slackware, onde o modo grfico carregado no runlevel 4.

Por exemplo, usando o runlevel 5, so carregados os scripts dentro da pasta /etc/rc5.d, enquanto que usando o runlevel 3, so carregados os scripts dentro da pasta /etc/rc3.d. Nada impede que voc modifique a organizao dos arquivos manualmente, de forma a fazer o X carregar tambm no runlevel 3, ou qualquer outra coisa que quiser. So apenas pastas com scripts e links simblicos dentro, nenhuma caixa preta.

Ativando e desativando servios

Nas distribuies que seguem o padro do Debian os executveis que iniciam os servios de sistema ficam todos dentro da pasta /etc/init.d. Para parar, iniciar ou reiniciar o servio ssh por exemplo, use os comandos: # /etc/init.d/ssh start # /etc/init.d/ssh stop # /etc/init.d/ssh restart

No Kurumin, Mandrake e algumas outras distribuies, Existe o comando service, que facilita um pouco as coisas, permitindo que ao invs de ter de digitar o caminho completo, voc possa comandar os servios atravs dos comandos: # service ssh start # service ssh stop # service ssh restart

Os scripts que esto na pasta /etc/init.d servem para "chamar" os executveis dos servidores. Eles apenas fazem as verificaes necessrias e em seguida inicializam ou encerram os executveis propriamente ditos, que em geral esto na pasta /usr/bin. A pasta /etc/init.d contm scripts para quase todos os servidores que esto instalados no sistema. Quando voc instala o Samba pelo apt-get por exemplo, criado o script /etc/init.d/samba, mesmo que ele no exista anteriormente.

O que determina se o Samba ser executado ou no durante o boot no o script na pasta /etc/init.d, mas sim um link simblico criado dentro de uma das pastas de inicializao. Por padro so executados primeiro o que est dentro da pasta /etc/rcS.d, e em seguida o que estiver dentro da pasta /etc/rc5.d (caso o sistema esteja configurado para inicializar em runlevel 5, padro no Kurumin) ou na pasta /etc/rc3.d (runlevel 3)

Os nmeros antes dos nomes dos servios dentro da pasta /etc/rc5.d determinam a ordem com que eles vo ser executados. Voc vai querer que o firewall seja sempre ativado antes do Samba por exemplo. O "S" (start) indica que o servio vai ser inicializado. A partir da o sistema vai inicializando um por vez, comeando com os com nmero mais baixo. Caso dois estejam com o mesmo nmero, eles so executados em ordem alfabtica. Para que um determinado servio pare de ser inicializado automaticamente no boot, basta deletar a entrada dentro da pasta, como em: # rm -f /etc/rc5.d/S20samba

Para que o servio volte a ser inicializado, voc deve criar novamente o link, apontando para o script na pasta /etc/init.d, como em: # ln -s /etc/init.d/samba /etc/rc5.d/S20samba

ou # ln -s /etc/init.d/ssh /etc/rc5.d/S21ssh

Existe um utilitrio de modo texto, do Debian, que facilita esta tarefa, o rcconf:

No Fedora, Mandrake e outras distribuies derivadas do Red Hat, voc pode ativar ou desativar a inicializao dos servios no boot usando o comando "chkconfig", como em: # chkconfig ssh on # chkconfig ssh off (desativa)

X
Diferentemente do que temos no Windows, onde a interface grfica um componente essencial do sistema, no Linux o modo grfico uma camada independente. Temos um "servidor grfico", o famoso X que prov a infraestrutura necessria. ele que controla o acesso placa de vdeo, l as teclas digitadas no teclado e os clicks do mouse e oferece todos os recursos necessrios para os programas criarem janelas e mostrarem contedo 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 seo do X), voc ver apenas uma tela cinza, com um X que representa o cursor do mouse. Ou seja, o X apenas uma base, ele sozinho no faz muita coisa. Se voc chama-lo com o comando "xinit" ou "xinit -- :2" voc j abrir junto uma janela de terminal, que poder ser usada para abrir programas. Porm ao abrir qualquer programa grfico voc perceber que algo est estranho. A janela do programa aberta, mas fica fixa na tela, voc no tem como minimiz-la, alternar para outra janela, etc.

Isto acontece por que estas tarefas so controladas pelo gerenciador de janelas, que (em quase todas as distribuies) no carregado com o comando xinit. Existem vrios gerenciadores de janelas, como o KDE, Gnome, WindowMaker, Fluxbox, IceWM e assim por diante. A idia que voc possa escolher qual lhe agrada mais. Chamando o X atravs do comando "startx", ou configurando o sistema para j abrir o X durante a inicializao, finalmente carregamos o conjunto completo, com o X e algum gerenciador de janelas rodando sobre ele. Finalmente podemos usar o PC ;-) O Xfree utiliza uma arquitetura cliente-servidor, onde o X em s atua como o servidor e os programas como clientes, que recebem dele os clicks do mouse e as teclas digitadas no teclado e enviam de volta as janelas a serem mostradas na tela. A grande vantagem deste sistema que alm de rodar programas localmente possvel rodar programas instalados em outras mquinas da rede. Existem vrias formas de fazer isto. Voc pode por exemplo abrir uma janela de terminal dentro do X, conectar-se outra mquina via SSH (com o comando "ssh -X IP_da_maquina") e comear a chamar os programas desejados ou mesmo obter a tela de login da mquina remota e a partir da carregar um gerenciador de janelas e rodar todos os programas via rede.

Neste caso voc precisaria configurar a outra mquina para aceitar as conexes via XDMCP e inicializar o X com o comando "X -query IP_da_maquina" no PC cliente. Muita gente diz que este sistema uma arquitetura ultrapassada, que responsvel por um desempenho ruim se comparado com outros sistemas operacionais, pois tudo teria que passar pela rede antes de ir para o monitor. Esta idia errada, pois ao rodar localmente o X se comunica diretamente com a placa de vdeo, usando todos os recursos de acelerao suportados. Entra a a questo do driver. Se voc tentar rodar um game 3D qualquer, antes de instalar os drivers 3D (da nVidia) para sua placa nVidia por exemplo, ele vai rodar com um desempenho muito baixo, simplesmente por que os recursos 3D da placa no esto ativados. O driver open-source do X para placas nVidia (o diver "nv") oferece apenas suporte 2D. Algumas placas realmente no possuem ainda drivers 3D no X, como por exemplo a maior parte das placas onboard da SiS. Isto tem mais a ver com a boa vontade (ou falta desta) do fabricante em desenvolver drivers ou pelo menos disponibilizar as especificaes das placas. A SiS um dos fabricantes mais hostis, o que faz com que suas placas tenham um suporte ruim. Como sempre questo de pesquisar antes de comprar. Os comandos de atualizao da janelas, etc. so transmitidos pelo X atravs de uma interface de rede local, o que num PC moderno tem um overhead muito pequeno. Os problemas de desempenho em algumas placas est relacionado qualidade dos drivers. 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 necessrio, pois os PCs eram lentos e o X demorava pra abrir. Atualmente o mais comum usar um gerenciador de login, como o KDM (do KDE) ou o GDM (do Gnome). A funo do gerenciador de login carregar o X, mostrar uma tela de login grfica e carregar o KDE, Gnome ou outro gerenciador de janelas escolhido.

Em geral as distribuies que usam o KDE como interface padro usam o KDM, enquanto as que usam 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, so carregadas todas as bibliotecas correspondentes, no h o que fazer. O programa demora mais pra abrir e no final o sistema acaba consumindo muito mais memria. O gerenciador de login aberto como um servio de sistema, da mesma forma que o apache e outros servidores. Voc pode parar o KDM e assim fechar o modo grfico usando o comando "/etc/init.d/kdm stop" e reabri-lo a partir do modo texto com o comando "service kdm start" Como sempre, tudo aberto atravs de um conjunto de scripts. O KDM por exemplo guarda a base das configuraes no arquivo /etc/kde3/kdm/kdmrc (ou /usr/share/config/kdm/kdmrc, dependendo da distribuio) e coloca um conjunto de scripts de inicializao, um para cada interface instalada dentro da pasta /usr/share/apps/kdm/sessions/. A configurao do kdmrc serve para configurar as opes da tela de login, que vo desde opes cosmticas, at a opo de aceitar que outras

maquinas da rede rodem aplicativos remotamente via XDMCP. Ao fazer login, executado o script correspondente interface escolhida. Ao usar o Fluxbox por exemplo, executado o script /usr/share/apps/kdm/sessions/fluxbox. 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 do home do usurio. Xfree x Xorg

Atualmente esto em uso no mundo Linux duas verses diferentes do X, o Xfree e o Xorg. O Xfree o projeto mais antigo e tradicional, o grupo que originalmente portou o X para o Linux e foi o principal mantenedor do projeto desde ento. Com o passar o tempo, comearam a surgir crticas, principalmente direcionadas demora para incluir correes e atualizaes nos drivers existentes. Isto foi se agravando com o tempo, at que uma deciso dos desenvolvedores em fazer uma pequena mudana na licena em vigor a partir do Xfree 4.4 foi a gota d'agua para que um consrcio formado por membros de vrias distribuies desenvolvedores descontentes com o modo de desenvolvimento antigo se juntassem para criar um fork do Xfree, o X.org. O X.org utilizou inicialmente a ltima verso de desenvolvimento da srie 4.3 do Xfree, disponibilizada antes da mudana da licena. Desde ento foram includos muitas atualizaes e correes, como novos drivers e vrios recursos cosmticos, como por exemplo suporte janelas transparentes. A pgina oficial a http://x.org. Inicialmente as diferenas eram pequenas, mas como o X.org tem o apoio das principais distribuies e est sendo desenvolvido num ritmo muito mais rpido, a tendncia que ele substitua inteiramente o Xfree num futuro prximo. Para quem configura, a principal diferena est nos nomes do arquivo de configurao e utilitrios. As opes dentro do arquivo continuam as mesmas, incluindo os nomes dos drivers (radeon, nv, intel, sis, etc.) possvel inclusive usar um arquivo de configurao de uma distribuio com o Xfree em outra (instalada na mesma mquina) com o X.org. Aqui vai uma pequena tabela com algumas diferenas: Arquivo de configurao principal: /etc/X11/XF86Config-4 - /etc/X11/xorg.conf Utilitrios de configurao: xf86cfg - xorgfg xf86config - xorgconfig possvel tambm eliminar estas diferenas criando um conjunto de links apontando para os nomes trocados. Assim o XF86Config vira um link para o xorg.conf por

exemplo, fazendo com que usurios desavisados e at utilitrios de configurao consigam encontrar os arquivos sem muitos problemas.

A rvore genealgica das distribuies

Por causa da filosofia de cdigo aberto e compartilhamento de informaes que existe no mundo Linux, muito raro que uma nova distribuio seja desenvolvida do zero. Quase sempre as distribuies surgem como forks ou personalizaes de uma outra distribuio mais antiga e preservam a maior parte das caractersticas da distribuio original. Isso faz com que distribuies dentro da mesma linhagem conservem mais semelhanas do que diferenas entre s. Das primeiras distribuies Linux, que surgiram entre 1991 e 1993, a nica que sobrevive at hoje o Slackware, que deu origem a algumas outras distribuies conhecidas, como o Vector, Slax e o College. O Slax um live-CD, desenvolvido para caber em um mini-CD, o Vector uma distribuio enxuta, otimizada para micros antigos enquanto o College uma distribuio desenvolvida com foco no publico estudantil, com o objetivo de ser fcil de usar. Os trs utilizam pacotes .tgz do Slackware e so compatveis com os pacotes do Slackware da verso a partir da qual so desenvolvidos. Os utilitrios de configurao do Slackware, como o netconfig continuam disponveis, junto com vrios novos scripts que facilitam a configurao do sistema. O Vector por exemplo inclui o Vasm, uma ferramenta central de configurao. O Debian apareceu pouco depois e ao longo dos anos acabou dando origem quase metade das distribuies atualmente em uso. Algumas, como o Knoppix continuam utilizando os pacotes dos repositrios Debian, apenas acrescentando novos pacotes e ferramentas, enquanto outras, como o Lycoris e o Ubuntu utilizam repositrios separados, parcialmente compatveis com os pacotes originais, mas sempre mantendo o uso do apt-get e a estrutura bsica do sistema. Embora o Debian no seja exatamente uma distribuio fcil de usar, o apt-get e o gigantesco nmero de pacotes disponveis nos repositrios formam uma base muito slida para o desenvolvimento de personalizaes e novas distros. Um dos principais destaques que nas verses Testing e Unstable, o desenvolvimento do sistema contnuo e, mesmo no stable, possvel atualizar de um release para outro sem reinstalar nem fazer muitas modificaes no sistema. Voc pode manter o sistema atualizado usando o comando "apt-get upgrade". Isso permite que os desenvolvedores de distribuies derivadas deixem o trabalho de atualizao dos pacotes para a equipe do Debian e se concentrem em adicionar novos recursos e corrigir problemas. Um dos exemplos de maior sucesso o Knoppix, que chega a ser um marco. Ele se tornou rapidamente uma das distribuies live-CD mais usadas e deu origem a um universo gigantesco de novas distribuies, incluindo o Kurumin. Uma coisa interessante que o Knoppix mantm a estrutura Debian quase intacta, o que fez com

que instalar o Knoppix no HD acabasse tornando-se uma forma alternativa de instalar o Debian. As distribuies derivadas do Knoppix muitas vezes vo alm, incluindo novos componentes que tornam o sistema mais adequado para usos especficos. O Kurumin inclui muitas personalizaes e scripts destinados a tornar o sistema mais fcil de usar e mais adequado para uso em desktop. O Kanotix inclui muitos patches no Kernel, com o objetivo de oferecer suporte a mais hardware e novos recursos, enquanto o Morphix usa uma estrutura modular, que acabou servindo de base para o desenvolvimento de mais uma safra de distribuies, j bisnetas do Debian. Tanto o Debian quanto o Slackware so distribuies basicamente no comerciais. Mas isso no impede que distribuies como o Lycoris e Linspire sejam desenvolvidas por empresas tradicionais, com fins lucrativos naturalmente. Elas procuram se diferenciar das distribuies gratuitas investindo em marketing e facilidades em geral. A terceira distribuio "me" o Red Hat, que deu origem ao Mandrake, SuSE, Conectiva, Fedora e mais recentemente a um enorme conjunto de distribuies menores. As distribuies derivadas do Red Hat no utilizam um repositrio comum, como no caso do Debian, nem mesmo o mesmo gerenciador de pacotes. Temos o yun do Fedora, o urpmi do Mandrake e tambm o prprio apt-get, portado pela equipe do Conectiva. Temos ainda vrios repositrios independentes, que complementam os repositrios oficiais das distribuies. As distribuies derivadas do Red Hat so junto com o Debian e derivados as mais usadas em servidores. O Fedora, Red Hat e SuSE possuem tambm uma penetrao relativamente grande nos desktops nas empresas, enquanto o Mandrake tem o maior pblico entre os usurios domsticos. Embora todas estas distribuies utilizem pacotes rpm, no existe garantia de compatibilidade entre os pacotes de diferentes distribuies. Os pacotes de uma verso recente do SuSE na maioria das vezes funcionam tambm numa verso equivalente do Mandrake por exemplo, mas isto no uma regra. O Gentoo inaugurou uma nova linhagem trazendo uma abordagem diferente das demais distribuies para a questo da instalao de programas e instalao do sistema. Tradicionalmente novos programas so instalados atravs de pacotes pr-compilados, que so basicamente arquivos compactados, com os executveis, bibliotecas e arquivos de configurao usados pelo programa. Estes pacotes so gerenciados pelo apt-get, urpmi, yun ou outro gerenciador usado pela distribuio. Compilar programas a partir dos fontes quase sempre um ltimo recurso para instalar programas recentes, que ainda no possuem pacotes disponveis. O Gentoo utiliza o Portage, um gerenciador de pacotes que segue a idia dos ports do FreeBSD. Os pacotes no contm binrios, mas sim o cdigo fonte do programa, junto com um arquivo ciom parmetros que so usados na compilao. Voc pode ativar as otimizaes que quiser, mas o processo de compilao e instalao automtico. Voc pode instalar todo o KDE com um "emerge kde". O Porge 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 otimizaes para o processador que est usando. Isso resulta em ganhos de 2 a 5% na maior parte dos programas, mas pode chegar a 30% em alguns aplicativos especficos. A parte ruim que compilar programas grandes demora um bocado, mesmo em mquinas atuais. Instalar um sistema completo, com o X, KDE e OpenOffice demora um dia inteiro num Athlon 2800+ e pode tomar um final de semana numa mquina um pouco mais antiga. Voc pode usar o Portage tambm para atualizar todo sistema, usando os comandos "emerge sync && emerge -u world" de uma forma similar ao "apt-get upgrade" do Debian. Nas verses atuais do Gentoo voc pode escolher entre diferentes modos de instalao. No stage 1 tudo compilado a partir dos fontes, incluindo o Kernel e as bibliotecas bsicas. No stage 2 instalado um sistema base pr-compilado e apenas os aplicativos so compilados. No stage 3 o sistema inteiro instalado a partir de pacotes prcompilados, de forma similar a outras distribuies. A nica exceo fica por conta do Kernel, que sempre precisa ser compilado localmente, mesmo ao usar o stage 2 ou 3. O stage 1 naturalmente a instalao mais demorada, mas onde voc pode ativar otimizaes para todos os componentes do sistema. J existe um conjunto crescente de distribuies baseadas no Gentoo, como vrios liveCDs, com games e verses modificadas do sistema, alguns desenvolvidos pela equipe oficial, outros por colaboradores. Uma das primeiras distribuies a utilizar o Gentoo como base foi o Vidalinux. Embora seja uma das distribuies mais difceis, e cuja instalao envolve mais trabalho manual, o Gentoo consegue ser popular entre os usurios avanados, o que acabou por criar uma grande comunidade de colaboradores em torno do projeto. Isto faz com que o Portage oferea um conjunto muito grande de pacotes, quase tantos quanto no apt-get do Debian e exista uma grande quantidade de documentao disponvel, com textos quase sempre atualizados.