Um pouco sobre a história do 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 também com o Gnome.

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.