Os componentes do sistema

Todas as coisas grandes começam pequenas e com o Linux não foi diferente. Para entender melhor os componentes que formam o sistema, nada melhor do que falar um pouco sobre a história do Linux, sobre como e por que eles foram introduzidos e tentar entender o processo de boot do sistema.

Kernel

Tudo começou em 1991, com a primeira versão do Kernel disponibilizada por Linus Torvalds. O “Freax” (renomeado para “Linux” pelo responsável pelo FTP, uma alma sábia e caridosa 🙂 ainda estava na versão 0.02 e era um sistema monolítico, um grande bloco de código que além do núcleo do sistema, continha drivers de dispositivos e tudo mais.

Para compilar o código fonte do Kernel, era necessário usar o Minix, outro sistema baseado em Unix que na época era popular entre os estudantes. Você começava compilando o Kernel e em seguida algumas ferramentas básicas 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 próprio Linux e compilar os demais programas a partir dele mesmo. Isso tudo muito antes das primeiras distribuições Linux começarem a surgir no horizonte.

Este procedimento e usar outro sistema operacional instalado para compilar uma instalação do Linux é de certa forma usada até hoje para gerar versões do sistema destinadas a serem usadas em dispositivos embarcados, como palms e celulares, onde você usa uma cópia do Linux instalada num PC para “montar” o sistema que vai rodar no dispositivo, compilando primeiro o Kernel e depois os demais aplicativos necessários, deixando para finalmente transferir para o dispositivo no final do processo. Isto é chamado de “cross-compiling“.

Atualmente o Kernel, junto com vários aplicativos podem ser compilados para rodar em várias plataformas diferentes. O código fonte do Kernel, disponível no http://kernel.org e diversos mirrors inclui o código necessário para gerar um Kernel para qualquer arquitetura suportada.

Na verdade, quase 95% do código 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 código envolvido :-). As partes que mudam de uma arquitetura a outra são organizadas na pasta “/usr/src/linux/arch/” .

É um trabalho relativamente complexo e tedioso, muitas coisas precisam ser ajustadas e é preciso encontrar programas específicos, que se ajustem à configuração de hardware da plataforma alvo. Você pode rodar Linux num celular com 2 MB de memória, mas com certeza não vai conseguir rodar o Firefox nele. Vai precisar encontrar um navegador mais leve, que rode confortavelmente com pouca memória e a tela minúscula do aparelho. 😉

Aqui temos um screenshot do Familiar, uma distribuição Linux para o Compaq Ipaq, que pode ser instalado em substituição ao Pocket PC Windows que vem originalmente instalado. Veja que ele é bem diferente das distribuições para micros PC:

Você pode entender melhor sobre como isto funciona instalando o “Linux from Scratch“, uma distribuição Linux toda compilada manualmente a partir dos pacotes com código fonte: http://www.linuxfromscratch.org/

Voltando à história, no início o projeto ainda não tinha muita utilidade prática. O conjunto de aplicativos que funcionavam no sistema era pequena. Era muito mais fácil usar o Minix, ou, se você tivesse condições financeiras, uma versão 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 não apenas o código fonte do sistema ser aberto e estar disponível, mas também a forma aberta como o sistema foi desenvolvido desde o início.

É normal encontrar muitos problemas e deficiências ao tentar usar um software em estágio primário de desenvolvimento. Se você for um programador vai acabar dando uma olhada no código e fazendo algumas modificações. Se você estiver desenvolvendo algum projeto parecido, é provável que você resolva aproveitar algumas idéias e pedaços de código para implementar alguma nova função e assim por diante.

No caso do Linux, estas modificações eram bem vindas e acabavam sendo incluídas 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 começou a ficar maduro o suficiente para concorrer com as várias versões 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 começaram a contribuir com o desenvolvimento do Kernel, a fim de tornar o sistema mais robusto e adicionar recursos necessários para determinadas tarefas.

Este modelo é diferente do adotado pela Microsoft por exemplo, que vende caixinhas do Windows e Office. Estas empresas ganham mais vendendo soluções, onde é fornecido um pacote, com o sistema operacional, aplicativos, suporte e garantias. Neste caso faz sentido contribuir para a construção de uma base comum (o Kernel), o que sai muito mais barato do que investir em um sistema próprio e diferenciar-se das demais investindo nos outros componentes do pacote.

Originalmente o termo “Linux” era usado especificamente com relação 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 versões do Unix e este fluxo continua até hoje, nos dois sentidos.

O Kernel é a base do sistema. Ele controla o acesso à memória, ao HD e os demais componentes do micro, dividindo os recursos disponíveis entre os programas. Todos os demais programas, desde os aplicativos de linha de comando, até os aplicativos gráficos rodam sobre o Kernel.

Por exemplo, imagine que você está desenvolvendo um aplicativo de edição de áudio. Você precisa incluir no seu programa várias funções de edição, filtros e assim por diante. Mas, você não 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 línguas diferentes. Por isso o Kernel inclui vários intérpretes, os drivers de dispositivos.

Driver em inglês significa “motorista”. Cada chipset de placa de som, vídeo, rede ou modem possui um driver próprio.

Podemos dizer que os módulos são as partes do Kernel mais intimamente ligadas ao hardware. Os módulos são as partes do Kernel que mudam de máquina para máquina. Depois vem o bloco principal, “genérico” do Kernel.

Sobre ele roda o shell, o interpretador de comandos responsável por executar os aplicativos de modo texto e servidores, como o Samba e o Apache. Estes aplicativos são independentes do modo gráfico, você não precisa manter o X aberto para instalar e configurar um servidor Samba por exemplo, embora as ferramentas gráficas 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 série de serviços e comandos que podem ser usados pelos aplicativos. Neste caso o bash dá a ordem para que o executável “cat”, junto com o arquivo sejam carregados na memória.

Para que isso aconteça, o Kernel precisa ler os dois arquivos no HD e carregá-los na memória RAM. No processo são usadas chamadas de vários módulos diferentes, como o responsável pelo acesso à porta IDE onde o HD está conectado, o responsável pelo sistema de arquivos em que o HD está formatado e módulo responsável pelo suporte ao controlador de memória da placa mãe.

No caso de programas grandes, a memória RAM pode ficar lotada, obrigando o Kernel a usar o sub-sistema de memória virtual para gravar as informações na partição swap.

Só depois de tudo isso que o “cat” pode ser executado e mostrar o conteúdo do arquivo na tela (usando mais um comando do Kernel, que aciona a placa de vídeo). Graças ao trabalho do Kernel, você não precisa se preocupar com nada disso, apenas com os programas que precisa executar.

Depois vem o X, o servidor gráfico, responsável por acessar a placa de vídeo e mostrar imagens no monitor. Ele serve como base para os aplicativos gráficos, que podem ser divididos em duas categorias. Primeiro temos os gerenciadores, como o KDE e o Gnome que são responsáveis 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 gráficos.

Mesmo dentro do modo gráfico você continua tendo acesso aos recursos do modo texto. Programas como o xterm e o konsole são usados para rodar uma instância do bash dentro do modo gráfico, 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 gráfico você continua tendo acesso aos recursos do modo texto. Programas como o xterm e o konsole são usados para rodar uma instância do bash dentro do modo gráfico, 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.