Linux

Paralelamente à história da informática que conhecemos, com a IBM
lançando seu IBM PC em 1981, o MS-DOS e as várias versões do Windows,
existiram várias versões dos sistemas Unix, como o Solaris e o AIX que
reinaram durante muito tempo nos servidores.

Mas, o Windows foi o primeiro sistema operacional amigável e acessível,
que o transformou numa espécie de opção default para micros domésticos. A
Apple tinha o Mac OS, outro sistema amigável e superior ao Windows em
muitos aspectos, mas que só rodava nos computadores produzidos pela própria Apple, muito mais caros que os PCs.

Quem precisava de um sistema robusto e confiável para seus servidores
optava por uma das várias versões do Unix, profissionais da área gráfica
usavam Macs e o resto convivia com os problemas do Windows.

O Linux surgiu de uma forma completamente despretensiosa, como o projeto
de um estudante Finlandês. Muitos sistemas são desenvolvidos como
projetos de conclusão de curso ou apenas por hobby. O que permitiu que o
Linux se transformasse no que é foi uma grande combinação de fatores e
alguma dose de sorte.

Tudo começou em 1983, pouco depois que a IBM lançou seu primeiro PC e a
Microsoft sua primeira versão do DOS. Richard Stallman criava a Free
Software Fundation, que ao longo da década produziu a licença GNU e toda
a base filosófica relacionada a ela e, mais importante, um conjunto de
ferramentas, como o editor Emacs e o compilador GCC.

O Emacs é um editor de texto que combina uma grande quantidade de
recursos e ferramentas úteis para programadores. O GCC é o compilador
que permite transformar o código escrito nele em arquivos executáveis. A
idéia era desenvolver um sistema operacional completo, mas para isso
faltava a peça principal: o Kernel.

Imagine o Kernel como o cérebro e o coração de um sistema operacional.
Ele sozinho não serve para nada, mas sem ele o resto do corpo também não
vai muito longe. Em 1991, a Free Software Fundation ainda estava dando
os primeiros passos no desenvolvimento do Hurd (que ainda hoje está
muito longe se ser concluído), enquanto o Linux de Linus Torvalds era
utilizável desde suas primeiras versões. O corpo encontrava o cérebro.

O fato do código fonte estar amplamente disponível e poder ser utilizado
de forma muito liberal permitiu que muitos desenvolvedores passassem a
trabalhar no sistema ainda em sua fase embrionária, adicionando novos
recursos num ritmo muito rápido. Mas, durante os primeiros anos, o Linux
ficou restrito a este círculo técnico, muito longe de ser usado em
larga escala.

Isso começou a mudar com o aparecimento da Internet. O Apache foi um dos
primeiros servidores web a ser lançado e tornou-se rapidamente o mais
usado numa época em que existiam poucos concorrentes à altura. O Apache
rodava em várias plataformas, mas o Linux tornou-se a opção mais comum,
por ser rápido e estável.

Pouco tempo depois veio o servidor Samba, que permitia compartilhar
arquivos numa rede Windows, de forma mais estável e mais barata que
usando um servidor Windows. Novamente, o Linux tornou-se a opção
preferida. Depois, vieram os bancos de dados e muitas outras aplicações,
mas todas tinham algo em comum: sempre falávamos de servidores.

Por volta do final de 1994 foi lançada a primeira versão for Linux do
Xfree. Ele é um "servidor gráfico", uma interface gráfica usada em
vários sistemas Unix. Antes do Xfree, 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. Em 2004, o
Xfree passou a ser gradualmente substituído pelo X.org.

Uma coisa interessante sobre o X é que ele fornece a fase para o
funcionamento da parte gráfica, incluindo o suporte à placa de vídeo e
mouse, mas não inclui a interface em si. Graças a isso, não existe uma
interface gráfica padrão como temos no Windows, por exemplo.

Existem no Linux várias interfaces diferentes, conhecidas como
gerenciadores de janelas. No início existiam muitas interfaces
diferentes, mas nenhuma chegava próxima
do nível de funcionalidade e integração que existe no Windows. Isto
mudou com o aparecimento do KDE (que é a interface usada por padrão em
diversas distribuições, incluindo o Mandriva, SuSE e o Kurumin) e mais
tarde tb c o Gnome.

[Tens de ter uma conta e sessão iniciada para poderes visualizar esta imagem]

Ainda por volta de 1994 começaram a surgir as primeiras distribuições
Linux, que eram um jeito mais "fácil" de instalar o sistema. Ao invés de
ficar compilando tudo, começando pelo Kernel e passando por todos os
aplicativos da Free Software Fundation, Xfree e o que mais você
pretendesse rodar, você simplesmente passava alguns dias editando
arquivos de configuração com a ajuda de alguns manuais mal escritos.
Para você ter uma idéia do tamanho da encrenca, uma das distribuições
consideradas mais "amigáveis" na época era o Slackware, ainda em suas
primeiras versões.

Se você é algum saudosista desta época em que "homens eram homens e
compilavam seus sistemas do zero", sinta-se livre para pesquisar no
Google sobre o "Linux from Scratch", um passo a passo (com muitos
passos...) que ensina como fazer isso. Pobres mortais como eu, possuem
coisas mais urgentes e menos chatas a fazer... ;-).

Uma distribuição é um conjunto com o Kernel e vários programas,
empacotado de forma que seja fácil de instalar e manter atualizado. Uma
das primeiras versões com foco na facilidade de uso foi o Red Hat, que
serviu de base para um grande número de distribuições, como o Mandrake,
SuSE e Conectiva.

O Red Hat trouxe uma idéia nova, que foi rapidamente adotada em todas as
outras distribuições: um sistema de gerenciamento de pacotes. Cada
programa incluído era transformado num pacote compactado, que podia ser
instalado através de um único comando. O sistema guardava as informações
dos pacotes instalados permitindo que você pudesse removê-los depois.
Não era tão amigável quanto clicar num executável e ter um instalador
gráfico e, existiam problemas com dependências (um pacote precisa do
outro, que precisa do outro, que precisa do outro...), mas já era muito
melhor que sair compilando as coisas na unha.

Por volta de 1997 já existiam um conjunto de distribuições relativamente
fáceis de usar, com sistemas de instalação relativamente simples, do
tipo que um técnico médio consegue seguir sozinho com a ajuda do manual.

Nesta época algumas empresas passaram a portar seus sistemas e utilizar o
Linux como uma forma de reduzir seus custos com licenciamento e
manutenção (imunidade a vírus, menos travamentos, menos reinstalações do
sistema; quem já usou o Windows 3.11 ou o 95 sabe do que estou
falando...). O Linux dava seus primeiros passos no desktop, mas ainda
existiam poucos aplicativos que rivalizassem em recursos e facilidade de
uso com os do Windows.

Nos anos seguintes houve um crescimento espantoso. Aquele sistema feio,
difícil de usar, famoso apenas por ser estável e bom para servidores
ganhou o KDE e o Gnome, finalmente duas interfaces bonitas e fáceis de
usar, ferramentas de configuração automática e um grande número de
aplicativos, incluindo compatibilidade com alguns programas e jogos do
Windows através do Wine, o que levou a um número cada vez maior de
desenvolvedores e usuários.

Ao contrário de um sistema comercial, com todo o planejamento e
estruturas envolvidas, o Linux é desenvolvido de forma descentralizada.
Qualquer um pode pegar o código de algum programa, adaptá-lo,
acrescentar novos recursos e transformá-lo em algo diferente do
original, com aplicações que o autor original não seria capaz de sequer
sonhar.

Isto cresce em escala geométrica, como uma bola de neve que vai
crescendo e passando por cima de quem se atrever a oferecer resistência.

A licença GPL, pode ser resumida em 4 direitos básicos e uma obrigação:

1- Você tem o direito de usar o programa para qualquer fim. Não existe
discriminação. Um exemplo é que ninguém pode impedir que um programa GPL
seja usado numa clínica de aborto ou numa instalação militar, por
exemplo.

2- Você tem o 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. A forma mais eficiente de ganhar dinheiro
com software livre é vender suporte e serviços de personalização sobre
os programas e distribuições que você domina. 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, pois
você pode 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
dos programas disponíveis 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 por 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 ou:

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 a 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.

5- Os softwares distribuídos sob a GPL 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 fechados na mesma edição. Os softwares GPL
continuam sendo GPL, com todas regras que vimos acima, enquanto os
softwares comerciais 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.


Um exemplo: desenvolvi o Kurumin usando como base dois projetos já
existentes, o Knoppix e o Debian. O Knoppix entrou com sistema de
detecção de hardware e configuração automática e o Debian com toda a
base do sistema, como os pacotes e ferramentas de administração como o
apt-get. Ao invés de ter que ficar compilando tudo, posso usar os
pacotes do Debian que já estão prontos; e, ao invés de ficar
desenvolvendo mais um ferramenta de detecção, posso usar o sistema do
Knoppix que funciona extremamente bem.

Como a parte funcional do sistema já está pronta, posso trabalhar
personalizando o sistema, desenvolvendo scripts de instalação,
ferramentas de configuração, adicionando novos recursos e corrigindo
problemas. Começo do ponto aonde os outros já chegaram, aproveitando
todo o esforço anterior.

Quando alguém desenvolve um projeto derivado, uma outra distribuição
Linux usando o Kurumin como base, como o Kalango ou o Dizinha, ganho
novamente, pois posso utilizar as correções e novos recursos adicionados
neles.

Muitas pessoas que utilizam o Kurumin acabam contribuindo com soluções
para problemas e melhorias diversas. Para eles é interessante fazer
isso, pois os problemas são resolvidos nas novas versões, evitando que
eles precisem ficar corrigindo manualmente os novos problemas
indefinidamente.

=====

Ententendo 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
idéia 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
idéia é que outros sistemas Unix, como o FreeBSD e o Solaris 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 idéia 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.

Esta é 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 comentes 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:

[Tens de ter uma conta e sessão iniciada para poderes visualizar esta imagem]

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 opçõ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:

[Tens de ter uma conta e sessão iniciada para poderes visualizar esta imagem]

Na maioria dos casos, os módulos possuem nomes que dão uma idéia 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 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 carregamentos dos módulos está
passando a ser feito de forma 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".

Em 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

Algumas distribuições oferecem uma opção de carregar módulos adicionais
durante a instalação, justamente pensando nos raros casos onde você
precisa de um determinado módulo para ativar a placa SCSI onde está
instalado o HD para poder prosseguir com a instalação, 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.